--- title: "Core-banking mandate authority for AI agents — KYE Protocol™" description: "A tangible walk-through for core-banking teams: an AI banking agent about to post a ledger entry against a mandate that already expired — refused at the action boundary and sealed as a receipt you can replay. Built for core-banking platforms." url: https://kyeprotocol.com/solutions/core-banking-mandate-authority/ lang: en source: "KYE Protocol" --- > A tangible walk-through for core-banking teams: an AI banking agent about to post a ledger entry against a mandate that already expired — refused at the action boundary and sealed as a receipt you can replay. Built for core-banking platforms. For core-banking teams # An AI agent tried to post a ledger entry against a mandate that had already expired. KYE™ refused it. Built for a platform like yours. Your data-defined core carries AI banking agents that create accounts, move balances and post to the ledger. KYE Protocol™ checks the governing mandate at the moment of posting — and refuses any entry against a mandate that has lapsed, been revoked, or never covered this action. Each refusal is sealed as a receipt your auditor can replay, so a reconciliation query drops from days to minutes. [Book a 20-minute walk-through](https://kyeprotocol.com/book-a-demo/) [Authority Finality™](https://kyeprotocol.com/authority-finality/) **AI banking agent** post entry · mandate #M-88 **KYE™** mandate validity check ### Refused mandate expired · signed ### Admitted mandate valid · signed **Stopped before the ledger moves.** The posting is refused because the governing mandate had already expired — and the refusal is signed and verifiable, so you can prove to the bank and the auditor that authority held at the moment of the act. That refusal, sealed REFUSED · MANDATE\_EXPIRED `kye:evidence:7c4e…` [Replay & verify →](https://kyeprotocol.com/evidence-pack-demo/) 1 · What KYE™ ™ governs in your stack ## You keep your platform. KYE™ governs the mandate boundary. Your platform already runs the accounts, balances and ledger of a bank in real time. KYE Protocol™ adds the one check an AI agent makes it urgent to enforce: at the moment of a consequential posting, is there a live, valid mandate that authorises exactly this action? - **Ledger posting** — an entry is admitted only when a current mandate authorises this actor, action and amount; a posting against an expired or revoked mandate is refused, not forced through. - **Account lifecycle** — opening, freezing or closing an account is admitted only within the delegated authority for that operation — an out-of-scope lifecycle action is refused and escalated. - **Every act sealed** — admit or refuse, the decision packs an [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) and a Replay-Proof™ verifiable from public keys alone — your reconciliation and audit file, built as it happens. 2 · The honest boundary ## KYE™ proves the basis — it does not keep the ledger. This is a governance layer, not a core-banking system. KYE Protocol™ does not hold balances, own the ledger of record, or stand in for your core system. It checks the governing mandate at the action boundary, admits or refuses, and seals the proof. An entry outside the agent’s mandate is refused and routed to a human step-up — the refusal is itself evidence. See how the delegation chain is drawn on the [authority diagram](https://kyeprotocol.com/authority-diagram/), then walk a sealed decision on the [Evidence Pack™ demo](https://kyeprotocol.com/evidence-pack-demo/). 3 · See it on your own flow ## Seeing is believing. Bring one real flow. In a 20-minute walk-through we take one of your live flows — a ledger posting, an account lifecycle event, a bulk mandate run — and show the AI action refused or admitted against the governing mandate, then hand you the sealed receipt to replay yourself. No credentials to share: the proof verifies against a public key set, the same runtime enforcement KYE Protocol™ uses to govern itself. [Book a 20-minute walk-through](https://kyeprotocol.com/book-a-demo/) [Replay a sealed decision](https://kyeprotocol.com/evidence-pack-demo/) Related ## Go deeper on core-banking authority. - [**Authority Finality™**](https://kyeprotocol.com/authority-finality/) — why a consequential action must reach signed closure under the authority that existed then. - [**Authority diagram**](https://kyeprotocol.com/authority-diagram/) — how the mandate and delegation chain are drawn and checked. - [**Evidence Pack™ demo**](https://kyeprotocol.com/evidence-pack-demo/) — replay a sealed decision and verify it from public keys alone. This page is an illustrative sector walk-through for core-banking teams; it shows how KYE Protocol™ would govern such a stack and does not describe or imply an existing deployment or commercial relationship with any named platform or vendor. Canonical KYE™ surfaces referenced on this page: [KYE Protocol™](https://kyeprotocol.com/).