CBDC, stablecoin, tokenised-deposit, FX, payment-versus-payment, CLS, trade-finance, and alternative cross-border architecture

Customer, institution, or market participant

Holds a legal claim or authorised access and initiates payment, exchange, redemption, or trade settlement.

Kind

actor

Owner

Participating customer or institution

Responsibilities

• Prove authority over the relevant account, wallet, asset, or obligation
• Understand which entity owes the claim

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Participant eligibility
• Identity and entitlement
• Jurisdiction and product rules

Failure modes

• Wrong participant or wallet
• Unauthorised transfer
• Claim misunderstood

Recovery

• Stop the instruction
• Restore authority and correct ownership records under the governing arrangement

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Access, wallet, custody, and participant gateway

Protects keys or account access, validates participant eligibility, and submits signed or authenticated instructions.

Kind

gateway

Owner

Wallet, custodian, bank, or infrastructure participant

Responsibilities

• Separate customer authority from operator authority
• Protect key, account, and transaction context

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Identity and entitlement
• Key or credential lifecycle
• Transaction integrity
• Replay prevention

Failure modes

• Lost key
• Custody outage
• Compromised participant

Recovery

• Suspend access without destroying the underlying claim
• Recover through the arrangement's authorised process

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Money or settlement-asset issuer

Defines the claim, issuance, redemption, backing, liability, and holder rights for central-bank money, tokenised deposits, or stablecoins.

Kind

external-network

Owner

Central bank, commercial bank, or arrangement issuer

Responsibilities

• Issue and redeem only under governing rules
• Keep liability, backing, and holder claim explicit

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Issuance authority
• Backing or reserve control
• Reconciliation and attestation
• Redemption terms

Failure modes

• Unbacked issuance
• Redemption suspended
• Issuer and ledger records diverge

Recovery

• Stop issuance
• Reconcile liabilities and backing
• Apply resolution and holder-protection arrangements

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Token, account, or settlement ledger

Records ownership or account balances and the state transition that the arrangement recognises.

Kind

ledger

Owner

Ledger or settlement-system operator

Responsibilities

• Apply an authorised state transition once
• Record ordering, finality condition, and reversal or correction authority

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Consensus or central ordering
• No double spend
• Balance conservation
• Finality rule

Failure modes

• Fork or inconsistent state
• Duplicate transfer
• Finality ambiguity

Recovery

• Pause unsafe finalisation
• Recover from an agreed checkpoint
• Reconcile participant and issuer records

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Interoperability and bridge boundary

Moves an instruction or representation between ledgers, account systems, jurisdictions, or technology stacks without pretending the two assets are the same.

Kind

gateway

Owner

Arrangement operators and participants

Responsibilities

• Name lock, burn, mint, escrow, prefunding, messaging, and legal mechanisms precisely
• Prevent value creation from inconsistent cross-system state

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Two-sided state proof
• Supply conservation
• Timeout and rollback
• Operator and legal responsibility

Failure modes

• Source locked but target not issued
• Bridge compromise
• Duplicate representation

Recovery

• Stop bridge processing
• Prove both sides before release
• Use governed compensation or redemption

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Foreign-exchange matching and payment-versus-payment control

Links two currency legs so final transfer of one occurs only with final transfer of the other under the arrangement.

Kind

control

Owner

FX settlement system or linked operators

Responsibilities

• Match both legs and participants
• Enforce payment-versus-payment rather than merely simultaneous message submission

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Trade and instruction match
• Currency-leg readiness
• Liquidity and cut-off
• Atomic or conditional finality

Failure modes

• One leg ready and the other missing
• Liquidity shortfall
• Cut-off missed

Recovery

• Keep both legs unsettled where the model permits
• Resolve liquidity or cancel under the governing rules

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Asset, document, or trade obligation

Represents the security, commodity, invoice, document, or trade obligation exchanged against payment.

Kind

ledger

Owner

Market infrastructure, custodian, registry, or trade platform

Responsibilities

• Prove entitlement and transfer conditions
• Link delivery state to the cash leg where delivery-versus-payment is intended

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Asset authenticity
• Transfer restriction
• Delivery-versus-payment condition
• Document and title control

Failure modes

• Asset unavailable
• Document discrepancy
• Cash and asset states diverge

Recovery

• Hold both legs when possible
• Open an exception with legal and operational ownership

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Policy, compliance, risk, and privacy controls

Applies participation, financial-crime, data, monetary, prudential, consumer, and market rules appropriate to the arrangement.

Kind

control

Owner

Issuer, participant, operator, compliance, legal, and risk owners

Responsibilities

• Apply controls to the actual parties, claims, assets, and jurisdictions
• Keep privacy and audit requirements compatible

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Sanctions and anti-money-laundering
• Limits and eligibility
• Privacy and disclosure
• Governance and change

Failure modes

• Pseudonym treated as anonymous
• Control absent at bridge
• Rule conflicts across jurisdictions

Recovery

• Hold or reject under authority
• Escalate legal conflict
• Preserve evidence without unnecessary disclosure

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Liquidity, settlement, reconciliation, and incident operations

Monitors positions, funding, ledger state, bridge state, redemption, both FX legs, asset delivery, and external account evidence.

Kind

operations

Owner

Arrangement and participant operations

Responsibilities

• Identify the last confirmed state on every ledger and claim
• Reconcile issuance, backing, settlement, redemption, and external cash

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Multi-ledger reconciliation
• Liquidity thresholds
• Incident authority
• No unsupported replay

Failure modes

• Token moves but bank cash does not
• Redemption queue ages
• One FX leg uncertain

Recovery

