Reaching Kotak811's account records the authorized way

Kotak811's balances, statements, UPI history and deposit records live behind Kotak Mahindra Bank's core systems — and in India there is a named, RBI-supervised way to reach the account-level pieces of that without ever touching a password: the Account Aggregator framework. This page sets out what the app actually holds, which authorized routes return which records, and what OpenBanking Studio hands over when you ask us to integrate it. You bring the app name and the records you need. We work out the route and deliver the build.

The short version: for deposit balances and dated transactions, build on the Account Aggregator path — it is regulated, the ReBIT contract is stable, and every pull is tied to an auditable consent. Card statements, reward ledgers and loan servicing do not travel over AA, so those we reach by reading the app's own authenticated traffic under your authorization. A native statement export stays useful as a coarse backfill when you only need PDFs or CSVs.

The Account Aggregator route, and what governs it

India runs a consent-based data-sharing system supervised by the Reserve Bank of India. It rests on three roles: an NBFC-AA (an RBI-licensed account aggregator that moves data but never reads it), a Financial Information Provider that holds the records, and a Financial Information User that consumes them for a regulated purpose. Kotak Mahindra Bank sits on the provider side — per Sahamati's ecosystem material it was among the early banks live on the framework alongside SBI, HDFC, ICICI, Axis, IDFC FIRST, IndusInd and Federal Bank.

The contract is published, not guessed at. ReBIT (Reserve Bank Information Technology) maintains the NBFC-AA API specification that all three roles must adopt, and the framework is administered under the Master Direction – NBFC-Account Aggregator Directions, 2016, and forms part of DEPA, India's broader architecture for consent-driven financial data rights. Consent itself is a digitally signed JSON object: it pins the purpose, the data types, the date range, the fetch frequency, the data-life after fetch, and the IDs of the FIP, FIU and AA in the loop. Scope is narrow by design, expiry is explicit, and the user can revoke at any time. The framework has scaled — Sahamati's dashboard reported roughly 2.6 billion accounts enabled for sharing and around 253 million users with linked accounts as of the end of 2025.

UPI is a separate rail with its own rules. Payment activity is governed by NPCI through the PSP and third-party-app-provider model, and under the Digital Personal Data Protection Act, 2023, an app handling UPI data acts as a data processor with storage kept inside India. We treat those two regimes distinctly rather than folding everything into one bucket.

What sits inside the 811 app

These are the surfaces Kotak811 exposes to a logged-in user, drawn from its store listings and the Kotak811 site. Each maps to a real record an integrator would want, and the table notes where it originates and what it is good for.

Authorized paths to 811's records

Account Aggregator (consent-based)

What it returns: deposit balances and transactions, and the financial-information types Kotak exposes as an FIP, increasingly including investments. Effort is moderate — it means onboarding as an FIU with a licensed account aggregator and wiring a ReBIT-conformant client. Durability is high because the contract is standardized and regulated. We handle the FIU onboarding with you, draft the consent templates against the purpose you actually need, and build the fetch loop.

Authorized interface integration

What it returns: the parts of the app AA does not carry — card statements, cashback and reward balances, EMI schedules, in-app servicing. We map the app's authentication and the request/response shapes from its own traffic, under your written authorization, and deliver a client that replays them. Effort is higher and durability tracks the app's front end, which Kotak updates often; that is something we account for rather than hand to you.

User-consented session and native export

A consenting account can drive the same interface route where a full FIU setup is not warranted yet. And where you only need raw statements, the app's own export produces PDFs and CSVs that we parse into structured rows — coarse, but cheap and stable. We pick among these per record, not per ideology.

The build you receive

Everything is concrete and tied to 811's surfaces, not a generic kit:

• An OpenAPI/Swagger specification covering the consent, balance, transaction and card endpoints we integrate.
• A protocol and auth-flow report: the ReBIT consent/fetch sequence for the AA path, and the token and refresh chain observed for the interface path.
• Runnable source for the key calls in Python or Node.js — consent request, FI fetch and decrypt, statement parse, card-statement read.
• A normalized schema so an AA deposit record and an interface-sourced card record line up in one model, with provenance flagged per field.
• Automated tests against recorded fixtures, plus interface documentation and data-retention guidance keyed to the consent terms.

A consent fetch, in code

Illustrative, and confirmed against the build during delivery. Field names follow the public ReBIT NBFC-AA specification; this is the AA path for a deposit account held by Kotak as the FIP.

# Account Aggregator (ReBIT) consent + fetch -- Kotak as Financial Information Provider
consent = {
  "Detail": {
    "consentStart":  "2026-06-24T00:00:00Z",
    "consentExpiry": "2026-12-24T00:00:00Z",
    "consentMode":   "STORE",
    "fetchType":     "PERIODIC",
    "Frequency":     {"unit": "MONTH", "value": 1},
    "DataLife":      {"unit": "MONTH", "value": 3},
    "fiTypes":       ["DEPOSIT", "TERM_DEPOSIT"],
    "Purpose":       {"code": "101", "text": "Account aggregation"},
    "FIDataRange":   {"from": "2025-06-24T00:00:00Z", "to": "2026-06-24T00:00:00Z"}
  }
}

