What it takes to pull bob World account data into your stack

bob World is Bank of Baroda's customer-facing channel, and the app states it carries roughly 240 services behind a single login. That breadth is the reason an integrator looks at it: one authenticated session sits on top of deposit accounts, the card rails, term deposits, a loan book, an investment desk, and a UPI handle. The bottom line for a build is that the data splits into two cleanly separable halves. Core account and transaction records are reachable through India's consent network without touching the app at all. Everything the bank layers on top of that account — spend categorisation, card controls, loan servicing, holdings — lives only in the app session and needs authorized protocol work to reach.

What the app actually holds

These are the surfaces the app exposes to a logged-in customer, mapped to where each one originates and what an integrator does with it.

Routes to the data

Three approaches apply here, and they overlap rather than compete.

RBI Account Aggregator consent

Bank of Baroda is a Financial Information Provider on the Account Aggregator network, so deposit balances, transaction history and term-deposit records can be requested through a licensed NBFC-AA with the customer's explicit consent. The data moves encrypted from the bank to the consuming party; the aggregator itself stays data-blind. This is the durable path for the account-and-transaction half, because it is regulated, the consent artefact is logged, and it does not break when the app's screens change. We arrange the FIU-side onboarding and the AA connection with you as part of the project.

Authorized protocol analysis of the app session

The surfaces the AA schema does not define — spend categories, card controls, loan servicing detail, investment holdings — are reachable only by observing and reconstructing the app's own traffic under your authorization. We capture the login and mPIN handshake, the session token lifecycle, and the per-feature endpoints, then re-implement them as clean calls. Effort is higher and it needs upkeep, but it reaches everything the customer can see.

Native statement export

For a lighter need, the app and net-banking already produce downloadable statements. We can parse those into structured records as a fallback where a live feed is not warranted.

For most builds the sensible split is plain: take the account and transaction core over Account Aggregator because it is consent-clean and stable, and add protocol analysis only for the app-specific surfaces that the AA schema leaves out. We will say which half your requirement actually needs before any code is written.

What we hand over

Each deliverable is tied to bob World's real surfaces, not a generic kit.

• An OpenAPI specification covering the endpoints your build needs — balance, statement, transfer history, and whichever app-specific surfaces are in scope.
• A protocol and auth-flow report: the dual-PIN login, the session token chain, device-binding behaviour, and the AA consent handshake as it applies to a Bank of Baroda FIP fetch.
• Runnable source for the key endpoints in Python or Node.js, with retry and error handling around session expiry.
• Automated tests against recorded fixtures so the flows stay verifiable as the app evolves.
• A normalized schema that folds AA-sourced records and app-session records into one consistent shape, with UPI/NEFT/IMPS legs tagged.
• Interface documentation plus data-retention and consent-logging guidance fit for the DPDP Act.

A sample flow

Illustrative only — exact field names are confirmed during the build against a consenting account. This sketches the two halves meeting in one client: an AA-sourced deposit fetch and an app-session statement pull, normalized together.

# bob World — combined fetch (illustrative)
# Half A: deposit + transactions via Account Aggregator (NBFC-AA)
consent = aa.request_consent(
    fip="bank-of-baroda",
    fi_types=["DEPOSIT", "TERM_DEPOSIT"],
    purpose="101",            # account aggregation, consent-logged
    fetch="PERIODIC",
)
# customer approves in the AA handle app; FIU receives encrypted FI data
fi = aa.fetch(consent.id)     # balances + dated transactions

# Half B: app-only surface via authorized session (re-implemented)
sess = bobworld.login(user_id, login_pin, device_id)   # then transaction mPIN
sess.refresh_if_expiring()
spend = sess.get("/pfm/spend-analyzer", params={"month": "2026-06"})

def normalize(txn):
    return {
        "account": txn["maskedAccNumber"],
        "amount": txn["amount"],
        "ts": txn["valueDate"],
        "rail": classify_rail(txn),   # UPI / NEFT / IMPS / internal
        "source": txn.get("_source", "AA"),
    }

records = [normalize(t) for t in fi.transactions] + spend.categories
      

Consent and the law that frames it

