e-Rupee Status and the AI Governance Gap

RBI launched the digital rupee pilot in November 2022 (wholesale) and December 2022 (retail). As of 2026, the e-Rupee retail pilot has expanded to multiple banks and covers multiple use cases: person-to-merchant payments, government benefit disbursement, and offline transactions. The scale-up is not organic — it is driven by a combination of institutional strategy and direct political pressure.

Utkarsh 3.0, RBI's three-year vision document for 2026–29, names digital rupee expansion as a strategic pillar. The targets are specific: interoperability with UPI and NPCI infrastructure, programmable money features (purpose-restricted CBDCs for government disbursements), and financial inclusion use cases that reach segments where UPI penetration remains limited. Finance Minister Sitharaman at Global Fintech Fest in September 2026 pushed RBI to "sharpen" digital rupee capability and accelerate adoption — a political signal that e-Rupee scale-up is a government priority in the FY2026–27 period.

The AI governance gap runs directly through this expansion. CBDC infrastructure embeds AI at multiple layers: fraud detection on e-Rupee transactions, anomaly detection in the distribution network, recommendation systems for wallet providers, and — in the programmable money use case — the rule engine that determines what a digital rupee can be spent on. None of these are explicitly addressed in any current RBI AI governance framework. RBI FREE-AI (August 2025) and MRMF (June 2026) apply to CBDC AI by their general scope — both cover AI used in financial services and by regulated entities respectively — but no RBI guidance has mapped CBDC-specific AI obligations. Banks expanding their e-Rupee roles are doing so into a governance framework that is structurally incomplete.

AI in e-Rupee: Six Use Cases

Retail e-Rupee Fraud Detection

AI transaction scoring for e-Rupee retail payments carries a materially different risk profile than equivalent UPI fraud AI. Unlike UPI, e-Rupee transactions are final — there is no chargeback mechanism. A false negative in fraud detection has no recovery path for the defrauded party. The higher stakes environment demands more conservative threshold calibration and more rigorous validation, but no current RBI guidance applies a higher governance standard to CBDC fraud AI than to equivalent UPI fraud models. Banks are operating CBDC fraud AI under the same MRMF requirements as lower-stakes models.

Wholesale e-Rupee (e₹-W) Interbank Settlement

