Loan books, Bajaj Pay and FD balances: the consented routes into Bajaj Finance

Fifty million-plus customers, per its Play Store listing, run personal loans, gold loans, fixed deposits, a Bajaj Pay UPI handle and a live CIBIL feed through a single org.altruist.BajajExperia login. That mix is the whole reason a third party wants in: one account holder's record here spans lending, deposits, investments, insurance and a payments ledger. India happens to have a clean regulated pipe for part of it, and a well-understood authorized-interface path for the rest. This brief maps both against the surfaces the app actually exposes to its own users.

The short version: for the customer's deposit, loan, mutual-fund and insurance accounts, the Account Aggregator framework is the route worth building on, because it is consent-governed and returns structured statements rather than scraped screens. For everything the AA rails do not carry — the Bajaj Pay UPI ledger, the wallet, bill-payment and recharge history, the EMI calendar view and the in-app CIBIL widget — authorized interface work against a consenting account is what reaches it. Most real integrations here use both, weighted toward whichever data the buyer actually needs.

Consent rails: the Account Aggregator route and the DPDP Act

India's Account Aggregator (AA) framework is the operative regime, run under the Reserve Bank of India. An AA is an RBI-licensed NBFC that sits between a Financial Information Provider (FIP), which holds the data, and a Financial Information User (FIU), which consumes it; it moves encrypted data on the customer's explicit, revocable consent and never reads the payload itself. The framework has been in commercial operation since September 2021 (per the Department of Financial Services). Bajaj Finance participates in this ecosystem as a user of AA data — its management described using AA consent to pull applicants' bank statements for underwriting on its Q4 FY24 earnings call — which means the plumbing to consume AA data through a certified handle is a road the studio builds on rather than invents.

Consent under AA is scoped and time-bound: a request names the FI types, the purpose, the fetch frequency and an expiry, and the customer can revoke at any point. On top of that sits the Digital Personal Data Protection Act, 2023, which puts every NBFC and fintech in the position of a data fiduciary and makes specific, purpose-bound consent the lawful basis for processing. We design integrations so the consent artefact, its scope and its expiry travel with the data, and so a withdrawn consent stops the next fetch — not a compliance afterthought but how the pull is wired.

Account data sitting behind a Bajaj Pay login

These are the surfaces the app shows its own users, mapped to where each one originates and what an integrator does with it.

Routes into Bajaj Finance account data

Account Aggregator consent (regulated)

What it reaches: the customer's deposit, loan, mutual-fund and insurance accounts held by registered FIPs, returned as structured statements. Effort is moderate — the work is FIU-side certification and the consent UX, both of which we set up with you during onboarding, arranging the certified AA handle and sandbox access as part of the project. Durability is high, because it is a regulated interface rather than a screen that shifts under you. This is the route we would build the account-data core on.

Authorized interface work on the app session

What it reaches: the surfaces AA does not carry — the Bajaj Pay UPI ledger, wallet, bill-payment and recharge history, the EMI calendar and the CIBIL widget. We analyse the app's authenticated traffic against a consenting account, document the token and request chain, and build a client that reads those surfaces the way the app itself does. Effort is higher and durability depends on the app's front end, which is why we plan re-validation into it (see build details). For UPI and payments data specifically, there is no substitute — that is where this route earns its place.

Native export as a reconciliation source

The app already lets a user download loan account statements. Parsing those PDFs is a low-effort, low-risk way to backfill history and cross-check the live pulls; on its own it is periodic rather than real-time, so we use it alongside the two routes above rather than as the primary feed.

What lands in your repo

The deliverables track the surfaces mapped above — loans and EMIs, deposits, holdings, UPI and payments, the CIBIL feed:

• An OpenAPI/Swagger specification covering the endpoints we integrate — loan and EMI reads, FD and MF holdings, UPI and wallet transactions, statement retrieval — with the AA consent flow documented alongside.
• A protocol and auth-flow report: the token, session and consent-handle chain as it actually behaves for this app, including how a fetch is authorized and how it fails.
• Runnable source for the key endpoints in Python or Node.js, structured so you can point it at a sandbox or a consenting account and get records back.
• Automated tests over the response shapes, including the awkward cases — a revoked consent, an empty UPI ledger, a loan with no active EMI.
• A normalized schema that folds loans, deposits, UPI and bill payments into one record model (below), so downstream code is not writing per-surface parsers.
• Interface documentation plus data-retention and consent-logging guidance keyed to DPDP obligations.

A statement pull, sketched

Two shapes, both illustrative and confirmed against real behaviour during the build. First, an AA consent request for the account-data core, following the ReBIT financial-information schema the framework uses:

# Illustrative — AA FI consent request (FIU side), ReBIT-style
POST /Consent  HTTP/1.1
Host: <aa-handle>                      # RBI-licensed Account Aggregator
Content-Type: application/json

{
  "ConsentDetail": {
    "consentStart": "2026-07-01T09:00:00+05:30",
    "consentExpiry": "2027-07-01T09:00:00+05:30",
    "Customer": { "id": "user@aa-handle" },
    "FIDataRange": { "from": "2025-07-01", "to": "2026-07-01" },
    "consentMode": "STORE",
    "fetchType": "PERIODIC",
    "fiTypes": ["DEPOSIT", "TERM_DEPOSIT", "MUTUAL_FUNDS", "INSURANCE_POLICIES"],
    "purpose": { "code": "101", "text": "Consolidated financial view" }
  }
}
# -> returns a consentId + consentHandle; data is fetched only after the
#    customer approves the request inside their AA app.

