Hold it against the sign-offs you actually run

BEAP v0.1 · Draft / Design Partner ReviewDated 2026-09-11. A draft the banks reviewing it can still change. Not a finished standard, and it may change before v1.0.

v0.1 is out now, while it can still change, so banks can test it against real work instead of reading it once it is fixed. A design partner here is a bank reviewing a draft document. The platform runs a separate program for teams putting a gate in front of real execution; that one is described on the platform's own page.

What we are asking

Not whether the document reads well. Whether it can describe the moments your bank already treats as the point of no return, in your words, and whether the evidence it asks for is evidence your systems can actually hand you.

How to go through it

1. Pick one area, say disbursements or the daily payment run. List the moments after which you cannot simply undo it. Ignore everything you can reverse; that is not what this covers.
2. For each one, write down who signs today, what they are actually signing over, and how you would prove a month later that what went out is what they signed.
3. Map each one onto an instruction and an area in the draft. Where something you need has nowhere to go, that is a gap in the draft, not in your process.
4. Check the multi-signature part against your real mandate: who must be kept apart, what delegation you allow, and what happens when an approval goes stale.
5. Check the evidence part against what your core system and your hub actually return. If all you get is an acknowledgement, the draft will say the payment is not confirmed, and you should decide whether you can live with that.

What is most useful to hear

• A moment of no return the draft cannot describe.
• A sign-off structure it gets wrong.
• A way you handle payment files that the fingerprint rule would break.
• A system whose response does not fit any of the evidence kinds listed.
• A data-protection rule the draft either breaks or fails to satisfy.

Sending it back

Write to beap@decionis.com and say which version and date you read; this page describes v0.1. Please do not send policies, credentials, production data, or anything covered by an agreement with a supplier. The shape of the workflow is enough, and it is all the draft needs.

What happens next

What comes back from this round decides what changes before v1.0. Until the document is frozen, we will not describe it as settled, and we will not describe any bank as meeting it, because there is not yet a fixed thing to meet.