Execution domain
Put deterministic authority between financial intent and commit — without replacing the payment rail, the core system, the identity provider or the fraud stack.
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 disbursement, a payment run, or a limit increase gets authority before it reaches your core banking, payments, 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 design-partner ladder starts offline, on your own historical data, and only reaches the transaction path once the verdicts have earned it.
See the pilot phases