October 13, 2025
September 20, 2026
Author: JoĂŁo Lages
“Tokenization” can describe three very different banking projects: replacing sensitive payment credentials with surrogate data, representing a bank deposit on programmable infrastructure, or issuing and servicing a financial instrument through a digital ledger. Treating them as one initiative produces the wrong legal analysis, operating model and business case.
For a bank, the useful question is not whether blockchain can make finance faster. It is: what legal claim does the token represent, whose balance sheet records it, what money settles it, and which record controls ownership? Those decisions determine whether the project changes only the data layer, creates a new channel for commercial bank money, or redesigns securities issuance and post-trade operations.
A payment token can substitute a card number or another sensitive identifier with a limited-use value. The token helps protect data and can be restricted to a device, merchant or transaction context. It does not normally create a new asset, move deposits onto a distributed ledger or alter who owes money to whom.
This is primarily a security and payments architecture. The bank still needs controls for token provisioning, domain restrictions, lifecycle events, fraud, authentication and recovery. Its value is reduced exposure of credentials, not atomic securities settlement or fractional ownership.
A tokenized deposit is intended to remain a claim on a deposit-taking bank while making that claim usable on programmable infrastructure. The holder’s credit exposure is to the bank, and redemption should return fiat money at par under the product terms. That separates the model from a stablecoin backed by a pool of reserve assets and from a central bank digital currency.
The distinction is legal as well as technical. In December 2024, the European Banking Authority’s assessment of tokenized deposits focused on classification and the boundary with electronic-money tokens. A bank cannot settle the question by naming the product a deposit. The contractual claim, redemption mechanics, transferability, holder identification and applicable national law must support that treatment.
A tokenized bond, note, fund unit, equity interest or loan participation represents rights against an issuer or underlying structure. The token may carry ownership, cash-flow, governance or transfer rights, but those rights must exist in the governing documents and applicable law. A ledger entry cannot repair an instrument that was never validly issued or assigned.
Where the token qualifies as a financial instrument, the relevant securities rules continue to apply. In the EU, the DLT Pilot Regime creates a controlled framework for certain DLT market infrastructures; it does not turn every blockchain transfer into regulated settlement or exempt an issuer from the wider MiFID II, prospectus, market-abuse, custody and investor-protection perimeter.
Before choosing a ledger, draw the accounting and legal entries for issuance, transfer, redemption and default. Four questions expose most structural weaknesses:
If the legal claim remains off-ledger while the token is only a mirror, the bank needs robust reconciliation and a rule for resolving discrepancies. If the ledger is intended to be the constitutive record, local law must recognize that function and the operating parties must be able to correct errors, execute court orders and manage lost access credentials.
A tokenized security does not settle itself. The transaction still needs a cash leg, finality rules and a mechanism ensuring that delivery and payment succeed together or fail together. Moving the asset leg to a new ledger while leaving cash in a separate, slow or manually reconciled system can add interfaces without reducing principal risk.
There are several settlement models:
The BIS Project Agorá report published on 27 May 2026 describes a prototype combining tokenized commercial bank deposits with tokenized central bank reserves for atomic, multi-currency wholesale payments. It is evidence that the model can be engineered, not proof that it is production-ready or universally cheaper. The next phase moves toward real-value testing.
In the euro area, the ECB announced in July 2025 that its Pontes initiative would link DLT platforms with TARGET Services for settlement in central bank money, with a pilot planned by the end of the third quarter of 2026. Banks should treat the ECB’s Pontes timetable and access model as infrastructure planning input and verify the current implementation status before designing dependencies around it.
Consider a corporate client that wants cash released automatically when specified supply-chain conditions are met. A tokenized deposit can preserve a bank liability while allowing conditional payment logic. The bank must decide who verifies the external condition, whether the instruction is revocable, when the payment becomes final and how sanctions or fraud controls can stop execution. The smart contract should automate an approved decision rule, not make an unexplained credit or compliance judgment.
A bank issuing a tokenized note must align the securities terms, investor register, distribution route, custody model and payment agent. The token can improve subscription and servicing, but it does not remove suitability, disclosure or product-governance duties. Coupon and redemption events need funds-flow controls, while transfers must respect investor and jurisdiction restrictions.
If secondary trading is intended, the bank must determine whether transfers occur bilaterally, on a regulated venue or through a DLT market infrastructure. ESMA’s June 2025 review of the DLT Pilot Regime shows that authorised infrastructures and intended instruments exist, but implementation remains bounded by eligibility, authorisation and settlement design.
A bank may seek to mobilise bonds or other collateral more quickly across treasury operations. The relevant gain comes from coordinated ownership, valuation, eligibility, margin and settlement records. The design must still handle haircuts, concentration limits, substitutions, defaults and competing claims. A fast ledger does not make poor collateral liquid or eliminate the need for legally effective control.
A bank has three practical architecture choices. A mirror model leaves the core system or conventional register authoritative and publishes selected states to another ledger. It limits legal change but creates reconciliation and latency. A native model makes the new ledger the primary record. It can reduce duplicated books, but demands stronger legal recognition, resilience and recovery controls. An orchestration model connects existing ledgers and payment systems through messages and conditional workflows. It may deliver much of the operational benefit without forcing every participant onto one network.
The right choice depends on the process being replaced. If the problem is duplicated subscription data, digitising onboarding and registers may matter more than on-chain trading. If the problem is settlement risk, synchronising the cash and asset legs matters more than token issuance. If the problem is trapped intraday liquidity, network hours, collateral mobility and finality matter more than retail fractionalisation.
The bank’s approval case should explain how the system behaves during key loss, cyberattack, ledger outage, erroneous transfer, participant default and legal freeze. At minimum, the operating model needs:
These are not generic technology requirements. They determine whether the bank can prove who owns the claim, stop an unlawful movement, restore access and continue servicing liabilities after a vendor or network failure.
Binding law, supervisory standards and market practice should be separated. EU banking, payments and securities law determines the licensed activity and customer protections. The DLT Pilot Regime provides a specific route for eligible market infrastructures. MiCA may apply to crypto-assets that are not already regulated financial instruments or excluded products. Contract, property and insolvency law determine whether token transfers have the intended legal effect.
Prudential treatment is a separate analysis. The Basel Framework’s crypto-asset exposure standard, including changes effective from 1 January 2026, distinguishes tokenized traditional assets from other crypto-assets and requires ongoing classification. The Basel crypto-asset exposure standard states that a tokenized traditional asset must confer the same legal rights as its non-tokenized equivalent to qualify within the relevant category. Basel standards are not themselves EU legislation; banks must confirm how the applicable rules have been implemented by their jurisdiction and supervisor.
A bank rarely needs to build every layer. It may retain control of the regulated product, customer relationship, risk decisions and books while using vendors for identity orchestration, wallet infrastructure, token lifecycle operations, investor portals or reporting. The make-or-buy decision should follow accountability.
For securities issuance and distribution, a white-label investment platform can provide configurable onboarding, subscriptions, payments and servicing interfaces. It does not replace the bank’s product approval, legal classification or regulated responsibilities. Banks comparing providers should map each promised feature to an accountable entity, system of record, regulatory permission and recovery process. Lympid’s guides to tokenization-as-a-service operating layers and European tokenized-securities infrastructure provide more detailed procurement frameworks.
Approve the use case in this order:
Tokenization creates value in banking when it changes the coordination of legally enforceable claims and money. If the project cannot identify the liability, authoritative record and settlement asset, the token is an additional database entry. If it can, tokenization may compress multiple operational steps into a controlled transaction without discarding the protections on which banking depends.
Book a call with us today and get a free assessment.
