Pulling savings, fixed-deposit and statement data out of IndusInd INDIE

IndusInd Bank went live as the first FIP on the Reserve Bank of India's Account Aggregator framework in October 2021 (per its own press release), and that one fact decides almost everything about pulling INDIE data at any kind of width. A date-bounded FI Data Request through a licensed AA on a consenting account hands back the same statement, deposit and holdings view a customer would see in the INDIE app — at backfill ranges the branch portal will never give an end user directly. We treat this page as the build sheet for two routes that usually run together for INDIE: the AA fetch-and-decrypt pipeline, and protocol analysis of the INDIE app's own JSON surfaces for the long tail the AA payload does not yet carry. Batch is the default cadence.

What INDIE actually holds, and how it is named

The INDIE app sells itself as a single super-app over savings, fixed and recurring deposits, instant personal loan and line of credit, credit cards, mutual funds and bill payments (per the IndusInd microsite and the Play Store listing). The data domains an integrator actually needs to model line up roughly as follows. Row names lean on the wording IndusInd itself uses in product pages and the AA FI Type taxonomy, rather than generic banking labels.

An ingestion sketch — what a batch fetch actually looks like

The AA spec runs on ECC-encrypted FI payloads with JWS-signed envelopes; this is what the production code we ship is shaped like (illustrative, exact field names confirmed against the FIP profile during the build).

# IndusInd FI Data Request via a licensed Account Aggregator.
# Consent already collected; we hold consent_id and the ECC key pair.
def fetch_indusind_fi_data(consent_id, fi_data_range, aa_base, ecc_priv, ecc_pub):
    txn_id  = new_txn_id()                          # required by the AA spec, per request
    payload = {
        "ver": "2.0.0",
        "timestamp": iso_utc_now(),
        "txnid": txn_id,
        "FIDataRange": fi_data_range,               # {"from": "2024-06-01T00:00:00Z",
                                                    #  "to":   "2026-06-01T00:00:00Z"}
        "Consent": {
            "id": consent_id,
            "digitalSignature": jws_sign_detached(consent_id)
        },
        "KeyMaterial": ephemeral_key_material(ecc_pub)
    }
    resp = post_signed(f"{aa_base}/FI/request", payload)   # session opens, FIP polled
    bundle = poll_fi_data(resp["sessionId"], txn_id)        # AA returns encrypted FI XML
    for fip in bundle["FI"]:
        if fip["fipID"] != "INDUSIND-BANK":
            continue
        for acct in fip["data"]:
            xml = ecdh_decrypt(acct["encryptedFI"], ecc_priv, fip["KeyMaterial"])
            yield normalize(parse_aa_fi_xml(xml))           # accounts / FDs / txns

The shape stays the same for the savings, term-deposit and mutual-funds FI Types; only the inner XML schema changes, and the FIP profile is the source of truth for which schemas IndusInd currently serves on its FIP endpoint.

Deliverables for an INDIE-only build

The deliverable is code that runs in your environment, not a slide deck. For an IndusInd build the bundle is typically:

• A Python module and a Node.js module covering the AA consent handshake, the FI Data Request, ECDH key generation, JWS signing, the FI XML decryption, and normalized Pydantic / TypeScript types for accounts, FDs, RDs and transactions.
• A signed-webhook handler for the AA FI Data Notification, so a recurring-consent run does not have to be polled.
• A batch backfill harness that splits the requested window to fit the FIP's per-FI-Type history cap, runs the splits in parallel under one consent, and writes through an idempotent merge keyed on the AA transaction reference.
• An automated test harness with fixture FIP responses for the common edge cases — a stale consent, an empty range, partial bank-side outage, decryption-key mismatch.
• An OpenAPI document for the internal endpoints you expose to the rest of your stack.
• A short protocol & auth-flow report describing the AA consent chain and any INDIE portal endpoints touched by the second route, plus a DPDP-aligned retention and minimization note for the data your store ends up holding.

Routes to the data

Three routes apply to INDIE in practice. We pick one as the spine of the build and let the others fill gaps.

1. RBI Account Aggregator (AA) — regulated, FIP-served

