On 17 November 2022, the Australian Securities Exchange paused the blockchain system it was building to replace CHESS, its clearing and settlement platform. An independent Accenture review found the software "63% complete" and named "significant challenges with the solution design". ASX booked an A$245-255 million pre-tax charge (ASX).
The technology was not what failed. The decision to build all of it, from scratch, for a whole market at once, was.
Every bank now pricing stablecoin infrastructure faces a smaller version of that decision. Most meet it too late, after the first vendor demo.
Banks have four ways to get stablecoin infrastructure: build it, buy a hosted service, compose licensed components around the bank's own ledger and controls, or share it with other banks. For most banks, composing fits best: the bank keeps the books, the key policy and the compliance decisions, and buys custody, conversion and monitoring.
It builds on a talk I gave to bank payment teams in September 2026 and on our payment and digital asset infrastructure work. Not legal advice.
Which questions decide between build, buy and compose?
Answer five questions before the first vendor demo. Each points to a part of the system the bank may have to own.
| The question inside the bank | What it decides |
|---|---|
| Who owns the money at each moment, and what happens to it if a provider or the issuer fails? | Whether you need your own subsidiary ledger. If the answer sits only in a vendor's system, you cannot give it yourself. |
| Will this pay back? | Which flow goes first. Price one flow on your own data before you price a platform. |
| Do the money, the keys and the know-how stay in the bank? | What you own: keys, transaction data, compliance decisions and the knowledge to run the system. |
| Will the supervisor accept it? | What evidence the system must produce: approvals by more than one person, an audit trail, a tested rollback plan. |
| Why has nothing gone live yet? | How small the first step is: one flow and only the parts it needs. |
The first question weighs most: the bank answers to its clients for their money at every hop.
How do the four models compare?
Think of it as housing. Building is designing your own house: everything fits, and it takes years. Buying is a hotel: you move in tonight and live by its rules. Composing is renovating with contractors while you stay the site manager. Sharing is a housing cooperative: lower cost per family, slower decisions.
| # | Build | Buy | Compose | Share |
|---|---|---|---|---|
| Control of data and process | Full | Low | High | Shared |
| Time to the first live payment | Slowest | Fastest | In between | Set by the group |
| Upfront cost | Highest | Lowest | Medium | Split |
| Team the bank needs | Large | Minimal | Small core | Small |
| Who reconciles balances across providers | The bank | The vendor, partly | The bank | The group and the bank |
Sharing fits when the product only has value if many institutions use it:
- Qivalis, backed by 37 European banks across 15 countries, received an e-money institution authorisation from De Nederlandsche Bank on 14 October 2026. Issuance of its MiCA e-money token is "planned to begin within the next months" (Qivalis).
- UK banks completed the first live customer transactions in tokenised sterling deposits on 24 September 2026, on a platform "developed by Quant as a shared UK industry infrastructure for tokenised commercial bank money" (UK Finance).
The price is governance: a shared roadmap moves at the pace of its slowest member. And each member still connects the shared token to its own core, books and controls.
When does building your own stablecoin infrastructure pay off?
Build when the system is the reason clients choose you, volume is large and stable, and a team will maintain it for years after go-live.
Citi Token Services runs on a private-permissioned blockchain, is live in seven markets after adding Japan and the UAE on 28 September 2026, and "continues to process billions of dollars in transactions" (Citi). Citi built it for its own clients, on its own network. It moves tokenized deposits, not stablecoins; we compare the two in tokenized deposits vs stablecoins.
When a board hears "our IT can build this", it should hear three risks: time, money and reputation. The CEO weighs money and reputation; the CTO weighs time. And if nobody in the bank has run a digital-asset system before, a build starts with hiring, not with code. Build only the part your clients pay you for.
What can a bank buy, and what stays with the bank?
Almost every step of a stablecoin payment can be bought in November 2026.
- Settlement. In December 2025, Visa said Cross River Bank and Lead Bank "have started settling with Visa in USDC over the Solana blockchain" (Visa).
- A full platform. Mastercard bought BVNK in August 2026 instead of building, then launched Mastercard Global Money Platform on 15 October 2026: an account where "fiat and stablecoins can sit side by side", behind a single API (Mastercard).
Buy when the service lets you answer the five questions above. When it does not, the gap is control, revenue or cost: keys, data and compliance decisions sit with the vendor; the conversion margin goes to whoever runs custody, issuance and redemption; and a licence priced for a full feature set can sink the business case for a handful of flows.
You buy speed. You do not buy away accountability. Under DORA Article 28, a financial entity that uses ICT third-party services remains "fully responsible" for its obligations. It must record each contract in its register of information and, for services behind critical or important functions, keep an exit strategy. So every provider is one your bank must supervise, register and be able to leave: the answer when a board member asks why the vendor cannot simply handle it.
Before you sign, ask each provider:
- Who holds the money during conversion, and under which licence?
- If you, your ramp partner or the issuer fails, what happens to our clients' funds?
- How do we leave, and what data do we take with us?
- Who adapts the system when the rules change, and is that in the contract?
Then test the day-to-day operations in the RFP.

