Each transition needs an explicit rule governing whether it:

• creates ledger entries;
• reserves available funds;
• releases a reservation;
• changes a pending position;
• creates a posted position;
• triggers an external instruction;
• requires evidence from another operational perimeter;
• permits a later return, reversal or adjustment.

An accepted payment instruction does not necessarily create a posted financial position. An authorisation may affect available funds while leaving the posted balance unchanged. Settlement may confirm an existing posting or create the event that permits posting, depending on the ledger’s operating model.

Two-phase transfer models make this separation explicit. A pending transfer reserves value and later resolves through posting, voiding or expiry. Systems such as TigerBeetle preserve each resolution as an immutable transfer linked to the original pending event. The state transition changes the usable financial position while retaining the full history.

Different payment instruments require different transition maps. Card authorisation and capture, an instant credit transfer, an ACH debit, an internal wallet transfer and a tokenised deposit transaction carry distinct return rights, timing rules and settlement evidence.

The ledger should preserve those differences without embedding every provider’s vocabulary into its core model. An integration layer maps external events into a controlled internal taxonomy. The mapping records the provider, event version, external reference and evidence that justified the transition.

The architecture should therefore define completion as a scoped statement:

Which object completed, inside which operational perimeter, under whose authority, and with what remaining possibility of rejection, return or reversal?

That definition allows product interfaces, treasury systems, finance teams and risk controls to consume the same transaction without assigning the same meaning to every state.

The posted balance follows ledger entries. The available balance also reflects policy.

Its calculation may include:

• outbound holds and reservations;
• spendable credit limits;
• risk or liquidity buffers;
• pending incoming funds accepted for provisional use;
• withdrawal restrictions;
• account-level minimums;
• chargeback or return exposure;
• intraday limits;
• asset-specific haircuts.

A system that credits an unsettled incoming payment to available balance extends some form of risk capacity. The architecture should identify who approved that policy, which accounts qualify, how much exposure it permits and what happens if the expected funds fail to settle.

An API field named only balance hides these decisions. Each exposed value should carry a defined balance type, currency or asset, account identifier, calculation time and journal position.

Concurrent payment instructions can observe the same available balance. If two application services each read 100 units and independently approve withdrawals of 80, both pre-checks succeed while the combined result exceeds the permitted position.

The ledger must enforce the relevant invariant when it accepts the postings or reservations. Application-side balance checks can improve user experience, but they cannot serve as the final financial control.

Implementations may use serial execution, account locks, compare-and-set balance versions or another deterministic concurrency mechanism. The guarantee remains the same: all transactions competing for the same constrained value must pass through one authoritative decision point.

High-volume ledgers usually maintain precomputed balances, materialised views or account aggregates. These records support low-latency reads without summing the full journal for every request.

A cached balance should remain reproducible from accepted entries. It needs a journal sequence, account version or equivalent marker that shows exactly which postings it includes. Recovery procedures must be able to rebuild the balance and detect divergence between the journal and its read models.

Historical queries also require explicit time semantics. A balance “as of” a date may refer to the entry’s recorded time, effective time or settlement date. The requested basis should remain part of the query and result.

The technical model described by Modern Treasury separates posted, pending and available balances and derives them from ledger entries. The broader architectural principle is stable: a balance becomes reliable when its included states, governing policy and journal position are explicit.

Consider a payment company that holds customer money in one pooled bank account. The bank ledger may show a balance of 1 million units. That record establishes the company’s or safeguarded account holder’s claim against the bank.

The internal ledger may allocate the same economic pool among 20,000 customers. Its customer liability accounts establish how much the platform owes each user.

Neither record replaces the other. The bank does not know the platform’s complete internal allocation. The internal ledger cannot prove that the corresponding cash remains at the bank. The architecture needs both records and a defined relationship between their totals.

This distinction becomes especially important in banking-as-a-service architecture, where a sponsor bank, programme manager, processor and middleware provider may each operate a different record. Contractual responsibility, write authority and technical possession of data can sit with different parties.

