A tokenised settlement system is a payment or securities settlement system with a chain underneath. Whether the chain entries are legally final depends on the same legal layer that governs every other settlement system: the law of the jurisdiction, the designation of the operator, and the rulebook the participants signed. The chain technology is one input. It is not the answer. Part 3 walks through how designation attaches to tokenised systems, what probabilistic and deterministic finality mean at the architectural level, and where atomic delivery versus payment (DvP) sits and does not sit on the legal map.
Tokenisation implications
A transfer between two wallets on a permissionless chain is, at law, an instruction to make a transfer. Whether the transfer is final depends on the legal status of the system the wallets sit in, not the technical state of the chain. If neither wallet is part of a designated payment or securities settlement system, the transfer's finality is governed by the general law of contract and property, the relevant insolvency code, and any contractual agreements between the parties. Most permissionless chain transfers fall into this category. They are operationally irrevocable in the sense that the chain will not roll them back voluntarily. They are not legally final in the institutional sense, because no designation hook attaches. The CPMI's 2024 tokenisation taxonomy is explicit on this point: tokenisation does not, in itself, manufacture finality, and operators have to attach the chain to a recognised legal envelope to achieve it (BIS CPMI tokenisation report).
For permissioned tokenisation systems to grant finality, three patterns are in production. The system operator seeks designation under the local payment systems or securities settlement systems regime. Participants agree finality contractually under the system rules, with each participant's finality opinion confirming enforceability against its own insolvency regime. Or the system runs under an existing finality umbrella, for example as a settlement layer operated by an already-designated CSD or central bank. Designation is the cleanest. Sub-component status is the most common in practice for early launches. Contractual finality is the highest legal risk and the rarest in any institutional-grade setup.
Probabilistic finality on proof-of-work or proof-of-stake chains is not legal finality. A transfer recorded in an Ethereum block is not unwindable by ordinary network operation, but the chain admits the theoretical possibility of a deep reorganisation, and historical reorgs on Ethereum and on Bitcoin have demonstrated this is not purely theoretical. A regulator looking at a settlement system that depends on probabilistic finality has to ask how the system handles the case where the chain reorganises. Most institutional permissioned designs solve the problem at the architectural level by avoiding probabilistic chains for the settlement leg.
Deterministic Byzantine fault tolerant (BFT) consensus on permissioned chains gives operational finality at block commit time. Once a block is committed, the chain does not reorganise. This is what makes permissioned chains suitable for institutional settlement at the architectural level, covered in Permissioned blockchains. Legal finality on top of that still depends on the system's designation status or the contractual arrangement among participants. A Canton Network domain or a Corda notary arrangement gives you operational finality. The legal layer is an independent design problem. Solving one without the other gets you partway.
The Basel Committee on Banking Supervision (BCBS) has set the prudential lens through the Basel SCO60 standard (Basel SCO60). The standard's classification conditions for Group 1a tokenised traditional assets include legal enforceability of the on-chain record, which is finality-adjacent. A bank seeking favourable capital treatment has to be able to demonstrate, on demand, that the chain entry is legally operative, which runs through the system's finality designation or its contractual basis. The standard does not specify which path; it specifies the test the path has to satisfy.
Atomic settlement and its limits
The atomic settlement claim, that delivery of an asset and payment of cash can be combined into a single indivisible operation that either succeeds in full or fails in full, is one of the cleanest applications of programmable settlement. The mechanics are covered in detail in Chapter VI on atomic delivery versus payment, but the finality implications belong here.
Atomic DvP works when both legs of the trade are tokenised on the same ledger or on linked ledgers with hash-time-lock or coordinator infrastructure, and when both legs are subject to compatible finality regimes. The payment leg has to settle in something with institutional-grade finality, which lands you back at the question of which tier of money is being used and which finality designation applies, covered in 03 bank money central bank money. The asset leg has to settle in a system whose designation or contractual basis makes the transfer irreversible at the same legal moment as the payment.
The limit is that atomic settlement does not, on its own, manufacture legal finality. It coordinates the timing of two transfers so that they both reach final status together, or neither does. If the underlying systems do not provide finality, atomic coordination does not retrofit it. Tokenisation pitches that conflate "atomic" with "final" are missing the legal layer. An atomic exchange between two non-designated chains, with no participant rulebook and no contractual finality opinion, gives you very fast simultaneous failure when one of the participants enters insolvency. The fast simultaneous part is the architectural achievement. The legal achievement, finality, is the separate one.
What designation does for tokenised systems specifically. Once an authority designates a tokenised settlement system, the chain entries become the records the law looks at to determine the moment of finality. The system's rulebook defines that moment, typically at the smart-contract event level, and the law of the system gives the rulebook insolvency-protected force. The chain stops being a "decorative" record running in parallel with an off-ledger system of record, the failure mode flagged in Tokenisation, defined, and starts being the operative settlement record in its own right. This is why the regulator-led tokenisation programmes in APAC have been so insistent on getting the designation question answered up front rather than retrofitting it after launch.