Agorá brings shared settlement into the bank workflow
A prototype spanning several currencies and subsequent tests with real money reveal what banks need to operate a programmable settlement service.
The Bank for International Settlements and the Institute of International Finance published Project Agorá's prototype findings on 27 May 2026. The work combined tokenised commercial bank deposits with tokenised central bank reserves on a shared programmable platform. Its purpose was to investigate whether wholesale cross-border payments could become easier to coordinate while preserving settlement in central bank money.
The result was a working experiment with legal and operational analysis. In July, a subsequent controlled exercise moved real monetary value. Together, the two stages show what banks need from software that improves the movement of money: compatibility with their existing balance sheets, control systems and responsibilities.
A shared platform with distinct monetary roles
The prototype uses a layered architecture that allows central banks to retain autonomy over their currencies and operations. The tokenised instruments remain central bank reserves and commercial bank deposits, with their legal character and associated obligations intact. Suppliers need to understand those roles when deciding which institution to serve and which permissions their software needs.
Atomic settlement means that all parts of a linked transaction complete together or none do. It can ease coordination across currencies and institutions, while the surrounding activities still require controls. Banks must identify the parties, manage available funds and ensure that instructions satisfy the relevant requirements before settlement is triggered.
Testing settlement with real money
The subsequent testing involved 28 financial institutions and central banks. Thirty transactions covered 17 scenarios, with a total value of approximately CHF 800,000. The cases included corporate and interbank payments, payment-versus-payment transactions and intragroup transfers. These totals describe the test programme; they do not measure daily processing capacity or set a commercial volume target.
| Period or category | scenarios in July 2026 real-value testing |
|---|---|
| Single-currency interbank | |
| Single-currency intragroup | |
| Single-currency corporate | |
| Dual-currency | |
| Payment-versus-payment |
BIS grouped its tests with real money into these five categories. The 17 scenarios together involved 30 transactions, so scenario counts differ from transaction counts. The categories describe what was tested, not production volumes, customer demand or the relative size of each payment market.
Source3
The reported average time from initiation to settlement was approximately 80 seconds. The prototype was not integrated with existing real-time gross settlement and core banking systems, although transactions interacted with them using established ISO 20022 payment and reporting messages. The exercise demonstrated operations within that defined setup. Full integration and production deployment required further work.
The runbook carried part of the system
Testing used predefined intraday windows and a detailed runbook coordinated by an operational facilitator. Participating institutions completed compliance checks before submission, and cross-currency amounts required manual confirmation in the relevant cases. The testing framework also included a contractual agreement and fallback procedures. These arrangements show why a prototype's technical architecture cannot be evaluated separately from the people operating it.
Issue
Institutions arrange the underlying funds and issue tokenised reserves or deposits.
Prepare
Participants complete checks and prepare ISO 20022 payment instructions; relevant currency amounts are confirmed.
Settle
Funds are locked and the linked payment settles atomically on the prototype.
Redeem
Token redemption is approved and the corresponding funds move through external systems.
The BIS test sequence used real money, with manual approvals and a coordinated runbook supporting the exercise.
For a startup, the useful product boundary may be an operational task around the shared platform: preparing instructions, checking the available balance, reconciling events with an internal ledger or explaining an incomplete process to an operator. Each task needs an accountable buyer and a clear connection to an existing banking system. A demonstration that works only through a specialist's manual intervention has a different cost profile from a supported product.
Controls for bank operations
The testing environment added maker-checker controls, manual approval points, transaction status information, statements at the end of each day and multifactor authentication. A new settlement method still needs the evidence and separation of duties expected by banks' operations, risk and audit teams.
The prototype findings also identify further work on technical, operational and contractual requirements across jurisdictions. A common ledger still needs to accommodate local legal requirements. Data access, confidentiality and settlement finality affect architecture and contracts. Product diligence should follow a specific payment through those requirements, including what happens if one participant cannot complete a step or an operator needs to invoke a fallback.
From a working prototype to a paid service
Agorá supplies evidence that institutions can cooperate around a different settlement architecture. It supplies much less evidence about the eventual distribution of software revenue. An infrastructure provider still has to establish who procures its service, who operates it, what availability is required and how implementation work is paid for. A bank's participation in an experiment is not equivalent to a production purchase order.
Commercial proposals need to show a measurable operating benefit, such as fewer reconciliation breaks or less effort preparing a cross-border instruction. They also need to budget for integration, assurance and customer support. The transactions with real money give investors a basis for assessing those costs and benefits, alongside the system's feasibility.
Investment implications
- The prototype and subsequent tests with real money provide different evidence about how the system operates.
- Atomic settlement can coordinate a payment chain, but account funding, compliance, redemption and exception handling remain operational work.
- A controlled experiment supports feasibility; production scale and a sustainable service model require further evidence.
Sources
- Project Agorá shows how tokenisation can improve wholesale cross-border payments; work will advance to real-value testing (opens in a new tab)
Bank for International Settlements
- Project Agorá: a shared programmable platform for wholesale cross-border payments (opens in a new tab)
Bank for International Settlements
- Project Agorá, including July 2026 real-value testing (opens in a new tab)
Bank for International Settlements
Published
