Documentation
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.
Everything published here is the draft itself and the files that go with it. Version 0.1, dated 2026-09-11, is out for review and can still change.
The draft
Twenty-six sections and four appendices. Every rule that can be tested carries an identifier you can quote back at us, and every section and rule has its own link.
Where to start
| If | Start at | Why there |
|---|---|---|
| You run payment or lending operations | Read sections 1 to 5, then section 16 on sign-offs and section 17 on payment runs. | Those are the parts that describe your week. |
| You are an engineer who has to build it | Read sections 9, 10, and 14 first, then 19 and 20. | Everything else hangs off how the instruction is written down and what a grant allows. |
| You audit or assure this | Read section 22 on evidence, then section 25 on what the draft does not prevent. | Both say what you can and cannot conclude from a record. |
| You are deciding whether to adopt it | Read section 24 on the three levels, then the worked examples. | Each level is a step you can take without the next one. |
The list of rules
Every numbered rule, generated from the document itself so it cannot drift from the text. An implementation can hand you the identifiers it meets instead of a paragraph claiming it does.
File formats
What each kind of file must contain, so two systems can exchange them. Each one identifies itself by its address here.
- What an instruction must contain
- What a payment run must contain
- What the record of one attempt must contain
- What a payment run's settlement record must contain
- What one payment's outcome inside a run must contain
- What a set of sign-offs must contain
- What an authority to execute must contain
- What an auditor's extract must contain
Fixed lists
Names the draft fixes, so two banks use the same word for the same thing.
- The banking areas
- The actions, and what each one affects
- The reasons an outcome is recorded with
- How an outcome is described
- Where evidence comes from
- How an effect is observed
Filled-in examples
One valid instance of each file format, with made-up customers, accounts, and approvers. The fastest way to see what a file looks like before you build one.
- A loan disbursement instruction, filled in
- A payment run release instruction, filled in
- A payment run, line by line
- A set of sign-offs from two approvers
- An authority to execute one disbursement
- The record of one disbursement attempt
- The record of a disbursement attempt whose answer never came back
- A payment run's settlement record
- One payment's outcome inside a run
- An auditor's extract
For assistants and agents
An assistant reads llms.txt and llms-full.txt. An agent with tools reads the same files, checks a document against them, and takes the fingerprint a sign-off binds to, through the server described in mcp.json. That server decides nothing: whether an instruction goes out is never its call.
What each outcome is recorded as
The demonstration on the front page puts 7 things someone in a bank could do to a signed payment run through the same boundary. 6 are turned away, some because the run no longer matches what was signed and others because the sign-offs it carries are not the ones the mandate asks for. The rest are not turned away at all: the hub never answers, so nobody knows whether the money moved, and that is recorded as its own outcome rather than as a refusal or a success. Each is recorded against a fixed reason and the rules it demonstrates, which is what an auditor and a second implementation both read.
| What changes | What happens | Why | Recorded as |
|---|---|---|---|
| One line's amount is raised after everyone has signed. | Refused | Changing a line changes the run the approvals were given for. The approvals stay attached to the run that was reviewed, not to this one, so a fresh decision is needed before anything can go out. | AUTHORITY_SET_INTENT_MISMATCHBATCH_MANIFEST_MISMATCHBATCH_SOURCE_FILE_MISMATCHBATCH_TOTALS_MISMATCHPOLICY_DENIEDBEAP-L2-BAT-10BEAP-L2-MPA-04 |
| One line keeps its amount but is redirected to another account. | Refused | The account each payment goes to is part of what was approved, held as a digest rather than in the clear. Redirect a line and the run stops matching what the signatories saw. | AUTHORITY_SET_INTENT_MISMATCHBATCH_MANIFEST_MISMATCHBATCH_SOURCE_FILE_MISMATCHPOLICY_DENIEDBEAP-L2-BAT-04BEAP-L2-BAT-07 |
| A payment nobody reviewed is appended to the file. | Refused | The count and the total the signatories approved are part of the run. An extra line changes both, and the approvals do not carry over to a run that is no longer the one they saw. | AUTHORITY_SET_INTENT_MISMATCHBATCH_ITEM_COUNT_MISMATCHBATCH_MANIFEST_MISMATCHBATCH_SOURCE_FILE_MISMATCHBATCH_TOTALS_MISMATCHPOLICY_DENIEDBEAP-L2-BAT-09BEAP-L2-BAT-08 |
| The maker signs a second time in the checker's place. | Needs another sign-off | The second sign-off is refused because it is the same person, so the run is still a signature short. No authority is issued while a required sign-off is missing. There is nothing to claim, so nothing reaches the hub. | AUTHORIZED_SIGNATORY_REQUIREDMAKER_CHECKER_REQUIREDSEPARATION_OF_DUTIES_VIOLATEDBEAP-L2-MPA-03BEAP-L2-MPA-05BEAP-L2-MPA-06 |
| The run is released with the maker, the checker, and one signatory, before the second has signed. | Needs another sign-off | A run of this size needs both mandated signatories, and the chain is not finished until the second has signed the same run. Nothing is issued and nothing can be claimed until then. | AUTHORITY_SET_NOT_SATISFIEDAUTHORIZED_SIGNATORY_REQUIREDMAKER_CHECKER_REQUIREDBEAP-L2-MPA-03BEAP-L2-GRT-06 |
| The same approval is used to release the run a second time. | Refused | An approval authorises one release. The first attempt consumed it, so the second has nothing to present, and the account is debited once. | AUTHORIZATION_INVALIDBEAP-L3-CLM-02BEAP-L3-CLM-04 |
| The run is submitted and the hub's response never arrives. | Outcome not known | An attempt whose outcome cannot be established is left open and is never sent again on its own. Reconciliation asks the hub what happened, and only then can anything further be authorised. | INDETERMINATE_OUTCOMEBEAP-L3-EFF-11BEAP-L3-CLM-06 |
The records one instruction leaves behind
A summary that says the record of a decision was turned into an authority to send, or that a sign-off is itself that authority, has the order wrong. The authority is issued on an allow, claimed once by the component in front of the core system, and spent; the records say what was allowed and what happened. Each step below names the filled-in example that shows the record.
- Issued. When the rules allow, one authority to execute is issued for this exact instruction, for a short time. Nothing is issued when the answer is to escalate or to refuse, and nothing is issued by an evaluation that only watches. An authority to execute one disbursement
- Claimed once. The component in front of the core system claims that authority immediately before it sends, and checks that what it is about to send is still what was authorized. A claimed authority does not authorize a second send. An authority to execute one disbursement
- What came back. The instruction went out once and the core system answered. What it did is recorded as its own record, separate from the permission to do it: an accepted request is not yet a moved balance. The record of one disbursement attempt
- The answer never came. The instruction went out and the core system went quiet. The attempt is recorded as not known, the authority stays spent, and nothing is sent again on its own: someone looks, read-only, before anyone decides anything. The record of a disbursement attempt whose answer never came back
- The auditor's extract. A month later, the extract says who allowed the instruction, what they were shown, what went out, and what came back. It is a record of what was allowed and what happened; it cannot be presented to send anything. An auditor's extract
Checking an implementation
The three levels say what each step requires and how to test it. The worked examples run end to end and turn away a list of attacks, so you can see the rules doing something rather than take our word for it.
Who builds what, and what is still open
The component in front of the core system is not written twice. It builds on the Agent-Safe Pipeline, the open-source component that claims the grant, sends the instruction once, keeps the credential on its own side, and records what came back (Apache-2.0, version 0.1.4, pinned exactly; checked 2026-09-12).
- What this profile adds. Sets of sign-offs from several people, bound to one fingerprint. A payment run bound to its lines. The record of what came back, including an attempt whose answer never came. One set of rules per banking area, all made up, and two runnable examples that turn away the attacks listed on the examples page.
- What a bank builds. The rules, in its own words. The component in front of its core system. Keeping the agent from reaching the core system, or any credential, another way.
- What is still open. The approval step underneath carries one verified sign-off per evaluation, so a chain of several sign-offs is this profile's set, presented as evidence of the same fingerprint. A confirmed effect is this profile's statement from its own record until the hosted platform accepts an observer for it. What the Decionis platform runs today for financial infrastructure is stated on its own page; this page does not restate it.
Telling us it is wrong
The review guide says how to hold the draft against your own sign-offs. Write to beap@decionis.com with the version and date you read.