# 1. FIU posts the consent request to the AA; the user approves in the AA app.
# 2. On approval, open an FI session, then fetch the signed, encrypted payload.
session = aa.fi_request(consent_id, fi_types=["DEPOSIT"])
payload = aa.fi_fetch(session.id)                 # encrypted at the AA
records = decrypt(payload, fiu_private_key)["Account"]["Transactions"]

# Card / reward surfaces are NOT an AA FI type -- authorized interface call instead:
# GET /811/cards/{cardRef}/statement?cycle=2026-06   Authorization: Bearer <token>
# -> { "outstanding": ..., "minDue": ..., "rewards": { "points": ... } }
      

What we plan around for this app

Three things shape the 811 build, and we own each of them:

• Consent windows. An AA artefact has a fixed expiry and a set fetch frequency. We design the sync to stay inside the granted window and raise a re-consent prompt before it lapses, so a feed does not silently go quiet mid-quarter.
• A moving front end. Kotak ships app updates frequently, and the card and rewards screens shift most. For the interface route we keep the request/response models versioned and re-check them on a cadence we run, so a layout change does not become your incident.
• Two regimes, kept apart. UPI data sits under NPCI and DPDP localization while deposit data flows under AA. We map which record comes from which path and store the UPI pipeline in-region, with access logged against the consent on file.

Access, sandbox and authorization are arranged with you during onboarding — the build runs against a sponsor AA sandbox or a consenting account, and we handle the paperwork as part of the engagement, under NDA where you need one.

Keeping the feed current

Freshness differs by route. AA fetches run at the frequency the consent grants — daily or monthly are common — so an aggregation feed is periodic, not live, and we schedule it accordingly. The interface path can poll closer to real time where you need a near-current card balance, within rate limits we observe and respect. We document the expected lag per data domain so nothing downstream assumes a record is fresher than it is.

Screens we mapped

Public store screenshots we reviewed while scoping the surfaces above. Tap to enlarge.

Where 811 sits among Indian banking apps

The same routes apply across this category, which widens what a unified integration can cover:

• ICICI Bank iMobile Pay — savings, card and UPI records for ICICI customers, reachable over the same AA path as an FIP.
• YONO SBI — State Bank's app, carrying accounts, deposits and investments behind one login.
• Axis Mobile — Axis Bank accounts, cards and payments in a single interface.
• IDFC FIRST Bank — savings, deposits and UPI; the bank publishes its TPAP roles openly.
• AU 0101 — AU Small Finance Bank's zero-balance digital savings and deposits app.
• Fi Money — a Federal Bank-backed front end with savings and spend analytics.
• Jupiter — Federal Bank-powered digital banking with budgeting tools.
• PhonePe — a UPI-first app holding transaction history across linked accounts.
• Paytm — wallet, UPI and bill-payment records across a wide base.

This is ecosystem context, not a ranking. Many of these resolve through the same AA contract, which is what makes one normalized schema across them realistic.

What we checked, and when

We reviewed Kotak811's Google Play and App Store listings and the Kotak811 site for the in-app surfaces, then cross-read the Account Aggregator framework through Sahamati and the ReBIT NBFC-AA API specification for the consent and fetch contract, and the NPCI third-party-app-provider roles for the UPI handling. Primary sources:

• Sahamati — Account Aggregators (roles, consent, ecosystem)
• ReBIT — NBFC-AA API Specification (consent and FI fetch)
• Roles of NPCI, PSP and TPAP in UPI
• Kotak Bank: 811 Mobile App on Google Play

Mapped by the OpenBanking Studio integration desk, June 2026.

Source for the 811 consent client and the card-portal endpoints starts at $300, paid after we deliver and you have confirmed it runs against your data. Prefer not to host anything, and you can call our endpoints instead, paying only per call with nothing upfront. Either way the build lands in one to two weeks. Tell us the records you need and we will scope it — start here.

Questions integrators ask about 811

Does Kotak811 data come through the Account Aggregator framework, or do you read the app directly?

Both are on the table. Deposit balances and dated transactions move cleanly over the RBI Account Aggregator path, where Kotak Mahindra Bank participates as a Financial Information Provider and the ReBIT API contract is standardized. Surfaces that AA does not carry, such as card statements, reward ledgers and loan servicing, we reach by mapping the app's own authenticated calls under your authorization.

Which 811 records does the AA route not return?

Account Aggregator carries defined financial-information types such as deposits and, increasingly, investments. Credit-card line items, cashback and reward balances, EMI schedules and in-app servicing actions sit outside that set, so we cover those through authorized interface integration rather than AA.

How do you treat UPI data given NPCI's rules?

UPI records are governed by NPCI and, under the Digital Personal Data Protection Act, 2023, handled the way a data processor would. We keep that pipeline's storage in-region, pull only the fields you need, and log every access against the consent on record.

What happens when an AA consent expires?

Every consent artefact carries an expiry, a fetch frequency and a data-life limit. We schedule the sync to stay inside the granted window and trigger a re-consent prompt before it lapses, so the data feed does not quietly stop returning records.