Why do most banks end up composing?
Most banks do not need to own the rails. They need to own the books: the ledger that says whose money it is at every step, reconciled daily against every provider. Almost everything else can be bought. Keep that ledger from day one, even if you buy the rest: it turns provider files, bank statements and on-chain events into one set of books, and accounting and the supervisor will both ask for it.

Banking Circle issues its own euro e-money token, EURI, but did not build the minting engine: "The burning and minting of EURI is enabled by the Fireblocks Tokenization Engine" (Banking Circle, August 2024).
Two more choices make it work:
- Add, don't replace. The stablecoin layer sits next to the payment hub or behind core banking, and the hub still routes each payment. Your channels stay, and reconciliation data flows into your data warehouse. This is how we approach stablecoin integration with core banking systems; our post on settlement middleware without core rewrites shows the mechanics.
- Connect each provider once, with a backup. If custody, FX and the ramps are separate connections, one provider's failure does not stop the flow. Keys can sit in the bank's own HSM, with a route to a custody platform later.
Take outgoing USD payments, which today pass through correspondent banks with deductions the sender cannot see upfront. In a composed design, the client sends dollars as today and never sees a stablecoin. Underneath, the payment settles in USDC. The bank picks its liquidity model: hold USDC, or buy it for each payment. The bank signs with the issuer, the technology partner answers for the technology, and the ledger shows where the money is at every hop.
The price of composing is the joins. The custodian, the off-ramp, the payout partner and the chain each report their own view, and someone must match them every day. That reconciliation gap lands on the bank. NetiRails, our stablecoin payment orchestration platform, is built on that principle and runs on the bank's own infrastructure.
What we learned drawing the line between built and bought
Alvarum: whose money is in one pooled account?
Alvarum, the Paris-based charity fundraising platform, rented its payment layer. Donations for hundreds of charities landed in one pooled account, and every euro had to be traceable to payout. In 2018 there were no off-the-shelf ledgers, so Alvarum built what it had to own: the ledger, KYC/KYB rules and a fee model per charity. It kept buying card acquiring and document verification. Then €56M in balances moved over, transaction by transaction, and production went live on the planned day, 20 April 2019. Read the Alvarum case study.
Damisa: "Whose is it right now?"
Damisa, a British cross-border payments company, moves money across bank and stablecoin rails. The platform had to answer one question first: "A payment stops halfway. The money has left one place and not arrived at the other. Whose is it right now?" KYT, MPC wallets and regulated FX and fiat liquidity were bought. We built what had to stay inside the licence holder: a self-hosted double-entry ledger, daily reconciliation against partner reports and an answer for every class of exception. Partner APIs arrived later than planned and moved the schedule; next time we mock every external dependency on day one. A six-person team delivered the MVP in four and a half months. It was accepted in December 2025 and went into production. See the Damisa case study.
A payment company: "the issuer's decisions become your product roadmap"
A company running its own payment systems settles merchant payments in its wallet. On someone else's token, "the issuer's decisions become your product roadmap". Our case study calls using someone else's stablecoin "the cheap answer and usually the right one". Here it was not. The client owned the issuance controls: every mint capped at the fiat reserve, several independent signatures for every mint and burn. We skipped the oracle, because a declarative proof of reserve met the requirement. The catch: multisig is slow, and "a control that people find painful is a control people look for ways around". Read the stablecoin issuance platform case study.
In all three, the client owned the part that decides whose money it is. Commodity parts were bought.
Where should a bank start?
Start with one payment flow, not a programme. Run it through the five questions, then:
- If nothing has to stay in the bank, buy a service.
- If the books, the keys and the compliance decisions must stay, compose.
- If the product only works when other banks join, find a group to share with.
Then price that one flow on your own data: volume, today's cost per payment, manual work and capital tied up. If the case does not close on one flow, it will not close on ten.
Every Neti project starts with a review of one payment flow, ending with a written report. Scope and cost come after it. One architect leads from that review to production, and from the bank we need a product owner and someone from compliance. If an off-the-shelf service is the better answer, the report says so. To book one, talk to our stablecoin payment orchestration team. If issuance is on the table, see how we build stablecoin for banks and credit unions.
FAQ
Usually neither in full. Building fits only when the system is why clients choose the bank and a team will run it for years, as with Citi Token Services. Buying fits a fast, small start. Most banks compose: they own the ledger and controls and buy custody and conversion.
Buy when the service lets the bank show who owns the money at each step and keeps keys, data and compliance decisions where the bank needs them. Where it does not, the gaps are control, conversion revenue, paying for a full package and dependence on one provider.
A layer next to the payment hub or behind core banking, with the bank's own double-entry ledger at its centre. Licensed providers plug in for custody, FX, on-ramp, off-ramp and transaction monitoring, each reconciled daily against the bank's books.
It can outsource tasks, not responsibility. Under DORA Article 28 the bank stays fully responsible for its obligations when it uses ICT third-party providers. It must register each contract and keep exit strategies for services behind critical or important functions.
No. A layer the bank owns turns on-chain events into postings in core banking and the general ledger, while the payment hub keeps routing payments. The core stays as it is.
Reconciliation. Every provider reports its own balances, and the bank must match them daily and explain each break. Buying a service does not remove this work. It moves the data outside the bank.


