Skip to content

GRA · Fintech Nexus

Spatial financeWhere capital meets hazard, exposure and transition

Distributed ledgers and digital assets

Distributed ledger analysis examines shared records maintained by consensus, the code that runs on them and the tokens they carry. In finance it serves two questions: whether a ledger-based infrastructure can meet the standards required of settlement systems, and how failures in crypto-asset markets could spill into regulated finance.

01Register

Distributed ledgers and digital assets on the record.

Method recordSTEM method
  1. MethodDistributed ledgers and digital assets
  2. StewardFintech Nexus
  3. Applied inFintech Nexus
  4. Canonical pageSTEM Commons
02Application

What distributed ledgers and digital assets does here.

Distributed ledgers and digital assets use shared, replicated records maintained by consensus among participants. They support new forms of payment, asset registration and contracting, with distinct operational and financial risks. In capital markets and investment, cyber and digital resilience and digital public infrastructure, ledger analysis informs how digital asset failures could spill into payments and markets. It supports evaluation of ledgers for transparent registries and aid distribution. The canonical description is on the STEM Commons.

Settlement finality analysis

A ledger's consensus protocol, its exposure to reordering of recorded transactions and its rulebook are read together to establish when a transfer is technically and legally final, and where the two differ.

On-chain flow and reserve reconciliation

Public ledger data are used to reconcile stablecoin supply with issuer disclosures and to trace flows between platforms, with attribution uncertainty carried into every conclusion.

Contract and bridge design review

Contract code, upgrade keys, oracle dependencies and bridge designs are reviewed against the failure modes seen in past exploits, and for who holds the power to change the code.

03Exposure, loss and capital

What distributed ledgers and digital assets means for exposure, loss and capital.

The exposure, loss, scenario and capital views a risk officer, supervisor or ministry of finance would ask for, with the frameworks they report against. Structures follow supervisory and actuarial practice. Values are illustrative: never prices, ratings or advice.

Transmission channels

How a shock in distributed ledgers and digital assets reaches credit, market, underwriting, liquidity and operational risk, and feeds back.

Channel structure after the Basel Committee's work on climate-related risk drivers and transmission channels; links shown are typical paths, not estimated exposures.
NGFS climate scenarios · Network for Greening the Financial SystemIFRS S2 Climate-related Disclosures · ISSBTCFD recommendations · Financial Stability Board TCFDPrinciples for the effective management of climate-related financial risks · Basel Committee on Banking Supervision
04Data

What the method consumes.

Datasets and records used by distributed ledgers and digital assets on this platform, with the role each plays and the label its values carry. Sources are listed in the source register.

DataRoleLabel
Public ledger recordsSupply, flows and contract stateOBSERVED
Issuer reserve attestationsReserve composition and backingDECLARED
Contract code repositories and audit reportsCode review and exploit analysisREPORTED
Blockchain analytics attributionAddress clustering and entity labelsESTIMATED
Regulator registersAuthorised issuers and service providersPublished statistics
05Process

How the process runs.

Process explorer · Process

Distributed ledgers and digital assets: Payment from instruction to finality

8 steps4 stages

Process

Distributed ledgers and digital assets: Payment from instruction to finality

An RTGS system checks a payment, queues it if funds are short, settles it gross in real time and gives final settlement.

  1. 01 Intake

    1. 01Payment instructionSource · ParticipantThe system should use, or at least accommodate, relevant internationally accepted communication procedures and standards.
    2. 04Validity and conditionality checksStep · System operatorA payment is accepted once it passes validity and conditionality checks, such as funds or credit. An invalid payment is generally rejected.
  2. 02 Settlement

    1. 02LiquidityDataset · ParticipantParticipants need liquidity for outgoing payments: central or commercial bank balances, incoming payments and intraday credit.
    2. 05QueueModel · System operatorA valid payment that fails conditionality checks is queued or rejected. Queuing and other liquidity-saving tools can cut liquidity needs.
    3. 06Settle in real time, grossStep · System operatorRTGS settles payments continuously, without deferral, usually one by one. Money settlements should use central bank money where practical.
  3. 03 Finality

    1. 07Final settlementRecord · System operatorThe system gives clear, certain final settlement by the end of the value date at least, intraday or real time where needed.
    2. 08ReconciliationStep · System operatorReconciliation checks that records issued by two different entities match. The pages read state no timing for payment systems.
  4. 04 Resilience

    1. 03Business continuity and secondary siteExercise · System operatorThe plan uses a secondary site and aims to resume critical IT within two hours and settle by end of day. Arrangements are regularly tested.

Outline of an external standard or method, from its public sources. It describes what the framework says, not a record of any run. It does not show that Nexus or any partner performs, certifies or approves a step. A gate is a step of the method, never a Nexus approval. The source is the CPMI-IOSCO Principles for financial market infrastructures. A business continuity plan covers disruption.

06Validation

How results are checked.

Protocols and contracts are checked through formal verification, audits and adversarial testing. On-chain data allow independent reconciliation of balances and flows.

CheckHow it is done
Independent node dataLedger data are read from own or several nodes rather than one provider's interface
Attribution sensitivityConclusions are tested against alternative address clustering and entity labels
Reserve cross-checkOn-chain supply is compared with attested reserves at the same reference date
Version controlEvery review records the exact contract version and upgrade permissions examined

Code defects and governance disputes can cause irreversible losses. Links to the traditional financial system are often opaque.

07Connections

Topics that rely on this method.

08Stewardship

Who maintains the method.

Fintech Nexus stewards distributed ledgers and digital assets for the Consortium and reviews how it is applied across platforms.

09Questions

Questions and answers.

What are the limits of distributed ledgers and digital assets in this field?
Code defects and governance disputes can cause irreversible losses. Links to the traditional financial system are often opaque.
How are results checked?
Protocols and contracts are checked through formal verification, audits and adversarial testing. On-chain data allow independent reconciliation of balances and flows.
Are the values on this page real?
The data names, roles and checks are real descriptions of practice. The canvas shows a design of the method's use, not a run; no result is reported here.
Where else is this method applied?
The canonical method page lists every platform that applies it.
ReportsContribute

Contribute evidence from this page.

Reports is the Consortium's quarterly publication. What you know about this subject can become evidence, a case or a correction in the next edition, credited to you and published under CC BY 4.0 where it is your own work.

Global Risks AllianceFintech NexusExponential TechnologyFinance and Insurance Readiness
Fintech Nexus

Bring an exposure or capital question to the Alliance.

Information and enquiries are open today. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.