Reaching the loan, UPI and FD records inside Bajaj Finserv

Fifty million-plus customers, per its Play Store listing, run loans, UPI payments, fixed deposits and mutual funds through a single Bajaj Finserv login. That breadth is the reason a lender, an accounting tool or a personal-finance product wants a clean, incremental feed out of it rather than a screen-scrape that re-reads everything nightly. The records sit behind an OTP-bound session and, for the regulated slices, behind a consent rail. Both are reachable. The work is mapping each surface, deciding which path carries it, and writing a sync that pulls only what changed since the last run.

The bottom line: the deposit, loan and investment numbers can come through India's consent network, and the busier surfaces — UPI, wallet, bill payments, the EMI card — come through an authorized read of the app's own backend. We would run both, anchored on a cursor so the daily job stays small.

Where the money data lives in the app

Each row below names the surface the way the app exposes it to the user, where it originates, how granular the records are, and the typical reason an integrator pulls it.

Three authorized paths to the records

Bajaj Finance is a non-banking finance company, so part of its data falls squarely inside India's consent network and part does not. We map each surface to the path that genuinely fits it.

RBI Account Aggregator consent (for the FI types)

Deposit, loan and investment records are the financial-information types an NBFC reports as a provider on the Account Aggregator network. The consumer grants consent through a licensed consent manager, and the data flows provider-to-user under that consent — no credentials change hands. This is the durable path for FD, loan and holdings data: it is regulator-backed, it survives app redesigns, and the user can revoke it. We arrange the AA leg with you during onboarding. Effort is moderate; durability is high.

Authorized session integration (for everything else)

UPI payment history, the Bajaj Pay Wallet, BBPS and FASTag receipts, the EMI card limit and the in-app CIBIL view are not AA datatypes. We reach those by analysing the app's authenticated session under the account holder's authorization, then writing a client against the same calls the app makes. Effort is higher and the surface can shift with app updates, which is why we pin it with contract tests. This is the path that gives you the fast-moving UPI and bills data.

Native export as a backstop

Bajaj Finserv lets a logged-in user download loan-account statements and a Bajaj Pay UPI statement as documents. For a one-off backfill, or where a surface is awkward to read live, we parse those exports to seed history before the live sync takes over. Low effort, limited to what the document contains.

Recommended shape for most teams: stand the deposit and loan slices on the Account Aggregator rail because it is the one that lasts, and run the UPI, wallet and bills slices through the session client because that is where the data actually moves day to day. Seed history once from native exports if you need a long look-back.

A delta-pull sketch against the ledger

Illustrative only — exact paths and field names are confirmed against a live session during the build. The shape that matters is the cursor: store the last reference per account, ask for newer entries, stop when the page comes back empty.

# Per-account cursor sync. Keeps the nightly job small.
client = BajajSession(device_id=DEVICE_ID, msisdn="+91XXXXXXXXXX")
client.start_session(otp_token)        # OTP-bound bearer; refreshed before it lapses

def sync_upi(cursor):                  # cursor = last txn ref we stored
    page = client.get("/bajajpay/payment-history",
                      params={"after": cursor, "limit": 50})
    for txn in page["transactions"]:
        store(key=txn["txnRef"],        # store keyed on txnRef
              data=txn)                 # vpa, amount, status, ts
    return page.get("nextCursor")      # None once we have caught up

def pull_loan(loan_no):                # repayment schedule + ledger
    return client.get(f"/loans/{loan_no}/statement",
                      params={"view": "ledger"})

# Holdings (FD / mutual funds) arrive over the AA consent leg,
# normalised into the same store the session calls write to.

Pagination stops when nextCursor comes back empty, and the stored reference is where the next run picks up. A stale cursor or a re-auth prompt is handled inside the client rather than passed to the caller.

What lands in your repo

The deliverable is code that runs against the surfaces above, not a slide deck. In order of what you get first:

• Runnable clients in Python and Node.js for the loan-statement, UPI-history, wallet, FD and mutual-fund calls — typed models, real error handling, retries.
• A delta-sync worker with a cursor store and a scheduler, so loan ledgers and the faster UPI feed reconcile into one dataset and re-runs resume cleanly.
• An automated test suite built on recorded fixtures and contract checks that pin each response shape the clients depend on.
• An OpenAPI/Swagger spec describing every endpoint the clients touch.
• A protocol and auth-flow report covering the OTP-bound session, token lifetime and refresh, and the AA consent handshake for the FI types.
• Interface documentation and data-retention guidance tied to the DPDP Act and the consent scope you operate under.

What we plan around on this build

These are the parts of Bajaj Finserv we account for up front, so the integration holds together once it is in your hands.

• Mixed backends, one cursor. Loan ledgers update slowly, UPI moves constantly, and FD or mutual-fund holdings refresh on their own cadence. We design token refresh around the short OTP-bound session so a long sync does not fail partway, and we flag any segment whose data looks stale rather than blending it in silently.
• The UPI leg sits under NPCI's TPAP model. Bajaj Pay rides the Unified Payments Interface through a PSP bank, so some fields are exposed at the app layer and some live bank-side. We map that split explicitly and document which payment attributes a third party can actually read.
• The CIBIL view is the sensitive one. The in-app score is a bureau pull surfaced to the user; we treat it read-only, rate-limit it, and keep it inside the granted consent. Access — a consenting account or an AA consent — is arranged with you during onboarding, not assumed.

