## Introduction (ftnea2025005)

## Source details

**Canonical URL:** [Introduction (ftnea2025005)](https://www.imf.org/-/media/files/publications/ftn063/2025/english/ftnea2025005.pdf)

## Other formats

- [Markdown version](/-/media/files/publications/ftn063/2025/english/ftnea2025005.pdf.md)
- [Structured JSON version](/-/media/files/publications/ftn063/2025/english/ftnea2025005.pdf.json)

---

### Overview
- Central banks worldwide are exploring retail central bank digital currencies (CBDCs) designs that can provide universal access and operate under all conditions.
- According to the Bank for International Settlements (BIS), almost all central banks surveyed in 2023 were considering offline payments to be vital or at least advantageous (BIS 2023a).
- Ensuring accessibility in limited or no connectivity environments is particularly relevant for emerging market and developing economies, remote regions, and areas prone to natural disasters.
- Offline functionality is prioritized in some advanced economies, such as the euro area, to ensure operational resilience, support cash-like usability, and uphold privacy.
- The note takes a neutral approach to technology options and focuses on usability, accessibility, functionality, cybersecurity risks, privacy, maturity, and track record of technologies.

### Methodology and scope
- Builds on BIS Project Polaris (BIS 2023a) and other work such as Bank of England (Bank of England 2025).
- Authors conducted interviews in early 2025 with payment platforms, central banks, and industry experts; most interviewed payment platforms have participated in CBDC pilot projects testing offline functionality.
- The note does not cover wholesale CBDC (wCBDC).
- Exclusions:
  - Legal and regulatory aspects, geopolitical issues, and technology lifecycle trends are not covered.
  - A forthcoming IMF Legal Department paper will cover financial integrity considerations (Schwarz and others 2025).
  - Macroeconomic considerations and a full cost-benefit analysis are out of scope.

### Connectivity scenarios and classifications
- Connectivity is categorized along a spectrum from zero connectivity to cellular-only connectivity that allows SMS and USSD protocols.
- Temporary disconnection scenarios (for example, natural disasters or outages), low-connectivity and intermittent/unreliable connections are considered.
- Offline payment scenarios classified into three categories:
  - Staged offline
  - Intermittently offline
  - Fully offline
- Payment transitivity implications:
  - Staged offline architectures require reconciliation before the payee can onward spend funds.
  - Intermittently offline allows onward spending up to issuer/PSP-set limits before connection is required.
  - Fully offline can technically execute transactions without reconciliation, though reconciliation can be useful for auditability, risk management, or financial integrity.

### High-level offline architecture types (summary)
- Mode — Ability for payee to spend funds received:
  - Staged — The payee cannot spend any further until they are connected to the database for reconciliation.
  - Intermittently — The payee can spend the amount received, although limits set by the issuer and/or payment service providers (PSPs) determine the value and/or volume of transactions that can occur before a connection is required.
  - Fully offline — No limits to the number or amounts of transactions.
- Source references: BIS (2023a) and authors.

### Historical context and evolution
- Experiments date back decades: examples include Mondex (UK 1995) and early mobile money systems like M-Pesa.
- Modern pilots explore custom devices, embedded secure elements, and smartphone apps for peer-to-peer transactions without real-time connectivity.
- Examples are illustrative of diverse technical approaches.

### No-connectivity environments: technologies and findings
- Zero connectivity scenarios: complete absence or prolonged breakdown of connectivity (for example, during a natural disaster, active conflicts, or remote areas with no coverage).
- Technological approaches explored (not mutually exclusive):
  - Low-cost stored-value card solutions relying on preloaded balances, secure hardware elements, and an intermediary device to transfer funds between cards.
  - Device-to-device smartphone solutions using short-range transmission (Bluetooth Low Energy (BLE), near-field communication (NFC), or quick response (QR) codes).
  - Wallets acting as temporary local ledgers exchanging cryptographically signed, time-sequenced payment instructions between devices.
- Pilots and vendors cited:
  - Giesecke+Devrient (G+D) piloted offline CBDC payments in Ghana and Thailand (BOG 2024; BOT 2024).
  - Crunchfish implemented pilots using NFC and QR codes (RBI 2023) and has piloted smartphone NFC-based offline payments in India since 2022 through “On Tap”.
  - IDEMIA demonstrated offline exchanges via NFC for the Bank of Israel (Bank of Isreal 2024) and experimented with QR codes but found limitations.

### Stored-value card-based offline payments
- Stored-value cards can transfer funds via NFC using intermediary devices like POS terminals or smartphones that can operate offline.
- Two main card types:
  - Bank-linked debit/credit cards.
  - Stored-value cards that hold funds directly (common in P2B contexts like transit or prepaid calling).
- Historical examples:
  - Mondex (UK 1995) — technically sound but failed due to low merchant adoption and limited P2P usability.
  - Finland’s Avant card (1993) — had offline capabilities but never activated them.
- Recent pilots:
  - Reserve Bank of Australia piloted offline P2B CBDC transactions at two universities using pre-loaded stored value cards (RBA 2023).
  - G+D pilots in Ghana and Thailand used dedicated POS terminals and SoftPOS smartphones, respectively (BOG 2024; BOT 2024).
  - Payala trialed a digital cash aid distribution system in Timor Leste (Payala 2019).
- Operational observations:
  - Stored-value cards are viable in many African markets where already in use; G+D highlighted battery-powered POS enabling fully offline P2P card payments.
  - Limitations include risks of “torn” transactions (card removed mid-transfer) and mitigations such as secure sessions, retransmission, and claim/compensation mechanisms.
  - Many government benefit distribution cards are offline but backed by commercial bank money and may not meet full CBDC requirements.
  - Stored-value cards are generally better suited for P2B than P2P transactions.

### Device-to-device offline payment solutions
- Enable transfer of funds between devices (typically smartphones) via NFC, BLE, QR codes, or manual entry; do not require central ledger connectivity during transaction execution.
- Pilots and experiments:
  - Crunchfish — smartphone NFC-based offline pilots in India since 2022; RBI approval for adoption by regulated entities in December 2023; collaboration with Tata Consultancy Services began July 2024 (Crunchfish 2024; RBI 2023).
  - Bank of Korea experimented with smartphone NFC-based offline CBDC payments in 2022, reportedly with Samsung Electronics (BOK 2023).
  - DigiTally — Java card applet for feature phones running on SIM or overlay SIM; pilot at Strathmore University in Kenya using keypad input (Baqer and others 2017).
  - IDEMIA demonstrated NFC-based smartphone exchanges for Bank of Israel (Bank of Isreal 2024).
- Technical notes:
  - Most NFC-capable smartphones also support BLE and cameras for QR scanning.
  - No known CBDC pilots rely solely on BLE or QR codes to date.
  - QR codes may be limited by data capacity, which may hamper use with quantum safe algorithms.

### Cellular connectivity environments (No Data)
- In scenarios where some internet connectivity exists but no data service is available, ledgers record holdings and wallets can initiate direct transfers.
- Transaction flow described:
  - Payer’s wallet sends cryptographically secured payment instructions (account identifiers, amount, verification code, and so on) to the ledger maintenance mechanism instructing the payer’s account provider to transfer value to the payee’s account.
- Distinction noted:
  - This is a “push” transaction; by contrast, a “pull” transaction is initiated by the payee’s wallet based on prior payer authorization.

### Box 1 — Insights from technology providers and experts (key takeaways)
- No single CBDC solution fits all contexts; offline capability requires trade-offs between form factor availability, security architecture, and operational feasibility.
- Jurisdiction-specific strategies:
  - Feature phones may be baseline in some jurisdictions; in others, remote users are connected through smartphones and mobile money ecosystems.
  - Cards are more viable where they are already widely used; in other jurisdictions people expect CBDC access through smartphones.
- Rollout considerations:
  - Technical feasibility alone is insufficient; distribution, cost, merchant readiness, and user trust are critical.
  - The most secure architecture might not be adopted if it is clunky or requires unfamiliar hardware.
- Security and privacy trade-offs:
  - Complete secure systems are unlikely; mitigations should make attacks harder, more expensive, less impactful, less scalable, and more visible.
  - Anonymity is possible with wallet caps and holding limits without requiring user IDs in every case.
- Technology maturity:
  - Secure hardware is expensive and slow to scale; investment in virtual secure elements and TEEs is common.
  - Quantum-safe cryptography exists but is slow; a new chip generation would be needed for field feasibility.
  - Representatives viewed the quantum horizon as similar to the CBDC horizon "(approximately five years)" based on NIST (2022 and 2024).
- SMS/USSD and low-connectivity form factors:
  - SMS began rolling out in 1993; USSD followed shortly after.
  - USSD can offer interactive menus when supported by the MNO and associated application servers and if the phone includes a SIM Application Toolkit (STK).
  - SMS/USSD are mature, with 2G/3G networks still widely operational in many countries, though 2G/3G are being phased out in some; continuity over 4G/5G must be assessed.
  - SIM sticker-based wallets can enable fully offline payments but face usability and durability concerns.

### Box 2 — The right security mindset among platform providers (key findings)
- Providers do not claim their hardware and software are tamperproof; evidence of secure element hacks in labs exists.
- Platforms operate under the assumption that hacks are inevitable and work to stay ahead of potential hacks.
- Target security posture: resist tampering at high attack potential parameters (for example, those defined by the Common Criteria standard).
- Software security challenges specific to offline:
  - wallet synchronization errors
  - duplicate transactions
  - double spending
  - reconciliation failures
- Cryptographic key management is more complex in offline scenarios because keys must be securely generated, stored, and managed across multiple devices without real-time central validation.
- Virtual secure elements (VSEs):
  - More scalable and cost-effective than hardware-based solutions.
  - More exposed to cyber threats and rollback risks.
  - Important for financial inclusion because they enable offline payments on consumer-grade smartphones and allow remote updates.
- Hardware secure elements (HSEs) and Trusted Execution Environments (TEEs):
  - HSEs are standalone tamper-resistant components (use JavaCard; security level uniform).
  - TEEs isolate sensitive code/data within the processor (security level homogeneous across phone brands but depends on hypervisor and hosting software).
- Physical Unclonable Functions (PUFs) can tie encryption keys to chip physical imperfections to protect key material.
- Compliance frameworks (for example, Common Criteria) and minimum assurance levels (for example, Evaluation Assurance Level (EAL)) are tools for security evaluation but may affect inclusion due to device cost.
- Hardware obsolescence risk requires forward-compatibility and modularity planning.
- Design trade-offs:
  - Balance inclusion and security; VSEs favor inclusion, HSEs favor stronger security.
  - Plan lifecycle and maintenance to mitigate obsolescence and costly in-field replacements.
  - Implement robust measures for synchronization, duplicate detection, double-spend prevention, and cryptographic key lifecycle management.

### Box 3 — Other attacks, mitigations, and operational best practices
- Attack types and root causes:
  - Counterfeiting via physical breaches, man-in-the-middle, side-channel, fault-inducing attacks, and third-party device compromises.
  - TEE-targeted exploits from input validation gaps, design errors, and lack of memory protection.
  - Root causes include weak operational hygiene and lack of security best practices.
- Rollback (double-spending) attacks:
  - Adversary snapshots wallet state, executes a transaction, then restores original state enabling repeated spending.
  - As noted by Schumacher (2024), it is mathematically impossible to eliminate rollback risk in a fully offline system.
  - Mitigations: tamper-resistant environments, anchoring state changes using transaction counters stored in separate secure areas (for example, TEE), or synchronizing with backend in staged/intermittent models.
- Best practice design principles:
  - Secure-by-design, defense-in-depth, default fail-safe.
  - Offline-specific principles: complete mediation and compartmentalization.
  - Transaction and balance caps to limit exposure if a device is compromised.
  - Proximity-only communications (for example, NFC) to slow attacks and increase operational burden.
  - Frequent synchronization, enforcement of limits, and staged offline models to raise attack costs.
- Mitigating operational risks:
  - Policy choices on recoverability differ (strict “cash-like” vs permitting recovery if no outgoing transactions occurred before reconnection).
  - Emerging recoverability: expiration mechanisms where offline balances auto-return to the ledger after a time threshold (example: Kahn and others (2024)); vulnerable to internal clock tampering.
  - Torn transactions mitigation: secure sessions requiring both device confirmations, retransmissions, or push-based models awaiting receipt acknowledgements to ensure atomicity.
  - Embed fraud detection into synchronization; use security operations centers for anomaly response.
  - Proposed IBM protocol to trace transaction chains during reconnection to identify/resolves double-spends (Androulaki and others 2024).
  - Pre-offline funding/synchronization via ATMs or automated pre-funding during online periods—many approaches assume prior knowledge of connectivity loss which may not hold in unexpected emergencies (example: widespread power outage in Spain in April 2025).
  - Routine security audits and penetration tests, especially when extending offline transaction limits or durations.
  - Maintain post-quantum preparedness: continuous assurances and a post-quantum plan for at-risk algorithms; design early cryptographic agility (Harishankar and others 2024).
  - Use synchronization events to detect rollback, double-spending, or tampering by tracing transaction chains and checking for anomalies (Androulaki and others 2024).
- Residual risks remain for small-value fraud and automated replication of small payments; reputational attacks can be consequential even with small financial loss.

### Box 4 — Privacy-enhancing technologies (summary)
- Privacy-enhancing technologies broadly categorized: input-preserving and output-preserving (Bains and Gaidosh 2025).
- Input-preserving example: homomorphic encryption.
  - Offers robust data privacy protection but is computationally intensive and significantly slower than traditional encryption.
  - Considered promising but requires further technological maturation for scalability and efficiency.
- Output-preserving example: zero-knowledge proofs (ZKPs).
  - Hold substantial promise for financial applications such as CBDCs (Murphy and others 2024).
  - Complex to implement and resource-intensive; considered promising but requires further maturation.
- Blind signatures and anonymous credentials:
  - Blind signatures: allow issuers to sign messages without accessing underlying content or revealing user identities—may offer a practical path toward privacy and anonymity depending on architecture.
  - Anonymous credentials: enable verification of attributes (for example, proof of age) without disclosing personally identifiable information.
- Integration with banking infrastructure:
  - When CBDC integrates into commercial bank accounts and existing banking apps, privacy levels are typically determined by banking-sector privacy requirements; usually only the payer’s bank sees identities of both parties.
- Preserving privacy in offline CBDC transactions:
  - Core technical measures: blind signatures, anonymous credentials, tamper-resistant hardware, and TEEs.
  - Operational and governance safeguards: strong cybersecurity practices, operational resilience across participants, and clear governance/oversight frameworks defining roles and fallback/revocation protocols.
- Policy and operational implications:
  - Central banks are expected to configure offline solutions to allow intermittent batches of transaction data to be sent to the central bank to detect double spending, counterfeiting, and fraud.
  - Transparency about what data will be included in intermittent checks and how privacy differs for individuals and merchants is important.
  - Feasibility statement: "with the current state of offline technology, it should be possible to develop a secure and usable offline solution."

### Offline payment verification, trust, and architectures
- Asynchronous verification (QR code, printed, email, SMS, postal) increases torn-transaction risk.
- Trust approaches:
  - Closed-loop systems: values trusted as transferred between payment applications executing in HSEs or TEEs.
  - Public key infrastructure (PKI): issuers act as certificate authority (CA) by signing certificates with wallets’ public keys; receivers verify sender signatures using CA root certificate so only sender wallet needs tamper resistant element.
- Interoperability:
  - Crunchfish platform allows multiple payment schemes to interoperate when sender wallets authenticated by same CA, aiding CBDC rollouts and potential cross-border offline payments.
- Platform configurations and usability:
  - Staged and intermittently offline platforms: allow continued transacting during temporary connectivity loss.
  - Fully offline platforms: allow transacting where connectivity is persistently unavailable but require devices loaded with funds.

### Token versus value in offline systems
- Token-based offline platforms:
  - Transfer individual units of digital currency with specific denominations and unique identifiers similar to banknote serial numbers.
  - Make transfers of non-multiple values difficult, requiring “change” to be paid back to payer from payee.
- Value-based offline platforms:
  - Represent balance as numeric amount, without unit tokens; allow transfers without identifying individual tokens or history.
  - Reduce need for frequent/large data transfers by relying more on wallet hardware security.
  - Subsequent transfers between users do not carry proof of origin or history; rely on "transitivity of trust": wallets verify attestations presented by other wallets to determine genuineness and rule compliance.
  - May still require online checks to verify wallet integrity and trustworthiness.
- Policy implications:
  - Choice between closed-loop vs PKI designs affects which devices must be tamper resistant and how trust propagates.
  - Interoperability (e.g., via a common CA) supports rollouts and cross-border offline payments.
  - Fully offline pre-loaded balances require mechanisms for initial value injection and reconciliation on reconnection.
  - Token-denomination systems need mechanisms to handle change; value-based designs avoid this but increase reliance on device security and periodic online validation.

*Source: ftnea2025005 - Introduction (IMF Fintech Notes).*

### Introduction ...........................................................................................................

### Introduction

### Structure of the note
- Coverage:
  - Introduction (page 4)
  - I. Connectivity Scenarios and Case Studies (page 5)
  - II. Assessment Criteria #1: Form Factor (page 12)
  - III. Assessment Criteria #2: Operational and Cybersecurity Risks (page 15)
  - IV. Assessment Criteria #3: Privacy Considerations (page 23)
  - V. How Current Progress Informs Policy Decisions (page 26)
  - VI. Conclusion (page 28)
  - References (page 29)
  - Annex: Value Transmission in an Offline System (page 33)

### Connectivity scenarios and technical case studies (Section I)
- Major themes and subtopics listed:
  - No Connectivity Environments (page 6)
    - Stored-Value Card-Based Offline Payments (page 7)
    - Device-to-Device Offline Payment Solutions (page 8)
  - Cellular Connectivity Environments (No Data) (page 9)
- Supporting materials:
  - Figure 1. Connectivity-Challenged Environments
  - Table 1. High-Level Offline Architecture Types
  - Box 1. Insights from Technology Providers and Experts

### Form factor and user considerations (Section II)
- Assessment focus:
  - Form Factor (page 12)
    - Accessibility (page 13)
    - Usability (page 14)
- Supporting figure:
  - Figure 2. Understanding feasibility and role of each form factor in a given jurisdiction

### Operational and cybersecurity risk assessment (Section III)
- Assessment components:
  - Risk Exposure (page 15)
  - Software Security and Software-Based Secure Environment (page 17)
  - Hardware Security and Hardware Secure Environment (page 18)
- Best practice content:
  - Best Practices for Offline Transactions Capability (page 20)
    - Design Considerations (page 20)
    - Mitigating Operational Risks (page 21)
- Supporting materials:
  - Box 2. The Right Security Mindset Among Platform Providers
  - Box 3. Other Types of Attacks Threatening a Secure and Trusted Environment Leveraged for Offline Payment Wallets
  - Table 2. Comparison of Hardware- and Software-Based Secure Elements

### Privacy considerations (Section IV)
- Topics covered:
  - Privacy on SMS and USSD (page 23)
  - Privacy on Offline Platforms (page 23)
- Supporting material:
  - Box 4. Privacy-enhancing Technologies

### Policy implications and conclusions (Sections V–VI)
- Themes:
  - How Current Progress Informs Policy Decisions (page 26)
  - Conclusion (page 28)

### Supplementary materials
- References (page 29)
- Annex: Value Transmission in an Offline System (page 33)

### Boxes, figures, and tables (inventory)
- Boxes:
  - Box 1. Insights from Technology Providers and Experts
  - Box 2. The Right Security Mindset Among Platform Providers
  - Box 3. Other Types of Attacks Threatening a Secure and Trusted Environment Leveraged for Offline Payment Wallets
  - Box 4. Privacy-enhancing Technologies
- Figures:
  - Figure 1. Connectivity-Challenged Environments
  - Figure 2. Understanding feasibility and role of each form factor in a given jurisdiction
- Tables:
  - Table 1. High-Level Offline Architecture Types
  - Table 2. Comparison of Hardware- and Software-Based Secure Elements

### Abbreviations (as listed)
- API Application Programming Interface
- AML/CFT Anti-money laundering/countering the financing of terrorism
- BIS Bank for International Settlements
- BLE Bluetooth Low Energy
- BOG Bank of Ghana
- BOK Bank of Korea
- BOT Bank of Thailand
- CA Certificate authority
- CBDC Central Bank Digital Currency
- CPU Central processing unit
- EAL Evaluation Assurance Level
- ECB European Central Bank
- EMV Europay, Mastercard, and Visa
- G+D Giesecke+Devrient
- GSM Global System for Mobile Communications
- GSMA Global System for Mobile Communications Association
- HSE Hardware secure elements
- NFC Near Field Communication
- P2B Person to business
- P2P Person to person
- PIN Personal identification number
- POS Point of Sale
- PSP Payment Service Provider
- PUF Physical Unclonable Function
- SE Secure Element
- SMS Short Message Service
- STK SIM Application Toolkit
- TEE Trusted Execution Environment
- USSD Unstructured Supplementary Service Data
- VaR Value-at-risk
- VSE Virtual Secure Element
- ZKP Zero-knowledge proof

*Source: ftnea2025005 - Introduction (IMF PDF).*

### Introduction

### Introduction

### Overview
- Central banks worldwide are exploring retail central bank digital currencies (CBDCs) designs that can provide universal access and operate under all conditions.
- According to the Bank for International Settlements (BIS), almost all central banks surveyed in 2023 were considering offline payments to be vital or at least advantageous (BIS 2023a).
- Ensuring accessibility in limited or no connectivity environments is particularly relevant for emerging market and developing economies, remote regions, and areas prone to natural disasters.
- Offline functionality is prioritized in some advanced economies, such as the euro area, to ensure operational resilience, support cash-like usability, and uphold privacy.
- The note takes a neutral approach to technology options and focuses on usability, accessibility, functionality, cybersecurity risks, privacy, maturity, and track record of technologies.

### Methodology and Scope
- Builds on BIS Project Polaris (BIS 2023a) and other work such as Bank of England (Bank of England 2025).
- Authors conducted interviews in early 2025 with payment platforms, central banks, and industry experts; most interviewed payment platforms have participated in CBDC pilot projects testing offline functionality.
- The note does not cover wholesale CBDC (wCBDC).
- Exclusions noted:
  - Legal and regulatory aspects, geopolitical issues, and technology lifecycle trends are not covered.
  - A forthcoming IMF Legal Department paper will cover financial integrity considerations (Schwarz and others 2025).
  - Macroeconomic considerations and a full cost-benefit analysis are out of scope.

### Connectivity Scenarios and Classifications
- Connectivity is categorized along a spectrum from zero connectivity to cellular-only connectivity that allows SMS and USSD protocols.
- The note considers temporary disconnection scenarios (for example, natural disasters or outages) and includes low-connectivity and intermittent/unreliable connections.
- Offline payment scenarios fall into three categories:
  - Staged offline
  - Intermittently offline
  - Fully offline
- Payment transitivity implications:
  - Staged offline architectures require reconciliation before the payee can onward spend funds.
  - Intermittently offline allows onward spending up to issuer/PSP-set limits before connection is required.
  - Fully offline can technically execute transactions without reconciliation, though reconciliation can be useful for auditability, risk management, or financial integrity.

### High-Level Offline Architecture Types (summary)
- Mode — Ability for payee to spend funds received:
  - Staged — The payee cannot spend any further until they are connected to the database for reconciliation.
  - Intermittently — The payee can spend the amount received, although limits set by the issuer and/or payment service providers (PSPs) determine the value and/or volume of transactions that can occur before a connection is required.
  - Fully offline — No limits to the number or amounts of transactions.
- Source references: BIS (2023a) and authors.

### Historical Context and Evolution
- Experiments date back decades: examples include Mondex (UK 1995) and early mobile money systems like M-Pesa.
- Modern pilots explore custom devices, embedded secure elements, and smartphone apps for peer-to-peer transactions without real-time connectivity.
- Examples provided are illustrative of the diversity of technical approaches.

### No-Connectivity Environments: Technologies and Findings
- Zero connectivity scenarios: complete absence or prolonged breakdown of connectivity (for example, during a natural disaster, active conflicts, or remote areas with no coverage).
- Technological approaches explored (not mutually exclusive):
  - Low-cost stored-value card solutions relying on preloaded balances, secure hardware elements, and an intermediary device to transfer funds between cards.
  - Device-to-device smartphone solutions using short-range transmission (Bluetooth Low Energy (BLE), near-field communication (NFC), or quick response (QR) codes).
  - Wallets acting as temporary local ledgers exchanging cryptographically signed, time-sequenced payment instructions between devices.
- Pilots and vendors cited:
  - Giesecke+Devrient (G+D) piloted offline CBDC payments in Ghana and Thailand (BOG 2024; BOT 2024).
  - Crunchfish implemented pilots using NFC and QR codes (RBI 2023) and has piloted smartphone NFC-based offline payments in India since 2022 through “On Tap”.
  - IDEMIA demonstrated offline exchanges via NFC for the Bank of Israel (Bank of Isreal 2024) and experimented with QR codes but found limitations.

### Stored-Value Card-Based Offline Payments
- Stored-value cards can transfer funds via NFC using intermediary devices like POS terminals or smartphones that can operate offline.
- Two main card types:
  - Bank-linked debit/credit cards.
  - Stored-value cards that hold funds directly (common in P2B contexts like transit or prepaid calling).
- Historical examples:
  - Mondex (UK 1995) — technically sound but failed due to low merchant adoption and limited P2P usability.
  - Finland’s Avant card (1993) — had offline capabilities but never activated them.
- Recent pilots:
  - Reserve Bank of Australia piloted offline P2B CBDC transactions at two universities using pre-loaded stored value cards (RBA 2023).
  - G+D pilots in Ghana and Thailand used dedicated POS terminals and SoftPOS smartphones, respectively (BOG 2024; BOT 2024).
  - Payala trialed a digital cash aid distribution system in Timor Leste (Payala 2019).
- Operational observations:
  - Stored-value cards are viable in many African markets where already in use; G+D highlighted battery-powered POS enabling fully offline P2P card payments.
  - Limitations include risks of “torn” transactions (card removed mid-transfer) and mitigations such as secure sessions, retransmission, and claim/compensation mechanisms.
  - Many government benefit distribution cards are offline but backed by commercial bank money and may not meet full CBDC requirements.
  - Stored-value cards are generally better suited for P2B than P2P transactions.

### Device-to-Device Offline Payment Solutions
- Enable transfer of funds between devices (typically smartphones) via NFC, BLE, QR codes, or manual entry; do not require central ledger connectivity during transaction execution.
- Pilots and experiments:
  - Crunchfish — smartphone NFC-based offline pilots in India since 2022; RBI approval for adoption by regulated entities in December 2023; collaboration with Tata Consultancy Services began July 2024 (Crunchfish 2024; RBI 2023).
  - Bank of Korea experimented with smartphone NFC-based offline CBDC payments in 2022, reportedly with Samsung Electronics (BOK 2023).
  - DigiTally — Java card applet for feature phones running on SIM or overlay SIM; pilot at Strathmore University in Kenya using keypad input (Baqer and others 2017).
  - IDEMIA demonstrated NFC-based smartphone exchanges for Bank of Israel (Bank of Isreal 2024).
- Technical notes:
  - Most NFC-capable smartphones also support BLE and cameras for QR scanning.
  - No known CBDC pilots rely solely on BLE or QR codes to date.
  - QR codes may be limited by data capacity, which may hamper use with quantum safe algorithms.

### Cellular Connectivity Environments (No Data)
- In scenarios where some internet connectivity exists but no data service is available, ledgers record holdings and wallets can initiate direct transfers.
- Transaction flow described:
  - Payer’s wallet sends cryptographically secured payment instructions (account identifiers, amount, verification code, and so on) to the ledger maintenance mechanism instructing the payer’s account provider to transfer value to the payee’s account.
- Distinction noted:
  - This is a “push” transaction; by contrast, a “pull” transaction is initiated by the payee’s wallet based on prior payer authorization.

*Source: ftnea2025005 - Introduction (IMF Fintech Notes).*

### Box 1. Insights from Technology Providers and Experts

### Box 1. Insights from Technology Providers and Experts

### Key principle and form factors
- "No single CBDC solution fits all contexts."
- Offline capability requires trade-offs between "form factor availability, security architecture, and operational feasibility," shaped by "local infrastructure and user expectations."
- Jurisdiction-specific strategies:
  - "There is no one-size-fits-all form factor. In some jurisdictions, feature phones are the baseline. In others, even the most remote users are connected through smartphones and mobile money ecosystems."
  - "Cards are more viable in markets where they are already widely used. But in other jurisdictions, people expect CBDC access through smartphones."

### Experience from past deployments and rollout considerations
- Technical feasibility alone is insufficient; distribution, cost, merchant readiness, and user trust are critical:
  - "We’ve learned from Mondex and Avant. The tech worked. The problem was merchant readiness and user trust. Without a clear rollout strategy and training, even perfect tech fails."
  - "The problem isn’t technology—it’s distribution, cost, and user trust. Most of the failures we’ve seen [of offline payment projects] have been for business reasons."
  - "We’ve seen that the most secure architecture might not be adopted if it’s clunky or requires unfamiliar hardware. Good user experience is therefore critical."

### Security and privacy trade-offs
- Pragmatic consensus on mitigations:
  - "Complete secure systems will probably never exist. But you can make it harder to break, more expensive, less impactful, less scalable, and more visible. In many cases this will be secure enough."
  - "Anonymity is possible. Wallet caps and holding limits are enough to manage risks without requiring user IDs in every case."

### Technology maturity, secure elements, and cryptography
- Observations on hardware and cryptography:
  - "Secure hardware is expensive and slow to scale. That’s why we’re investing in virtual secure elements and using trusted execution environments on consumer devices."
  - "Quantum-safe cryptography exists, but it's slow. You’d need a new chip generation to make it feasible in the field."
- Quantum computing horizon and preparedness:
  - Representatives viewed the quantum horizon as similar to the CBDC horizon "(approximately five years)" based on NIST (2022 and 2024).
  - IDEMIA demonstrated offline payments incorporating "quantum-resistant public key cryptography endorsed by NIST (IDEMIA 2024)."

### SMS, USSD, and low-connectivity form factors
- SMS and USSD basics and user interaction constraints:
  - SMS began rolling out in 1993; USSD followed shortly after.
  - USSD can offer interactive menus when supported by the MNO and associated application servers and if the phone includes a SIM Application Toolkit (STK).
  - Most basic feature phones lack NFC and smartphone capabilities; input is typically limited to numeric keypad interactions.
- Mobile money example:
  - M-Pesa started as an SMS-based platform in 2007 in Kenya; in 2020 it added a USSD interface.
- Country examples of USSD/mobile initiatives:
  - Ecuador: Dinero Electrónico (launched 2014; discontinued 2018).
  - Uruguay: e-Peso pilot from November 2017 to April 2018; "deemed a technical success."
  - Nigeria: eNaira launched in 2021 via a smartphone app; USSD access added in 2022.
  - Peru: Since 2024, a USSD-based digital Sol pilot limited to BiTel users.
- Observations from pilots:
  - "There is no single solution for any one country"—each "distinct digital habitat requires a bespoke response."
  - USSD-based systems are "generally less cash-like" and some users associate them more with telecommunications companies than the sovereign issuer.
  - Secure element-based pilots reported that "the biggest barrier to workability was the need for an intermediary device" when required.
  - "All pilots reported positive feedback from users for some elements of the digital money experience."

### Assessment Criteria #1: Form Factor — accessibility and usability
- Framework dimensions: i) payment instrument form factor and user experience (accessibility, usability); ii) cyber and operational risks; iii) control of privacy.
- No single form factor meets all users or use cases; an effective offline CBDC strategy must account for multiple form factors.
- Four broad categories of form factors considered: smartphones, feature phones, custom-made devices, and stored-value cards.
- Accessibility considerations:
  - Device accessibility depends on connectivity availability, manufacturing/distribution costs, and practicality.
  - In extreme events disabling telecommunications, SMS networks may still operate when data networks are down, making SMS/USSD important backups.
  - If power is cut off, "all of the payment platforms discussed in this note will eventually fail, leaving physical cash as the ultimate fallback."
  - SIM sticker-based wallets can enable fully offline payments but face usability and durability concerns.
  - SMS/USSD is "a mature and reliable option" and 2G/3G networks supporting these protocols "are still widely operational in many countries," though 2G/3G are being phased out in some countries; strategies must assess continuity over 4G/5G.
