Every consequential banking action executes exactly as approved.

What goes wrong today

The problem is not whether the workflow has controls. It is whether the action that executed was covered by them.

Most banks already have four eyes on the payment run. The awkward question is narrower: for one exact payment, can you show who authorised it, what they were looking at, and that the control fired on the path the money actually took.

Every outcome, written out

The same refusals the run shows one at a time, in full. Each verdict, reason code, and rule is one this repository produces.

Each refusal is recorded against a fixed reason, so an auditor reads the same thing the operator saw. The same cases run for real in the repository, against a synthetic hub, and the demonstration exits with an error if any of them gets through. See what the examples cover, or how each refusal is recorded.

Each area has its own chain of approval, and its own line no sign-off crosses

Who has to sign changes with the area and with the amount. So does the set of things that collecting more signatures will never resolve. Four areas, written as the rules in this repository are written.

The lower half of each card is the part a workflow tool finds hard. A gate is not a shortage of approvals, so gathering more of them does not open it. A screening hit is not answered by a second approver, and a run that no longer reproduces from the file it arrived in is not made to match by a third. Ordering the rules the other way round is the common mistake: put the approvals above the gates and four eyes sign straight past a sanctions hit.

One execution boundary. Your rules change by banking area.

Your workflow remains yours. Your core remains your core. What sits between them is the decision about whether this exact action may execute, and the evidence of what happened when it did.

How it fits

Decionis does not carry out the banking action. It decides whether the action has authority to be carried out.

YOUR CHANNELS
Agent · App · Employee · Batch
            |
            v
       PROPOSE ACTION
            |
            v
+-----------------------------+
| DECIONIS EXECUTION AUTHORITY|
|                             |
| Rules -> Authority -> Evidence
+-----------------------------+
            |
     +------+-------+
     v      v       v
   ALLOW ESCALATE BLOCK
     |      |
     |   Approvers
     |      |
     +---+--+
         v
   EXECUTION BOUNDARY
         |
         v
YOUR BANKING SYSTEMS
Core · Payment Hub · Lending · Ledger

Approval should authorise an action, not a document that once described it

TODAY

Payment file
    |
    v
Approval  ok
    |
    v
changes / handoffs / middleware
    |
    v
Core executes
    |
    v
Audit reconstructs what happened

WITH DECIONIS

Exact payment
    |
    v
Approval
    |
    +----- bound together -----+
                               v
                   what the sign-off covers
                               |
                               v
                  checked again before sending
                               |
                               v
                        Core executes
                               |
                               v
                    record of what happened

A sign-off that lives only in a screen is not a control when another route can post straight through. Binding the approval to the action closes that gap, and it is the reason an edited run stops matching.

The hub accepted it is not the same as the money moved

1. Policy checked, one-time authority issuedALLOWED
2. Authority claimed once, run released onceCLAIMED ONCE
3. Hub acknowledges: accepted at the boundaryACCEPTED
4. No answer comes back; the bank cannot prove what happenedUNPROVEN
5. Someone retries with the same authorityREFUSED
6. Reconciliation reads the core by the same reference
7. The posting matches the beneficiary, amount, and currencyCONFIRMED
8. The uncertain record stays; the beneficiary was paid once

When the result is uncertain, the attempt is recorded as uncertain and reconciled before anything further can be authorised. The operational point is plain: nobody pays twice because a timeout looked like a failure.

None of this is new ground

Supervisors have already written about keeping the people who enter and approve a payment apart, about authentication that covers staff and service accounts, and about proving how a firm handles failure. Links checked 2026-09-11.

Whether any of it applies to your bank is your compliance team's call, not ours. The draft does not interpret regulation and does not claim to satisfy any of it.

The control model is open for review

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.

The Banking Execution Authority Profile defines how all of this is expressed so that two systems can agree: the banking areas, binding an action exactly, sign-offs from several people, single-use authority, and evidence of the effect. Reading it is the fastest way to judge whether it fits your bank.

Read BEAP v0.1DocumentationWhat adoption takes

Bring us one consequential banking workflow

We will map the action, the rules you already apply, the sign-offs, and where execution actually happens, with your team.

Pressure-test your workflowWrite to beap@decionis.com

Please bring made-up values. Real customer data, real policies, and credentials do not belong in a review.