Consent and the Account Aggregator rails

The dependable basis for everything here is the account holder's own authorization. On top of that, India gives the regulated slices a purpose-built channel. The RBI Account Aggregator network — set out in the NBFC-AA Master Direction (2016) and live commercially since September 2021, per the Department of Financial Services — moves financial information from a provider to a user only with explicit, revocable consent through a licensed consent manager; the Department notes more than 2.8 billion accounts are enabled on it. UPI sits under NPCI, and bill payments run over Bharat BillPay, both RBI-supervised. India's Digital Personal Data Protection Act, 2023 is the privacy regime, now being phased in through its 2025 Rules, with consent, notice and withdrawal at its centre — which lines up cleanly with how the AA flow already works. We operate authorized, logged and data-minimised, keep consent records, and sign an NDA where the engagement needs one.

Where teams plug this in

• A lender pulls a borrower's loan ledger and FD holdings over AA consent to size a top-up offer without asking for documents.
• An accounting product mirrors Bajaj Pay UPI history and BBPS receipts so a small business sees Bajaj transactions next to its bank feed.
• A personal-finance app rolls FD maturities and mutual-fund SIPs into a single net-worth view, refreshed on a cursor.
• A collections tool reads the repayment schedule to reconcile EMIs and time reminders before a due date.

Screens we mapped

App screens from the Play Store listing, used to locate each surface named above. Tap to enlarge.

The wider India fintech shelf

Bajaj Finserv rarely lives alone in a stack. Teams usually want a uniform feed across several of these, which is the case for a normalised schema across providers:

• Paytm — UPI, wallet and a broad bill-payment surface, plus its own lending and investment data.
• PhonePe — India's largest UPI app, with recharges, bills and an investments tab over the same rail.
• CRED — credit-card bill payments and UPI, holding repayment and card-statement records.
• Navi — large personal loans through a phone, with video-KYC and loan-account data.
• MoneyTap — a revolving credit line, so balances and draw history rather than fixed EMIs.
• KreditBee — instant personal loans aimed at self-employed and salaried borrowers.
• Moneyview — instant loans with its own statements and repayment ledger.
• mPokket — small-ticket loans for thin-file users, scored on a digital footprint.
• Fibe — short-tenure lending with loan-account records similar in shape to the above.

What we read, and when

Checked on 2026-06-15 against the app's Play Store listing, the Bajaj Finserv help pages for downloading loan and UPI statements, the Government of India's Account Aggregator material, NPCI's third-party app provider model, and the text of the DPDP Act. Primary sources:

• Bajaj Finserv: Loans, UPI & FD — Google Play listing
• How to download a Bajaj Pay UPI statement (Bajaj Finserv)
• Account Aggregator framework — Dept. of Financial Services, Govt. of India
• The Digital Personal Data Protection Act, 2023 (MeitY)

OpenFinance Lab — interface mapping, 2026-06-15.

Questions we get about Bajaj Finserv

Can the loan ledger and UPI history stay in sync without re-pulling everything each night?

Yes. We keep a per-account cursor for each surface and request only entries newer than the last reference we stored, so a daily run reads a handful of new transactions rather than the full history. Loan repayment ledgers move slowly; the UPI feed moves fast. The delta worker handles both on the same cursor model and reconciles them into one store.

Which Bajaj Finserv records arrive over the RBI Account Aggregator rails, and which need session integration?

The Account Aggregator network carries the financial-information types an NBFC reports as a provider: deposit, loan and investment records under explicit consent. UPI payment history, the Bajaj Pay Wallet, BBPS and FASTag receipts, the Insta EMI Card limit and the in-app CIBIL view are not AA datatypes, so we read those through an authorized session against the app's own backend. Most builds use both paths.

Is the CIBIL score shown in the app something we can read programmatically?

The score and credit-health report displayed in-app are a TransUnion CIBIL bureau pull surfaced to the user. We treat it as read-only and rate-limited, capture it only inside the consent the user has granted, and do not retain the score beyond what the engagement allows. It is reachable, but it is the most consent-sensitive surface on the app and we scope it deliberately.

If we only need FD and mutual-fund holdings, not the loan side, can the build be scoped down?

Yes. The deposit and investment surfaces are separable from the lending and UPI surfaces, so a holdings-only client is a smaller job than the full sweep. A scoped build like that typically runs one to two weeks end to end, including the auth-flow report and tests for just those calls.

Working with us

A first working sync — the Python and Node clients, the cursor worker, and the tests around them — usually lands inside one to two weeks. Source-code delivery starts at $300 and is billed only after the code is in your hands and runs against your account; or skip the build and call our hosted endpoints instead, paying per call with nothing upfront. Tell us the app and what you want out of its data on the contact page, and we scope the rest with you — access and compliance included.