GRA · Fintech Nexus
Spatial financeWhere capital meets hazard, exposure and transition
Digital assets and tokenisation
Tokenisation records claims on money, securities and other assets as tokens on programmable ledgers, so that transfer, settlement and some servicing can happen on one platform. Central banks, commercial banks and market infrastructures are testing tokenised deposits, wholesale central bank money and tokenised bonds and funds. Design choices decide where settlement finality, legal certainty and operational risk sit. This page sets out how tokenised market infrastructure works, where its risks lie, and who decides its rules.
Digital assets and tokenisation on the record.
Digital assets and tokenisation: how the risk develops.
Digital market infrastructure and risks. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
The settlement asset decides the risk
A tokenised trade can settle in central bank money, tokenised commercial bank money or a stablecoin. Each carries different credit and liquidity risk, and the PFMI expect settlement in central bank money where practical and available.
Atomic settlement moves liquidity needs
Delivery versus payment on one ledger can remove principal risk, but both legs must be prefunded at the moment of settlement. Liquidity that netting once saved now has to be found in advance.
Legal finality can lag technical finality
A ledger can record a transfer as final while insolvency law, securities law or the token's terms leave its legal status uncertain. Finality has to be defined in the rulebook, not inferred from the consensus protocol.
Fragmented ledgers rebuild silos
Separate platforms for each asset, bank or jurisdiction need bridges and interoperability layers to connect. Each connection adds an operational and cyber dependency and can trap liquidity on one platform.
Fintech risk and operations.
The screen a team would use to follow this subject: its measures, states and decisions. Names are examples and values are illustrative.
Fintech risk and operations
Digital assets and tokenisation · Fintech F1 · Week 17
- Active users737,52910Active
- API uptime, %99.54Normal
- Fraud per 10,000 transactions134Alert
- Complaints open67Watch
Fraud rate by channel
Credit model fairness
| Women | 63 | 3 | Within |
| Rural | 42 | 5 | Review |
| Under 25 | 37 | 4 | Within |
What is measured, and how well.
Each indicator carries its unit, its cadence, the kind of source behind it and the evidence label a value would carry. No values are shown: a programme supplies them under its own authority.
| Indicator | Unit | Cadence | Source type | Label |
|---|---|---|---|---|
| Tokenised assets on regulated platforms | outstanding value in reporting currency | quarterly | Platform and supervisor disclosures | REPORTED |
| Tokenised settlement in central bank money | percent of settlement value | quarterly | Operator records | Published statistics |
| Ledger platform availability | percent of scheduled operating time | monthly | Operator logs | OBSERVED |
| Settlement fails on tokenised platforms | percent of settlement instructions | monthly | Operator records | OBSERVED |
| Interoperability connections per platform | count of bridges and gateways | quarterly | Platform documentation | DECLARED |
| Central bank tokenisation and CBDC projects by stage | count by research, pilot and launch | annual | Central bank surveys and announcements | Published statistics |
| Participants in pilot regimes and sandboxes | count of firms and infrastructures | annual | Regulator registers | Published statistics |
What digital assets and tokenisation 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 digital assets and tokenisation reaches credit, market, underwriting, liquidity and operational risk, and feeds back.
Where the evidence comes from.
Named public datasets and institutional records, each with its licence class. Sources by agreement are used only under their terms and never republished.
| Source | What it gives | Licence class |
|---|---|---|
| BIS survey of central banks on digital currencies and crypto | Stage of central bank work on retail and wholesale CBDC and tokenisation | Free, attribution under BIS terms of use |
| BIS Innovation Hub project reports | Designs, findings and stated limits of wholesale settlement and tokenisation experiments | Free, attribution under BIS terms of use |
| ESMA register under the DLT Pilot Regime | Market infrastructures permitted to operate DLT trading and settlement systems in the EU | Public register, ESMA terms |
| FSB and CPMI reports on tokenisation | Assessments of financial stability and market infrastructure implications | Free, attribution under FSB and BIS terms |
| Central bank and securities regulator sandbox registers | Participants and scope of tokenisation pilots by jurisdiction | Public records, terms per authority |
| Public ledger records | Token issuance, transfers and contract code on permissionless networks | Open data, terms per network |
Who decides, and what the evidence serves.
Fintech Nexus prepares evidence. The decisions below are taken by the authorities named, under their own rules, and never by the platform.
| Who decides | The question | Evidence this page serves |
|---|---|---|
| Central banks | Whether and how to make central bank money available for settlement on tokenised platforms | Settlement asset design notes, pilot findings, liquidity effects of atomic settlement |
| Securities regulators and market infrastructure overseers | Whether a ledger-based system meets the PFMI and the rules for trading and settlement | PFMI mapping, availability and fail records, finality analysis |
| Boards of market infrastructures and banks | Whether to issue, settle or service assets on a tokenised platform, and against which settlement asset | Dependency maps, legal finality analysis, operational resilience evidence |
| Legislators and justice ministries | Whether property, securities and insolvency law recognise tokenised holdings and ledger finality | Comparative legal notes, legal gaps identified in pilots |
Outputs this topic produces
- Design notes on settlement assets and finality in tokenised markets
- Mapping of PFMI principles to ledger-based infrastructure
- Interoperability and bridge dependency maps
- Comparative notes on tokenisation pilot regimes
The questions experts ask.
- What legal rights does a token actually represent, and are they enforceable?
- How does settlement on a distributed ledger change counterparty, liquidity and operational risk?
- How do stablecoins maintain their value, and what happens under stress?
- How interoperable are tokenised systems with existing financial infrastructure?
- Which governance arrangements control changes to a ledger and its code?
Ledgers, tokens and their risks.
Distributed ledgers maintain a shared record across many participants, with rules for validating changes. Permissionless ledgers are open to anyone; permissioned ledgers restrict participation to known entities, which is the more common model for regulated tokenisation projects. Programmable code on the ledger can automate actions such as transfer conditions or interest distribution, which brings efficiency and also the risk that coding errors are executed automatically.
Atomic settlement, where asset and payment move together, can reduce counterparty risk but requires both legs to be available on compatible ledgers at the same time, which raises liquidity demands. Stablecoins aim to hold a fixed value through reserves or other mechanisms; their stability depends on the quality, liquidity and legal segregation of reserves, and several have failed or lost their peg under stress.
Legal certainty is central: whether a token confers ownership, how insolvency law treats it and which jurisdiction applies. Crypto-asset market failures have shown risks from leverage, conflicts of interest, poor custody and fraud.
Methods and their limits.
Legal analysis
Analysing the rights represented by tokens across jurisdictions.
Protocol analysis
Studying ledger design, consensus and code risk.
Market data analysis
On-ledger and market data; data quality and wash trading complicate analysis.
Limits: many tokenisation projects are pilots, so evidence on performance at scale is limited, and on-ledger data do not show off-ledger obligations.
How it is studied, and what the methods cannot say.
- 01Distributed ledgers and digital assetsSettlement finality analysis · On-chain flow and reserve reconciliationApplied here
- 02Payment and financial market technologyDependency mapping of a payment chain · Liquidity stress simulationApplied here
- 03Cybersecurity and cryptographyThreat-led penetration testing · Supply chain and dependency analysisApplied here
- 04Digital identity and public digital systemsAssurance-level mapping · Remote proofing attack testing · Exclusion analysisApplied here
Questions and answers.
What is a tokenised deposit?
How does tokenisation differ from a stablecoin?
What is a unified ledger?
Does Fintech Nexus recommend tokenised products?
Does GRA recommend any digital asset?
Is tokenisation the same as crypto?
Are stablecoins safe?
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.
- EmailGateway GW-GRASend it from this pageEvidence, a correction, a case, a method, a review, a translation or profile input. It arrives tagged with this page, so the editor who owns it receives it.
- ZenodoOpen depositDeposit it and submit to the communityPublish your own record on Zenodo with your ORCID iD, then submit it to the Reports community there. Curators review it; the DOI stays yours.
- ReportsGlobal Risks AllianceSee every way to contributeThe contribution types, how each is reviewed, what credit you receive, the licence and what is never accepted.
Never send personal data, sensitive infrastructure detail or anything you have no right to share. A contribution is reviewed before use; sending it confers no authorship or editorial rights, and sponsorship never buys a finding.
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.
Legal documents.
Maps, data and figures on this site are shown for context and general information. They are not advice, forecasts or warnings; the limits of the information are set out in the Disclaimers and Data Notices.