The consent route is the Reserve Bank of India's Account Aggregator framework. Account Aggregators are licensed as NBFC-AAs under the RBI Master Direction first issued in 2016, with the network entering commercial operation in 2021. The model is explicit: no financial information moves without the customer's consent, the consent is scoped by FI type, purpose and duration, and it can be revoked. The aggregator never decrypts the payload. For personal-data handling on the consuming side, India's Digital Personal Data Protection Act, 2023 governs how records are stored and minimized. We keep the consent artefact and an access log on every fetch, sign an NDA where the engagement calls for it, and pull only the FI types your purpose actually requires.

Engineering notes we account for

Two things about this app shape how we build, and we handle both inside the project.

• The AA FI schema covers deposits and transactions but not the app's derived layers — spend categories, card on/off state, loan EMI schedules, holdings. We map domain by domain which records come from the consent network and which need session reconstruction, then merge them so a consumer sees one schema rather than two feeds with different shapes.
• bob World separates the login PIN from the transaction mPIN and binds the session to a registered device. We design the auth handling and token refresh around that against a consenting account, so the integration does not keep tripping device re-registration. When the app's front end shifts, we re-validate the captured flows as part of routine upkeep rather than waiting for a feed to fail silently.
• UPI, NEFT and IMPS all land against the same deposit account, so a raw transaction stream mixes rails. We tag each leg during normalization so reconciliation downstream stays unambiguous.

Access, credentials and the AA onboarding are arranged with you during onboarding; the build runs against a sponsor sandbox or a consenting account. None of that is something you sort out before we start.

Mapping reviewed 2026-06-28.

What the interface looks like

Screens from the Play Store listing, useful for spotting which surfaces feed which records.

Working with us

The runnable bob World client and its docs are the thing you actually receive. There are two ways that lands. Under source-code delivery, pricing starts at $300, you get the runnable API source plus interface documentation, and you pay after delivery once the build satisfies you. Under the hosted option, you call our endpoints and pay only per call, with no upfront fee. A typical cycle runs one to two weeks. Tell us the data you need from bob World and we will scope it — start the conversation here.

Sources and provenance

Checked on 2026-06-28: the app's own Play Store listing for its service set and package id, the Account Aggregator framework documentation for the consent model and FIP/FIU roles, and Bank of Baroda's open-banking pages for its participation. Citations below.

• bob World on Google Play
• Account Aggregator framework — Dept. of Financial Services
• Bank of Baroda open banking

Mapped by the OpenBanking Studio integration desk · June 2026.

Peer apps in the same data space

An integrator weighing bob World usually wants the same records across several Indian banking apps. These hold comparable account and transaction data, which makes a single normalized schema worthwhile.

• SBI YONO — State Bank of India's app; deposits, loans and investment surfaces behind one login.
• ICICI iMobile Pay — accounts, cards and UPI, with payment data for non-ICICI accounts too.
• HDFC Bank MobileBanking — accounts, cards, deposits and bill payments.
• Axis Mobile — full retail banking with transfers, cards and investments.
• Kotak Mobile Banking / 811 — accounts, UPI and the 811 digital savings product.
• PNB ONE — Punjab National Bank accounts, statements and transfers.
• Canara ai1 — Canara Bank's consolidated retail banking app.
• IndSMART — Indian Bank accounts and digital services.
• Union Ease — Union Bank of India banking and payments.

FAQ

Which bob World data comes through the Account Aggregator route, and which does not?

Deposit balances, transaction history and term-deposit records map cleanly to the AA FI-type schema, since Bank of Baroda participates as a Financial Information Provider. The app's spend-analyzer categories, debit-card controls, loan servicing and investment holdings sit outside that schema, so we reach them through authorized protocol analysis of the app session and normalize both sources into one shape.

How does bob World's dual-PIN security shape an integration?

Login uses a separate PIN from the transaction mPIN, and the app binds to a registered device. We design the auth handling and token refresh around that during the build, working against a consenting account so the captured login and session-keepalive flow stays stable rather than re-triggering device re-registration.

Can you cover UPI transaction history from bob World?

Yes. UPI activity in bob World is recorded against the underlying deposit account, so the transaction stream surfaces through the AA deposit FI type and through the app's statement view. We reconcile the two and tag UPI versus NEFT and IMPS legs in the normalized output.

What regulator and data law govern this work in India?

The consent-based route is the RBI Account Aggregator framework, run by licensed NBFC-AAs under the 2016 Master Direction that went into commercial operation in 2021. Personal data handling follows India's Digital Personal Data Protection Act, 2023. We keep consent artefacts and an access log for both.