- Usability considerations:
  - Best user experiences rely on NFC, BLE, or QR codes—generally limited to smartphones.
  - Feature phones and SMS/USSD rely on keypad input, which is "more error-prone, less intuitive, and considerably less 'cash-like' than smartphone-based tap-to-pay functionality."
  - Stored-value cards require an intermediary device (unconnected smartphone with NFC/BLE or merchant POS) and "cannot independently execute direct P2P or P2B payments."
  - Introducing custom intermediary devices increases costs, complexity, and compatibility concerns.
  - Leveraging existing merchant POS infrastructure can "ease integration and lower rollout barriers."

### Assessment Criteria #2: Operational and Cybersecurity Risks
- Offline capabilities vary significantly by system design, architecture, and underlying algorithms; security scrutiny by central banks and ecosystem participants is essential.
- SMS and USSD inherent insecurity:
  - These systems primarily rely on GSM channel cryptography "(A5/1 stream cipher)" which "has been deemed weak in modern cryptanalysis studies (Zhang 2019)."
  - Any payment system relying exclusively on SMS/USSD GSM security is insecure for financial transactions; platform providers mitigate by offering application-layer encryption on top of GSM channel encryption.
- Vulnerabilities for offline payment solutions include:
  - Interrupted inter-device connections, device loss or tampering, exposure to rollback risks, double spending, side-channel, fault-injection, and cryptography compromises.
  - Traditional threats: software vulnerabilities, third-party and supply-chain dependencies, and gaps in secure system design.