Caches, balance tables, search indexes, data warehouses and reporting platforms can reproduce ledger information. They remain derived records.

A derived system should carry enough provenance to identify:

• the originating ledger;
• the journal sequence or account version included;
• the extraction or event-processing time;
• transformations applied to the data;
• any known lag or incomplete partitions.

A warehouse report can support analysis and regulatory production. It cannot create or reverse a customer financial position unless the architecture explicitly routes an authorised transaction back through the ledger’s write path.

The same principle applies to replicated ledger databases. A replica may serve authoritative data, but the authority comes from the accepted journal and its controlled replication process. The replica does not gain independent write authority.

Every connection between ledgers needs a boundary contract. That contract defines how one system interprets evidence from another.

A complete contract normally specifies:

• account and party mappings;
• transaction and external reference identifiers;
• currency, amount and precision rules;
• state translations;
• expected event sequence;
• timing and cut-off assumptions;
• settlement or completion evidence;
• retry and duplicate behaviour;
• correction and return handling;
• ownership of unresolved exceptions.

The contract should also identify which external event can justify an internal posting. A provider’s accepted event may only confirm receipt. A bank statement entry may confirm a booked account movement. A settlement-system confirmation may establish finality for the participant transfer. These events carry different evidential weight.

Two systems can remain internally consistent while their combined records become inconsistent. The internal ledger may balance perfectly even though an external payment failed. The bank account may contain the correct aggregate cash while the customer subledger allocates that cash incorrectly. Internal invariants and cross-system agreement protect different properties.

Ledger architecture defines the expected relationship and the records that carry authority. Reconciliation architecture tests whether those independently maintained records continue to satisfy that relationship.

Inside a canonical ledger, relevant accounts and postings enter one controlled journal. Customer balances, fees, reserves, clearing positions and other product accounts share common transaction and control rules.

One transaction can then update several accounts atomically. The same boundary creates a central operating dependency: new products, account models and posting rules enter a governed financial language.

Business states can remain in product systems. Orders, user journeys and provider workflows enter the canonical journal only when they create a financially meaningful event.

When currencies, assets, legal entities, jurisdictions or business lines need controlled separation, a ledger platform can place them in distinct partitions. The engine applies common technical controls and restricts which accounts may participate in one transaction.

A partition carries financial meaning only when it represents a real financial or control boundary. A cross-currency entry invokes an exchange model; a cross-entity entry creates intercompany positions or an external settlement step. Database atomicity leaves those obligations intact.

For every cross-partition transaction, the boundary specification states whether it:

• remains atomic inside the platform;
• creates balanced legs within each partition;
• uses due-to and due-from accounts;
• waits for an external settlement event;
• requires a bridge, clearing or orchestration process.

Where products maintain specialised subledgers for cards, wallets, lending, rewards or merchant settlement, each domain can use its own states and account structures.

Across those domains, an inter-ledger protocol connects the two financial effects. A wallet-to-card movement uses one shared transaction identity, defined intermediate positions and recovery rules for partial progress, so the debit and credit remain parts of the same business event.

If a central accounting ledger receives summarised or event-level postings, the product subledger retains authority for detailed operational positions and the central ledger owns entity-level accounting classification. Their transfer contract is the control boundary.

Even on shared software, separate legal entities commonly operate separate ledgers. Each entity controls its own accounts, obligations, permissions and reporting periods.

When a customer movement passes through two entities, it creates a position in each perimeter. Intercompany receivables or payables may arise, together with settlement accounts or prefunded balances. A global customer identifier connects the records while the underlying liabilities remain separate.

Where jurisdictional separation applies, it can support local settlement assets, access rules, data-location requirements and regulatory control. The Federal Reserve’s 2026 ledger analysis provides the institutional example: accounts connect distinct perimeters while implementation and governance stay separate.

When an external system owns the authoritative asset record, location of authority follows the asset. A bank controls a deposit account. A securities infrastructure controls an ownership record. A blockchain network controls the state represented on-chain.

