How a bank should prepare for asset tokenisation

Blockchain Arbitration & Commerce Society (BACS) · no. 11 · 8 October 2026

Spanish institutions are moving from proof of concept to product. And in almost every project we have seen, the legal work arrives late: the technology is chosen, the operation is designed, and only then does someone ask whether it is lawful.

The right order is the reverse, because three legal decisions determine the technical architecture rather than following from it.

The first question is not a technical one

Before choosing a network, a custodian or a provider, you have to answer what the token is. On that classification depend the licence, the supervisor, the prospectus, the custody rules and the marketing regime.

If the token represents a financial instrument — shares, bonds, fund units — it falls outside MiCA and within the perimeter of MiFID II and, where applicable, the pilot regime for market infrastructures based on distributed ledger technology, Regulation (EU) 2022/858. If it is an e-money token or an asset-referenced token, it is MiCA. And if it is neither, the analysis moves to national law, which is where the answers stop being harmonised.

MiCA has applied in full since 2024, and in Spain the transitional period for providers already operating ended on 1 July this year. The CNMV has published interpretative criteria and points to the register of authorised providers maintained by ESMA.

It is worth saying plainly: resolving this classification once the product is already designed is the most common way to lose a year of work.

Custody is where the real risk sits

A bank holding crypto-assets on behalf of clients is doing something that resembles custody but is not the custody its systems were built for. Article 75 MiCA sets this out with some precision, and it repays reading in full, because almost everything that matters is in it.

It requires a custody agreement identifying the parties and describing the service, the custody policy, the methods of communication and client authentication, the security systems, the fees and the governing law.

It requires a register of positions opened in the name of each client, recording their rights over the crypto-assets, with movements instructed by the client logged as soon as possible, so that every movement affecting the holdings has its corresponding entry.

It requires a custody policy ensuring the safekeeping or control of the crypto-assets or of the means of access to them, and minimising the risk of loss through fraud, cyber threats or negligence.

It requires segregation, on three planes: legal segregation from the provider’s own estate, so that its creditors cannot reach client assets on insolvency; operational segregation; and segregation on the ledger itself, where client assets must be held separately from the provider’s own and the means of access clearly identified as belonging to clients.

And it allocates liability. The provider is liable to its clients for the loss of crypto-assets or of the means of access where the incident is attributable to it, subject to a cap: the market value of the lost asset at the time the loss occurred.

The limit of Article 75 is what must be explained to the client

That last rule has a reverse side worth reading carefully, because no commercial brochure carries it.

The provider is not liable for incidents it can show occurred independently of the provision of the service or of its operations, such as a problem on the ledger itself which it does not control.

Put differently: the bank answers for what it controls. For what nobody controls, nobody answers. And the perimeter of what nobody controls — a cross-chain bridge failure, a bug in a third party’s smart contract, a decision by validators — is neither small nor theoretical.

That residual risk exists, it does not disappear because the contract is silent about it, and the institution has two duties in respect of it: to disclose it clearly and to allocate it expressly in the contract. A custody agreement that says nothing about who bears the loss when the infrastructure fails is not an agreement that protects the bank; it is an agreement that moves the argument to a judge who has not thought about it before.

The third piece: where disputes are resolved

This is where traditional banking practice fits worst.

An institution’s general terms point to its own courts. That works for the client relationship. It does not work for everything else, which in a tokenised transaction is almost everything: the issuer may sit in another State, the infrastructure provider in a third, the issuing vehicle in a fourth, and the asset nowhere in particular.

When something fails between those actors, determining which court has jurisdiction and which law applies consumes months before the merits are reached. Meanwhile, the asset moves.

A well-built arbitration agreement resolves that stretch: one seat, one set of rules, an arbitrator who understands the technology, and an award enforceable under the New York Convention in more than a hundred and seventy States. What it does not resolve — and this is better known in advance than afterwards — is physical enforcement: an award obliges a person to do something, but it does not itself move an on-chain asset, nor reverse a confirmed transaction, nor reach someone who controls a set of keys and chooses not to comply. Hence the design of the transaction must provide, from the outset, a point of control on which a decision can act: an escrow, a multi-signature authorisation, an intermediary subject to jurisdiction.

The arbitration agreement and the technical architecture are the same decision taken twice. Taken separately, they do not meet.

Evidence, which is what gets forgotten

When a matter reaches a procedure, the institution will have to establish what happened: what instruction the client gave, when, from where, who held the means of access and what state the register was in.

The register of positions under Article 75 is not only a regulatory obligation. In practice it is the bank’s principal evidentiary asset. It is worth designing on the assumption that one day it will have to be shown to a third party who does not know the technology, and not only that it will satisfy the supervisor.

Six decisions before the first pilot

1. Classify the token before choosing the technology, and record the classification in writing with its reasoning.

2. Decide whether custody is provided or outsourced, and if outsourced, review what the provider’s contract says about Article 75 and about the risk it excludes.

3. Document the perimeter of what is not controlled and allocate it expressly in client documentation.

4. Draft the arbitration agreement alongside the technical architecture, not after it, and check that at least one point exists on which a decision can act.

5. Design the register of positions as evidence, not only as compliance.

6. Define who, inside the institution, answers for all of the above. In most of the projects that fail, the answer to that last question was “nobody in particular”.

BACS is a non-profit arbitration institution registered in the EU Transparency Register (REG 9106897105368-14) and operates a Court of Arbitration specialised in digital assets. This article is for informational purposes and does not constitute legal advice.

References to Article 75 follow the text of Regulation (EU) 2023/1114 as set out in ESMA’s interactive single rulebook.