- Risk exposure categories:
  - Financial risks: fraud and theft from unauthorized reuse of value.
  - Security risks: cryptographic integrity, data leakage, key management, device-level vulnerabilities.
  - Operational risks: system failures, recovery limitations, user-device dependencies.
  - Regulatory risks: gaps in AML/CFT and know-your-customer compliance (outside this section’s scope).
- Offline-specific risk drivers:
  - Risk correlates with offline duration and/or number of consecutive offline "hops" (Sveriges Riksbank 2024).
  - Hops: "sequential transfers of digital value from one user to another without re-synchronization with the central ledger."
  - Platforms mitigate by limiting offline duration and/or number of hops before reconciliation with a central ledger.
- Design scrutiny and "secret sauce":
  - Risk tolerance and thresholds vary across providers; central banks must "conduct a thorough scrutiny of the design and underlying algorithms of the CBDC solution," including proprietary "secret sauce" schemes.
- Hardware-based secure and trusted environments:
  - Strong requirement for hardware-based secure and trusted environments; some providers offer hybrid solutions with optional software-based trusted and secure environments.
  - Interviewees highlighted tamper resistance and challenges posed by torn transactions or hardware attacks.
  - Mitigations noted: physical unclonable functions (PUFs), card trust elements such as holograms, and biometric consent features.

