The hard part of offline digital rupee payments is not simply letting two phones exchange value without a network. It is making sure the same balance cannot be spent twice, then safely bringing transactions back into sync when devices reconnect.
RBI’s e₹ retail work has been conducted as a pilot, with offline payments among the capabilities being explored. A 2026 rollout date by itself does not establish whether the plan is a limited expansion or a nationwide launch; that depends on RBI’s published scope and schedule.
What still needs to work reliably
- Double-spend prevention: While a device is offline, it cannot check the payer’s latest balance or learn whether the same funds were already used elsewhere. Secure device storage, transaction limits, and risk controls can reduce the chance of overspending, but the design has to decide who bears losses if a device is compromised.
- Offline transaction reconciliation: Payments must be recorded locally and reconciled after connectivity returns. The system needs clear rules for duplicate records, interrupted transfers, and conflicting updates across wallets, without accidentally creating or losing value.
- Device security and recovery: Lost, rooted, or damaged phones raise awkward questions: how can legitimate users recover access, and how can compromised devices be blocked if they are offline? Hardware-backed protections vary across low-cost phones, which are especially relevant for wider access.
- Interoperability between wallets: A practical rollout needs payments to work across participating banks, wallet apps, and supported devices, not just within one test setup. Different offline technologies and device capabilities can make consistent behaviour harder to guarantee.
- Privacy and auditability: Offline payments need enough records for fraud checks and dispute resolution, while limiting unnecessary disclosure of a person’s spending. Designing useful privacy-preserving audit trails is a policy and engineering challenge together.
- Real-world reliability: Power loss, app crashes, delayed network access, and confusing payment confirmations can all leave users unsure whether money moved. The system needs to handle these failures predictably and be simple enough for people who may not have reliable connectivity or recent phones.
So the central trade-off is between spending convenience and control: the more value users can transfer while disconnected, the harder it is to limit fraud before transactions are reconciled. Limits, secure hardware, recovery procedures, and clear liability rules all need to fit together before offline CBDC can work at scale.