The lane IndusInd actually publishes on. A licensed NBFC-AA acts as the consent rail; once consent is captured, the FI Data Request goes out as above and the payload is encrypted FI XML. Coverage: savings deposit account, term-deposit and (where the depository is linked) mutual-fund holdings. Effort: medium on the first build because the FIP profile and the AA's contracts both need to be wired correctly; low for every additional FIP afterwards because the schema is shared. Durability: high — this is the rail the regulator is steering everyone toward. The studio arranges the AA sponsorship and the sandbox account with the client during onboarding.

2. App-layer interface integration of INDIE's authenticated traffic

Where the AA payload does not yet carry a surface — credit-card reward points, bill-pay scheduling state, INDIE-specific reward configuration — the route is documented protocol analysis of the INDIE app's authenticated traffic under the user's own consent and authorization. Coverage: anything a consenting customer sees in their own session. Effort: higher, because the surface changes with app releases; we map it once and wrap it with a re-validation pass. Durability: medium, sustained by the maintenance contract.

3. Native customer-driven export

INDIE supports statement PDF generation for the savings account and the credit card; this is the fallback for one-off needs where setting up either of the first two would be over-engineering for the customer. Coverage: limited to whatever the export emits.

For a build that aims to keep running, the AA route is the spine. The interface route fills gaps. We recommend that combination on most INDIE engagements.

Consent, AA and DPDP — the boundary lines that matter

Three regulators set the shape of this. RBI runs the Account Aggregator framework under the NBFC-AA Master Direction first issued in September 2016 (per the Department of Financial Services); Sahamati is the industry body the FIPs and FIUs coordinate around, and reported the network at roughly 2.61 billion linked financial accounts as of December 2025 (Sahamati / DFS figures). NPCI runs UPI as the central clearing house; for the data fragments that flow through UPI, NPCI sits as the data fiduciary and the PSP banks act as data processors under DPDP. The Digital Personal Data Protection Act 2023 was notified by Parliament on 11 August 2023; the DPDP Rules were notified on 14 November 2025 and the substantive provisions take effect from 13 May 2027 (per the EY and DLA Piper public summaries). The build assumes DPDP-aligned consent records, purpose-bound use and right-to-withdraw plumbing from day one — not because they are mandatory today, but because the rule is what every Indian financial integrator will be measured against by mid-2027. Consent records, NDAs and data-minimization defaults are how we operate.

Engineering judgments for this build

Three things have come up enough across INDIE-shaped engagements to be worth flagging as the studio's posture, not the customer's homework.

• FIP profile, not the generic AA spec, is the source of truth. The maximum history window per FI Type, the supported FI Types, and the encryption parameters all live in the IndusInd FIP profile published on the AA network — not in the AA's abstract documentation. We pull the profile on the first build and pin the request pagination to whatever IndusInd actually serves, so a savings backfill does not silently truncate at a boundary that nobody documented in your code review.
• Two products under one consent come back as separate FI entries. A savings account plus its linked auto-sweep FD return as distinct entries in the FI bundle, with different inner schemas. The normalized writer emits them into the right internal tables on the first pass; we do not flatten them into a single transaction stream because the maturity and tenure fields on the FD side have no equivalent on the savings side and matter for any wealth-shaped use.
• Encrypted payloads, short-lived keys. The FI Data response is encrypted with ECDH key material posted in the original request. We generate ephemeral ECC keys per session, keep the private key only for the lifetime of one consent fetch, and zero it once the bundle is decrypted. A retention or data-protection audit then reads as data-minimized by construction, not by promise.
• Mixed-route reality. The AA payload covers the audited statement view, but UPI reward credits, scheduled bill payments, and credit-card statement detail live on the INDIE portal surface. The build accepts that both routes run, writes them into one normalized model, and labels the source on each record so a downstream auditor can tell which lane an entry came in on.

Nearby apps an INDIE build often sits next to

None of the names below are competitors of OpenFinance Lab; they are simply the apps an INDIE integration usually shares a normalized model with, because the same FIU is consuming several Indian banks' AA feeds at once.