*Source: Box 1. Insights from Technology Providers and Experts (ftnea2025005).*

### Box 2. The Right Security Mindset Among Platform Providers

### Box 2. The Right Security Mindset Among Platform Providers

### Key findings and assumptions
- None of the representatives of the offline platforms interviewed for this note claimed that their hardware and software are tamperproof. There is ample evidence of successful secure element hacks in lab environments.24
- Payment platforms operate under the assumption that hacks are inevitable and work to stay ahead of potential hacks.
- Offline payment platforms aim to resist tampering at the highest attack potential parameters, for example, by those defined by the Common Criteria standard as an attack by very skilled attackers with almost unlimited funding (Mead 2006).
- In most cases, security evaluations are performed by independent laboratories to detect potential exploitable vulnerabilities.

### Software security and software-based secure environments
- Software security is foundational to the integrity of any payment platform, especially for supporting offline functionality. This responsibility extends across every layer of the software stack—from central bank servers to end-user devices.
- Offline capability introduces specific software-related challenges:
  - wallet synchronization errors
  - duplicate transactions
  - double spending
  - reconciliation failures
- These software risks can arise across components including:
  - server operating systems
  - databases
  - Application Programming Interface (API) integrations
  - mobile applications
- Device fragmentation increases the attack surface: feature phones, smartphones, and custom hardware complicate updates and maintenance.
- Cryptographic key management is more complex in offline scenarios because keys must be securely generated, stored, and managed across multiple devices, potentially without real-time access to central validation servers, increasing risks of key leakage, loss, or misuse—particularly when wallets are in user custody (mobile apps or embedded in general-purpose devices).
- Virtual secure elements (VSEs):
  - Are software-based secure environments offered by several payment platforms.
  - Are more scalable and cost-effective than hardware-based solutions.
  - Are inherently more exposed to cyber threats because they typically share hardware resources with the main device and offer less resistance to physical attacks.
  - Are more susceptible to rollback risks (an attacker restoring a previous wallet state and reusing funds).
  - Are important for financial inclusion because they enable secure offline payments on consumer-grade smartphones without dedicated hardware and allow remote updates, reducing logistical burdens associated with hardware distribution.