Internally, the platform may record customer entitlements, fees, pending instructions or accounting positions. Each entry identifies whether the claim originates inside the platform or depends on confirmed external state.

Because the external ledger controls the asset, its availability, correction model, privacy rules and finality shape the internal architecture. Confirmation thresholds and event-ingestion controls govern the connection, with explicit treatment for chain reorganisations, provider corrections or disputed external records where relevant.

Inside one ledger transaction, entries can commit atomically. Across independently controlled ledgers, atomicity ends at the authority boundary.

Cross-ledger movement may require:

• prefunding;
• reservations and releases;
• clearing accounts;
• bilateral credit;
• synchronised settlement;
• conditional execution;
• compensating transactions;
• reconciliation after independent posting.

The topology decision answers a structural question: which financial invariants must hold inside one authority boundary, and which relationships can be managed between separately authoritative systems?

The UK Prudential Regulation Authority defines a tokenised deposit as a deposit claim represented on a programmable ledger. In a transferable model, the token remains a liability of the issuing deposit-taker and the recipient becomes a customer of that institution. The PRA also notes that market definitions continue to evolve.

The token can support programmability, atomic settlement and continuous transfer availability. The issuing bank still owns the liability model, customer eligibility, redemption obligation and prudential controls.

A transfer between two holders of the same bank’s tokenised deposit can remain inside one issuer perimeter. A transfer involving deposits issued by different banks introduces separate liabilities. The architecture then needs a settlement asset, exchange mechanism, shared platform or interbank obligation that connects them.

Project Agorá applies this distinction directly. Tokenised commercial-bank deposits remain claims against their respective banks, while tokenised central-bank reserves provide a settlement mechanism between institutions. The 2026 Agorá report concludes that tokenisation in its prototype does not alter the legal character of the represented balances.

Token issuance often links a conventional account or reserve record with a programmable ledger. The architecture must prevent value from remaining independently usable in both representations.

A controlled issuance sequence may include:

1. receiving an issuance instruction;
2. confirming funds or another eligible backing position;
3. restricting or debiting the original position;
4. minting the corresponding tokens;
5. linking both actions through one issuance identifier.

Redemption reverses that relationship:

1. the holder submits a redemption instruction;
2. the system locks or burns the tokens;
3. the issuer confirms the off-ledger credit or asset release;
4. the ledger closes the redemption state with external evidence.

Failure between these steps creates a distributed-state problem. A burn cannot remain completed without a recoverable redemption obligation. A bank credit cannot be retried as a new redemption after the token has already been consumed.

The ledger should preserve issuance, circulation and redemption as distinct transaction types. Supply controls need to show the quantity minted, burned, locked and available for transfer, together with the corresponding issuer or reserve position.

Recent services demonstrate how tokenised deposits are entering operating payment environments while remaining inside bank-controlled perimeters.

HSBC expanded its Tokenized Deposit Service to the United States in April 2026. The service supports eligible corporate and institutional clients across several jurisdictions and currencies, with 24/7 domestic and cross-border transfers and integration into existing treasury infrastructure. HSBC remains the service and deposit provider.

In July 2026, Siam Commercial Bank became the first financial-institution client reported live with Citi’s integrated 24/7 USD Clearing and Citi Token Services solution. Citi describes the tokens as deposits held within its own global network and uses its clearing service to connect Citi and non-Citi accounts. The first reported transaction crossed the US holiday weekend.

These services extend operating hours and programmability. Their ledger architecture still needs to identify the issuing bank, the represented deposit, the point at which another bank receives settled funds and the record that proves each stage.

Institutions increasingly consume wallets, mint-and-burn workflows and policy controls through managed platforms. Visa introduced its Stablecoin Platform in July 2026 with wallet infrastructure, bank-account connectivity, approval policies, allowlists, audit logging and mint, burn, hold and transfer functions. The service remains in beta testing with selected clients.