AI-assisted settlement optimization for interbank e-Rupee positions RBI as an AI operator in systemic infrastructure. The same dynamic visible in DPIP (RBI's Digital Payment Intelligence Platform) applies here — RBI is running or overseeing AI that affects systemic settlement outcomes. The governance boundary between RBI's AI components and the bank AI that interfaces with wholesale e-Rupee creates the same accountability problem discussed below.

Programmable Money Rule Engine

e-Rupee for direct benefit transfer (DBT) can be purpose-restricted: usable only for specific categories such as food, fuel, or education at approved merchants. The rule engine enforcing these restrictions is AI-assisted pattern matching. A miscalibrated rule engine can block legitimate beneficiary spending — a failure mode with welfare implications that exceed ordinary payment disputes. The beneficiary population for government DBT e-Rupee is disproportionately from low-income and rural segments; a fairness failure in the rule engine is both a governance failure and a financial inclusion setback.

KYC and Onboarding AI for e-Rupee Wallets

Wallet providers use AI for e-Rupee KYC — subject to both DPDP Act consent requirements and RBI KYC Master Direction. AI-driven differential KYC for CBDC (lighter KYC for low-value wallets, designed to enable financial inclusion) requires fairness testing to avoid discriminatory access to digital currency. A KYC AI that systematically rejects applicants from particular demographic segments does not just create a compliance gap — it defeats the financial inclusion rationale for the lighter-KYC design.

Offline e-Rupee Transaction Reconciliation

Offline e-Rupee transactions (conducted without internet connectivity) are reconciled when connectivity is restored. AI assists in reconciliation, detecting duplication or fraud that occurred during the offline period. Model failures in offline reconciliation can create double-spend conditions or generate false fraud flags that lock legitimate offline transactions. The offline use case is specifically targeted at low-connectivity rural and semi-urban segments — failure is felt hardest by users with the fewest alternatives.

Interoperability Bridge AI (Future)

Planned e-Rupee/UPI interoperability — a core Utkarsh 3.0 target — requires AI to handle transaction routing, currency conversion context, and failure recovery at the interface between two major payment systems. The AI governing this bridge will be systemic financial infrastructure. Its failure modes propagate across both CBDC and UPI ecosystems simultaneously. Governance requirements for this AI will need to exceed those applied to single-system payment AI — but no framework currently addresses cross-system CBDC AI risk.

RBI FREE-AI and MRMF: How They Apply to CBDC

RBI FREE-AI (August 2025) applies to "all AI systems used in financial services in India." CBDC systems are RBI-operated and bank-integrated financial services — FREE-AI applies. The six pillars translate to CBDC AI contexts as follows:

FREE-AI Pillar CBDC AI Application Key Challenge
Pillar 1: Safety e-Rupee fraud AI must demonstrate safety testing — particularly for the no-chargeback environment Standard safety thresholds calibrated for recoverable payment systems may be insufficient for final-settlement CBDC
Pillar 2: Fairness Programmable money rule engines must be tested for equitable application across beneficiary demographic groups DBT beneficiary populations include protected categories under both DPDP and RBI's financial inclusion mandate
Pillar 3: Explainability Fraud decisions in e-Rupee must be explainable to transaction parties CBDC's finality makes post-hoc explanation particularly challenging — there is no reversal window during which explanation can precede remedy
Pillar 6: Accountability Who is accountable for AI failures in e-Rupee: RBI (as CBDC operator), the bank (as wallet provider), or the technology vendor? The three-party structure of CBDC creates accountability gaps that bilateral bank-regulator AI governance frameworks were not designed to address

MRMF (June 2026) covers models used by regulated entities. Banks distributing e-Rupee wallets are covered entities. AI used by banks in their e-Rupee distribution role — KYC AI, fraud screening, customer recommendation — is in MRMF scope with the same model validation, documentation, and monitoring requirements as any other bank AI model. The CBDC framing does not create an exemption; it creates an additional documentation requirement (the CBDC use case and its specific constraints must be captured in model documentation).

The Accountability Problem: Who Governs RBI's Own AI?

RBI MRMF applies to regulated entities. RBI is the regulator, not a regulated entity under its own framework. When RBI operates AI — the wholesale e-Rupee settlement engine, the DPIP fraud platform, DAKSH supervisory AI — that AI is governed by RBI's internal policies, not MRMF. No external examination requirement, no independent validation obligation, no mandatory model documentation standard that external parties can inspect.

This creates a supervision gap: the AI in India's central bank digital infrastructure is subject only to RBI's self-governance. This is not unique to India — no central bank globally has submitted its own AI systems to external model validation. But it matters particularly when bank AI and RBI AI interact in settlement and supervisory workflows.

The practical implication for banks is asymmetric. Banks must govern their AI in e-Rupee workflows under MRMF — documenting, validating, and monitoring every model in their CBDC role. But when a transaction fails at the CBDC settlement layer, the bank must determine whether the failure originated in their AI or in RBI's AI components — with no access to RBI's model documentation, no validation reports, and no assumption logs to review. A bank investigating an e-Rupee failure must attribute the failure without the tools that MRMF requires them to maintain for their own models.

Governance gap

The RBI-bank interface in CBDC creates a model risk boundary that neither MRMF nor FREE-AI was designed to address. Banks are accountable for their AI. RBI is not accountable to any external examiner for its AI. When they interact in a system whose failures are final and irreversible, the governance architecture is structurally incomplete.

What Banks Must Build: Five CBDC AI Governance Controls

1. CBDC AI Model Inventory

Extend the MRMF model inventory to e-Rupee specific AI — fraud detection, KYC, offline reconciliation, and any recommendation or rule-engine AI used in the bank's CBDC distribution role. CBDC model entries should note the CBDC use case, the finality constraint (no chargeback), and any RBI infrastructure dependencies where the bank's AI interacts with or depends on RBI-operated AI components.

2. CBDC-Specific Fraud Model Validation

Validate fraud detection AI against e-Rupee's no-chargeback environment. The false negative cost is materially higher than for UPI-equivalent fraud models — a false negative in e-Rupee fraud detection means an unrecoverable loss, not a disputed charge. Model validation should document this constraint and justify threshold calibration against it. Standard UPI fraud model validation methodology is insufficient if it does not explicitly address finality.

3. Programmable Money Rule Testing

If the bank is a distribution partner for government DBT e-Rupee, test the rule engine for equitable application across beneficiary categories before deployment. Testing should cover geographic distribution (urban vs. rural merchant recognition), demographic group access (SC/ST beneficiary categories, tribal Schedule V/VI areas), and language-based merchant categorization (regional language merchant names). A rule engine that performs well in aggregate may perform poorly for specific beneficiary segments — aggregate validation metrics can mask demographic performance gaps.

4. Failure Attribution Protocol

Establish a documented protocol for attributing e-Rupee transaction failures to bank AI versus RBI infrastructure versus network. This protocol is required for two separate compliance obligations: MRMF incident documentation (which requires the bank to characterize the source of a model-related incident) and customer dispute resolution (which requires the bank to explain to the customer why a transaction failed). Without a documented attribution protocol, an e-Rupee incident generates both an unexplained MRMF entry and an unresolvable customer complaint.

5. DPDP Consent Architecture for CBDC Data

e-Rupee transaction data is high-sensitivity personal data. Unlike UPI data (which reveals spending patterns at merchant category level), e-Rupee offline transaction data can reveal location, social graph (who the user transacted with in-person), and spending behaviour in contexts where the user had no digital connectivity. DPDP consent architecture for CBDC wallets must be designed before scale-up — retrofitting consent architecture onto an operating CBDC wallet creates data liability for transactions processed without adequate consent. Banks designated as Significant Data Fiduciaries face DPIA obligations for AI processing of e-Rupee data; these DPIAs should be commissioned before expanding CBDC AI use cases.

Frequently Asked Questions

Is e-Rupee subject to DPDP Act data protection obligations?
Yes. Digital rupee wallet data (transaction history, merchant patterns, location data from offline transactions) is personal data under the DPDP Act. RBI as CBDC operator and participating banks as wallet providers are data fiduciaries. Banks designated as Significant Data Fiduciaries face DPIA obligations for AI processing of e-Rupee data.
Does MRMF apply to RBI's own CBDC infrastructure AI?
RBI is the regulator, not a covered entity under MRMF. MRMF does not bind RBI's own AI systems. However, banks' AI components in their CBDC roles (KYC AI, fraud detection in wallet distribution) are fully in MRMF scope. The RBI-bank interface creates a governance boundary problem with no current regulatory resolution.
What is "programmable money" and why does it create AI governance obligations?
Programmable money is CBDC that can only be spent for specific purposes (e.g., food subsidies usable only at FSSAI-registered merchants, education subsidies usable only at approved institutions). The AI enforcing these restrictions must be validated for accuracy (legitimate merchants not blocked), fairness (equal access across geographies and demographics), and explainability (why was a specific merchant blocked?). All three are RBI FREE-AI obligations.
How should banks document CBDC AI for MRMF examination?
Banks should document CBDC AI in the same model inventory used for all other AI. CBDC-specific documentation should note: the CBDC use case, the no-chargeback constraint (affects threshold calibration justification), RBI infrastructure dependencies (portions of the workflow not in bank control), and DPDP consent architecture. Examiners will ask for MRMF documentation for all AI in the bank's e-Rupee role — the CBDC framing does not exempt bank AI from standard documentation requirements.

CBDC AI governance ready before your e-Rupee role expands?

Zytra's India compliance team will review your CBDC model inventory, FREE-AI gap assessment for e-Rupee AI, and DPDP consent architecture — and map the fastest path to MRMF-compliant CBDC governance.