How it works

Identity is not authority. Knowing who an AI agent is tells you nothing about what it may do, and the whole history of payment fraud lives in that gap. Agent Passport closes it on the bank's side: a registered provider, a product the bank approved, a mandate the customer signed, and a check on every payment before a penny moves. Every link in that chain can only narrow what the AI agent may do, never widen it.

APS 1001, the proposed standard (PDF) specifies the passport, the register filing, the bank's admission, issuance at signing and the nine-step verification. This site is its reference implementation.

Three layers and a check

The bank registers the AI product
Once. The bank records what the provider supplied: provider identity, an accountable principal with a signed declaration, insurance, the payment intent the product is filed for, its UK data protection declaration (UK GDPR and the Data Protection Act 2018, ICO registration, how long personal data is kept), and Independent Assurance Evidence for the product's use case. Completeness checks F.1 to F.7 run and are recorded with a signed receipt. Registration records accountability; it does not certify that the product is good.
The bank approves the product for its list
Once. A named officer decides whether the bank's customers may delegate payments to the product, sets the ceilings every mandate must sit within, and a hold condition. A commercial risk decision, assisted by a deterministic review tool that never decides. A "Bank approved" product is approved by that bank alone; no regulator is involved.
The customer signs the mandate in its bank account
Once, inside its own banking app: a product from the bank's list, a key pair for the deployment, and a mandate saying which accounts may be paid, how much and until when. The mandate is the consent artefact. The passport is issued at signing.
The bank checks every payment
Nine ordered checks, hold by default, no model in the loop, a signed receipt either way. A manipulated invoice fails at the payee check whatever it says, and nothing is refused outright: a failed check holds the instruction for a person, who approves or declines it with a written note. Trust is graduated: a person signs the mandate, a person confirms the first payment under it, a person decides anything above the bank's hold condition, and payments inside the mandate between those points flow on their own.
The evidence trail, as the bank's Activity
Every event hash-chained and replayable. Instructions held for review reach the bank's risk team as alerts and incidents. A supervisor can request the evidence for an incident through normal supervisory processes; it never has to operate the system to reconstruct what happened.

Who answers for what

The provider answers for the accuracy of what it declared to the bank and carries the insurance it declared. The bank answers for registering the product, for its approval decision and for executing without checking. The customer answers for the mandate it signed and for its deployment of the AI agent. The register holds the identities that make any failure attributable. The supervisor holds none of the infrastructure and can still reconstruct any incident from the evidence.

In plain terms. The bank gets a checkpoint that holds out-of-mandate AI agent payments for a person and a signed record that limits its reimbursement exposure. The business customer gets AI agents that can pay its suppliers without being able to pay anyone else. The supervisor gets complete, consistent evidence per incident without operating anything.

Where this sits in UK policy

HM Treasury's consultation Modernising Payment Services Regulation (published 14 July 2026, closing 6 October 2026) says in section 3.2 that the Payment Services Regulations 2017 were designed before AI and may not fully facilitate agentic payments. Question 15 asks how authentication, consent and liability provisions should adapt. This prototype is one working answer. The passport authenticates the AI agent and binds it to a registered product and an admitted deployment. The signed mandate is the customer's consent, expressed as an OAuth 2.0 Rich Authorization Request. The evidence trail is the liability record: who was permitted to do what, what was attempted, and what the bank did.

The consultation's Open Banking chapter describes the governance model we propose: a not-for-profit Future Entity sets common standards, industry adopts them voluntarily through commercial schemes, and the FCA sets guardrails, receives information and can intervene, without building or approving the technology. Government expects commercial incentives, not mandates, to drive adoption. APS 1001 is written as a candidate standard for such a body, on the precedent of the Open Banking Implementation Entity established under the CMA Order.

