Reaching PNB ONE through India's Account Aggregator consent rails

Punjab National Bank onboarded an account-aggregation platform in 2022, which puts PNB ONE's deposit data inside India's RBI-regulated consent network as a Financial Information Provider. That single fact decides most of how an integration here should be built. The app itself is the retail front end — savings, current, loan and overdraft accounts, term deposits, cards, UPI, bill pay — for one of the country's largest public-sector banks. Two routes reach that data under authorization, and they cover different parts of the app.

Where PNB ONE sits in India's Account Aggregator network

The dependable basis for sharing this data is the customer's own consent, captured and regulated through the Reserve Bank of India's NBFC-Account Aggregator framework and DEPA, NITI Aayog's consent-based data-sharing architecture. The framework went live commercially in September 2021. In it, a licensed Account Aggregator acts as a data-blind consent manager: it shows the user every request, captures a signed consent artefact, and relays only an encrypted payload from the FIP to the Financial Information User. It never decrypts the data.

Punjab National Bank is on the FIP side of that pipe. The consent artefact is granular and revocable — it carries the data types, purpose, duration and fetch frequency, and the user can withdraw it at any point. FIPs are required to keep audit logs, which RBI Master Directions set at a seven-year retention. For PNB ONE that means deposit balances and statements have a standardized, regulator-backed path that does not touch the customer's MPIN or password. What it does not mean is full coverage: the FI types are asset-based, so several PNB ONE surfaces live outside this route entirely.

What PNB ONE holds for each customer

These are the surfaces the app exposes to an authenticated user, named the way PNB ONE names them where possible.

Routes we'd take to PNB ONE's data

1 · Regulated Account Aggregator consent

This route reaches the asset-based FI types: the Deposit type (savings and current accounts, with statement lines), and — because PNB supports them — the Term Deposit and Recurring Deposit types. Securities and insurance follow the same schema if the customer holds them. Effort is moderate and the durability is high, since the schemas are published by ReBIT and the path is RBI-regulated rather than scraped. We handle onboarding as a Financial Information User, or work through a licensed AA and a technology service provider, and design the consent artefact to match the data you actually need.

2 · Authorized protocol analysis of the app

Everything the AA schema does not carry sits here: UPI transaction history, debit and credit card limits and controls, bill-pay and biller records, cheque status, scheduled and recurring transactions. We capture the app's traffic against a consenting account, document the MPIN / TPIN / OTP auth chain it uses, and build a client for the endpoints behind those screens. Effort is higher and the route needs maintenance when the app changes between releases, but it is the only way to reach the transactional and card surfaces.

3 · Native statement export

PNB ONE can download an account statement as a PDF from M-Passbook. That makes a low-effort fallback for statement data when a project only needs periodic statements and not a live feed — we parse the PDF into structured rows. It is coarse compared with the AA feed, but durable.

For PNB ONE the deposit and statement data is exactly what the Account Aggregator schema was built to carry, so we'd anchor a build on the AA consent route and bring in protocol analysis only where you need the card, UPI or bill-pay surfaces the FI types leave out. The PDF export is there if statements are all you want.

What lands in your repo

The output is a working integration, not a report. For PNB ONE that means:

• An OpenAPI / Swagger specification mapping the surfaces above to normalized endpoints — deposits, statements, transfers, UPI, cards.
• A protocol and auth-flow report: either the FIP-to-AA consent handshake and ReBIT FI schema mapping, or the MPIN / TPIN / OTP token chain for the protocol-analysis route, whichever the project uses.
• Runnable source in Python or Node.js for the key calls — balance read, statement fetch, deposit list, UPI history.
• Automated tests against representative payloads.
• Interface documentation a developer can hand to the next person.
• Compliance and data-retention guidance: consent-record handling, alignment with the seven-year FIP audit-log expectation, and data minimization.

A statement pull, sketched

The shape below is illustrative — it follows the ReBIT FI schema for the AA route; the exact field values are confirmed against the FIP during the build.

# Request PNB deposit data over the Account Aggregator consent rails,
# then flatten one statement line. The AA relays an encrypted payload
# from PNB (the FIP); the FIU decrypts it after consent is granted.

import requests

def fetch_fi_data(aa_base, consent_id, session_id, fiu_token):
    r = requests.post(
        f"{aa_base}/FI/fetch",
        json={"consentId": consent_id, "sessionId": session_id},
        headers={"Authorization": f"Bearer {fiu_token}"},
        timeout=30,
    )
    r.raise_for_status()
    return r.json()   # { "FIP": [ { "data": [ { "encryptedFI": "..." } ] } ] }

def normalize_deposit_txn(txn):
    # ReBIT "Deposit" transaction element -> one flat row
    return {
        "account_type":  txn.get("type"),            # SAVINGS | CURRENT | TERM-DEPOSIT
        "amount":        float(txn["amount"]),
        "narration":     txn.get("narration", ""),
        "value_date":    txn["valueDate"],           # YYYY-MM-DD
        "balance_after": float(txn.get("currentBalance", 0)),
    }

Engineering details we account for

A few things about PNB ONE specifically shape how the work runs:

