See where financial operations are creating control exposure, using your own numbers.

Your data+Your policies=Quantified control exposure

Four domains of control exposure

For banks and financial firms whose operating state changes faster than post-event controls and periodic reporting can follow. Not because a control is missing, but because the action that executed was not covered by it.

Each one maps onto banking areas whose rules already exist in this repository, written as a bank writes them: who has to sign, with what evidence, and what no signature gets past. Where your month has a moment none of them describes, that is the first thing to tell us.

From your history to one boundary

Five steps, read-only, and none of them changes how your bank works before you have seen what your own controls would have said.

1. 1

   Connect, read-only

   Hand over an extract of up to ninety days of the actions your systems already carried out: payment files, instructions, transfers, corrections, limit and rate changes. Nothing connects to a live system and nothing is executed.

2. 2

   Replay ninety days

   Each action is written down in one agreed form and replayed against controls you author, at the moment it happened, with the facts your systems reported then and the sign-offs they recorded then.

3. 3

   Quantify exposure

   See which actions would have gone through, which needed a sign-off they never had, which would have been refused, and the money on each, by domain, by banking area and by the rule that held it.

4. 4

   Review findings

   With your team: the refusals you disagree with, the thresholds and roles to tune, and the facts the rules needed that your systems did not have at that moment. That last list is the integration work, and this is where it shows itself first.

5. 5

   Select one boundary

   Pick one action a person can name. Put the component beside it, in shadow, and let the comparison run before anything is enforced.

The same evaluation runs on a laptop over ninety made-up days, and takes an extract of your own actions in the same form, so the first figures you see are yours. What the runnable examples cover.

The Control Exposure Report

Ninety made-up days of one bank's finance operations, evaluated by this repository's own rules; every figure is what that run produced, and none says anything about any bank.

Your figures will look nothing like these, and no figure on this site is a benchmark. What carries over is the shape: every action answered, the sign-offs the rules asked for against the ones actually given, the money on the actions that needed another decision, and the facts the rules needed that your systems did not have at that moment. A test re-runs the made-up ninety days and fails if this page and the run disagree.

Existing finance systems continue to run. Decionis decides whether the exact action is authorised.

Decionis sits after the business context is known and before a consequential action commits. It does not carry out the action, and it does not replace the core, the reconciliation, the treasury or the valuation system that produced the context.

YOUR CHANNELS
Agent · App · Employee · Batch · Scheduled job
            |
            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 · Treasury · Reconciliation
Lending · ERP and finance · Ledger
         |
         v
DECISION RECORD
for audit, risk and compliance

• AllowThe action goes ahead in your existing systems, once, exactly as it was checked.
• EscalateThe action waits for the sign-off the rules name, from a person the rules name, bound to this exact instruction.
• BlockThe action is refused, with the rule and the reason recorded, and no number of signatures changes that.

Every decision leaves a record for audit, risk, and compliance: who allowed this exact 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.

Finance signals can inform authority

Your systems already produce the facts a rule needs. Decionis computes none of them; the rules read what was reported, and a fact that was not reported is counted, never assumed. Six questions, and what the rules in this repository read for each today.

Cash at bank reconciled?

The treasury rules read the reconciliation state of the position the money leaves. A movement out of an unreconciled position goes back to treasury operations, and no signature stands in for the reconciliation.

Open reconciliation break?

The same state, with a name. A break open against the account sends the movement back the same way, a correcting entry included.

Current asset value available?

A write-down or a concession is refused unless the exposure snapshot it relies on reproduces from the ledger, and a limit change reads the exposure it would leave. A valuation your rules need that no system reports is counted as a fact the rules could not see, never assumed.

Payment within limit?

The desk limit, the mandate's daily limit, the four-eyes ceiling and the account's counter authority are read from the services that own them. A breach is a refusal, not a request for another signature.

Counterparty and screening clear?

Screening, beneficiary confirmation, the standing settlement instructions and the trade match are read from the systems that own them. A hit or a mismatch refuses at any sign-off count.

Correct execution window?

The settlement calendar and the cut-off clock. A closed window refuses; past the cut-off, the operations head decides.

You define authority. Decionis makes it executable.

Nothing here asks you to trust Decionis to decide how your bank should operate. You write the policy; Decionis binds it to the exact action and holds the boundary.

• You author the policy
• Credentials stay behind the trusted executor
• Verified human approval when required
• Signed decision records
• Your systems remain the systems of record

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 at the top 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.

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

Cash at bank is a question about what actually happened, not about what was sent. The record keeps the two apart.

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, and nobody reports a balance the core has not confirmed.

Start with evidence. Define production scope after you have seen your own exposure.

1. 1

   Finance Control Evaluation

   Up to ninety days of the actions your systems already carried out, replayed against controls you author, read-only. The result is a Control Exposure Report in your own figures.

   How the evaluation works
2. 2

   Shadow validation

   The selected workflow runs in parallel with the component beside it. Nothing in production changes while the thresholds, the signals, the roles and the escalations are confirmed against what actually happens.

   What shadow takes
3. 3

   One production boundary

   One agreed consequential workflow moves to enforcement while your existing systems stay in place and stay the systems of record.

   The three steps, checkable
4. 4

   Scale by proven value

   Expand only where the first workflow showed operational or economic value: the next action, the next area, the next entity.

   What a bank deploys

Success is one workflow and one measurable control problem. Each step is worth something on its own, and you can stop after any of them. Write your stopping criteria before you start, as sentences someone can check; nothing on this site gives you a figure to borrow. What production costs is defined with each bank from the workflows governed, how the component is deployed, and the decision volume; the platform states its plans once, on its own pages, and Get started says where.

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 profile does not interpret regulation and does not claim to satisfy any of it.

The control model is open for review

BEAP v1.0 · PublishedDated 2026-09-15. A published version is never edited; corrections appear in the next. The profile Decionis publishes and implements, not a standard approved by any body.

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 v1.0DocumentationWhat 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, and run the Finance Control Evaluation over your ninety days first.

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.