### Hardware security and hardware secure environments
- Hardware security is vital for offline capability; risk increases for offline transactions relative to online.
- Most offline platforms reviewed are based on hardware-based secure and trusted environments (HSEs and TEEs); one was based purely on software.
- Hardware secure elements (HSEs):
  - Standalone hardware components, typically on a separate chip, designed to resist both physical and software attacks (“tamper resistant”).
  - Include a CPU, secure memory, and the ability to perform cryptographic operations, providing a strong security boundary.
  - Used in offline payment solutions like cards, EMV, chips, wearable devices, and so on.
  - All use JavaCard and the security level is uniform.
- Trusted Execution Environments (TEEs):
  - Protected areas within a device’s processor that isolate sensitive code and data from the main operating system.
  - Isolate cryptographic keys and transaction logic from the main device, making extraction of sensitive data or manipulation of wallet state significantly harder.
  - Used in offline payment solutions requiring a smartphone.
  - Security level is homogeneous across phone brands but depends on the level of security of the separating layer (that is, hypervisor) and the hosting software.
- Virtual Secure Elements (VSEs) (table comparison highlights):
  - Software implementation that emulates hardware-based SE functionality.
  - Used in offline payment solutions requiring a smartphone.
  - Cost and ease of scaling is low because it is app-based and distributed and upgraded using the existing app store ecosystems.
  - Security levels may not be uniform or interoperable across phone brands.