• Freeze affected path
• Trace every claim and ledger
• Recover under the arrangement's legal and technical rules

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Authorised instruction

ev-user → ev-access

Submit payment, exchange, delivery, redemption, or issuance intent.

Contract

api · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Reject unclear authority or unsupported asset and jurisdiction.

Eligibility and control request

ev-access → ev-compliance

Apply participant, transaction, asset, and jurisdiction controls.

Contract

control · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Hold when required controls are unavailable or inconclusive.

Controlled ledger instruction

ev-compliance → ev-ledger

Release an authorised state transition.

Contract

control · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Preserve rejected, held, and expired states.

Issuance and redemption authority

ev-instrument → ev-ledger

Change instrument supply or liability under governing rules.

Contract

posting · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Stop supply change when backing, authority, or reconciliation is uncertain.

Source-ledger state proof

ev-ledger → ev-interoperability

Prove lock, burn, final transfer, or other source condition.

Contract

event · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Do not create target value from incomplete or unverified source state.

Target-ledger action

ev-interoperability → ev-ledger

Complete the governed cross-system action without duplicating supply.

Contract

posting · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Use timeout and compensation rules for incomplete two-sided state.

Currency-leg readiness

ev-ledger → ev-fx-pvp

Make each matched currency leg ready for conditional settlement.

Contract

settlement · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Keep the pair unsettled when required readiness or liquidity is missing.

PvP settlement release

ev-fx-pvp → ev-ledger

Finalise both currency legs under the arrangement's PvP rule.

Contract

settlement · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Record and resolve any residual uncertainty before participant credit.

Delivery-versus-payment condition

ev-ledger → ev-asset-leg

Coordinate cash and asset delivery when the arrangement supports it.

Contract

settlement · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Keep delivery and payment states visible if atomicity is unavailable.

Ledger, liability, and settlement evidence

ev-ledger → ev-ops

Reconcile instrument supply, claims, transactions, backing, and external settlement.

Contract

event · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Stop reopening when ledgers or backing do not reconcile.

Cross-system exception

ev-interoperability → ev-ops

Open a case when two systems disagree or time out.

Contract

event · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Keep both states and operator actions immutable.

Two-leg payment-versus-payment exchange

Follow two currency claims from authorised access to matched, conditional final settlement and reconciliation.

1. Submit the exchange — Two-leg intent created. The participant identifies both currency claims, parties, amounts, and settlement conditions.
2. Prove authority — Participant and instruction authenticated. The access layer proves who may move each claim.
3. Apply controls — Instruction eligible. Policy and compliance controls apply to parties, claims, jurisdictions, and arrangement.
4. Make both legs ready — Currency legs matched and funded. Each ledger or account system records readiness without finalising only one side.
5. Settle payment versus payment — Both legs final under the arrangement. The control releases one currency leg only with the other.
6. Record final ownership — Ledger states final. Both settlement records and participant positions now reflect the exchange.
7. Reconcile claims and settlement — Exchange reconciled. Participants reconcile matched instructions, both ledger outcomes, fees, liquidity, and external evidence.

Only one FX leg is ready

One currency leg lacks liquidity or valid settlement authority.

Last confirmed state

The pair is matched; only one leg is ready.

Settlement

Payment-versus-payment settlement has not completed.

Funds and entries

Neither leg should be treated as final under the illustrated PvP control.

Next owner

FX settlement operations

Safe action

Keep the pair unsettled, resolve liquidity or eligibility, and apply cut-off or cancellation rules.

Evidence required

• Matched instruction
• Both ledger states
• Liquidity position
• Cut-off and rule

Recovery

• Fund or correct the missing leg
• Settle both or expire/cancel under rules
• Reconcile positions

Cross-ledger bridge stops halfway

Source value is locked or burned but the target action is not confirmed.

Last confirmed state

The source-side condition is recorded; target-side state is uncertain.

Settlement

Cross-system settlement is incomplete.

Funds and entries

The user's usable value may be unavailable on both sides until recovery.

Next owner

Interoperability incident command

Safe action

Freeze the affected path and prove both ledger states before compensation, mint, unlock, or refund.

Evidence required

• Source proof
• Target proof
• Bridge event sequence
• Operator authority

Recovery

• Recover target or apply governed compensation
• Reconcile supply and liabilities
• Reopen only after two-sided proof

Redemption cannot complete

The token is surrendered but external bank-money payment is delayed or rejected.

Last confirmed state

Redemption request and token state are recorded.

Settlement

External cash settlement is not confirmed.

Funds and entries

The holder's token and issuer liability treatment depends on the governing arrangement.

Next owner

Issuer treasury and redemption operations

Safe action

Do not mark redemption paid; preserve the claim and apply documented retry, reinstatement, or refund treatment.

Evidence required

• Redemption ID
• Token burn or lock state
• Bank payment status
• Backing and liability records

Recovery

• Resolve external payment
• Restore or reissue claim if rules require
• Reconcile supply, backing, and holder record

What exactly does the holder own or claim?

• Explicit issuer liability — Makes redemption, insolvency, backing, and reporting questions visible.
• Technology-only token label — Hides the legal and financial meaning behind a ledger object.

Name issuer, holder claim, settlement asset, governing law, redemption right, backing, and finality before choosing technology.

How should two systems coordinate value?

• Governed interlink or common platform — Can make two-sided state explicit but concentrates operational, legal, and security dependencies.
• Uncontrolled representation or bridge — May appear simple but can create duplicate supply and unresolved claims.

Document source and target state, supply conservation, operator authority, timeout, compensation, finality, and incident ownership.