Tokenised stocks are no longer a niche experiment. In March 2026 the SEC approved trading of tokenised securities on Nasdaq for Russell 1000 stocks and the main ETFs, carrying the same rights as the traditional security. Tokenised stocks already exceed USD 2 billion in value and, according to RWA.xyz, more than half of their trading happens outside stock-market hours.
For a bank, the question is no longer whether its retail clients will access these assets, but where they will do it. If the bank does not offer them in its own app, clients will find them with another intermediary, and part of their wealth and of the relationship will go with them. This article sets out what a bank needs, in practice, to distribute tokenised stocks issued by third parties to its clients, under its own brand and its own licences.
Why retail clients are moving
Three features explain much of the interest. The first is access outside market hours: a tokenised asset can be transferred and settled on any day, at any time, which clients already expect from other digital products. The second is fractional ownership, which allows small amounts to be invested in securities whose unit price would be out of reach for many savers. The third is near-immediate settlement, which simplifies the experience and removes friction.
On top of this, clients already see these products in the apps of brokers and exchanges that sit outside their bank. Every time they open an account elsewhere to reach them, the bank loses visibility over part of their financial activity. Offering the product inside the bank’s own app is not a matter of fashion; it is a matter of retention.
The regulatory fit: MiFID II, not MiCA
A tokenised stock is a financial instrument. For institutions operating in the European Union, that means MiFID II applies, not MiCA, regardless of whether the security is recorded on a blockchain. The DLT Pilot Regime (Regulation (EU) 2022/858) also exists for DLT-based market infrastructures, but the relationship between the bank and its client follows the investment services framework the bank already knows.
The usual obligations therefore remain in place:
- Client categorisation as retail, professional or eligible counterparty, with the corresponding level of protection.
- Suitability or appropriateness assessment, depending on the service provided, before the transaction is allowed.
- Product governance, defining the target market of each instrument and its specific risks, including those arising from the issuer’s structure and the underlying technology.
- Pre-contractual and cost disclosure, together with the relevant issuer documentation.
- Best execution and transaction records, with the traceability the supervisor requires.
The advantage for a bank is that it already holds the licences and runs the processes. The task is not to obtain a new authorisation, but to extend existing controls to a new type of instrument and document how they apply.
Custody, keys and wallet model
The most visible operational difference from a traditional share lies in custody. The asset sits at a blockchain address, and whoever controls the private key controls the asset. The decision on where keys are generated and held is therefore central.
The option most consistent with a bank’s risk profile is for client keys to be generated and held in the bank’s own HSMs, whether physical or in its cloud. Both options offer an equivalent level of security, and in both cases the bank retains full control over the key lifecycle, signing policies and permissions.
On that basis, the bank has to choose a wallet model:
- Individual wallets, one per client, which make traceability and asset segregation easier.
- Omnibus wallets, where the bank holds assets in aggregate and keeps individual records in its own systems, closer to the traditional custody model.
There is no single answer. The choice depends on supervisory requirements, the bank’s accounting model and its risk policy, and the infrastructure should support both.
Liquidity, pricing and execution
The bank does not issue tokenised stocks; it distributes them. It therefore needs access to reliable issuers and liquidity sources, with the ability to execute orders at prices consistent with the market for the underlying. This means deciding which issuers and liquidity venues to connect to, assessing their legal and operational soundness, and setting out how the price shown to the client is formed, including spreads and fees.
Execution must take place under the bank’s licences and with its controls: limits, pre-trade checks, monitoring and record-keeping. Outside the trading hours of the underlying, the bank also needs to define how prices are formed and what information the client receives about it.
Core banking integration and client experience
A tokenised stock that does not appear in the client’s overall position, statement or tax information is not truly integrated. This is often the most demanding part of the project:
- Core banking, for debits, credits and cash movements linked to each transaction.
- Accounting records consistent with the chosen custody model.
- Daily reconciliation between what is on the blockchain and what internal systems record.
- Client identity, reusing existing KYC and authentication.
- Regulatory and tax reporting, including the information clients need for their tax returns.
Client experience deserves the same attention. Clients expect to find the product in their bank’s app, under its brand, alongside market data, charts and content that help them understand what they are buying. When all of this is delivered inside the bank’s own app, the relationship stays with the bank.
Own infrastructure or a closed service
There are two ways to approach the project. One is to contract a closed service that handles everything from the outside. The other is to deploy the infrastructure inside the bank, integrated with its systems, its HSMs and its processes, so that the bank keeps the client, the brand, the data, the keys, the licences and operational control. The second route requires more integration work at the start, but leaves the bank in a stronger position with its supervisor and with the future development of its own product.
Either way, the sensible starting point is a tightly scoped proof of concept, on the bank’s infrastructure or in a test environment, to validate custody, execution, reconciliation and experience before anything reaches production. At Finhattan we work this way: a senior engineering team that deploys and operates the infrastructure inside each bank, as described in how we work and security and control.
For a bank considering this step, an initial conversation is usually enough to identify which pieces are already in place and which are missing. The starting point is our contact page.