Reaching the e-rupee ledger inside PNB's Digital Rupee wallet

Every e-rupee (e₹) unit held in PNB's wallet is legal tender issued by the Reserve Bank of India, exchangeable one-to-one with paper currency and tied to the holder's Punjab National Bank account. That makes the app a CBDC token store, not a balance counter: it carries a denominated token ledger, a timestamped transaction log, and a bridge to a regulated bank account. Those three surfaces are what a third party usually wants to read, sync, or reconcile, and they are reachable through authorized interface work under the account holder's consent.

The practical read on this app: the e-rupee itself lives in the wallet as on-device tokens that settle against RBI rails, so the cleanest path to the wallet's own data is documented interface integration against a consenting account. The funding-and-redemption account at PNB is separate, bank-held, and reachable through India's Account Aggregator consent rails. We would build the e-rupee read against the wallet interface and bring the linked account in over Account Aggregator where a project needs the full money trail — the two together give a complete load, spend, and redeem picture.

What the wallet actually holds

Routes to the data

Authorized interface integration of the wallet

We capture and document the wallet's own request/response traffic against a consenting account — token ledger, activity log, load/redeem events — then rebuild those calls as a clean, typed client. This reaches the e-rupee data that exists only inside the app and nowhere else. Effort is moderate; durability depends on the app's release cadence, which we manage with a refresh step in maintenance. Access to a consenting invited wallet or a sponsor sandbox is arranged with you at onboarding.

Account Aggregator consent flow (linked PNB account)

The deposit account that funds and redeems e-rupee is bank-held, so it qualifies for India's RBI-regulated Account Aggregator framework, where PNB acts as a Financial Information Provider. Through a licensed NBFC-AA and an explicit consent artifact, we pull that account's statement to complete the load-and-redeem trail. This route is the regulated, audit-logged one and is durable because it rides a standard consent schema rather than a UI.

User-consented session access

For the invite-only wallet, the account holder authorizes the session and we operate within it — token authentication and refresh handled as the app does them. Useful where a sandbox is not on offer and a live consenting user is.

For most projects we would lead with the interface integration, because the e-rupee token ledger and offline-transfer state are unique to the wallet and have no equivalent in the bank statement. The Account Aggregator pull is the right addition the moment a project needs the linked-account side of the money flow with a regulated consent record behind it; the two read against each other cleanly.

What lands at the end

Concrete artifacts, scoped to this wallet:

• An OpenAPI/Swagger spec covering the token-balance read, transaction log, and load/redeem endpoints as observed.
• A protocol and auth-flow report: the token-issue and refresh chain, request signing, and how offline transfers reconcile on reconnect.
• Runnable source for the key endpoints in Python and Node.js, including the per-token-to-aggregate normalization.
• An Account Aggregator integration module for the linked PNB account, with the consent-artifact lifecycle wired in.
• Automated tests against captured fixtures, plus interface documentation and data-retention guidance.

A sample read

Illustrative only — field names and the exact auth chain are confirmed during the build against a consenting wallet, not asserted here as the app's published contract.

POST /cbdc/v1/wallet/ledger
Authorization: Bearer <device-bound session token>
X-Consent-Ref: <account-holder consent id>
{
  "wallet_id": "e-rupee wallet handle",
  "include": ["tokens", "pending_offline"]
}

# 200 -> denominated token ledger, not a single balance
{
  "aggregate_inr": 2450,
  "tokens": [
    { "denom": 500, "count": 4 },
    { "denom": 200, "count": 2 },
    { "denom": 50,  "count": 1 }
  ],
  "pending_offline": [
    { "ref": "nfc-...", "amount_inr": 100, "state": "awaiting_reconnect" }
  ]
}

# normalize: aggregate_inr for the usable total,
# tokens[] kept for the RBI denomination model,
# pending_offline[] surfaced as eventual, never dropped.

# error contract to handle:
#   401 token_expired      -> refresh and retry once
#   409 consent_revoked    -> stop, re-request consent
#   423 wallet_not_invited -> account outside the invite rollout

Consent and the rules that bind it

Two regimes apply here, and they are different. The e-rupee instrument itself sits under the Reserve Bank of India, which issues it as legal tender and runs the CBDC pilot PNB participates in; access to wallet data rests on the account holder's own authorization. The linked bank account is governed by the RBI Account Aggregator framework, where data moves only on an explicit, revocable consent artifact through a data-blind NBFC-AA that never decrypts what it carries. Personal data across both is subject to India's Digital Personal Data Protection Act, 2023, so we keep collection to the fields a project actually uses. Consent scope and expiry are honoured as set, revocation stops the flow, and every pull is logged; NDAs are in place where a client needs them. This is how we operate, not a hurdle placed in front of the reader.

