Reaching account and transaction data inside YONO SBI

State Bank of India has been live as a Financial Information Provider on the RBI Account Aggregator network since approximately 30 July 2022, per SBI's own account-aggregator notice. That single fact sets the cleanest authorized path into the data the YONO app surfaces: a consenting SBI customer can share their account and transaction records over the AA rails without anyone touching their YONO credentials. Most of what an integrator wants — balances, statement lines, deposits — flows that way. The rest sits in the app session and needs a second, complementary route.

How the data is reached

Two routes do the real work here, and they cover different surfaces.

Account Aggregator consent (recommended for the core records)

SBI participates as a FIP, so a consenting customer's CASA accounts, term deposits and card records can be requested through a licensed Account Aggregator under a signed consent artefact. Data arrives in the ReBIT standard FI schemas — one implementation against the AA specs reaches every AA, which is why this is the durable choice for the regulated core. We set up the FIU-side onboarding and the AA handshake with you during the build; what is reachable is bounded by the consent the user signs, not by guesswork.

Authorized protocol analysis (for the app-only surfaces)

UPI pay/collect history, the mPassbook view, the loyalty ledger and the credit-score simulator output are YONO presentation surfaces that the AA schema does not enumerate. For those we document the app's authentication and token chain under your written authorization and build a consented client that reads them. Effort is higher than the AA route and the surface can shift when SBI updates the front end; we account for that in maintenance. Where a YONO surface offers a native e-statement or PDF download, that export is a low-effort fallback for ad-hoc pulls.

The recommendation for an SBI-centric build is concrete: run the regulated AA consent flow for everything it covers, because it is the most durable and the most defensible, and reserve the protocol client for the UPI and mPassbook data the schema leaves out. Mixing them gives a single normalized view without over-reaching on either side.

What YONO actually holds

What lands at the end

The output is built around the surfaces above, not a generic banking stub:

• An OpenAPI/Swagger specification covering the normalized endpoints — accounts, transactions, deposits, cards, UPI history.
• A protocol and auth-flow report: the AA consent handshake on one side, and the YONO token/session chain for the app-only surfaces on the other.
• Runnable source for the key endpoints in Python or Node.js — the AA FI-fetch client plus the consented app client.
• Automated tests against recorded fixtures so a YONO front-end change is caught before it reaches you.
• Interface documentation mapping every field back to where it originates in the app or the FI schema.
• Consent-handling and data-retention guidance fitted to the AA artefact lifecycle.

A consent-bound fetch, in outline

Illustrative shape of the AA route once consent is active — field names follow the ReBIT FI direction; values are confirmed against the live schema during the build.

# 1. Resolve the signed consent artefact, then request an FI session
POST /Consent/handle        -> { "ConsentStatus": "ACTIVE", "consentId": "..." }
POST /FI/request
  body: { consentId, "FIDataRange": { "from": "2026-01-01", "to": "2026-06-26" } }
       -> { "sessionId": "...", "ver": "2.0.0" }

# 2. Poll, then pull SBI account + transaction blocks (decrypted client-side)
GET  /FI/fetch/{sessionId}
  -> { "FI": [ { "fipId": "SBI",
                 "Account": { "type": "deposit", "maskedAccNumber": "XXatXXXX1234",
                              "Summary": { "currentBalance": "...", "currency": "INR" },
                              "Transactions": { "Transaction": [
                                  { "txnId": "...", "amount": "...", "type": "DEBIT",
                                    "mode": "UPI", "valueDate": "2026-06-21",
                                    "narration": "..." } ] } } } ] }

# Surfaces outside the FI schema (mPassbook view, UPI ledger, rewards)
# are read via the consented app client and merged into the same record.
def normalize(fi_block, app_block):
    # one account/txn/deposit shape regardless of source; errors surfaced, not swallowed
    ...

Consent and the RBI framework

The route rides India's Account Aggregator framework, regulated by the Reserve Bank of India under the NBFC-AA Master Direction and the ReBIT technical specifications. The dependable basis for sharing is the customer's own consent: a granular, digitally signed artefact in which the user fixes the data types, the date range, the purpose and an expiry, and which they can revoke at any time. The AA itself moves encrypted data and never decrypts it. We work to that posture throughout — authorized and documented access, consent and access logs retained, data minimized to the stated purpose, and an NDA in place where the engagement needs one. For the app-session route, access is exercised only under your written authorization for accounts you control or that consent to it.