# Illustrative — authenticated read for a surface AA does not carry
GET /emi/schedule?loanRef=<loan_id>
Authorization: Bearer <session_token>     # from the documented app auth chain
# 200 -> { loanRef, product: "PERSONAL", instalments: [ {due, principal, interest, status} ] }
# 401 -> token expired; client runs the refresh step, then retries once

Normalized records

The point of the schema layer is that a UPI payment, a loan instalment and an FD booking arrive in one shape, tagged by source. Two examples:

{
  "record_type": "loan_account",
  "source": "bajaj_finance",
  "account_ref": "<masked>",
  "product": "gold_loan",
  "sanctioned_amount": { "value": 250000, "currency": "INR" },
  "next_emi": { "due": "2026-07-05", "amount": 8310, "status": "upcoming" }
}

{
  "record_type": "upi_transaction",
  "source": "bajaj_pay",
  "txn_ref": "<masked>",
  "direction": "debit",
  "amount": { "value": 499, "currency": "INR" },
  "counterparty_vpa": "<masked>",
  "category": "bill_payment",
  "ts": "2026-06-28T18:12:04+05:30"
}

Where teams plug this in

1. A lender doing FIU-side underwriting pulls a consenting applicant's Bajaj Finance loan, FD and MF records through AA to size existing exposure before sanctioning fresh credit.
2. A money-management app consolidates the same user's Bajaj Pay UPI ledger, wallet spends, FDs and active loans into one dashboard — AA for the accounts, authorized interface work for the payments.
3. An accounting or expense tool matches Bajaj Pay bill payments and recharges against invoices, using the normalized UPI records to auto-categorise recurring utilities.

Build details we plan around

Bajaj Finance is not one product, so the integration is scoped per surface rather than switched on wholesale. We map each loan type to its own record shape because a gold loan, a two-wheeler loan and a business loan carry different fields and different statement layouts; a build that treats them as one blurs data the buyer cares about. Where the app renders the CIBIL score, we tag it as a TransUnion CIBIL bureau value with its own refresh cadence, so downstream logic never mistakes a cached bureau number for a real-time signal.

The second detail is drift. AA-sourced account data rides a regulated interface and stays stable; the UPI, wallet and EMI surfaces ride the app's own front end, which changes on release cycles. We design the authorized-interface client with a re-validation pass in maintenance, so a changed screen surfaces as a failing test rather than silent bad data. Access — the certified AA handle, a sandbox, a consenting test account — is arranged with you as the project starts; it is part of the engagement, not something you assemble before we will begin.

Screens we mapped

The store screenshots we worked from, as a quick visual reference of the surfaces above.

Where these notes come from

We read the app's Play Store listing for its named products and features, cross-checked the Account Aggregator mechanics against the Department of Financial Services and Sahamati, and confirmed the consent basis against the DPDP Act text. Primary references:

• Bajaj Finance : UPI & Loan App — Google Play listing
• Account Aggregator Framework — Department of Financial Services
• FIPs & FIUs in the AA ecosystem — Sahamati
• The Digital Personal Data Protection Act, 2023 (MeitY)

Mapped by the OpenBanking Studio integration desk, July 2026.

Nearby apps in the same Indian market

Same category, useful when a buyer wants a unified view across more than one provider.

• PhonePe — UPI payments, bill pay and in-app credit, insurance and mutual-fund distribution, with a large transaction ledger per user.
• Google Pay — UPI transfers, bill payments and offers; holds a per-user payment history and linked-account handles.
• Paytm — wallet, UPI, bill pay and lending marketplace; broad payments and merchant records.
• Navi — instant personal loans and UPI, with loan accounts and repayment schedules behind the login.
• CRED — credit-card bill payments and a bureau-linked credit view; holds card and payment records.
• KreditBee — short-tenure personal loans; per-user loan and repayment data with fast disbursal.
• Moneyview — personal loans plus expense tracking; loan accounts and categorised spend history.
• LazyPay — pay-later credit line and small-ticket loans; per-user credit and repayment ledger.
• Freo — a credit line, UPI and fixed-deposit products combined; blended payments and credit data.

Questions integrators ask about Bajaj Finance data

Can a customer's Bajaj Pay UPI history be reached through the Account Aggregator route?

Not directly. The AA rails, as regulated by the RBI, carry bank, NBFC, deposit, mutual-fund and insurance account statements from registered providers. A UPI transaction ledger and the in-app Bajaj Pay wallet sit outside that scope. We reach those through authorized interface work against a consenting account, then reconcile them against the AA-sourced loan and FD records.

What identifies a loan inside the app's data, and can EMI schedules be read per account?

Each loan carries an account reference, a product type (personal, gold, home, business or two-wheeler), a sanctioned amount and a repayment schedule the app renders as an EMI calendar. Those schedules can be read per account, either from the authenticated session or by parsing the statement PDFs the app already lets a user download.

How do you treat the CIBIL score shown inside the app?

The score and credit-health report are a TransUnion CIBIL bureau value surfaced in the app, not a Bajaj-computed number. For a consenting user we can capture the displayed score and report, but we mark it as a third-party bureau field refreshed on the bureau's own cycle, so downstream logic does not treat it as real-time.

The app spans loans, UPI, FD, insurance and bill pay — does an integration have to take all of it?

No. We scope to the surfaces you name. A build that only needs loan statements and EMI schedules skips the UPI, insurance and mutual-fund surfaces entirely. Once the surface list is fixed, a scoped Bajaj Finance integration runs one to two weeks.

Source is delivered as runnable code you pay for only after it is in your hands and working — from $300 for a scoped Bajaj Finance integration. If you would rather not run anything yourself, the same endpoints are available as a hosted API you pay for per call, with nothing upfront. Tell us the app and which surfaces you need at our contact page and we will scope it, usually inside a one-to-two-week cycle.