What Account Aggregator (AA) actually changes consent, FI flow, expiration, revocation.
Account Aggregator is treated as a feature flag in many fintech platforms. It isn't. AA reshapes how consent, data fetch, and data lifecycle are modeled, with downstream implications for KYC, underwriting, wealth-tech analytics, and audit posture.
Account Aggregator (AA) is the consent-led, FI (Financial Information) sharing framework regulated by RBI. It abstracts data flow between Financial Information Providers (FIPs) and Financial Information Users (FIUs) through a consent layer, with explicit, expirable, revocable, granular permissions.
What AA actually changes in your architecture
1. Consent is a first-class entity
An AA consent has a purpose, a data range, an expiration, and a revocation event. Your platform must model consents as durable entities with full lifecycle, not as a boolean flag on the customer record. Consent change events drive downstream behavior across underwriting, servicing, and analytics.
2. FI flow handling needs idempotency and retries
Data fetch from FIPs through the AA pipe is asynchronous. Your platform must handle partial fetches, retries, FIP-side delays, and reconcile consents that returned partial data. This is plumbing, but plumbing your architecture must be designed for, not retrofitted.
3. Expiration and revocation cascade
When a consent expires or is revoked, downstream systems must stop using the data, but defensibly retain decisions made on data fetched while the consent was valid. This is a retention + provenance + decision-history problem, not a delete-the-row problem.
4. DPDP intersection
AA consent is a specific instrument under a broader DPDP regime. Your data classification, retention, and erasure flows must reconcile AA's contractual consent with DPDP's broader data principal rights. Most platforms model these separately, they should be modeled together.
Where AA matters most
- NBFC underwriting: bank statement analysis through AA replaces brittle BSA-vendor flows
- Wealth-tech profiling: consented portfolio data unlocks better suitability and analytics
- Insurance underwriting and claims: financial data corroborates declared income and claims history
- Account aggregation by FIUs: provides a regulated path for cross-institution data flow
Common implementation mistakes
- Treating consent as a boolean rather than a versioned, time-bounded entity
- Storing fetched data without consent linkage, breaking audit replay
- Failing to handle partial FI fetches gracefully, silent data gaps
- Not modeling revocation cascades, leaving stale data in analytics
- Missing the DPDP intersection, consent semantics differ at the framework level