Engineering notes specific to this wallet

• e-rupee is held as discrete denominated tokens rather than a single figure, so we normalize the per-token ledger into an aggregate plus a denomination breakdown — downstream systems get a usable total without losing the token-level detail RBI's model exposes.
• Offline transfers over NFC or telecom-based methods settle to the ledger only when the device reconnects. We design the sync to treat device-local pending sends as eventual, so a value that moved offline is never read as missing and never double-counted when it posts.
• The wallet ships to PNB customers on an invite basis and its front end changes with each release. We run the build against a consenting invited wallet or a sponsor sandbox arranged with you, and re-run the traffic capture to refresh the mapping when an app update shifts the interface.

Where this gets used

• An accounting tool pulling a PNB merchant's e-rupee receipts into a daily settlement report alongside UPI takings.
• A treasury dashboard tracking value loaded into e-rupee versus redeemed back to the linked PNB account.
• A reconciliation job matching offline NFC transfers to their eventual on-ledger settlement.

Interface evidence

Wallet screens from the public store listing, used to map the surfaces above. Tap to enlarge.

How this was checked

Surfaces and routes were mapped against the app's own description and store listing, the RBI's Digital Rupee FAQ for the instrument and offline behaviour, PNB's own wallet page, and the Department of Financial Services material on the Account Aggregator framework, reviewed June 2026.

• RBI — Digital Rupee (e₹) FAQs
• Punjab National Bank — Digital Rupee Application
• Dept. of Financial Services — Account Aggregator framework
• Digital rupee — background and pilot timeline

Mapped by the OpenBanking Studio integration desk, June 2026.

Peer wallets in the same e-rupee pilot

India's retail CBDC runs across many participating banks, each shipping its own wallet over the shared RBI rails — a unified integration would read the same instrument behind different front ends.

• eRupee by SBI — State Bank's CBDC wallet holding e-rupee tokens linked to an SBI account.
• ICICI Bank Digital Rupee — ICICI's e-rupee wallet with UPI-interoperable QR payments.
• HDFC Bank Digital Rupee — among the early movers on UPI-compatible CBDC QR.
• Axis Mobile Digital Rupee — Axis wallet that added UPI and an offline transfer mode.
• YES BANK Digital Rupee — e-rupee wallet with UPI integration for merchant pay.
• Kotak Mahindra Digital Rupee — Kotak's CBDC wallet with UPI interoperability.
• IDFC FIRST Bank Digital Rupee — participating-bank wallet on the retail pilot.
• Union Bank of India Digital Rupee — public-sector peer wallet for e-rupee transactions.
• CRED e-rupee — fintech-distributed access to CBDC riding a partner bank.

Questions an integrator tends to ask

Can you tell offline e-rupee transfers apart from online ones in the transaction feed?

Yes. e-rupee supports offline transfers over NFC and telecom-based methods that settle to the ledger only when the device reconnects, so we flag device-local pending transfers as eventual rather than dropping them, and reconcile them against the online log once they post.

Is the linked PNB savings account reachable through the regulated Account Aggregator route?

The PNB deposit account that funds and redeems e-rupee is bank-held data, which falls under the RBI Account Aggregator framework where the bank acts as a Financial Information Provider. We can pull that account's statement through a consenting AA flow, while the wallet's token ledger itself comes from the app interface.

How do you handle e-rupee being held as denominated tokens instead of one balance?

The wallet stores e-rupee as discrete denominated tokens, the digital equivalent of notes and coins, not a single figure. We normalize the per-token ledger into an aggregate balance plus a denomination breakdown, so downstream systems get both a usable total and the token-level detail RBI's model exposes.

Does the invite-only rollout change how a PNB e-rupee build gets started?

PNB issues the wallet to its customers on an invite basis, so we run the build against a consenting invited wallet or a sponsor sandbox. Access is arranged with you during onboarding; you send the app name and what you need from e-rupee, and we handle the rest.

Source code for the wallet's read endpoints lands in one to two weeks. You can take that delivery from $300 and pay after it runs against your consenting wallet and you are satisfied; or skip any upfront cost and call our hosted endpoints instead, paying only per call. The starting point is the same either way — send the app name and what you want out of e-rupee, and we arrange access and the compliance side with you. Begin at our contact page.