How Does Digital Money Keep the Books? From Accounts and Tokens to CBDC Ledger Design

Suppose an account holds 100 dollars, and a corresponding 100-dollar token is issued in a separate system. Can these two assets be spent simultaneously? If not, who prevents the second payment, and at what stage?

This question touches the foundational accounting logic of digital money. Whether dealing with Central Bank Digital Currency (CBDC), Tokenised Deposits, or Stablecoins, any asset attempting to operate within the real financial system inevitably grapples with reconciliation, access permissions, and clearing and settlement arrangements.

When discussing the account-based versus token-based paradigms, beyond specific technical implementations, a system must clarify several fundamental architectural rules: in what form value exists, what is verified during a transaction, who maintains the authoritative state, how double spending is prevented, and precisely when a state transition achieves legally irrevocable finality.

1. How Digital Money Keeps the Books: Value Representation, Verification Logic, and Data Models

The most fundamental accounting unit of a traditional bank account is the balance/account state. The system maintains an account mapping table:

Account A Balance: 100 dollars

Account B Balance: 50 dollars

When A pays 20 dollars to B, the central ledger records two sequential entries: Account A is debited 20 dollars, and Account B is credited 20 dollars. The core verification focuses on identity and access authorization (Identity Verification)—confirming whether the initiator has legitimate authority over Account A and whether Account A maintains sufficient available funds.

The token model shifts attention directly onto the digital value object itself (Object/Authenticity Verification). Here, the ledger tracks discrete digital value units with unique identifiers and their corresponding control rights:

Token #001 (Denomination: 20 dollars) → Current Control: Holder A

When a payment occurs, the system does not verify A's legal identity or aggregate balance. Instead, it checks whether the token was genuinely minted by the authorized issuer, whether it remains unspent, and whether A's cryptographic digital signature is valid. Once verified, the system transfers control of the value unit to B, or burns the old voucher and mints a newly signed voucher designated to B.

The Bank for International Settlements (BIS) has noted across multiple payment system design reports that the terms "token-based" and "account-based" are frequently conflated across economics, computer science, and payment clearing, typically spanning three orthogonal dimensions: ^[1][2]

1. Value Representation: Whether monetary value is recorded as an aggregated numerical balance under a single entity (Balance), or as discrete digital objects with unique identifiers (Discrete Value Object).
2. Verification Logic: Whether verification targets the initiator's access identity and operational permissions ("Who are you, and can you operate this account?"), or the authenticity and validity of the value carrier itself ("Is this token authentic, and has it already been spent?").
3. Underlying Data and Ledger Model: Whether the system uses a centralized relational database (Centralised Database) or Distributed Ledger Technology (DLT). Even within the blockchain domain, Bitcoin relies on the Unspent Transaction Output (UTXO) model, which closely resembles discrete token verification, whereas Ethereum operates on an account-based state model that directly tracks balances and nonces for each address.

[Account-based]  A: 100 ──(Verify Identity / Permissions / Balance)──> Debit A 20 / Credit B 20 ──> A: 80, B: 70
[Token-based]    Token #001 ──(Verify Token Validity / Signature)──> Transfer Control Claim ──> Token #001 Owned by B

A common misconception equates token-based systems directly with "digital cash." Physical banknotes naturally support peer-to-peer exchange because physical objects possess spatial exclusivity—once a banknote is handed over, the original holder no longer possesses it. The digital realm, by contrast, is composed of data, which is inherently replicable. Without deliberate preventive mechanisms, identical digital data could be transmitted simultaneously to multiple payees.

Consequently, digital tokens cannot function in a vacuum without a ledger. They must rely on an authoritative mechanism to prevent double spending. Whether enforced via consensus algorithms across a decentralized network or through tamper-resistant hardware security chips during offline transactions, digital tokens are fundamentally sustained by a state-recording and verification network.

2. Practical Trade-offs: Identity, Control, and Recovery Costs

The selection of an accounting paradigm for financial market infrastructures represents an engineering trade-off.

The Account-based Model

The account-based model represents the most established path for modern commercial banks and retail payment networks. Its defining characteristic is the tight coupling between asset control and verified legal identity:

• Direct Compliance and Risk Control Integration: Customer Due Diligence (Know Your Customer, KYC), Anti-Money Laundering (AML), and sanctions screening can be embedded directly at the account access gateway.
• Comprehensive Policy and Administrative Tools: Balance caps, tiered interest rates, holding limits, and judicial freezing are structurally straightforward, requiring only parameter adjustments or operational holds at central nodes.
• Mature Dispute Resolution and Disaster Recovery: If a user forgets a password or damages a physical device, they do not lose ownership of their underlying funds. Banks or Payment Service Providers (PSPs) can restore account access through offline identity verification, biometric authentication, or credential reset protocols.

