Reaching the four ledgers behind Flipkart's super.money

One install of super.money is really four account ledgers stacked behind a single UPI front end: a payments history under superUPI, a fixed-deposit-backed RuPay credit line called superCard, RBI-backed term deposits under superFD, and pre-approved loans under superCash. Each holds its own per-user records, and each reports through a different financial institution. That is the shape that decides how you reach the data, and it is the reason a generic "UPI app" integration plan does not fit here.

What sits behind each product, and what you would do with it

The authorized routes that actually apply here

Account Aggregator consent (the regulated path for bank-held data)

superFD deposits, the superCard line, and the bank account behind superUPI are all reported by RBI-regulated institutions, which makes them Financial Information Providers in the Account Aggregator network. With the user's consent through a licensed AA, a Financial Information User pulls these as standard FI types — DEPOSIT, RECURRING_DEPOSIT, CREDIT_CARD, and the deposit/loan equivalents — over the ReBIT-specified APIs. Reachable: structured, signed, official records. Durability: high, because it is a regulated rail rather than a scraped screen. We handle the FIU onboarding or work through an AA/TSP you already use; that setup happens with you during the engagement.

Authorized protocol analysis of the app's own traffic

The cashback ledger, reward campaigns, and the way super.money stitches the four products into one timeline are app-internal and not standard AA FI types. For those we document the app's authenticated request and response shapes under your authorization and build a clean client against them. Effort is higher and it needs a re-check when the front end shifts, but it reaches surfaces the regulated route does not carry.

User-consented credential access and native export

Where the app offers a statement download or an in-app export, that serves as a verification fallback and a way to seed test fixtures; it is narrow but useful for cross-checking the live pull.

For most super.money projects the Account Aggregator consent does the heavy lifting and we layer authorized traffic analysis on top only for the cashback and cross-product views the regulated rail will not return. If your use case is purely deposits or loan servicing, the AA route alone is usually enough; reach for the analysis work when superUPI rewards data is the point.

What lands on handover

• An OpenAPI/Swagger spec covering the consent request, the FI fetch, and the normalized read endpoints for deposits, card, loans and UPI history.
• A protocol and auth-flow report: the AA consent artefact lifecycle on the regulated side, and the token/cookie chain captured for the in-app surfaces, with error handling for revoked or expired consent.
• Runnable source for the key calls in Python or Node.js — consent creation, FI request, artefact validation, and parsing of superFD, superCard and superCash records.
• A normalizer that folds all four product ledgers into one schema, plus automated tests against captured sample payloads.
• Interface documentation and data-retention guidance — purpose codes, consent logging, and field-level minimization.

Consent fetch, in code

Illustrative, in the ReBIT FI-request style — field names confirmed against the AA API specification during the build, not guessed from the app:

POST /Consent  (FIU -> Account Aggregator)
{
  "ver": "2.0.0",
  "FIDataRange": { "from": "2025-01-01T00:00:00Z", "to": "2026-06-23T00:00:00Z" },
  "consentMode": "VIEW",
  "fetchType": "PERIODIC",
  "consentTypes": ["TRANSACTIONS", "SUMMARY", "PROFILE"],
  "fiTypes": ["DEPOSIT", "RECURRING_DEPOSIT", "CREDIT_CARD"],   # superFD, superCard
  "Purpose": { "code": "101", "text": "Wealth & spend aggregation" },
  "consentExpiry": "2026-12-23T00:00:00Z"
}

# After the user approves in the consent manager:
POST /Consent/fetch        -> returns the signed consent artefact (artefact id, FI types, validity)
POST /FI/request           -> AA notifies the FIPs; sessionId issued
GET  /FI/fetch/{sessionId} -> encrypted FI blocks per account, decrypt with the session key

# Error paths we wire in:
#   consent REVOKED        -> stop fetch, surface to caller, purge cached keys
#   artefact PAUSED/EXPIRED-> re-request consent, do not retry silently
#   FIP partial response   -> reconcile per-account, flag the gap

Consent, and how the AA regime governs it

India's framework is unusually clean for this kind of work. The Reserve Bank of India regulates the Account Aggregator as an NBFC, and no financial record moves without an explicit, user-granted consent artefact created in a licensed consent manager. That artefact pins the FI types, the fetch frequency, the purpose, and a validity window, and the user can revoke it at any moment to cut off further fetches. On our side that means logging every artefact id and fetch, requesting only the FI types your use case needs, and encrypting FI blocks end to end. Where in-app traffic analysis is involved, the same posture applies under your authorization: documented scope, access logs, data minimization, and an NDA where the engagement calls for one. The UPI rail itself sits under NPCI, which is why transaction records resolve to the linked bank account rather than to super.money as a store of record.