The FCA's AI Lab runs the Supercharged Sandbox. Its second cohort (July to December 2026, 21 firms selected from 199 applications) names agentic payments as a priority focus, with NayaOne, NVIDIA and Anthropic among its partners. The FCA's stated approach is to rely on existing frameworks and use practical experimentation to inform future supervisory expectations. That is our intended testing route: the FCA AI Lab is a natural testing environment for this evidence model. We say that as our intention; it implies no FCA involvement or endorsement. The sandbox tests designs; it does not approve products, and neither does anything in this prototype.

Authorised push payment fraud reached £576 million in the UK last year, up 19%, and since 2024 the sending bank reimburses most of it. That is the commercial reason a bank would adopt this before anyone asked it to.

Who sees what

Each party sees only what its role requires. The customer, and conceptually the provider, sees its own agent's error pattern. The bank sees instructions, checks and verdicts. A supervisor sees evidence on request. Refusals are classed, not just counted: a fraud indicator (a destination, key or record the customer never authorised) is a different event from an agent error (a wrong amount, currency, action or frequency inside the agent's own remit), and the second is an operational quality signal for the agent's owner, not a report to anyone. Nothing here reports automatically to an authority.

What a regulator gets

Regulators cannot inspect every AI agent, product or transaction, and they have told us they will not try. What they need is high-quality data and complete evidence when they investigate a specific incident, and that need grows as agentic activity scales. Every refusal here is a violation row with the instruction, the rule, the invoice extraction that produced it, and the audit entry. Every passport can be exported as one self-verifying evidence bundle: the register filing and its receipt, the bank's admission, the customer's agent identity and mandate, every verification with its inputs and signed receipt, and the hash chain segment. The export is read-only and is itself recorded. The framing question a supervisor can put to the register is the one this design answers: does this product meet the minimum assurance requirements for this use case, and who is accountable?

The passport

Each AI agent deployment holds a key only it can use; the bank challenges that key on every payment, so a copied name or a lookalike model cannot answer.

Not one token. An envelope of three independently signed JWTs (EdDSA / Ed25519, RFC 8037), each signed by the only party entitled to the claim: the bank signs the admission (the product, its declared assurance level, the ceilings scaled by that level, the hold condition, the binding to one agent identity); the customer signs the agent identity (its deployment: agent key in RFC 7800 cnf, proof of possession, configuration hash, key custody; every instruction that key then signs carries a nonce, a value used once, so the same signed instruction cannot be presented twice) and the mandate (RFC 9396 authorization_details: currency, payee accounts checked against the public company register, per-payment limit, 30-day limit per account, payments per day, expiry, and the account type and customer class the limits were derived from). The register signs a receipt for the filing that the admission cites by hash. Remove any one signature and the bank refuses.

Assurance levels