The International Monetary Fund (IMF) highlighted in its research on CBDC cyber resilience that the core defense perimeter of an account-based architecture centers on identity verification, credential management, and access controls. ^[3] However, this model introduces corresponding costs: users remain entirely dependent on the continuous online availability of centralized institutions; ledger operators accumulate comprehensive transaction relationship graphs, demanding stringent data privacy governance; and in offline environments disconnected from networks, centralized ledgers cannot execute real-time debits and credits.

The Token-based Model

The token-based model shifts emphasis from identity-gated access to asset control claims. Users execute value transfers by signing transaction instructions with cryptographic private keys. This architecture unlocks unique functional capabilities:

• Machine-to-Machine and Conditional Value Flows: Tokens are well suited for encapsulation within programmable logic, serving as friction-free settlement units across Internet of Things (IoT) devices or on-chain smart contracts.
• Homogeneous Representation of Money and Assets: In a shared operating environment, cash can share identical data schemas with tokenised financial assets, establishing the technical foundation for atomic transactions.

However, this design relocates operational risk to key security and system governance:

• Irreversibility of Key Loss or Theft: Without custodial intermediation, the principle of "holding the private key equals owning the asset" means that private key destruction results in permanent financial loss, and stolen assets cannot be recalled through technical reversing entries.
• Hardware Dependency for Offline Anti-Double-Spending: Preventing double spending without real-time online verification requires tamper-resistant hardware security modules, such as a Secure Element (SE), which poses formidable engineering and manufacturing hurdles.
• Divergence Between Technical Control and Legal Title: Whether holding a cryptographic token legally constitutes a direct liability claim against the issuer remains subject to complex legal definitions regarding bankruptcy remoteness, judicial clawbacks, and cross-jurisdictional portability.

3. Why Tokens Coexist with Blockchains: Eliminating Reconciliation, Not Central Ledgers

In discussions of financial market infrastructure, a fundamental question often arises: given that central bank reserves and commercial bank deposits have long been electronic, why are global institutions committing substantial resources to tokenisation and blockchains?

Within Luminale's analytical framework for payment infrastructures, the primary driver is not an ideological pursuit of decentralization, but an economic imperative: eliminating the immense cost of cross-institutional reconciliation across siloed ledgers.

In traditional financial markets, asset and cash legs are segregated across isolated proprietary systems:

• Securities registries are maintained by a Central Securities Depository (CSD);
• Cash settlement is executed across a central bank's Real-Time Gross Settlement (RTGS) system;
• Commercial banks maintain customer deposit ledgers within internal core banking platforms;
• Exchanges and clearing houses track order matching and counterparty exposures.

When a bond transaction executes, the absence of a shared state machine forces disparate systems to communicate asynchronously via ISO 20022 or SWIFT messaging networks. The CSD transmits a payment request message to the RTGS; the RTGS debits and credits reserve accounts before returning a payment confirmation message; upon receiving this receipt, the CSD updates its securities ownership registry. Every handoff point introduces potential risks of message loss, network timeouts, and state discrepancies, requiring financial institutions to expend immense computational resources and manual labor on end-of-day reconciliation and dispute resolution.

When financial assets and settlement funds are deployed as standardized tokens on a shared ledger or across interoperable programmable platforms, the financial infrastructure achieves critical structural upgrades:

1. Unification within a Single State Machine: Trade conditions, compliance checks, and settlement logic are encapsulated within a single atomic transaction, eliminating inter-system messaging latency.
2. True Delivery versus Payment (DvP) and Payment versus Payment (PvP): Transactions achieve atomic settlement—the asset transfer and the cash settlement either execute simultaneously or fail entirely, eliminating principal settlement risk (Herstatt Risk).
3. Elimination of Post-Trade Inter-Institutional Reconciliation: Participating institutions share an identical, synchronized record of truth. The shared ledger itself serves as the definitive record of final settlement, unlocking significant liquidity previously trapped in transit.

Empirical testing of this architecture is well advanced. Project Jura, led by the BIS Innovation Hub alongside the Swiss and French central banks, demonstrated the feasibility of conducting cross-border PvP for foreign exchange and DvP for commercial paper on a single distributed platform using tokenised wholesale central bank reserves. ^[4]

The Swiss National Bank (SNB) outlined in its Project Helvetia reports two primary technical avenues for settling tokenised assets in central bank money: first, issuing wholesale central bank money directly as a digital token on a DLT platform; second, retaining the existing centralized RTGS system while establishing a cross-system trigger mechanism to link the DLT platform with the RTGS. The native token approach provides superior programmability and atomic settlement efficiency, while the trigger approach preserves existing central bank governance frameworks with lower transition costs. ^[5]

