Key takeaways
- A Bank of England Bank Underground post, as reported by TODAQ Press, says that legal responsibility for an agent's actions remains with the human deployer.
- An IMF Policy Note proposes separating probabilistic AI decisions from deterministic payment execution; TODAQ Press argues the surrounding record must also be bound to execution.
- OSFI Guideline E-23 covers AI and machine-learning models from 1 May 2027 and expects adequate vendor documentation.
- Qatom can run hosted, in a VPC, on-premises or air-gapped, with RBC holding the reserve funds backing USD inside Qatom.
- The proof shows what was executed, paid and settled under which authorization; it gives no system-wide view and cannot prove a decision was right.
What are agentic payments for banks?
Agentic payments for banks are payments that AI agents start and complete for a bank's customers, or for the bank itself, within limits a human sets. The agent finds a service, checks the price, pays and keeps a receipt. The human sets the budget and decides which payments need approval.
For a bank, the payment step is familiar. Three other parts are new: who carries responsibility when the agent errs, how spending authority is enforced, and what record survives for customers, auditors and supervisors. This guide covers what banks are being asked, how deployment and reserves work, and where the evidence stops.
It describes what rules and public bodies have said. It is not legal advice.
What are regulators asking about AI agent payments in banking?
Several public bodies, and publications by their staff, have set out views that bear on AI agent payments in banking.
- Bank of England. A Bank Underground post of 21 May 2026, as reported in The Invisible Shelf, says legal responsibility for an agent's actions remains with the human deployer. TODAQ Press also reports that Deputy Governor Sarah Breeden warned in June 2026 that AI agents could "amplify volatility in stress."
- IMF. The Policy Note "How Agentic AI Will Reshape Payments" (Davidovic & Tourpe, 24 April 2026), as reported by TODAQ Press, proposes separating probabilistic AI decisions from deterministic payment execution.
- OSFI Guideline E-23. E-23, Model Risk Management was finalized in a September 2025 letter and takes effect on 1 May 2027. It applies to federally regulated financial institutions, explicitly covers AI and machine-learning models, and is risk-based and proportional. Vendors must supply adequate documentation, and third-party models are validated and monitored commensurate with risk.
- EU AI Act. Credit assessment is a stand-alone (Annex III) high-risk use. Under the Digital Omnibus on AI, those obligations now apply from 2 December 2027. Article 19 and Article 26(6) say providers and deployers that are financial institutions keep automatically generated logs as part of their documentation under financial services law.
TODAQ Press adds one caution from a MAS and IMDA paper: "The regulatory obligations, including the Travel Rule, persist regardless of the technology rail used." A new rail does not remove existing duties. Which of these apply to your institution, and how, is something to confirm with your counsel.
Why should settlement and the verifiable record be one operation?
The IMF's separation addresses execution. TODAQ Press argues it leaves the record exposed: "even with deterministic settlement, the surrounding record may remain probabilistic, generated after execution by the same system that executed" (Settlement Without Proof).
That matters for banks because agents behave differently from the systems compliance was built around. TODAQ Press puts it this way: "The same agent, given the same input, produces different financial outputs, breaking standard compliance assumptions built around deterministic systems."
The answer TODAQ Press proposes is to bind the two. In Qatom, "Settlement and verifiable record are the same atomic operation." The record of what settled is produced with the settlement itself, so there is nothing to reconcile later and nothing to reconstruct.
How does verifiable settlement for AI agents work?
Verifiable settlement for AI agents in Qatom runs on the TODA file protocol.
- Money. Money inside Qatom is USD-TDN, a US-dollar token (1 USD-TDN = 1 USD). Settlement between twins (small wallet apps) takes under one second.
- Proof. Each TODA file carries a Proof of Provenance built from rigs: an unbroken, verifiable chain of custody. A rig proves non-equivocation, meaning no conflicting version of the history was produced. Double-spend prevention is a proved theorem in Simple Rigs Hold Fast.
- Authorization. Each update must carry a satisfaction of the previous step's requirements, such as specific signatures or weighted multi-signature lists.
- Verification. The proof travels inside the file, so verification is local and works offline. Any party can verify it without trusting the bank that produced it.
- No ledger. TODA is not a blockchain: no global consensus, no shared ledger and no gas.
Qatom charges a 0% take rate and no transaction fees, and transaction cost does not scale with the value or volume of the payment.
What are the main bank AI agent risks, and which controls apply?
The table maps common bank AI agent risks to controls in the product and to the evidence each leaves. Step IDs link to the Capabilities Index.
| Risk | Control | Evidence it leaves | What you still need |
|---|---|---|---|
| Agent overspends | Separate agent wallet with its own budget; the balance is a hard ceiling (A3, A8) | Transfers into the agent wallet and each purchase | Budget policy per agent |
| Large payment without consent | Auto-approve limit, with passkey or phone approval above it (A9, A14) | No settlement above the limit without approval | Rules for who may approve |
| Wrong seller or price approved | Check item, seller and price before approving (A31) | Payee and amount in the record | Approver training |
| Duplicate charge on retry | Retries are new charges; check the receipt first (A28) | One transaction id per purchase (A15) | Agent retry logic |
| Replayed or forged fulfilment call | Seller verifies X-Qatom-Transaction-Id; secret header on paid endpoints (B20, B12) | Settled sale matched to delivery | Seller-side monitoring |
| Leaked credentials | Key rotation and revocable API keys (B24, B29) | Your key inventory and rotation records | Secrets management |
| Too many people can move funds | Role-based access to each twin (C29) | Who can see or move funds | Access reviews |
| Model behaves badly | None in the payment layer | What the agent paid, never why | Model risk management under E-23 |
TODAQ Press also cites Capco and Info-Tech Research Group warning that machine commerce will create duplicate payments that banks cannot detect in real time. Double-spend prevention stops the same funds being spent twice, but it does not stop an agent paying twice by retry or by mistake: each payment gets its own transaction id, so retry checks (A28) and reconciliation are the controls here.
How can a bank deploy agentic payments?
Deployment is an early question in agentic payments for banks, because it sets where the data sits and who controls the network. Qatom offers four options.
| Option | Where it runs | Consider it when |
|---|---|---|
| Hosted | Qatom's infrastructure | You are running a pilot or a lower-risk use case |
| VPC | A private cloud network your institution controls | Policy requires network isolation or data residency in your cloud |
| On-premises | Your own data centers | You need full control of the infrastructure |
| Air-gapped | An isolated network with no outside connection | The environment must stay offline; verification still works |
Air-gapped deployment fits the protocol's design, since a TODA proof verifies against the file itself with no network call.
Where do the reserves sit, and how does money leave?
RBC holds the reserve funds backing USD inside Qatom and supports bank on-ramp and off-ramp transfers. A cash-out sells USD-TDN to TODAQ Treasury, which pays US dollars to a US or Canadian bank account by ACH. The minimum is 10 USD-TDN, with a flat $1 fee, and ACH takes 2–5 business days (C25, C26).
How do privacy by consent and record export to supervisors work?
TODAQ Press summarizes the privacy model as "Privacy is the default; visibility is conferred by consent." The owner can shield data before anchoring, so the trusted system records a proof without seeing the contents. A counterparty or regulator can then be given the full record, while others see nothing.
For export, the essays describe a "Transaction Binder": "a Transaction Binder can be exported and shared with any defined party, a regulator, an audit firm, a supply-chain consortium, or a sector supervisor" (The Agentic Economy's Missing Middle). In the product today, you can export a twin's ledger as CSV (C9), verify a file and download the .toda file (C8), and inspect provenance history (C7). The Qatom Console shows TODA files, provenance and verification per twin.
For E-23 vendor documentation, the primary sources are public: the Rigging Specifications, the Abject Specification, the formal proofs and the open-source JavaScript implementation. Dann Toliver (CSO) co-authored the Rigging Specifications and Simple Rigs Hold Fast; Adam Gravitis (CTO) co-authored the Abject Specification.
How should a bank evaluate agentic payments?
A sensible evaluation of agentic payments for banks starts small and tests the evidence as closely as the payment.
- Pick one bounded use case. Choose agent purchases of data or API calls with a small, fixed budget.
- Choose the deployment. Decide between hosted, VPC, on-premises or air-gapped based on data and network policy.
- Set authority in the money. Fund a separate agent wallet, set an auto-approve limit, and require passkey approval above it.
- Map the evidence. List what your auditors and supervisors will ask for, against the risk table above.
- Run test transactions. Make several purchases, including a retry, and check one transaction id per intended payment.
- Hand over a record. Export the ledger and a .toda file, and have internal audit verify the file offline.
- Document the gaps. Record what the payment proof does not cover, and the model risk and monitoring controls that fill it.
What does the proof show, and what does it not?
| Proves | Does not prove |
|---|---|
| What was executed, paid and settled, and when | That the agent's decision was correct |
| Who acted, under which authorization | That the agent stayed within its intended policy scope |
| That the history was not altered or substituted | That the original data or judgment was accurate ("Verification does not equal truth.") |
| That no conflicting history was produced, so no double-spend | A system-wide view for macro-prudential monitoring ("TODAQ has no native global observation surface") |
| That any party can verify it without trusting the originator | That supervisors accept such records; none has formally opined |
TODAQ Press is direct about the last point: "Teaching a supervisor to trust a rigging tree is a heavy lift." Plan for that conversation early.
Further reading
- Settlement Without Proof (TODAQ Press, 19 May 2026)
- When The Transaction Becomes The Record (TODAQ Press, 20 May 2026)
- The Agentic Economy's Missing Middle (TODAQ Press, 7 Aug 2026)
- Simple Rigs Hold Fast (Coward & Toliver) and the Rigging Specifications
Next steps
- Read the assurance overview for bank risk and payments teams.
- Book an enterprise demo to discuss deployment options and verify a live record.
- Work through the agentic payments risk controls checklist.