Financial infrastructure · walkthrough
AI agent execution authority in a bank credit workflow
An automated decisioning flow raises a customer's credit limit past the threshold where one approver is no longer enough. This page walks that one raise from the proposed write to the written limit, and says at each step what runs today, what is integration work, and what is not a claim at all.
The example is the credit-limit pattern on the financial-infrastructure page, at an illustrative threshold. No institution is named because none is a customer.
Six moments, one raise
Each step says what the operator sees, carries the status of that step, and links the document that owns the detail.
1The proposed write
Runs over the API todayA decisioning flow — an agent, or a scheduled system — proposes credit.limit.raise for one customer, at an amount past the threshold where one approver is no longer enough. It proposes; it cannot write.
Where this is written down: Agent-Safe Pipeline
2The trusted borrower and account context
Runs over the API todayWho the customer is, which account, what the limit is today and what the arrears and affordability position says come from the bank's own systems, attached at capture. The flow supplies only the action, the target and the parameters, and none of its own facts about the customer are taken as true.
Where this is written down: Trust boundary
3The policy owner
Runs over the API todayThe bank's written policy — A raise of €50,000 or more requires dual authority before the limit is written. — decides. Not a model, not the flow. Here the verdict is ESCALATE: the raise may not proceed on the flow's say-so, and the record of that evaluation is signed whether or not anyone goes on to approve it.
Where this is written down: Shadow mode first · Shadow mode in the reference implementation
4The named approval
Private betaA named person approves this exact raise, for this customer, at this amount. An approval that lives only in a screen is not authority: the approval is bound to the action and handed back to policy, which evaluates the same action again with it. The second named approver the policy asks for is expressed as a set of sign-offs in the banking profile and in the reference implementation; the hosted path carries one verified approval per evaluation.
Where this is written down: Presence · Presence evidence
5The grant claim
Private betaOnly an allow carries the authority to execute, once, for this exact action, for a short time. The component that writes the limit claims it immediately before the write, and a claimed authority cannot be presented again. Placing that claim inline on a bank's own transaction path is integration work, in private beta.
Where this is written down: How execution authority is evidenced · The agent authorization reference · What a bank deploys in front of its core system
6The downstream result
Runs over the API todayThe limit is written and the record says so. If the core system goes quiet after the write was sent, the attempt is recorded as not known and is reconciled by looking, never by sending it again; a new attempt needs a new decision. The record — the Decision Dossier — is evidence of what was decided and what happened; it is never the thing presented to execute.
Where this is written down: Execution outcomes · Evidence, not authority
The chain the hub draws for this pattern: Decisioning flow → credit.limit.raise €50,000+ → Decionis → ESCALATE → Two named approvers → Limit written, dossier signed.
What you can evaluate now, and what you cannot yet
A bank engineer is entitled to know which of the six steps they can run this afternoon.
What you can evaluate now
- Policy evaluation against the signals you supply, a signed Decision Dossier behind every verdict, and shadow mode first — recording what the gate would have done without enforcing anything.
- The reference implementation, on your laptop: capture, evaluate, approve, claim once, execute once, against a fixture authority and synthetic policy.
- The banking profile's runnable examples: a credit decision and three disbursements, with the attacks they turn away, against a made-up core system.
What is integration work
- Attaching the bank's own customer, account, limit, arrears and affordability facts at capture.
- Putting the claim inline on the transaction path in front of the core system.
- Isolating the component that writes the limit, and keeping the core system's credentials behind it.
What is not a deployed-bank claim
- Inline authorization on the transaction path. Phase one replays your historical authorization logs offline and returns a prevented-loss report, so nothing sensitive leaves your systems to find out whether the gate is worth having.
- Nothing on this page says a bank's production credit path is enforced today, and nothing here validates a credit decision.
What to ask for before you start
The evidence a bank can request before allowing an agent anywhere near a credit workflow, and which party owes each piece. Every row links what exists; none of it is a deployed-bank claim.
The exact contract the gate speaks
The published OpenAPI specification: what is sent to evaluate, bind, claim and finalize, and what comes back.
Proof that a grant is claimed once and an unknown outcome is never retried on its own
The reference implementation's tests and self-checking demos at the published version, run in its CI on every commit.
Which controls the library does not supply
The trust boundary and the accepted-risks table: executor isolation, agent egress, credential scoping and incident response are the bank's.
A signed record for every decision, verifiable without an account
The Decision Dossier: retrieve it, verify it against the published key, and see why a dossier identifier is never the thing presented to execute.
How a bank writes the instruction down and who signs it
Banking Execution Authority Profile, BEAP v1.0 — Published. A published version is never edited; what banks send back shapes the next.
How a bank gets from a test to a deployment
The profile's get-started path: try it, run it on a laptop, watch it in shadow beside one workflow, bind the sign-offs, then enforce. Its deploy page has the process a bank runs in front of its core system and two kits, with every host and credential the bank's to supply.
What the platform runs today, and what it does not yet
Policy evaluation against the signals you supply, a signed Decision Dossier behind every verdict, and shadow mode first — recording what the gate would have done without enforcing anything. Inline authorization on the transaction path is in private beta.
The full index — what each artefact establishes, what it does not, and who owns which control — is the evidence index.
In banking terms
The Banking Execution Authority Profile (BEAP) says the same moment in a bank's own words — How a Finance Control Evaluation finds where your financial operations create control exposure, in your own figures, and how the same rules then govern a payment run, a transfer, a correction, or a limit change before it reaches your core banking, payments, treasury, or lending system — at banking.decionis.com. BEAP v1.0 · Published. Not a standard approved by any body.
The execution boundary itself is implemented in the open as the Agent-Safe Pipeline (Apache-2.0 · v0.1.4): Open reference implementation of exact-action authorization, lifecycle enforcement and audit evidence for agent pipelines. A bank walkthrough of the same shape is in its remote authorization sequence.
What runs today, and what does not
Runs over the API today
Policy evaluation against the signals you supply, a signed Decision Dossier behind every verdict, and shadow mode first — recording what the gate would have done without enforcing anything.
Private beta
Inline authorization on the transaction path. Phase one replays your historical authorization logs offline and returns a prevented-loss report, so nothing sensitive leaves your systems to find out whether the gate is worth having.
Not replaced, not bypassed
Decionis does not stand in for your payment rail, core system, identity provider or fraud stack. It answers the one question none of them is built to answer, and hands the verdict back.