Project Agorá, advancing through 2026, combines tokenised commercial bank deposits with tokenised wholesale central bank reserves on a unified programmable platform to test cross-currency cross-border settlements. ^[6] This trajectory underscores that tokenisation does not discard traditional financial architecture, but rather leverages modular composability to fundamentally re-engineer multi-ledger synchronization.

4. The Source of Truth: When Accounts and Tokens Coexist, Which Ledger Governs?

In institutional practice, emerging technology rarely displaces legacy infrastructure overnight. The standard environment is hybrid: commercial banks run core relational databases for statutory customer deposits, while secondary platforms operate tokenised claims.

This setup introduces a pivotal engineering and legal question: If a single unit of fiat currency exists simultaneously across account-based and token-based environments, which ledger represents the authoritative Source of Truth?

Without strict technical and legal constraints, the same underlying funds could be pledged or spent simultaneously across both environments, triggering systemic unbacked expansion. To guarantee monetary conservation and settlement finality, payment systems generally adopt one of three coordination architectures:

Model 1: Single Authoritative Ledger with Derived Tokens

Under this architecture, the core account ledger maintained by the central bank or a commercial bank serves as the sole legal and accounting source of truth. Tokens circulating on secondary chains represent controlled digital claims on off-chain collateral.

When funds migrate into tokenised environments, they must first be debited or locked in a segregated custody/escrow account within the core banking system. A compliance gateway or smart contract subsequently mints an equivalent volume of tokens on-chain. When a token holder redeems back into traditional accounts, the smart contract burns the tokens, and upon receiving cryptographic proof of burn finality, the gateway signals the core banking system to release and credit the locked funds.

The legal source of truth remains anchored in the traditional account. In the event of an on-chain smart contract exploit, unauthorized re-entrancy, or network hard fork, statutory claims and bankruptcy entitlements are determined strictly by the actual balances held within the core escrow account.

Model 2: Dual Co-equal Authority with State Handoff

In wholesale digital currency pilots, central banks often accord equal statutory settlement finality to both the legacy RTGS ledger and the new DLT settlement platform, with each managing non-overlapping segments of the monetary base.

A prominent example is the Swiss National Bank's Project Helvetia Phase III pilot: wholesale CBDC (wCBDC) issued on the SIX Digital Exchange (SDX) platform carries identical legal status and economic equivalence to sight deposits held on the Swiss traditional RTGS system (SIC). ^[7]

To prevent liquidity double-spending, the SNB enforces a strict State Handoff mechanism:

• When a commercial bank requires wCBDC to settle tokenised bond issuances on SDX, it debits its sight deposit reserves within SIC during operational hours;
• Upon verification of the debit, an equivalent volume of wCBDC is created on SDX;
• At the close of the business day, all unused wCBDC is de-tokenised and burned on SDX, with corresponding reserve balances automatically re-credited to the bank's primary RTGS account.

Both ledgers are statutory sources of truth, but at any given microsecond, an individual unit of sovereign central bank liability can hold an active, spendable state in only one system.

Model 3: Hybrid Online Account & Offline Token Architecture

This dual-state architecture is widely deployed in retail CBDC designs to enable dual-offline payments.

Under normal conditions, the central bank and operating intermediaries maintain an online account ledger tracking total balances. When a user requires offline functionality, funds must be pre-funded or "cashed in" from the online account into a hardware Secure Element (SE) embedded in a smartphone or smart card:

Online Core Ledger debited by 500 dollars ──> Hardware SE provisioned with 500 dollars of offline value claims

When two devices transact in an environment devoid of cellular or internet connectivity, they execute peer-to-peer transfers via Near Field Communication (NFC). Because neither device can contact the central ledger, the transaction relies on internal monotonic anti-replay counters, cryptographic hardware certificates, and private key signatures within the SE chips.

This introduces a fundamental ledger consistency challenge: If a hardware chip is physically compromised, or if a user attempts malicious double spending across multiple offline recipients before reconnecting, which record prevails?

If the central online ledger is unconditionally authoritative and rejects payment to a bona fide payee upon reconnection, offline payments lose commercial certainty. Conversely, if the central bank honors all unverified claims, it assumes unhedged credit risk from counterfeit value creation. Consequently, hybrid architectures rely on strict risk-mitigation frameworks:

