Reaching HDFC Bank account data through India's consent rails

HDFC Bank is one of the banks live as a Financial Information Provider on India's Account Aggregator network, which means a consumer's deposit and card records inside this app can be moved — with a signed consent — to a third party that the consumer authorizes. That single fact decides most of the integration. The app itself, as its store listing describes it, folds savings and current accounts, fixed and recurring deposits, credit cards, UPI and IMPS/NEFT transfers, bill payments and loan servicing into one logged-in surface. Some of those map straight onto the AA rulebook; a handful do not, and that split is what an integration has to plan around.

The route we would take here is the regulated consent flow for everything the AA schema covers, with authorized interface analysis of the app session filling the surfaces it leaves out. Below is the data, the two paths, the trace, and how the build is priced.

Data it holds, and what you'd do with each piece

Mapped to how the app presents these surfaces and to the AA FI-type schema (Profile / Summary / Transactions) that HDFC exposes as an FIP.

How we reach it

1 — Account Aggregator consent flow

HDFC publishes its regulated FI types through the AA network, so a consumer who holds an account can grant a signed consent and have the deposit, term-deposit and card data delivered to your FIU endpoint. Reachable: the Profile, Summary and Transaction blocks for those account types. Effort is moderate and front-loaded into onboarding rather than scraping. Durability is high — this is a regulated, versioned interface, not a fragile screen. We arrange the FIU registration and the TSP connection (Setu, Perfios and similar all expose the FIP data session) with you during onboarding and run the build against a sandbox or a consenting account.

2 — Authorized interface analysis of the app session

Reward-point balances, bill-pay and recharge history, and the app's spending insights are not carried by the AA FI schema. We reach those by analysing the authenticated app's own traffic under your authorization — the token and session chain the app uses after biometric or mPIN login — and rebuild the calls as documented endpoints. Effort is higher and the surface can shift when the app updates; durability is medium and maintained with a re-validation pass.

3 — Native export, where present

Statement PDFs and CSV exports the consumer can already pull serve as a fallback and a reconciliation check against the structured feeds. Low effort, useful for backfill rather than live sync.

For HDFC specifically, the consent flow is the dependable backbone for the regulated deposit and card data, and we layer the interface work on top only for the reward-point and bill-pay surfaces the AA schema does not reach. We would not build the whole thing on interface analysis when half of it is available through a stable, consented channel.

What lands on your side

Each deliverable is tied to HDFC's actual surfaces, not a generic checklist.

• An OpenAPI specification covering the consent request, the FI data-session fetch, and the normalized deposit / term-deposit / card endpoints.
• A protocol and auth-flow report: the AA consent-artefact lifecycle, and — for interface-sourced surfaces — the post-login token and session chain as confirmed during the build.
• Runnable source in Python or Node.js for the key calls: create consent, poll status, fetch FI data, parse Profile/Summary/Transactions into your schema.
• Automated tests against recorded fixtures, including consent-expiry and empty-account cases.
• Interface documentation plus a data-retention and consent-logging note matched to the AA rulebook.

A consent-to-data trace

Illustrative, reflecting the AA consent-then-fetch shape HDFC's FIP data follows; field names confirmed during the build.

# 1. Create a consent request (FIU -> Account Aggregator)
POST /Consent
{
  "Detail": {
    "consentStart": "2026-06-27T09:00:00Z",
    "FIDataRange": { "from": "2025-06-27T00:00:00Z", "to": "2026-06-27T00:00:00Z" },
    "consentMode": "STORE",
    "fetchType": "PERIODIC",          # recurring auto-fetch
    "Frequency": { "unit": "MONTH", "value": 1 },
    "fiTypes": ["DEPOSIT", "TERM_DEPOSIT", "CREDIT_CARD"],
    "Customer": { "id": "9990001234@hdfc-aa" }
  }
}
-> 200 { "consentId": "c-7f3...", "status": "PENDING" }   # user approves in their AA app

# 2. After approval, open an FI data session
POST /FI/request   { "consentId": "c-7f3...", "format": "json" }
-> { "sessionId": "s-91a...", "status": "READY" }

# 3. Fetch and parse
GET /FI/fetch/s-91a...
-> {
     "Account": {
       "type": "deposit",
       "Profile": { "Holders": [{ "name": "...", "dob": "****" }] },
       "Summary": { "currentBalance": "48213.55", "currency": "INR",
                    "type": "SAVINGS", "status": "ACTIVE" },
       "Transactions": [
         { "txnId": "T1", "type": "DEBIT", "mode": "UPI",
           "amount": "640.00", "narration": "UPI/merchant/...",
           "valueDate": "2026-06-21" }
       ]
     }
   }

# Handle: status != READY -> backoff poll; consent EXPIRED -> re-prompt, do not retry blind
      

Consent & the AA rulebook