A managed interface can control operational access to a token ledger. It does not automatically become the issuer record, reserve ledger or legal source of the represented claim. The architecture should preserve those authority boundaries even when one service presents them through a unified API.

The critical design rule remains stable: the location of a token, the location of its backing and the location of the legal liability may coincide or remain separate. The ledger must state which arrangement applies.

Even with equal debits and credits, a transaction can use the wrong accounts.

Consider a customer deposit credited to revenue instead of a customer liability account. Total debits and credits remain equal. The journal is balanced; the institution’s obligation is misrepresented.

Control discipline extends from posting code to transaction templates, account eligibility rules and financial classification. Their changes pass through approval and versioning, with test cases based on expected economic positions.

By retaining the transaction type and rule version behind each posting, the ledger gives investigators the evidence needed to locate the semantic error in the instruction, mapping, rule set or posting engine.

Across an authority boundary, two systems can each contain a locally valid record and still disagree.

For example, an internal ledger may correctly show a payment as pending after the provider has rejected it; a bank account may hold the correct aggregate cash while the customer subledger allocates it incorrectly; or a settlement system may complete an interbank transfer before the receiving institution credits its customer.

Shared identifiers connect these records. Reconciliation then tests the relationship defined by the ledger model: which states should agree, at what level and within what timing tolerance.

During operational recovery, the target is accepted state with its original transaction identities.

Replaying an event stream, resubmitting an outbound instruction or rebuilding a balance view uses those identities. If a recovery tool generates new identifiers for previously accepted actions, restoration can create duplicate payments.

When an external action is pending, recovery distinguishes an instruction that was never sent from one sent with an unknown response, accepted by the provider or completed externally. Network uncertainty triggers evidence retrieval and an idempotent retry under the existing identity. It does not establish payment failure.

Some of the most consequential ledger weaknesses leave normal health indicators intact. Databases remain available. Transactions balance. APIs return successful responses.

Architecture tests expose those silent conditions through the following scenarios:

• two concurrent instructions spending the same available funds;
• a duplicated provider event;
• an external response lost after successful execution;
• a completion event arriving before an acceptance event;
• a partial capture followed by expiry;
• a return received after period close;
• a posting routed to the wrong legal entity;
• a correction applied twice;
• failover during transaction acceptance;
• token minting followed by failure of the corresponding funding restriction;
• reconstruction of every balance from the journal;
• reconstruction of every external movement from linked references.

The resulting evidence identifies the affected position and its transaction identity, contains further movement and supports restoration of agreement without rewriting the financial past.

For cross-system control, the ledger exposes the following evidence:

• immutable transaction and entry identifiers;
• business-instruction and idempotency references;
• provider, bank and network references;
• account and legal-entity mappings;
• transaction state and state-transition history;
• recorded, effective and settlement times;
• posted, pending and reserved positions;
• journal sequence or account version;
• links between original, reversal, return and adjustment transactions;
• balance snapshots tied to a defined journal position.

At each external boundary, the expected relationship specifies which records agree, the level of comparison, the timing assumptions and the state transition after which comparison becomes valid.

Depending on the claim, comparison occurs at a different level. A customer-liability ledger may reconcile in aggregate to safeguarded bank balances while retaining customer-level detail internally. A processor clearing account may reconcile by transaction reference; a settlement account, by participant position and settlement cycle.

When reconciliation discovers a break, it may indicate a missing event, duplicated posting, incorrect account mapping, timing difference or external failure. Resolution stays inside the ledger’s controlled write path.

Through that path, an authorised correction enters as a new posting, reversal, adjustment or state transition linked to the original event. Reconciliation tooling passes the finding and supporting evidence to the ledger; it neither overwrites journal entries nor sets balances directly to an externally observed total.

Detailed matching strategy, exception classification, break ownership, ageing, investigation and remediation belong to reconciliation architecture. At the handoff, the ledger supplies the authoritative internal state, immutable identifiers and expected relationship; reconciliation returns a documented break or confirmation of agreement. Any financial change then re-enters through an authorised ledger transaction linked to that evidence.