• HDFC Bank MobileBanking — HDFC's primary retail-banking app; live as a FIP on AA and one of the highest-volume Indian sources.
• ICICI iMobile Pay — ICICI's retail app, covering accounts, cards, loans and investments; FIP-live, deep AA presence.
• Axis Mobile — Axis Bank's primary mobile app for savings, cards and investments; FIP-live on AA.
• Kotak 811 / Kotak Mobile Banking — Kotak's mobile-first account product and the broader Kotak mobile app; FIP-live.
• SBI YONO — State Bank of India's super-app covering accounts, cards, loans, investments and a marketplace; FIP-live, very large account base.
• IDFC FIRST Bank — IDFC FIRST's retail banking app; participates in the AA framework as both FIP and FIU.
• Federal Bank FedMobile — Federal Bank's mobile app; FIP-live on AA, common in South-India focused stacks.
• Bank of India BOI Mobile — BOI's mobile banking app; FIP participation in the AA ecosystem.
• Yes Bank — Yes Bank's mobile app, FIP-live.
• RBL MyCard / RBL Mobile — RBL Bank's card management and mobile-banking apps, often paired in INDIE-adjacent stacks.

A unified FIU build for an Indian lender or PFM typically reads from six to ten of these alongside INDIE; the schema on the AA side is shared, so the marginal cost of a second bank is small once the first is in.

Questions integrators tend to ask

How wide can a single batch fetch reach for IndusInd statements through the AA channel?

AA FIPs publish a maximum historical window per FI Type — for savings deposits it commonly sits around two to three years, depending on the FIP profile, and gets paginated by date range under one consent. The build splits the requested range to fit and reconciles results by transaction reference so a re-run merges cleanly into the internal store.

How does AA consent expiry interact with a daily sync we would run for IndusInd?

It surfaces as a 401-equivalent at the AA boundary on the next fetch, never a corrupt write into your store. The refresh of the underlying consent runs on its own schedule against the recurring-consent renewal flow where the FIP allows it; the sync code resumes the moment the new consent ID lands in the config.

Can the same pipeline cover surfaces the AA payload does not return — like reward points or scheduled bill payments?

Those live in the INDIE app's own portal surface, not the AA channel. The protocol-analysis path captures the relevant authenticated endpoints under the user's consent and writes into the same normalized model the AA pipeline uses. Most integrators end up running both.

What does a first cut look like for an IndusInd-only build?

One to two weeks for a runnable Python or Node.js client wired to a sponsor AA, the FI XML decryption, normalized JSON for accounts/FDs/transactions, and the OpenAPI for whichever internal endpoints you expose. Engagement details are on the contact page.

Sources checked

What was opened for this brief, with the dates the wording on each page matched on 2026-06-03:

• IndusInd Bank press release — first bank live as FIP on RBI's AA framework (October 2021).
• Sahamati — FIPs & FIUs in the AA ecosystem (network composition and current participant counts).
• Department of Financial Services — Account Aggregator framework (regulatory scope and growth figures).
• IndusInd Bank — INDIE app microsite (product surfaces and feature wording).

Engineering notes by OpenFinance Lab, 2026-06-03.

The shape of the engagement is short. $300 buys a runnable Python or Node.js client for the AA fetch and decryption, normalized accounts/FDs/transactions models, automated tests against a sponsor AA, and the OpenAPI for whichever internal endpoints you expose — invoiced after delivery, once the build runs against your AA or a consenting test account. The same code base also runs as a hosted endpoint on the pay-per-call model with no upfront fee, billed only on calls a downstream system actually makes. The first conversation on the contact page needs one line: the IndusInd surfaces you need, where the data lands, and the timeline. Access, sandbox onboarding and compliance paperwork — DPDP-aligned consent records, NDA, data-minimization defaults — are arranged with the client during that conversation, not asked for upfront. Delivery on a first cut runs 1–2 weeks.

App profile (factual recap)

App. IndusInd Bank: Savings A/C, FD — branded as INDIE, the bank's flagship mobile banking app. Operator: IndusInd Bank Limited. Package ID: com.indusind.indie. Available on Android (Google Play) and iOS (App Store).

Stated features (per the Google Play listing and the indie.indusind.bank.in microsite). 100% digital savings account opening, zero-balance variant, zero-fee NEFT/RTGS, scan-and-pay UPI, fixed deposits (regular, tax-saving, senior citizen), auto-sweep FD, instant personal loan up to ₹5 lakh, line of credit, credit card application and management, recharge and bill payments, mutual fund investing with SIPs from ₹500, and standard fund-transfer rails (UPI, IMPS, NEFT, RTGS). Customer-support email indie@indusind.com.

Reach. Banking Frontiers reported INDIE extending to a customer base in the order of 15 million users; the figure is from press coverage, not the bank's annual filings.

Screenshots from the Play Store listing.