- Physical Unclonable Functions (PUFs):
  - Potential to further protect sensitive key material by tying an encryption key to the imperfections of the physical structure of the chip—physically attacking the chip modifies this structure and destroys the ability to decrypt the sensitive data the attacker is after.
- When designing offline payments capability, compliance frameworks for TEE, SE, and VSE like the Common Criteria, among others, ensure standardized and robust security evaluation.26
- Requiring minimum assurance levels (for example, Evaluation Assurance Level (EAL)) may exclude certain minorities and populations because devices with a higher level of assurance are more expensive; central banks will have to evaluate and decide on device security requirements and acceptable levels of risk while maintaining a high level of inclusion.
- Hardware obsolescence is a risk: if vulnerabilities are discovered after deployment, replacing hardware in the field is costly and slow.27 Forward-compatibility and modularity are important considerations when selecting HSE and TEE architectures.

### Design considerations and trade-offs for central banks and platform designers
- Balance inclusion and security:
  - Higher-assurance devices provide stronger security but can reduce inclusion due to higher costs.
  - VSEs offer inclusion benefits through use on consumer-grade smartphones and remote updateability but present higher cyber exposure and rollback risks.
- Manage lifecycle and maintenance risks:
  - Plan for hardware obsolescence, costly in-field replacements, and the need for forward-compatibility and modularity.
  - Use independent laboratory evaluations and recognized compliance frameworks (for example, Common Criteria) to assess security.
- Address offline-specific operational risks:
  - Implement robust measures for wallet synchronization, duplication detection, double-spend prevention, and reconciliation workflows.
  - Strengthen cryptographic key lifecycle management for offline contexts where central validation servers may be unavailable.

*International Monetary Fund — FINTECH NOTES: Technology Solutions to Support Central Bank Digital Currency with Limited Connectivity*

### Box 3. Other Types of Attacks Threatening a Secure and Trusted