A filing declares one of three assurance levels with its evidence: self-declared (the provider's own statement), independently verified (a named party checked the documentation against the product), independently audited (a named party tested the product against the minimum assurance requirements for the use case). The level describes the evidence provided; nobody on this side certifies it. A bank uses it as an input to admission: this demo's bank approves at independently verified or above and scales its ceilings by level (×0.25, ×0.5, ×1).

Agent-channel limits

An AI agent is a new payment channel on an account. The account type sets the product ceiling (in the demo: personal current £2,500 a payment, business current £10,000, business savings £25,000, with matching 30-day and per-day limits) and the customer class carries a default account type. Every mandate must sit at or below the lower of that tier and the bank's admission ceiling; the customer's form shows the maximum it can grant.

Planned fields, not built

Delegation chains with attenuation: user to agent to sub-agent, each hop only narrowing authority (an optional prototype exists behind a switch in the expert console). Escalation threshold as a first-class passport field: the hold-for-a-person amount as something the customer can tighten, not only the bank's admission condition. Both are described so the direction is on record; neither changes the demo.

Every payment instruction is signed by the AI agent's key over the canonical JSON of passport_id, action_type, payee_account_ref, supplier_name, amount, currency, invoice_ref, nonce; R.4 verifies the signature bytes against the key in agent_identity.cnf. Flipping one byte fails it. A copied passport is useless without the key. The nonce is spent when the bank accepts the signature, so the same instruction presented twice is refused as a replay, with its own reason code (REPLAY_DETECTED) and the spent nonce in the evidence record. Two properties, kept apart. Determinism: replaying the recorded inputs of any decision yields the same decision, which is what the audit page's replay button does. Replay protection: resubmitting the same signed instruction is refused as a duplicate, which is what R.4 does.

Payees and the public register

When a customer adds a supplier to its mandate it can identify the company by Companies House number or name. The app reads the live record from the Companies House Public Data API (or a labelled synthetic register when no key is configured or the API is unavailable) and records the legal name, status and registered office in the signed mandate. Companies House verifies nothing itself: it reports what companies filed, which is exactly what our own register does. It holds no bank account data, so the sort code and account number still come from the customer; a Confirmation of Payee check on the account name is planned, bank-side. The mandate's core protection remains that payment goes only to the listed account.

Where it sits in the bank

Agent Passport is a pre-authorisation checkpoint inside the bank's existing payment pipeline. It runs alongside fraud detection and sanctions screening, before settlement, and replaces none of them. Instructions map to standard payment messaging (ISO 20022 pain.001 fields: debtor, creditor account, amount, currency, remittance reference), and the demo's rail semantics correspond to UK Faster Payments, so the checkpoint sits in front of rails the bank already runs. Registration and verification live at the bank, so the checks run where the money is, with no dependency on an external service at payment time.

Rules in this pack

On the register, at filing (completeness, not judgement)

F.1 Provider resolves at Companies House CURRENT · Companies House public register (live lookup, or the synthetic demo register when offline). Companies House reports what companies filed; it verifies nothing itself
F.2 Accountable principal named, with a signed declaration PROTOTYPE · Filing declaration, as for a Companies House filing; accountability for the filing, not a quality judgement
F.3 Insurance evidenced, cover at or above the minimum, in force PROTOTYPE · Professional indemnity policy summary; minimum cover in the policy table
F.4 AI product documented with a pinned model version PROTOTYPE · Filing form: product name, identifier, release, foundation model provider and pinned version, documentation location
F.5 Independent Assurance Evidence attached, with its assurance level, covering the registered use case PROTOTYPE · Independent benchmark or audit report and a declared assurance level (self-declared, independently verified, independently audited). Presence, level and scope are checked; the register makes no quality judgement
F.6 Product not already on the register PROTOTYPE · Agent Passport Register
F.7 UK data protection declared: UK GDPR and Data Protection Act 2018 compliance, ICO registration, personal data retention period PROTOTYPE · Provider declaration signed for by the accountable principal; ICO register of fee payers (format of the registration number only). The register verifies nothing about compliance

At the bank, on every payment, in this order

R.1 Admission signature genuine (bank key) → DENY PROTOTYPE · EdDSA / Ed25519 (RFC 8037)
R.2 Passport active and unexpired (bank's list lookup) → DENY PROTOTYPE · The bank's passport list (real-time lookup)
R.3 Agent identity signature genuine (customer key), bound to this admission → DENY PROTOTYPE · EdDSA / Ed25519 (RFC 8037)
R.4 Instruction signed by the AI agent key inside agent_identity, with a nonce not seen before → DENY PROTOTYPE · RFC 7800 cnf / DPoP-style proof-of-possession
R.5 Mandate signed by the customer, unexpired, not revoked → DENY PROTOTYPE · EdDSA / Ed25519 (RFC 8037); mandate validity
R.6 Action and currency permitted, payee account on the customer-signed allowlist → DENY PROTOTYPE · authorization_details (RFC 9396 shape); Confirmation-of-Payee analogue
R.7 Amount within the per-payment limit → DENY PROTOTYPE · Mandate per_payment_limit
R.8 Cumulative limits: 30-day total for this payee account and payments per rolling day within the mandate → DENY PROTOTYPE · Mandate monthly_limit_per_account and max_payments_per_day; bank-held ledger (limits in the mandate, totals at the bank)
R.9 Bank hold conditions: an amount above hold_above is held for the customer's named approver; the first payment under a mandate version is held for the customer's own confirmation → ESCALATE PROTOTYPE · Admission condition set by the bank's payments risk officer; graduated trust: a person at the mandate, at the first payment, at the threshold, autonomy in between

With a delegation chain (optional)

C.a Root mandate scope is well formed → DENY PROTOTYPE · Delegation invariant S_n ⊆ … ⊆ S_0
C.b Delegation is a subset of the root mandate → DENY PROTOTYPE · Delegation signed by the orchestrator key in agent_identity.cnf; beneficiaries, ceiling, actions, validity ⊆ root
C.c Action lies inside the narrowest scope → DENY PROTOTYPE · Instruction signed by the delegated execution key named in the delegation

Unknown action types are held at R.6. The limit lives in the mandate; the running 30-day total lives at the bank. Approval ceilings: per payment ≤ £10,000, per account in 30 days ≤ £50,000, expiry ≤ 2027-03-31; every customer mandate is checked against them at signing. A repeat of the same refused rule within 24 hours (2 or more) raises an alert to the bank's risk team; three refusals of any kind raise an incident.

Technical standards

Customer mandate: OAuth 2.0 Rich Authorization Request (RFC 9396), in line with NIST NCCoE 2026 guidance on OAuth 2.0 for agentic systems. Credential format: W3C Verifiable Credentials JWT profile (RFC 7519). AI agent key binding: RFC 7800 cnf, an equivalent workload-identity guarantee to SPIFFE SVID. Signatures: Ed25519 / EdDSA (RFC 8037). Bank-side verification: deny-by-default, deterministic, no model inference at execution time. Ed25519 keys are compatible with W3C did:key resolution. Revocation is a list lookup at the bank and a voucher revocation on vouch.finance. The FATF 2025 guidance on AI-enabled circumvention of AML/CFT identity controls is addressed by the mandate's named-beneficiary field and amount ceiling, which prevent the AI agent from redirecting money even when the agent itself has been manipulated (R.6 and R.7 here).

Where the model sits, and where it does not

Registration is a form the bank's officer fills in by hand, from what the provider supplied. Gemini is used at the edges only: the AI agent reads invoices into payment instructions with a verbatim quote per fact, and the bank's officer can ask for a draft file note. It never checks, scores, approves or verifies. If the API is unavailable the system falls back to a deterministic fixture and says so. The consequential middle is the rule pack payments-2026.09.7, so the same inputs always give the same decision. A grounds declaration records, before the AI agent opens a document, what it intends to pay and to which account the customer signed for; when the instruction it then generates differs, the record shows the document changed the destination, not the agent.

What this is not

Not a payments rail. It authorises; vouch.finance and the bank's own rails settle.
Not an AML or sanctions system. It runs beside them and reports into neither.
Not a regulator's operating tool. Supervisors read evidence; they run nothing.
Not model certification. The register files evidence; each bank makes its own approval decision.

What we do not claim

That any bank or register operates this today; that a passport replaces the provider's authorisation, the customer's contract or the bank's own mandate; that Independent Assurance Evidence proves an AI agent is safe or correct; that a valid passport compels a bank to execute; that this is production cryptographic infrastructure. This prototype does not attempt biometric synthetic-identity detection, agent swarm detection at infrastructure scale, cross-border mutual recognition, liability calculation, or systemic risk modelling. The mandate enforces money destination and authority, not invoice semantic accuracy. The register, the bank, the firms, the accounts and the invoices are synthetic. The AI agent and the customer's signing ceremony are simulated inside this server.

Legis Labs · C:\>DIR Global 'Agentic Regulator' Hackathon 2026, Know Your Agent problem space · developed alongside Cambridge academic and industry partners · synthetic data only · standard: APS 1001 · this deployment runs vouch in live mode on the vouch rail.