Part 1 set the legal-versus-technical split. This part shows how that split plays out operationally. In production, a tokenized asset lives on two ledgers at once, and the reconciliation surface between those ledgers is where most of the operational risk sits. The two worked examples below, a tokenized money-market fund and a tokenized deposit, are deliberately different shapes. The legal claim sits in different places, the role of the existing transfer agent or registrar differs, and the consequences of a ledger divergence diverge accordingly.
The two-ledger model
A tokenized asset has two systems of record running in parallel. There is the issuer's general ledger or the registrar's book, which is the system of record for accounting, regulatory reporting, and capital treatment. There is the token ledger, which may be a public chain, a permissioned chain, or a private deployment of a chain technology operated by the issuer or a market infrastructure provider (see Permissioned blockchains for the architectural taxonomy). The two must reconcile, continuously, and the reconciliation logic is where most of the operational risk lives.
Continuous reconciliation does not mean event-driven reconciliation. A bank reconciling its general ledger against the token ledger once a day is running a different operation from a bank reconciling on every transfer. The cadence is a function of the licence, the asset class, and the prudential expectation set by the supervisor. The Basel SCO60 prudential framework requires Group 1a treatment to demonstrate that on-chain holdings reconcile to the underlying on demand, which in practice means at sub-daily cadence for any meaningful balance (Basel SCO60).
Worked example: tokenized money-market fund
For a tokenized money-market fund (MMF), the typical arrangement looks like this. The fund's transfer agent maintains a register of holders. The smart contract on the chain mints and burns units according to instructions signed by the transfer agent or by an oracle the transfer agent controls. Subscriptions and redemptions land in fiat at the fund's cash account, and the corresponding token mint or burn happens on the chain. Legally, in most current structures, the chain entry is the register, or the chain entry is treated as a permitted electronic representation of the register under the relevant fund-formation law (Delaware, Cayman, Luxembourg, or Singapore VCC).
The transfer agent's role does not disappear, it changes shape. The smart contract effectively becomes a piece of the transfer agent's operating infrastructure rather than a replacement for it. KYC, sanctions screening, and eligibility checks still happen off-chain at the transfer agent, and the on-chain whitelist enforces the result. When a holder is added or removed, the transfer agent updates the chain via signed instruction. This architecture is why tokenized MMFs are typically restricted to qualified purchasers or qualified institutional buyers with permissioned transfer logic, not bearer-style transferable like a payment stablecoin.
The largest deployed examples (BlackRock's BUIDL issued through Securitize, Franklin Templeton's FOBXX, Ondo Finance's OUSG) all run this pattern with implementation differences in the token contract design and the chain choice rather than in the underlying legal architecture.
Worked example: tokenized deposit
For a tokenized deposit, the structure is different. A deposit is, at law, an unsecured loan from the depositor to the bank. The token is a representation of that claim. When you transfer a tokenized deposit on a chain operated by the bank or a consortium, you are transferring the identity of the creditor on the bank's books. The bank's general ledger is updated atomically with, or immediately after, the chain transfer. If the ledgers ever diverge, the bank's books govern, and the chain has to be rolled back or reconciled by manual journal entry.
This is why no major bank has so far put deposit tokens onto a permissionless chain it does not operate. The reconciliation surface is unbounded if the bank cannot freeze the chain. JPMorgan's Kinexys Digital Payments runs on a permissioned ledger derived from the Quorum lineage; Partior, the consortium between DBS, JPMorgan, and Standard Chartered, runs on Quorum-based infrastructure for cross-bank tokenized deposit settlement. In both cases the operator can pause the chain, and that ability is part of what makes the legal claim operative for the bank's regulator.
A tokenized deposit holder bears single-name credit risk to the issuing bank. That is the same credit exposure as holding the underlying deposit; the tokenisation does not change it. A holder switching from a USD deposit at Bank A to a USD-pegged stablecoin issued by an unrelated entity is changing the credit exposure, even if the chart shape near par looks identical. Conflating the two is the most common error a Web3 reader makes when stepping into a TradFi room. Chapter II goes deeper on the stablecoin-versus-deposit distinction.
Reconciliation under stress
The two-ledger model holds in normal operation. Under stress, it bends. A chain reorg on a permissioned ledger is rare but not impossible (a validator failure, a software bug). When it happens, the bank's general ledger is the authoritative record, and the chain is rolled forward to match. The window between the divergence and the reconciliation is the operational risk that prudential supervisors expect capital to be held against. Group 1a treatment under Basel SCO60 includes a flat 2.5 percent capital add-on for infrastructure risk, which is the regulator's pricing of exactly this exposure.
Part 3 takes the mechanical picture and overlays the legal-control question: under what statutory or common-law mechanism does the chain entry actually become operative, and how does the answer differ across the four jurisdictions an institutional issuer cares about most.