• Deposit coverage is bank-specific. Fixed and recurring deposits are only exposed by a subset of banks on the AA network; PNB is one of them (per Sahamati's FI-type list). We map the Term Deposit and Recurring Deposit types rather than treating every deposit as a savings balance, so maturity and tenure come through.
• Consent has a clock. The artefact carries a fixed duration and fetch frequency. We design the sync cadence around that window and add renewal prompts, so a feed does not quietly stop returning data when consent lapses.
• The app uses layered authentication. PNB ONE signs in with MPIN, confirms transactions with TPIN and OTP, and adds biometric or face authentication on iOS, per the bank's own pages. For the protocol-analysis route we document that multi-factor chain and run capture against a consenting account arranged with you during onboarding.
• The app moves between releases. The 4.x line changes its front end over time, so for the protocol route we keep a re-validation step in the maintenance plan for when surfaces shift between versions.

Access, sandbox and consent arrangements are part of the engagement — set up with you as the build starts, not a checklist to clear first. We work authorized, log what we touch, minimize the data we pull, and sign an NDA where a project needs one.

Where teams plug this in

• A lender pulling PNB ONE deposit statements over the AA route to do cash-flow underwriting without asking the borrower for paper statements.
• A personal-finance or wealth app folding a customer's PNB balances and term-deposit maturities into one dashboard alongside other banks.
• A reconciliation tool matching NEFT and UPI payouts captured from the app against ledger entries in an ERP.

App screens

Screens from the Play Store listing, useful for confirming where each surface sits. Select to enlarge.

What we checked

This mapping was put together in June 2026 from the app's own store listings and Punjab National Bank's mobile-banking pages, the news record of PNB joining the Account Aggregator network, and the published FI-type catalogue for the AA framework. Primary sources:

• Business Standard — PNB on-boards account aggregation platform
• Sahamati — data (FI types) available on the Account Aggregator framework
• Dept. of Financial Services, Ministry of Finance — Account Aggregator framework
• Punjab National Bank — PNB ONE mobile banking

Mapped by the OpenBanking Studio integration desk, June 2026.

Other Indian banking apps in the same data picture

Same category, same broad shape of data, all reachable through the same Account Aggregator network as FIPs — useful context when a project needs more than one bank under a single integration. Named for reference only, no ranking implied.

• YONO SBI — State Bank of India's all-in-one app; deposits, cards, investments and a marketplace behind one login.
• HDFC Bank MobileBanking — accounts, cards, payments and statements for HDFC retail customers.
• ICICI Bank iMobile Pay — UPI, accounts, investments and credit services in a single app.
• BOI Mobile — Bank of India's official banking app covering accounts, transfers and bill pay.
• Canara ai1 — Canara Bank's consolidated "one bank, one app" with the usual deposit and payment surfaces.
• bob World — Bank of Baroda's mobile app for transfers, card payments and utility bills.
• Axis Bank mobile banking — accounts, deposits, cards and payments for Axis customers.
• Kotak811 — Kotak Mahindra Bank's digital account app with balances, deposits and UPI.
• BHIM — the NPCI UPI app; per-VPA payment history rather than full account data.

Questions integrators ask about PNB ONE

Can the Account Aggregator route return PNB term and recurring deposits, or only savings balances?

It returns more than demand deposits. Punjab National Bank is among the banks that expose the Term Deposit and Recurring Deposit FI types on the Account Aggregator network, so we can map principal, tenure and maturity for fixed and recurring deposits, not just savings and current account balances. The savings and current data arrives as the Deposit FI type, with statement lines attached.

How do we reach PNB ONE surfaces the Account Aggregator schema does not carry, like UPI history or card limits?

Through authorized protocol analysis of the app's own traffic against a consenting account. The Account Aggregator FI types cover deposits, securities, insurance and a few other asset categories, but not UPI transaction history, debit and credit card limits, bill-pay records or cheque status. For those we document the MPIN, TPIN and OTP auth chain that PNB ONE uses and build a client against the relevant endpoints.

Who regulates this data sharing and where does the consent actually live?

The Reserve Bank of India, through the NBFC-Account Aggregator framework and DEPA, NITI Aayog's consent-based data-sharing architecture. Consent is a signed, revocable, machine-readable artefact held by a licensed Account Aggregator that relays only encrypted data and never decrypts it; the Financial Information Provider keeps audit logs, which RBI Master Directions require to be retained for seven years.

Does the corporate PNB One Biz app need a separate build from PNB ONE?

Yes. PNB One Biz is a distinct corporate application with its own login, entitlements and approval flows, per Punjab National Bank's own pages. A retail PNB ONE integration does not automatically cover it, so we scope the corporate app as separate work when a project needs both.

The PNB ONE integration ships as runnable source for the endpoints, packaged with the OpenAPI spec, tests and interface docs — from $300, billed only after delivery once you are satisfied. If you would rather not host anything, call our endpoints instead and pay per call, with no upfront fee. Either way the cycle is one to two weeks, and you only ever give us the app name and what you want from its data — tell us that on the contact page and we set up the access and consent side with you.