Reaching IPPB and Post Office Savings data behind one login

One IPPB login shows two ledgers at once: the customer's India Post Payments Bank account and their linked Post Office Savings Account, side by side. Around that sit a full IMPS, NEFT, RTGS and UPI transfer history, a stack of utility-bill and recharge payments, and the profile fields a customer can edit. For anyone building reconciliation, personal-finance, or lending-underwriting tooling on top of an Indian deposit account, that is a dense, useful set of records — and there is an authorized way to read each part of it.

The bottom line: this is a deposit-account data problem with a regulated answer for the core records and a protocol-analysis answer for the rest. We map the surfaces the app shows, decide which authorized route reads each one cleanly, and hand back code that returns them in a normalized shape.

What sits behind an IPPB login

Each row below is a surface the app itself presents to a signed-in customer, named the way IPPB names it where possible.

Three authorized ways in

Account Aggregator consent (regulated AIS)

India runs a consent-based data-sharing network under the RBI's NBFC Account Aggregator directions. A signed consent artefact carries explicit duration, frequency and purpose, and the user can revoke it natively. Deposit-account balances and statement data are precisely what the network was designed to carry. We handle the Financial Information User side of onboarding and work with a licensed Account Aggregator; whether IPPB is currently live as a Financial Information Provider on the network is something we confirm against the Sahamati FIP–AA mapping during scoping rather than assume.

Authorized protocol analysis of the Appzillon traffic

The app is built on i-exceed's Appzillon platform, which exposes banking functions as JSON-over-HTTPS microservices behind a device-bound, mPIN-gated session. Working from a consenting account you authorize, we read the request and response shapes for any surface the app shows a user — transfer history, bill payments, profile — and reproduce them in clean client code. Durability is tied to app versions, so we build in a re-validation step.

In-app statement download

The app lets a customer pull a statement directly. That covers ad-hoc, one-off needs but does not scale to a sync, so we treat it as a fallback rather than a feed.

For IPPB specifically, balances and statements sit squarely inside the Account Aggregator schema, so where IPPB is enrolled as an FIP that consented route is the one we'd reach for first; the transfer-rail and bill-payment detail the AA schema does not always carry we pick up through the protocol route. The in-app download stays in reserve for one-offs.

What lands in your repository

• An OpenAPI/Swagger description of the modeled endpoints — balance, statement, transfer history, bill payments.
• A protocol and auth-flow report covering the Appzillon device-binding plus mPIN session and the token lifecycle as it behaves on this build.
• Runnable source for the key endpoints in Python and Node.js.
• A normalized schema that folds the IPPB ledger, the linked Post Office Savings ledger, and the payment rails into one model.
• Automated tests that run against a consenting account or an Account Aggregator sandbox.
• Interface documentation, plus data-retention and consent-logging guidance aligned to the DPDP Act.

A statement pull, sketched

Illustrative only — exact paths and field names are confirmed during the build against a consenting account, not lifted from any IPPB document.

POST /appzillon/txn/accountStatement          # Appzillon microservice surface
Authorization: Bearer <session token from mPIN + device-bind login>
Content-Type: application/json

{
  "accountId": "<IPPB or linked POSA account ref>",
  "fromDate":  "2026-04-01",
  "toDate":    "2026-06-23",
  "channel":   "MOBILE"
}

# Normalized response our client emits (mapped from the raw payload):
{
  "account": { "type": "IPPB_SAVINGS", "masked": "XXXX4821" },
  "balance": { "available": 10840.50, "currency": "INR" },
  "entries": [
    { "ts": "2026-06-21T09:14:00+05:30", "rail": "UPI",
      "amount": -250.00, "narration": "DTH recharge", "ref": "..." }
  ]
}

# Error handling we wire in:
#  401 / session expired -> re-run device-bind, refresh token, retry once
#  throttle / rate cap    -> back off, resume the date window from last cursor

Consent under the AA regime and the DPDP Act

The dependable basis for reading a customer's IPPB records is the customer's own authorization. Under the RBI's Account Aggregator framework — set out in the NBFC-AA Master Direction first issued in September 2016 — that authorization takes the form of a signed consent artefact with a stated purpose, duration and frequency, and the user can revoke it at any time. No financial information moves without it, and India's data-residency rules keep the path in-country.

On top of that sits the Digital Personal Data Protection Act, 2023, India's first comprehensive privacy law; where RBI sectoral rules are stricter, they prevail. We operate inside both: access is authorized, logged and data-minimized, consent records are kept, and we sign an NDA where the work calls for one. None of this is a hurdle we hand to you — it is how the build runs.

Things we plan around on this build

