A EUR 1,000 demand deposit and a EUR 1,000 tokenized deposit are the same liability on the balance sheet. They are different instruments for settlement, redemption, and compliance purposes. Traditional double-entry accounting assumes that liabilities of the same type are fungible and interchangeable: two EUR 1,000 deposits can be offset, aggregated, and reported as a single EUR 2,000 balance without loss of information. Tokenized deposits break this assumption. Each token carries traceable ownership, programmable conditions, and an on-chain settlement path that requires distinct treatment in the ledger.
$27.5 billion in tokenized real-world assets are on-chain as of Q1 2026, up 30% in three months. 37 European banks across 15 countries are building a MiCAR-compliant euro stablecoin under the Qivalis consortium. Tokenized deposits are moving from trading infrastructure to banking infrastructure. The ledger design decisions made now will determine whether institutions can satisfy MiCAR reserve requirements, produce accurate balance sheet reports, and process redemptions without manual reconciliation.
The Fungibility Assumption in Traditional Double-Entry
Traditional double-entry accounting treats liabilities of the same type as fungible. When a bank holds EUR 50 million in demand deposits, the individual balances are aggregated: the bank owes EUR 50 million to depositors collectively. The identity of which depositor holds which balance is tracked in the customer ledger, but for balance sheet and liquidity purposes, the EUR 50 million is a single pool.
This fungibility works because demand deposits are legally homogeneous: all depositors have the same redemption rights, the same applicable interest rate, and the same regulatory treatment. A bank can satisfy any depositor's withdrawal request from the same pool of reserve assets.
Tokenized deposits are not legally homogeneous. Each token may carry:
- Programmable conditions: a token that can only be redeemed after a lock-up period, or only by a specific category of recipient, or only within a defined transaction amount range. These conditions are encoded in the token's smart contract and cannot be violated without a failed transaction.
- Traceable ownership lineage: on-chain tokens carry a complete transaction history from issuance to current holder. The lineage is public, immutable, and verifiable. For AML purposes, this is valuable. For balance sheet purposes, it means two tokens of the same face value may have different risk profiles based on their transaction history.
- On-chain settlement finality: once a token is transferred on-chain, the transfer is irrevocable. A traditional demand deposit transfer can be returned (SEPA R-transaction). A token transfer cannot be reversed through a structured scheme mechanism. Only a new compensating transaction initiated by the recipient can undo it.
An accounting model that aggregates tokenized and fiat deposits into a single liability pool loses the information needed to process redemptions correctly, satisfy MiCAR reserve requirements, and produce accurate regulatory reports.
What the Ledger Must Track Distinctly
Three properties require explicit representation in the ledger, not as metadata fields on fiat accounts, but as first-class account attributes.
Token type and settlement path. Each tokenized deposit account must carry the token type identifier (MiCAR EMT, ART, or utility token), the on-chain address, the chain identifier, and the settlement model (atomic on-chain, deferred fiat, or hybrid). The settlement path determines how redemption is processed: a pure EMT redemption is a token burn plus a fiat credit. A hybrid path may require both on-chain and SEPA operations in a coordinated workflow. The ledger cannot execute the correct settlement without knowing which path applies.
Reserve linkage. MiCAR requires that every EMT in circulation is backed by a segregated reserve asset of equivalent value. The ledger must maintain an explicit linkage between the total outstanding token liability and the corresponding reserve asset balance. This is not a reporting query run at month-end. It is a constraint enforced at every token issuance and redemption event. When a new token is issued (liability increases), the reserve account must receive an equivalent deposit (asset increases). If the reserve transfer fails, the token issuance must be rolled back. Both operations must be atomic.
Programmable conditions as ledger constraints. If a token carries a lock-up condition, that condition must be enforced by the ledger, not by the application layer alone. An application that checks the lock-up condition before executing a transfer provides one layer of enforcement. A ledger that rejects transfers against locked accounts provides a second, independent layer. Defense in depth applies here for the same reason it applies to multi-tenant isolation: a bug in the application layer that bypasses the condition check must not corrupt the financial record.
The Balance Sheet Fragmentation Risk
If tokenized deposits are not properly segregated in the ledger, three balance sheet problems emerge at audit time.
Overstated liquidity. A bank that counts tokenized deposits in the same liquidity pool as demand deposits may report a higher liquid asset ratio than it actually holds. If 20% of the "demand deposit" pool is actually locked tokens that cannot be redeemed until a condition is satisfied, the institution's actual ability to meet withdrawal requests is lower than the reported figure suggests. DORA's operational resilience requirements and the ECB's liquidity coverage ratio (LCR) calculation under CRR both require accurate liquidity representation.
Reserve under-reporting. If the institution issues EUR 10 million in EMTs but the reserve backing is tracked as a general-purpose liquidity reserve rather than a segregated EMT reserve, the MiCAR reserve requirement is technically satisfied but not verifiably so. ESMA and EBA expect institutions to demonstrate that the reserve is dedicated to EMT redemption and cannot be used for other purposes. A general liquidity reserve cannot provide this demonstration.
Incorrect regulatory capital treatment. The capital requirements for tokenized liabilities under CRR III (Capital Requirements Regulation) differ from those for traditional deposits, particularly for ARTs where the underlying basket may include volatile assets. If the ledger does not distinguish token liabilities from fiat liabilities by type, the capital calculation inputs are incorrect.
Token Issuance and Redemption as Durable Workflows
Token issuance and redemption are multi-step processes with different atomicity requirements than single-asset transfers.
Issuance (customer deposits fiat, receives token):
Step 1: Receive fiat deposit (SEPA Credit Transfer credited to customer account)
Step 2: Debit customer fiat account
Step 3: Mint token on-chain (broadcast transaction, await confirmation)
Step 4: Credit customer token account in ledger
Step 5: Transfer equivalent amount to segregated reserve account
Steps 3 and 4 must be atomic: if the on-chain mint fails, the fiat debit in step 2 must be reversed. If step 5 fails (reserve transfer), the issuance must roll back entirely. A partial execution (fiat debited, token minted, reserve not funded) creates an unbacked token, which is a MiCAR violation.
Redemption (customer returns token, receives fiat):
Step 1: Receive redemption request
Step 2: Verify token balance in customer account
Step 3: Burn token on-chain (broadcast transaction, await confirmation)
Step 4: Debit customer token account in ledger
Step 5: Release equivalent amount from reserve account
Step 6: Credit customer fiat account
Step 7: Initiate fiat outgoing transfer (SEPA or internal)
If step 3 succeeds but step 6 fails, the customer has burned their token and received nothing. The compensation path (re-mint the token and reverse the reserve release) requires the orchestration layer to execute a compound compensation, not a simple step reversal.
Durable execution provides the recovery guarantee: every step is journaled before execution. On restart after a crash between any two steps, the engine replays the journal and either completes the workflow or executes the compensation from the exact point of interruption. The token balance and the reserve balance are never out of sync for longer than a single recovery cycle.
MiCAR Reserve Requirements as Ledger Architecture
MiCAR Article 36 requires EMT issuers to maintain a reserve of at least 100% of outstanding issuance in assets with specific liquidity and credit quality characteristics. The reserve must be segregated: held in a dedicated account at a credit institution, legally separate from the issuer's own funds.
This is the same architectural requirement as EMD2 safeguarding, applied to tokenized liabilities. The ledger constraint is identical: the sum of all outstanding token liabilities must never exceed the sum of reserve account balances. At any point in time. Not at month-end. Not after reconciliation.
The enforcement mechanism is the same: explicit account types in the ledger, with transfer rules that prevent reserve assets from flowing to operational accounts except through authorized, journaled redemption workflows. A real-time safeguarding report (query the reserve accounts, query the outstanding token balances, compare) must show surplus or zero at any instant. A negative value is a MiCAR violation in real time, not a reconciliation discrepancy to be addressed later.
Trade-offs
Extending the ledger to first-class tokenized account support has costs.
Data model extension. Adding token type, on-chain address, chain identifier, and settlement model as ledger-level fields requires schema changes and migration for existing systems. For systems built on general-purpose SQL databases, the migration is a standard schema change. For purpose-built settlement engines, the protocol must be extended to carry the new fields. Neither migration is trivial at production scale.
On-chain monitoring operational overhead. Tracking token settlement confirmation requires running or connecting to blockchain nodes, monitoring for transaction confirmation, and handling chain reorganizations. This is a new operational domain for institutions that have not previously operated blockchain infrastructure. Node uptime, chain fork handling, and mempool monitoring are not problems that SEPA processing teams have experience with.
Regulatory ambiguity on reserve composition. The EBA's draft regulatory technical standards for MiCAR reserve composition are not fully finalized as of mid-2026. An institution building reserve management infrastructure against the current draft must design for policy change: the acceptable asset types, the diversification requirements, and the custody standards may shift before the final RTS is published.
Fernel Context
Fernel's ledger supports explicit account types, including customer_emoney, safeguarding, operating, and float, enforced at the protocol level. Extending the account type taxonomy to include token_emoney and token_reserve follows the same pattern: each account carries a type flag that the engine validates before executing transfers. The reserve linkage constraint, outstanding token balance must not exceed reserve balance, is enforced as a real-time balance check, not a periodic report. Durable workflows couple token issuance and redemption steps atomically, with journal-based recovery for any mid-workflow failure.
Read more: The Ledger | Safeguarding Architecture for E-Money Institutions | MiCAR, Stablecoins, and the Compliance Layer
Sources:
- Cambridge Centre for Alternative Finance, Tokenized RWA Data Q1 2026: $27.5 billion on-chain, +30% in three months
- Qivalis consortium: 37 European banks, 15 countries, Sir Howard Davies as Chairman, H2 2026 MiCAR-compliant euro stablecoin target
- MiCAR, Regulation (EU) 2023/1114, Art. 36 (Reserve requirements for EMTs), Art. 48 (Redemption rights and timelines), Art. 56 (Reserve management for ARTs)
- EMD2, Directive 2009/110/EC, Art. 7-10 (Safeguarding requirements), for structural comparison with MiCAR token reserve obligations
- CRR III (Capital Requirements Regulation III), EU 2024/1623, capital treatment of tokenized instrument exposures
- ECB, Liquidity Coverage Ratio under CRR, requirements for accurate liquidity asset classification
- HGB §246, Verrechnungsverbot (Prohibition of offsetting), requirement to report assets and liabilities separately