The governing regime is the RBI's Account Aggregator framework, set out in the NBFC-Account Aggregator Master Direction and run operationally through the Sahamati-maintained registry. The dependable basis for every pull is the consumer's own signed consent: an AA artefact with explicit duration, frequency and purpose fields, and native revocation. The Account Aggregator itself is a neutral pipe — it cannot read, store or use the data, only move it from HDFC to the authorized user. We operate consent-first: access is authorized, every fetch is logged against its consent id, data is minimized to the FI types the use case needs, and we work under NDA where a client requires it. For interface-sourced surfaces outside the AA schema, the same posture applies — work proceeds under the consumer's authorization and is documented.

Where the work actually goes

Two things consume most of the engineering on an HDFC build, and we account for both up front.

• The AA / interface split. Only the FI types HDFC has enabled as an FIP resolve through the consent network. We map, per surface, which of savings, current, FD, RD and card data comes back through the AA handle versus which needs authorized interface analysis — so the integration covers the full set you expect rather than quietly dropping reward points or bill-pay history.
• The consent-refresh window. Recurring consents auto-fetch on a frequency you set, but the artefact has an expiry. We build the sync to watch that window and re-prompt cleanly before it ends, so a monthly feed does not lapse without warning.
• Front-end churn. HDFC has shipped an "all-new" app, per its own listing, and the post-login interface can move under a redesign. For the interface-sourced surfaces we include a re-validation pass so a UI change is caught and patched rather than breaking a live feed.

Typical builds

• A lender pulling twelve months of HDFC deposit transactions through AA consent to underwrite a small-ticket loan.
• A personal-finance app syncing balances and card spend nightly, with consent re-prompts handled automatically.
• An accounting tool reconciling NEFT/IMPS transfers against invoices, normalized across rails.
• A wealth dashboard combining HDFC term-deposit maturities with holdings from other FIPs into one net-worth view.

App screens

From the public Play listing — useful for confirming which surfaces a build needs to cover.

How this was checked

Checked the app's own Play listing for its feature set and surfaces, then the AA documentation for the consent and FI-data mechanics and HDFC's standing as an FIP. Primary sources, opened June 2026:

• Setu — Account Aggregator FI data types (Profile / Summary / Transactions, 23 FI types)
• Setu — AA consent flow and recurring auto-fetch
• Sahamati — FIPs and FIUs in the AA ecosystem
• Ministry of Finance — Account Aggregator framework overview

Mapped by the OpenBanking Studio integration desk · June 2026.

Other India banking apps in the same picture

Same category, all candidates for a single consent-driven integration across institutions. Listed for context, not ranked.

• ICICI iMobile Pay — deposit, card and UPI data behind an authenticated retail app; an FIP on the same AA network.
• YONO SBI — accounts, deposits and lifestyle services for India's largest bank base.
• Axis Mobile — broad retail banking surface with similar deposit and transfer records.
• Kotak811 — digital-first accounts and card servicing.
• IndusInd Bank Mobile — deposits, cards and transfers for a private-bank customer base.
• Federal Bank FedMobile — retail accounts and deposits, AA-connected.
• IDFC FIRST Bank — savings, deposits and card data in one app.
• bob World — Bank of Baroda's retail app, comparable deposit and transfer surfaces.

Questions integrators ask

Which HDFC surfaces resolve through the Account Aggregator handle versus the app session?

Deposit accounts (savings and current), fixed and recurring deposits, and card statements map cleanly onto the AA FI types HDFC publishes as a Financial Information Provider, returned as Profile, Summary and Transaction blocks. Surfaces the AA schema does not carry — debit-card reward-point balances, bill-pay and recharge history, the app's spending insights — are reached through authorized interface analysis of the logged-in session. We tell you per surface which path applies before any build starts.

Does HDFC return Account Aggregator data as JSON or XML?

The AA data session lets the consumer specify the format, and the FI payload is available as both XML and JSON per Setu's FIP documentation. We normalize whichever HDFC's FIP returns into a stable JSON schema with consistent transaction narration across UPI, IMPS and NEFT rails, so downstream code does not branch on rail or format.

How is consent expiry handled so a recurring HDFC data pull does not lapse?

The AA consent artefact is a signed object carrying explicit duration, frequency and purpose fields plus native revocation. For a recurring feed we design the sync around those fields and watch the artefact's expiry so the auto-fetch keeps running inside the consented window and re-prompts cleanly before it lapses, rather than failing silently mid-cycle.

Can one consent combine HDFC data with accounts at other banks?

Yes. The AA network is cross-institution, so a single consumer consent can name several Financial Information Providers at once. HDFC deposit and card data then arrives in the same FI session as accounts the consumer holds at other AA-connected banks, each as its own Profile/Summary/Transactions block. We build the parser to merge them on your side, keyed by account and FI type, so a net-worth or underwriting view does not have to stitch banks together itself.

Source-code delivery for the HDFC build starts at $300, paid only after we hand it over and you confirm it runs against the deposit, term-deposit and card surfaces; or skip the upfront cost and call our hosted endpoints on a pay-per-call basis. Either way the cycle is one to two weeks — tell us the app and the data you need at /contact.html.