From Pilot to Production: What Banks Need From Tokenisation Infrastructure.

Banks have spent several years proving that deposits and securities can be represented as tokens on a ledger. The question now in front of them is what it takes to run that activity every day, under supervision, with client money at stake.

Moving tokenisation from pilot to production requires the controls banks already apply to any system of record: integration with the core ledger, identity and eligibility checks before every transfer, segregated custody and signing authority, reconciled settlement with a full audit trail, and supervised operational resilience. Issuing a token covers none of these on its own.

Why issuing the token is the easy part

The Financial Stability Board, in a report to the G20 published on 22 October 2024, described adoption of DLT-based tokenisation as very low but growing. It listed operational fragilities among the vulnerabilities that would matter if activity scaled.

IOSCO is more specific about where production efforts stall. Its final report on the tokenisation of financial assets, published on 25 November 2025, found that tokenised arrangements often run in parallel with traditional infrastructure. Where the central securities depository ledger stays the reference record, reconciliation and parallel-running costs can offset the expected efficiency gains.

That finding describes the gap between a pilot and a production platform. A pilot can show a token moving between two wallets. A production platform has to show who was allowed to hold it, which ledger is authoritative, what happens when a transfer fails, and how each step is evidenced to a supervisor. UK Finance made a related point in September when it called for a single national plan to move UK tokenised wholesale markets beyond pilots.

Integration with core banking and existing records

The first design decision is which record governs. IOSCO notes that hybrid on-chain and off-chain registers raise the question of which one prevails when they conflict. For most banks the answer is the core banking system that already holds the customer ledger, so the token platform has to post to it, and receive postings from it, without creating a second version of the truth.

Live deployments show how conservative that integration tends to be. When First Abu Dhabi Bank completed a tokenised deposit transaction with Citi on Swift’s ledger platform, the deposits stayed on each bank’s balance sheet and final settlement ran through existing correspondent banking channels, as Fintechly reported in September. Behind that sits plain engineering work: agreed message formats, duplicate-instruction handling, reversal logic and tested behaviour when a downstream system is down.

Identity, eligibility and compliance before the transfer

On most ledgers a settled transfer is corrected with a new entry rather than undone. Eligibility therefore has to be checked before an instruction executes: customer due diligence, investor classification, sanctions screening, selling restrictions by jurisdiction, and any lock-up or transfer limits attached to the instrument. Each check needs an owner, a recorded outcome and a rule for what happens when a check cannot run.

The BIS Innovation Hub’s Project Agorá, which involves central banks and more than 40 private financial institutions, is testing compliance logic inside smart contracts on a shared platform. It is examining settlement finality, AML/CFT and data privacy alongside it. IOSCO adds an investor-protection point. Holders of some tokens may be unclear about their ownership and transfer rights, so disclosures have to match what the token legally confers.

Custody, signing authority and separation of duties

IOSCO states that a custodian must be able to exercise real control over the tokenised assets it safeguards, and it names the loss of private keys as a specific custody risk. Holding a key is a narrower thing than controlling an asset, and supervisors will test the difference.

In production that means defined signing quorums, hardware-backed key storage, and separate people to initiate, approve and sign a transaction. The bank’s books, the orchestration software and the key holder need clear boundaries, even where one provider covers several roles. In the US, the OCC has allowed national banks to outsource custody to third parties provided they manage that risk, part of a series of interpretive letters behind banks’ move into digital-asset custody.

Settlement, reconciliation and the audit trail

A tokenised security needs a settlement asset on the other side of the trade. In its 2025 Annual Economic Report, the BIS described tokenisation as a way to combine messaging, reconciliation and asset transfer into one process, and argued that settlement in central bank money should remain the foundation of that system.

That combination only holds if the bank can prove its records agree. Reconciliation in a tokenised set-up spans the ledger, the core banking system, the custodian’s or settlement agent’s books and the cash legs. The cost of getting it wrong is visible outside tokenisation. After Synapse collapsed, its partner banks found they held less customer money than Synapse’s records showed, a shortfall the CFPB put at between $60 million and $90 million.

Exception handling belongs in the design from the start. That covers failed or partial transfers, mismatched cash and asset legs, corporate actions, and errors that need a reversing entry. Every event needs a timestamped record of who acted, under what authority and with what outcome.

Cyber security, continuity and supervisory oversight

IOSCO lists cyber-attacks on nodes, transaction congestion, data leakage and smart contract bugs among the vulnerabilities specific to distributed ledgers, and warns that automated, shareable assets can transmit operational shocks faster. Those risks sit on top of the usual requirements for recovery time objectives, failover testing and incident reporting.

Vendor risk is often where a programme first meets its supervisor. In the UK, the PRA’s supervisory statement SS2/21 sets expectations for outsourcing and third-party risk management, and a revised version is due to take effect in March 2027. A tokenisation stack can span a software provider, a key-management provider, a ledger operator and a custodian. Each relationship needs audit rights, an exit plan and a tested way to substitute the supplier.

Supervised routes to live activity exist. The Bank of England and the FCA run the Digital Securities Sandbox, which lets firms issue, trade and settle digital securities under limits that rise as they pass each gate. It is due to run until 8 January 2029.

Planning the move to production

For banks drawing up an implementation plan, the practical step is to write each area as a testable requirement before choosing a ledger or a vendor. Suppliers can then be scored on evidence and failure scenarios, not demonstrations. Asset Haus has published a checklist of bank tokenization platform requirements that sets out criteria for that kind of infrastructure evaluation.

Tokenisation does not by itself guarantee compliance, liquidity or lower costs, and IOSCO’s finding on parallel running shows how expected savings can disappear. Whether a programme reaches production depends on how its records, controls and suppliers hold up under the scrutiny applied to any other system of record. Firms building this layer are listed on Fintechly’s infrastructure sector directory.