• Imposing strict caps on single-transaction amounts and cumulative offline transaction counts;
• Enforcing mandatory synchronization time windows, requiring devices to reconnect periodically;
• Establishing contractual risk-sharing rules that allocate losses among chip manufacturers, wallet operators, merchants, and contingency reserve funds;
• Defining in statutory law that an offline handover constitutes a conditional claim transfer, with full legal finality consummated upon online clearing and settlement.

5. CBDC Ledger Architectures: Distinguishing Retail and Wholesale Engineering Demands

When designing digital currency ledgers, retail central bank digital currency (Retail CBDC) and wholesale central bank digital currency (Wholesale CBDC) must be evaluated separately. Their target users, risk priorities, and performance constraints diverge, leading to distinct architectural paradigms.

Retail CBDC: Account-based Core with Controlled Token Features

Retail CBDC serves hundreds of millions of individual citizens and small merchants. Its primary engineering priorities are high throughput, broad accessibility, disaster recovery, and AML/CFT compliance.

If a retail system relied strictly on unpermissioned, private-key-driven tokens, users would bear sole responsibility for private key custody. Key loss would mean irrecoverable asset loss—an unacceptable barrier for public consumer payments. Furthermore, purely bearer tokens without identity anchors impede statutory transaction limits and fraud detection.

Consequently, major global retail CBDC initiatives adopt a Two-Tier Hybrid Architecture: ^[1]

• Core Settlement Tier: The central bank maintains a centralized, high-throughput account ledger (Direct or Hybrid Account Ledger) to record aggregate currency issuance and reserve liabilities to commercial banks, ensuring the system can process tens of thousands of peak transactions per second while providing statutory identity recovery channels.
• Intermediary and Distribution Tier: Commercial banks and non-bank PSPs manage customer-facing wallets, distribute currency, and conduct compliance checks. Token-based mechanisms are deployed modularly—specifically within hardware secure elements for dual-offline payments and small-value managed anonymity.

This two-tier framework safeguards financial stability and prevents commercial bank disintermediation, while delivering the convenience required of modern payment instruments.

Wholesale CBDC: Embracing Shared Ledgers and Tokenised Financial Networks

Wholesale CBDC serves commercial banks, non-bank financial institutions, and clearing houses. These institutions already maintain reserve accounts at the central bank, and interbank transfers within RTGS systems have long been electronic.

In the wholesale domain, the primary demand for tokenised ledgers is breaking down systemic silos between financial assets and settlement cash.

Wholesale participants engage in bond issuances, foreign exchange trading, syndicated lending, and real-time margin adjustments. In these complex workflows, the time lag between asset delivery and cash payment introduces substantial counterparty risk.

By issuing or mapping central bank money directly as a token on shared financial market platforms, wholesale CBDC integrates into smart contracts, binding payment and delivery into a single immutable transaction to deliver continuous, atomic settlement finality.

Conclusion: The True Substance of Ledger Evolution

The evolution of digital currency is not a wholesale replacement of accounts by tokens, nor does it render traditional principles of clearing and settlement obsolete.

The transition from account-based to token-based paradigms alters the structural representation and topology of monetary claims:

• Account-based systems leverage centralized identity verification and state aggregation to secure institutional governance, customer recovery, and administrative flexibility;
• Token-based systems leverage discrete cryptographic control claims to achieve programmable composability and seamless cross-platform orchestration.

Every operational digital currency system remains bound by foundational rules: defining legal claims, preventing double spending, and providing an unambiguous statutory basis for settlement finality.

The maturity of a financial market infrastructure is not measured by whether it adopts blockchain or token labels, but by whether its multi-ledger architecture maintains monetary conservation, harmonizes clearing and settlement, and guarantees definitive, enforceable legal finality.

References

[1]: Bank for International Settlements, "Central bank digital currencies: System design," 2024-11-26. BIS ↩

[2]: Bank for International Settlements, "High-level technical requirements for a functional central bank digital currency (CBDC) architecture," 2023. BIS PDF ↩

[3]: International Monetary Fund, "Cyber Resilience of the Central Bank Digital Currency Ecosystem," IMF FinTech Note, 2024. IMF ↩

[4]: Bank for International Settlements, "Project Jura: Cross-border settlement using wholesale CBDC," 2021-12. BIS ↩

[5]: Bank for International Settlements & Swiss National Bank, "Project Helvetia: Settling tokenised assets in central bank money," 2020-12. BIS ↩

[6]: Bank for International Settlements, "Project Agorá: Building on the unified ledger concept," 2026-05. BIS ↩

[7]: Swiss National Bank, "Project Helvetia III: The Swiss National Bank's pilot for wholesale CBDC," Speech, 2024-05. BIS ↩

Originally published by Luminale Fintech Observer: https://luminale.cn/articles/digital-currency-ledger-account-token-cbdc-design-en