### Box 3. Other Types of Attacks Threatening a Secure and Trusted Environment Leveraged for Offline Payment Wallets

### Types of attacks and root causes
- Counterfeiting via physical breaches, man-in-the-middle, side-channel, fault-inducing attacks, and third-party device compromises are documented attack types (BIS (2023a) referenced).
- Attacks targeting TEE vulnerabilities arise from:
  - missing or erroneous input validation,
  - architecture and design gaps,
  - lack of memory protection mechanisms.
- Targeted exploits can escalate privileges, compromise the entire device, or force secure elements to leak data such as extracting encryption keys.
- Root causes: weak operational hygiene and lack of security best practices during design and development.
- Countermeasures and best practices exist: layered security architecture, strong and continuous monitoring, and fraud detection.

### Rollback (double-spending) attacks
- Double-spending or “rollback” attacks: adversary snapshots wallet state, executes a transaction, then restores original state enabling repeated spending.
- As noted by Schumacher (2024), it is mathematically impossible to eliminate rollback risk in a fully offline system.
- Mitigation begins with tamper-resistant environments to detect or prevent unauthorized state restoration (Hupel 2024a and 2024b).
- For software-based secure environments, partial rollback mitigation includes anchoring state changes using transaction counters stored in a separate secure area (for example, TEE) or synchronizing them with the backend in staged or intermittent offline models.
- Recommended as per BIS (2023a): limit or delay “cash-out” options to reduce exploitability.

### Best practices for offline transaction capability — Design considerations
- High-level cybersecurity principles to integrate early: secure-by-design, defense-in-depth, default fail-safe.
- Offline-specific principles: complete mediation and compartmentalization to tightly control access to value and prevent compromise propagation (OWASP 2025).
- Ensure transaction integrity and authenticity to detect replay attacks and tampering attempts.
- Robust development practices: secure software development lifecycle, threat modeling, secure coding, supply-chain vetting, secure API integration, and “shift-left” embedding of security.
- Policy-driven countermeasures in hardware and software, e.g. imposing transaction and balance caps to limit financial exposure even when a device is compromised.
- Controls on the receiving wallet (payee) are as important as controls on the payer’s wallet to prevent scalable fraud (platforms like Thales and Paycode referenced).
- Economics-of-security principle: make attacks economically prohibitive so cost of attack far outweighs gains.
- Operational mitigants: proximity-only communications (for example, NFC) to slow attacks and increase operational burden.
- Residual risks remain, particularly for small-value fraud and automated replication of small payments to many recipients; reputational attacks can also be consequential even if financial loss is small.
- Design mitigants: frequent synchronization, enforcement of limits, and staged offline models to increase attack cost.

### Mitigating operational risks
- Policy choices on recoverability differ: strict “cash-like” (lost device means lost funds) versus permitting recovery if no outgoing transactions occurred before reconnection.
- Emerging recoverability approaches: expiration mechanisms where offline balances auto-return to the ledger after a time threshold (Kahn and others (2024)); such mechanisms are susceptible to internal clock tampering and require secure elements and cryptographic techniques to mitigate.
- Torn transactions (payments interrupted mid-process) risk: mitigation via secure sessions requiring both devices confirmation, retransmissions, or push-based models waiting for receipt acknowledgements to ensure atomicity.
- Recommendation: adopt secure-by-design, secure software development lifecycle, and IMF’s “5P framework” (preparation, proof-of-concept, prototype, pilot, production) to identify edge cases and iterate.
- Continuous monitoring and incident management: embed fraud detection into synchronization processes and empower security operations centers to act on anomalies.
  - Example: IBM proposal for a protocol that traces transaction chains during reconnection to identify and resolve potential double-spends (Androulaki and others 2024).
  - After anomalies are flagged, measures such as wallet freezing and transaction flagging can prevent misuse (Bharath and others 2024).
- Pre-offline mechanisms for funding/synchronization during blackouts: pre-funding via ATMs or automated pre-funding during online periods; many approaches assume prior knowledge of connectivity loss which may not hold in unexpected emergencies (example: widespread power outage in Spain in April 2025).
- Testing and validation: threat modeling, Architecture Risk Analysis, legal safeguards for independent review of proprietary algorithms and protocols, and testing across diverse devices and edge cases.
- Integrate cyber value-at-risk (VaR) modeling to quantify threats and impacts (World Economic Forum 2015).
- Routine security audits and penetration tests, especially when extending offline transaction limits or durations.
- Maintain post-quantum preparedness: continuous assurances and a post-quantum plan for at-risk algorithms; design early cryptographic agility for smooth and safe upgrades (Harishankar and others 2024).
- Synchronization events must be used to detect rollback, double-spending, or tampering by tracing transaction chains and checking for anomalies (Androulaki and others 2024).

### Privacy considerations for offline and telco-based systems
- Privacy is generally desired but varies by jurisdiction; regulatory and legal requirements can challenge privacy when identifying information must be stored for fraud detection and AML/CFT compliance.
- Platform providers claim they can offer “complete privacy,” but proving privacy is technically and organizationally challenging.
- SMS and USSD:
  - These are online systems reporting transactions back to a ledger; ledger owner/controller will have access to transaction data.
  - Privacy protections are best supported through legislation, civic rights, and transparent relationships among central bank, government, and telcos.
- Offline platforms:
  - Some providers claim no need to ever connect to a server to settle offline transactions, but most central banks prefer intermittently offline models that batch and upload transaction data after a set number of transactions or when value thresholds are met to detect double spending and tampering.
  - Privacy loss can occur at upload stage if data can be linked to individuals.
  - Example: European Central Bank (ECB) adopting an intermittently offline model for the digital euro; the proposed regulation includes a modified AML/CFT framework to allow greater privacy for offline payments.
    - Article 37 of the proposed regulation specifies that transaction data shall not be retained by payment service providers, the ECB, and the national central banks for offline digital euro payment transactions; payment service providers will only access funding and defunding data related, among other things, to the identity of the user and the amount funded and defunded.
  - Some propose sharing device-level balances (not transaction histories) to allow reconciliation while protecting privacy.
  - Tiered privacy models: transaction thresholds determine required identifying information (ECB 2019; Darbha and Arora 2020), but may pose AML/CFT challenges.
- Trade-offs and policy impacts:
  - Rich transactional data can aid macroeconomic monitoring (for example, velocity of money, inflation signals) and services like merchant “coloring,” but raise privacy trade-offs and potential trust loss.
  - Most platforms prioritize end-user privacy and allow merchant/agent data access to authorities; clear communication of this distinction is essential to maintain trust.
- Technical and regulatory building blocks for privacy-enhancing CBDC:
  1. Leveraging privacy-enhancing technologies (specific cryptographic techniques as described in Box 4).
  2. Design patterns focused on preserving user privacy while allowing necessary regulatory oversight.
  3. Privacy regulation and tier-models defining legal rules and identifying information required by transaction amount.
  4. Security frameworks — without security there is no privacy; implement recommendations to design, implement, and deploy a secure CBDC with offline capabilities.
