Loading…
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
Built with design partnersA 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
Built with design partnersOnly 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 the work done with design partners.
Where this is written down: How execution authority is evidenced · The agent authorization reference
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.
- Design partners are not customers and not pilots.
- Nothing on this page says a bank's production credit path is enforced today, and nothing here validates a credit decision.
In banking terms
The Banking Execution Authority Profile (BEAP) says the same moment in a bank's own words — How a disbursement, a payment run, or a limit increase gets authority before it reaches your core banking, payments, or lending system — at banking.decionis.com. BEAP v0.1 · Draft / Design Partner Review. Not a finished standard.
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.
Built with design partners
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.