4.3 Account Aggregator (AA)
See 2.8 AA rules for the regulatory framework. This page focuses on vendor and operational integration choices.
AA TSPs (for FIU integration)
Section titled “AA TSPs (for FIU integration)”You become an FIU; you integrate via a TSP (Technology Service Provider) that gives you an SDK / API to interact with multiple AAs.
| Vendor | Strengths |
|---|---|
| Setu | One of the most mature FIU SDKs; broad bank coverage; clean APIs (setu.co) |
| FinBox | FIU SDK + analytics; strong on BSA layer too (finbox.in) |
| OneMoney FIU SDK | Direct from one of the AAs; pure-play |
| Saafe / Finvu / Anumati | AAs themselves; integration possible but multi-AA usually via TSP |
Why multi-AA
Section titled “Why multi-AA”- Coverage redundancy — different AAs have different bank-side maturity for OTP, account discovery, fetch reliability.
- Borrower preference — borrower may already have an account at one AA; smoother UX.
- Resilience — one AA outage shouldn’t kill onboarding.
Integrate with 2 – 4 AAs via your TSP from MVP.
FIP coverage
Section titled “FIP coverage”The most important FIPs for SME WC underwriting are banks offering current and savings account data. As of training data:
- Public-sector banks: SBI, PNB, Canara, BoB, Union, etc. — coverage growing but uneven.
- Private banks: HDFC, ICICI, Axis, Kotak, Yes, IndusInd, IDFC FIRST — generally good coverage.
- Co-op / small banks: spotty.
GST coverage on AA exists in principle but is patchy in practice; use a GSP instead.
Consent UX
Section titled “Consent UX”The AA consent screen is shown by the AA, not by the lender. The lender / FIU initiates a request; borrower is redirected to the AA’s web/app to consent; redirected back.
Best practice:
- Pre-explain to borrower what AA is and why (one-screen onboarding); reduces drop-off.
- Pick a default AA based on borrower’s bank (some banks have preferred AAs).
- Fallback to PDF upload if AA fails or coverage gap; treat both as first-class.
Data fetch flow
Section titled “Data fetch flow”- FIU (your service via TSP) creates a consent request — purpose, FI types, date range, FIPs, frequency, validity.
- AA presents UI; borrower authenticates; selects accounts; approves.
- AA issues consent artefact.
- FIU triggers fetch (one-time or periodic).
- Data flows: FIP encrypts → AA forwards → FIU decrypts.
- FIU persists data + consent reference.
Consent management
Section titled “Consent management”- Persist consent artefact (JWT-like signed by AA) as audit unit.
- Track expiry and trigger re-consent workflow.
- Handle revocation events from AA (webhook).
- Delete data on revocation per DPDP.
Pricing proxy
Section titled “Pricing proxy”- TSPs typically charge per consent created + per fetch + small monthly minimums.
- Per consent:
₹5 – ₹15. - Per fetch:
₹5 – ₹15. - At volume, total cost per fully-fetched application:
₹15 – ₹50.
AA vs PDF tradeoffs
Section titled “AA vs PDF tradeoffs”| Dimension | AA | PDF upload |
|---|---|---|
| Data quality | High (structured at source) | Variable (depends on parser) |
| Authenticity | High (signed by FIP via AA) | Tampering risk |
| Coverage | Growing; uneven | Universal |
| UX friction | Single redirect + auth | Borrower must download + upload |
| Latency | Seconds to minutes | Minutes (BSA parse time) |
| Cost | ₹15 – ₹50 per fetch | ₹10 – ₹30 per PDF parse |
| Refresh | Periodic via consent frequency | Borrower re-uploads each time |
Recommendation: AA-first, PDF-fallback. Always support both.
Compliance implications
Section titled “Compliance implications”- AA Master Direction governs.
- DPDP — consent is purpose-specific, time-bounded, revocable.
- Outsourcing MD — TSPs and AAs governed.
Build vs buy
Section titled “Build vs buy”- TSP / FIU SDK: Buy. Building from scratch is months of work for cryptography, certifications, multi-AA orchestration.
- Consent management on platform side: Build minimal layer on top (storage, expiry, revocation hooks).
- Data normalisation: Build. AA-returned schemas differ slightly across FIPs; normalise once into your internal model.