- Proving privacy is difficult; device-based mechanisms can help demonstrate privacy properties (example noted: Apple demonstration of phone data load behavior in the cloud when data was being removed in a way that compromised user identity).

*Source: FINTECH NOTES — Technology Solutions to Support Central Bank Digital Currency with Limited Connectivity (excerpt: Box 3).*

### Box 4. Privacy-Enhancing Technologies

### Box 4. Privacy-Enhancing Technologies

### Overview
- Privacy-enhancing technologies can be broadly categorized into two types: input-preserving and output-preserving technologies (Bains and Gaidosh 2025).
- The box compares strengths, limitations, and practical applicability of specific technologies for CBDC privacy and offline scenarios.

### Input-preserving and output-preserving technologies
- Input-preserving technologies:
  - Example: homomorphic encryption.
  - Findings: "offer a robust mechanism for safeguarding data privacy. However, they are computationally intensive and significantly slower than traditional encryption methods."
  - Assessment: "considered promising, but their scalability and efficiency limitations suggest that they still require further technological maturation."
- Output-preserving technologies:
  - Example: zero-knowledge proofs (ZKPs).
  - Findings: "hold substantial promise for privacy protection in financial applications such as CBDCs (Murphy and others 2024). Yet, ZKPs remain complex to implement and resource-intensive."
  - Assessment: "considered promising, but their scalability and efficiency limitations suggest that they still require further technological maturation."

### Blind signatures and anonymous credentials
- Blind signatures:
  - Mechanism: "provide a cryptographic method for entities such as central banks to sign messages without accessing the underlying content or revealing user identities."
  - Practicality: May offer a practical path toward achieving privacy and anonymity depending on system architecture and design choices.
- Anonymous credentials:
  - Function: "support user anonymity by enabling the verification of specific attributes (for example, proof of age or citizenship registration) without disclosing personally identifiable information."
  - Practicality: Alongside blind signatures, "may offer a practical path toward achieving privacy and anonymity."

### Integration with banking infrastructure and observable privacy outcomes
- When CBDC is integrated into a commercial bank account and accessible through existing banking apps:
  - Privacy outcome: "the levels of privacy tend to be determined by the privacy requirements set in the banking sector."
  - Typical arrangement: "This usually means that only the payer’s bank sees the identity of both parties in the transaction."

### Preserving privacy in offline CBDC transactions — architectural and operational requirements
- Core technical measures:
  - Use of privacy-enhancing technologies such as blind signatures and anonymous credentials.
  - Combination with tamper-resistant hardware and TEEs.
- Operational and governance safeguards:
  - "These safeguards must rest on strong cybersecurity practices and operational resilience across all CBDC participants, including central banks and PSPs."
  - "Equally critical is a clear governance and oversight framework to define roles, accountability, and fallback or revocation protocols, particularly for offline scenarios."

### Relationship to policy takeaways (as reflected elsewhere in the note)
- Privacy technologies are evolving and present trade-offs with scalability, complexity, and resource intensiveness.
- Regulatory design and transparency considerations:
  - Central banks are expected to configure offline solutions to allow "intermittent batches of transaction data to be sent to the central bank to test for patterns of double spending, counterfeiting, and fraud."
  - Importance of transparency: "It is important for the central bank to be transparent upfront about what type of data will be included in these intermittent checks, and how the levels of privacy differ for individuals and merchants."
- Feasibility statement: "with the current state of offline technology, it should be possible to develop a secure and usable offline solution." 

*Source: Box 4. Privacy-Enhancing Technologies, FTNEA2025005*

### part in the transaction in real time, which does away with the secure session and allows the payee’s

### part in the transaction in real time, which does away with the secure session and allows the payee’s

### Offline payment verification and trust
- Asynchronous verification can be generated and sent as a QR code, printed, or sent by email, SMS message or even regular mail, but this increases the risk of torn transactions.
- To trust value transfers from sender wallets, the offline payment platform must either:
  - be a closed-loop system where values are trusted as they are transferred between payment applications executing in HSEs or TEEs, or
  - rely on public key infrastructure.
- Christodorescu and others (2020) shows how trust can be established offline by issuers acting as certificate authority (CA) by signing certificates with wallets’ public keys. Using public key infrastructure and sender signatures, only the sender wallet needs to be secured by a tamper resistant element.
- By verifying the sender signature using the CA root certificate receivers or any node may trust the sender and accept the value transfer.
- The Crunchfish offline platform allows for multiple payment schemes to become interoperable when sender wallets are authenticated by the same CA (Crunchfish, 2023). This interoperability is beneficial for CBDC rollouts as the service may become interoperable with existing payment services or to support cross-border payments with other CBDCs, even in offline mode.

### Platform configurations and usability
- The functionality and usability of offline payment platforms will vary by configuration.
- Staged and intermittently offline platforms:
  - allow users to continue to transact when/where connectivity is temporarily unavailable, like during natural disasters.
- Fully offline platforms:
  - allow users to transact where connectivity is persistently unavailable, although such usability requires that devices be loaded up with funds (Minwalla and others, 2023).

### Token versus Value
- Distinction applies to offline systems (not SMS/USSD systems) and has policy implications.
- Token-based offline platforms:
  - are based on transferring individual units of digital currency that have specific denominations and even unique identifiers like physical banknotes with unique serial numbers.
  - make it hard to transfer values that are not multiples of one of the denominations held by the sender, resulting in “change” needing to be paid back to the payer from the payee.
- Value-based offline payment platforms:
  - represent the balance as a numeric amount, without a unit token, allowing transfers without identifying the individual tokens or their history.
  - reduce the need for frequent and large data transfers by relying more on the hardware security of the wallet.
  - involve value created by the central bank and injected into the system, but subsequent transfers between users do not carry a proof of origin or a history.
  - rely on the "transitivity of trust" principle: wallets verify the attestation presented by other wallets they interact with to determine that they are genuine and follow the same rules as their own.
  - mean a payee will accept a transfer from a payer because it trusts the sender wallet and accepts the value transferred as genuine.
  - may still require online checks to verify the integrity and trustworthiness of wallets.

### Policy and operational implications
- Choice between closed-loop versus PKI-based designs affects which devices must be tamper resistant and how trust is propagated in offline transfers.
- Interoperability (e.g., via a common CA) can support CBDC rollouts and cross-border offline payments.
- Offline designs that rely on pre-loaded device balances (fully offline) require operational mechanisms for initial value injection and eventual reconciliation when connectivity is restored.
- Systems that use token denominations need mechanisms to handle change; value-based designs avoid this but increase reliance on device security and periodic online validation.

*Technology Solutions to Support Central Bank Digital Currency with Limited Connectivity — NOTE/2025/005*

---


_Source: https://www.imf.org/-/media/files/publications/ftn063/2025/english/ftnea2025005.pdf_