Things we handle on the build

Two specifics that shape an SBI integration, both handled on our side:

• AA consent has a fixed validity and a fetch frequency baked into the artefact. We design the sync around that window so a long-running feed does not silently expire mid-period, and we surface a renewal prompt before it lapses rather than after.
• The mPassbook and UPI surfaces are app-rendered and move when SBI ships a YONO update. We pin the protocol client to recorded fixtures and run a re-validation pass in maintenance so a layout or token change is caught in tests, not in your production data.
• SBI's investment and card data is sourced from subsidiaries linked into YONO, so identifiers differ across products. We map them to a single account model so a deposit, a card and a mutual-fund holding read consistently. Access — an AA sandbox or a consenting account — is arranged with you during onboarding.

Interface evidence

Screens from the public Play Store listing, used to locate the surfaces named above.

Neighbouring apps in the same data space

Same-category Indian apps an integrator often unifies alongside YONO. Named for context, not ranked.

• ICICI iMobile Pay — holds CASA, cards, investments and UPI for ICICI customers behind one login.
• HDFC Bank MobileBanking — exposes accounts, deposits, cards and loan records for HDFC account holders.
• Kotak 811 — a mobile-first account with savings, UPI and card data held server-side.
• Axis Mobile — accounts, deposits, cards and investment holdings for Axis customers.
• bob World (Bank of Baroda) — savings, deposit and loan records under one banking login.
• Paytm — wallet balances, UPI transactions and bill-payment history.
• PhonePe — UPI transaction records and linked-account references.
• BHIM — UPI payment records tied to linked bank accounts.
• Google Pay (India) — UPI transaction logs and linked-account references.

What was checked

Surfaces were read from the public Play Store description and listing; the regulated route was checked against SBI's account-aggregator notice and the RBI/ReBIT and Sahamati ecosystem documentation. Sources opened for this write-up:

• SBI — Account Aggregator framework notice (FIP participation)
• YONO SBI on Google Play (feature listing)
• Sahamati — Account Aggregator API specs & FI schemas (ReBIT)
• Ministry of Finance — Account Aggregator framework overview

Mapped by the OpenBanking Studio integration desk · June 2026.

Questions an SBI integrator asks

SBI is live on the Account Aggregator network — does that let you pull a YONO user's full transaction history?

Through the AA route you get what the consent artefact authorizes: CASA balances and transaction records under the ReBIT FI schemas, scoped to the date range and purpose the user signs. Full historical depth depends on what the FIP exposes for that account type; deeper or app-only surfaces such as the mPassbook view and UPI activity are reached through the authorized protocol route instead.

Which State Bank of India products actually show up once YONO data is normalized?

Savings and current accounts, term and recurring deposits, card records, and the investment and loyalty surfaces YONO links from SBI's subsidiaries. We map each to a common schema so an account, a deposit and a card read consistently rather than as three unrelated payloads.

How do you reach the UPI and mPassbook data that the Account Aggregator schema doesn't cover?

Those live in the app session. We document the YONO authentication and token chain under your authorization and build a consented client that reads the mPassbook and UPI history surfaces, then normalize them into the same model as the AA-sourced records.

What consent and revocation rules apply under the RBI framework here?

AA consent is a granular, digitally signed artefact: the user fixes the data types, the date range, the purpose and an expiry, and can revoke at any point. We design the sync around that window so it does not silently expire, keep consent and access logs, and minimize what is fetched to the stated purpose.

Working with us

You bring the app name and what you need out of YONO's data; we handle the route, the AA onboarding or the consented app client, the access arrangements and the compliance posture. Delivery runs on a one-to-two-week cycle. Take the source-code delivery from $300 — runnable client, spec, tests and docs, paid after delivery once you are satisfied — or call our hosted endpoints and pay per call with no upfront fee. Tell us which SBI surfaces matter and we will scope it: start a conversation.