Execution Authority for financial infrastructure
Decouple your AI reasoning engine from your actual systems of record. Instantly identify where your credit or reporting pipelines leak execution authority, refuse any movement whose inputs changed after approval, and enforce human approval that is cryptographically bound to the exact action.
Step 1 of 3: Map the agent's data ingest
Real-time threat assumption: awaiting the authority boundary
Map the data the agent reads, then set how far it can act.
Exposure not yet quantified
Answer the next question to see what the agent can change without approval.
Target runtime architecture requirement
Deploy a Decionis EffectAdapter to convert this pipeline into immutable Agent-Safe Intents. Each action's parameters are hashed at capture, and a single-use grant bound to that hash is claimed before anything executes: change one input and the grant is refused.
Built from your answers. Nothing here connects to your systems.
Every institution already runs the first three. The gap is not a missing control — it is a question nobody owns.
Who is acting?
Your IdP authenticates the human, the service account or the agent making the request.
Does this look suspicious?
Your scoring models weigh the transaction against patterns and return a probability.
Can it reach the payment rail?
Your gateways and network controls decide what the caller is permitted to connect to.
Does this exact transaction have authority to execute?
A deterministic verdict against written policy, bound to the specific action, before commit.
Specific decisions with specific policy shapes — not a catalogue of everything a bank could theoretically gate.
payment.releaseA treasury agent or scheduled system moves to release €250,000. The delegated authority attached to that actor stops at €100,000.
Policy: Release above delegated authority requires a named human with treasury authority to approve on their own device.
credit.limit.raiseAn automated decisioning flow raises a customer's credit limit past the threshold where one approver is no longer enough.
Policy: A raise of €50,000 or more requires dual authority before the limit is written.
deploy.productionAn engineer — or an agent authoring the pull request — moves to deploy core-banking.payment-service to production.
Policy: A material change to payment infrastructure requires change approval, production authority and the exact artifact digest.
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. 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.
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.
Running a card program? Card-lifecycle gating — create card, raise limit, merchant lock — has its own page: Execution Authority for card programs.
Where this is written down and built in the open: the banking profile of the protocol — 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 — is published as BEAP v1.0, a Published document, at banking.decionis.com; the execution boundary is implemented as the Agent-Safe Pipeline (Apache-2.0 · v0.1.4); and the evidence index says which control belongs to which of them. Bank lending? The profile's underwriting guide says what an underwriting agent may propose on its own, who signs the credit decision, and what is recorded — and nothing about whether the decision was right.
How a bank gets from a test to a gate in front of its core system — try it, run it on a laptop, watch it in shadow beside one workflow it runs today, bind the sign-offs, then enforce — is the profile's get-started path. What it deploys — one process in front of the core system, with a kit for a core banking system and one for a lending rail, shadow first — is on its deploy page. Every host, credential and threshold in those kits is the bank's to supply; nothing there has run against a vendor system.
The rollout starts offline, on your own historical data, and only reaches the transaction path once the verdicts have earned it.
See the rollout phases