Two ledgers, one screen. The IPPB account and the linked Post Office Savings Account are separate backend ledgers that the app happens to show together. We model them as distinct sources so a POSA balance is never silently merged into the IPPB figure, and statements stay attributed to the right account.

KYC tiering changes the surface. The app describes a Digital Savings account as carrying a cumulative monthly cap of about Rs. 10,000 before full KYC, with transfer rails like IMPS, NEFT, UPI and Standing Instructions only switching on after full KYC. We scope per tier so the integration reports the right limits and the right available endpoints instead of assuming a uniform account.

Appzillon front-end versioning. Because the surfaces come off a versioned Appzillon client, a release that reshapes a payload can shift field names. We pin the captured version, keep a mapping layer, and re-validate after app updates so the feed does not quietly drift.

Locale spread. The app ships in English plus twelve Indian languages, so narration strings can arrive in different scripts. We pin the capture locale and keep parsing tolerant of that.

Screens we mapped

The store screenshots, full size. These are what we read against when planning capture.

Keeping the feed honest

Freshness depends on the route. An Account Aggregator consent governs how often a pull can run, so the sync cadence is set by the consent you grant, not guessed at. Balance reads are near real time; statements come date-ranged, which means a backfill resumes cleanly from the last cursor. On the protocol route, the watch item is app releases — our re-validation pass catches a reshaped payload before it reaches your data.

Working with us, and what it costs

What you get back is a git repository: runnable endpoints for the balances, statements and transfer history described above, an OpenAPI file, the auth-flow report and tests — usually inside a one-to-two-week cycle. For source-code delivery, pricing starts at $300, and you pay after delivery, once the code runs against your consenting account and you are satisfied with it. If you would rather not host anything, call our endpoints instead and pay per call, with no upfront fee. Either way, the starting point is the same: tell us the app and what you need from its data at our contact page, and we scope the access with you.

Where IPPB sits among India's banking apps

The same modeling carries across the wider Indian payments and banking landscape, which makes a unified integration practical. Apps an integrator commonly sees alongside IPPB Mobile Banking:

• PhonePe — UPI-first app holding transfer history, linked accounts and bill payments.
• Google Pay — UPI transfers with recharge and bill-payment records.
• Paytm — wallet, UPI and bank surfaces holding balances, transactions and merchant payments.
• BHIM — NPCI's UPI app, carrying transfers and VPA-linked account detail.
• Amazon Pay — UPI and wallet tied to purchase and payment history.
• SBI YONO — full-service bank app with accounts, statements and transfers.
• ICICI iMobile Pay — bank app exposing balances, statements, cards and UPI.
• HDFC PayZapp — payments app with card, UPI and bill records.
• DakPay — IPPB's own BHIM-UPI app, sharing the same payment rails.

Questions integrators ask about IPPB

Can the integration read both the IPPB account and the linked Post Office Savings Account?

Yes. They are two different backend ledgers that the app surfaces in one view. We model each as a distinct source so an IPPB Savings balance and a linked Post Office Savings Account balance never get conflated, and we can also emit a single consolidated read across both for a treasury or net-position use.

Does a pre-full-KYC Digital Savings account expose the same data as a full-KYC account?

Not quite. The app describes a Digital Savings account as carrying a cumulative monthly transaction cap of about Rs. 10,000 before full KYC, with IMPS, NEFT, UPI and Standing Instructions activating only after full KYC. We scope the integration per KYC tier so the limits and the available surfaces are handled correctly rather than assumed.

Which authorized route do you recommend for IPPB statement and balance data?

Balances and statements are exactly the structured records India's Account Aggregator network was built to move, so where IPPB is live as a Financial Information Provider, consented AA access is the route we reach for first. Surfaces the AA schema does not always carry, such as bill-payment detail, we pick up through authorized protocol analysis of the app's Appzillon traffic.

We need IPPB statement data feeding reconciliation; how does the build actually run?

Against a consenting IPPB account or an Account Aggregator consent you grant. We capture the statement and transfer surfaces, map them onto a normalized schema with rail, amount, narration and reference, and hand back runnable code plus tests. The access and the compliance side are arranged with you during scoping.

How this brief was put together

Drawn up on 2026-06-23 from IPPB's own product pages, the app's Play Store listing, i-exceed's published case study on the Appzillon build (the com.iexceed.appzillon.ippbMB package id points at that platform), and the RBI / government Account Aggregator material together with the DPDP Act text. Specifics checked against:

• i-exceed — India Post Payments Bank case study (Appzillon)
• IPPB — Remittances & Fund Transfers (IMPS/NEFT/RTGS/UPI)
• Dept. of Financial Services — Account Aggregator framework
• Sahamati — FIP–AA mapping

Mapping reviewed by OpenBanking Studio's integration desk, June 2026.