Build notes specific to super.money

Two things shape this build more than anything else, and we account for both up front.

• The four products fan out across institutions. superCard is a FD-backed RuPay line reported by the issuing bank, superFD bookings sit with separate partner banks, and superUPI resolves to the user's own linked account. We address each FIP correctly rather than treating "super.money" as one endpoint, and we reconcile the small backing FD against the card limit so the credit picture is coherent.
• Consent has a clock. A multi-month statement or deposit sync has to live inside the artefact's validity window, so we drive the schedule off the FI notification callbacks and the stated fetch frequency, and design re-consent as a normal step rather than something that fails quietly when the window closes.
• The in-app surfaces move. When super.money revises its app front end, the captured request shapes for the cashback and cross-product views get re-checked as part of maintenance, so the analysis-based client keeps returning the same fields.

Access — an FIU/TSP relationship or a consenting test account — is arranged with you during onboarding; the build runs against a sandbox or a consenting account, and that arrangement is part of the project, not a hoop to clear before we start.

Where teams use this

• A lender pulling a prospective borrower's superFD and superCash records, with consent, to assess affordability before extending credit.
• A personal-finance app folding superUPI spend and cashback into a single household timeline alongside other accounts.
• An accounting tool ingesting superCard statements for a small business that runs spend on the FD-backed line.

Interface screens we worked from

The app's own product surfaces, for reference. Select to enlarge.

How this was checked

Worked through the app's Play Store listing and product pages for the four-product structure, the Sahamati AA documentation and the NBFC-AA API specification for the consent and FI-fetch mechanics, and recent reporting on Flipkart's NBFC licence and super.money's credit roadmap. Reviewed June 2026 by the OpenBanking Studio integration desk. Primary sources opened:

• super.money Play Store listing
• NBFC-Account Aggregator API specification (Sahamati)
• SahamatiNet consent workflow (ReBIT)
• Flipkart RBI lending licence (Retail Banker International)

Neighbouring apps an aggregation project tends to touch

Same Indian UPI and consumer-finance space, named for keyword and ecosystem context — no ranking implied:

• PhonePe — UPI transaction history and linked-account data for a large payments base.
• Google Pay — UPI payments and bill records tied to a Google account.
• Paytm — UPI, wallet balances, and a spread of bill and recharge records.
• CRED — credit-card bill payments and a rewards ledger for a premium user set.
• Navi — UPI alongside loans and insurance held under its own NBFC.
• MobiKwik — UPI, wallet, credit and mutual-fund holdings in one app.
• BHIM — NPCI's reference UPI app, with plain transaction records.
• Amazon Pay — UPI, wallet, and card transactions across Amazon's services.
• Freecharge — Axis-linked UPI, recharges, bill payments and loans.
• iMobile Pay — ICICI Bank's app combining full retail banking with UPI.

Questions integrators ask about super.money

Which super.money products come through the Account Aggregator route, and which need protocol analysis?

The bank-held surfaces — superFD bookings, the superCard credit line, and the linked bank account behind superUPI — are FIP-reportable, so they come through a regulated Account Aggregator consent as DEPOSIT, RECURRING_DEPOSIT, CREDIT_CARD and similar FI types. Things that live only inside the app, like the superUPI cashback ledger and reward accruals, are not standard AA FI types; those we reach by documented analysis of the app's own authenticated traffic, under your authorization.

superCard is issued with Utkarsh Small Finance Bank — does that change how its statements are pulled?

Yes. The card sits on a fixed-deposit-backed RuPay line reported by the issuing bank, so superCard statements surface under that bank as the FIP rather than under super.money. We map the issuer relationship explicitly so the statement pull is addressed to the right participant and the FD that backs the limit is reconciled against the card.

How is a user's consent recorded and revoked for a super.money data pull?

On the AA route, consent is a signed artefact created when the user approves the request in the consent manager; it names the FI types, the fetch frequency and a validity window, and the user can revoke it at any time, which cuts off further fetches. We log the artefact id, the purpose code and every fetch against it, and the build is data-minimized to the fields your use case needs.

We want a spend-analytics view over superUPI cashback — how soon can a working pull land?

A focused pull over the linked-account transaction history plus the in-app cashback ledger is a one-to-two-week build. You get runnable source for the fetch and normalization, a short auth-flow report, and tests against captured samples, so you can run it against a consenting account yourself.

Pricing is simple, and you only commit once. Source you can run lands from $300, billed after we hand it over and you've checked it against your own super.money setup; if you'd rather not host anything, our endpoints are pay-per-call with nothing up front. Tell us the app name and what you need from its data at our contact page and we'll scope the route — typical delivery is one to two weeks.