The Account Aggregator framework is architecturally elegant but often poorly explained. Most descriptions either oversimplify it into “you share your data” or bury the reader in technical terminology. If you need a foundational understanding first, here’s what the account aggregator framework is and why it exists. Neither approach serves the lending professional, compliance officer, or fintech founder trying to understand how to work with this infrastructure.
This guide walks through the AA process in concrete, sequential steps, covering what happens at each stage, who the participants are, and what technical mechanisms ensure the process is secure and auditable. Understanding the mechanics matters because it directly affects how lenders should design their AA integration and borrower experience.
The Five Participants in Every AA Transaction
Before mapping the steps, identify the parties involved in a complete AA data flow:
The Borrower (or Data Principal): The individual or business whose financial data is being shared. Under the AA framework, this person is always in control; they initiate and authorize every data share.
The Financial Information Provider (FIP): The institution holding the data, typically a bank. When a borrower has an account at HDFC Bank, HDFC is the FIP for that account’s data.
The Account Aggregator (AA): The licensed NBFC that manages the consent mechanism and routes encrypted data between FIP and FIU. The AA does not store or read the underlying data.
The Financial Information User (FIU): The institution requesting the data, typically a lender, wealth manager, or insurance company. For a detailed explanation of FIP and FIU roles in the AA ecosystem, refer to this guide.
The Technology Stack: The APIs and cryptographic infrastructure that connect all four parties, standardized by the Sahamati network and built to the BIS-compliant specification.
Step-by-Step: How an AA Data Share Works
Step 1: The FIU Initiates a Data Request
When a borrower applies for a loan through an FIU (say, an NBFC’s digital lending platform), the lender identifies that they need the borrower’s bank transaction data for underwriting. The FIU generates a consent request via the AA’s API. This request specifies which account types are needed, what date range of transactions, what the data will be used for, how long the FIU will retain it, and whether it is a one-time or recurring pull.
Step 2: The Borrower Receives a Consent Request
The borrower receives a consent request notification, typically via SMS or push notification from the AA’s app or the FIU’s interface. This notification includes a summary of what is being requested: “NBFC XYZ has requested your HDFC Bank savings account transactions from January 2024 to January 2025 for the purpose of loan assessment.”
Step 3: The Borrower Reviews and Approves Consent
The borrower opens the consent screen and reviews the full request. They can approve the exact request, modify it (for example, reduce the time range), or reject it entirely. If they approve, they digitally sign the consent, which generates a cryptographically signed Consent Artefact. This artefact is a digital record of exactly what was consented to, when, and by whom. To understand how the account aggregator consent flow works in detail, this guide breaks down each stage.
Step 4: The AA Notifies the FIP
The AA sends the signed Consent Artefact to the FIP (the borrower’s bank) along with a data request. The FIP validates the consent artefact, confirming it is properly signed and that the request is within the consented parameters. If valid, the FIP prepares the requested data.
Step 5: The FIP Encrypts and Transmits Data
The FIP takes the transaction data and encrypts it using the FIU’s public key, meaning only the FIU can decrypt it. Not the FIP, not the AA, not any intermediary. The encrypted data is then transmitted to the FIU via the AA’s routing infrastructure.
Step 6: The FIU Decrypts and Processes Data
The FIU receives the encrypted data package and decrypts it using its private key. The data is now in a structured JSON format, conforming to the Sahamati data schema. The FIU’s underwriting engine can immediately process it, calculating income metrics, identifying EMI obligations, scoring cash flow patterns, and flagging anomalies, without any manual intervention. This is where how account aggregator data is analysed by lenders after collection becomes critical to credit decisions.
Step 7: Consent Management and Revocation
At any point after consent is granted, the borrower can log into the AA’s app and view their active consents. They can see who has access to what data and for how long. They can revoke consent at any time. Once revoked, the FIU can no longer request new data pulls, though they may retain data already received within the parameters of the original consent and applicable data protection regulations.
What the Data Actually Looks Like
The data delivered via the AA pipeline conforms to a standardized schema defined by Sahamati. For a savings account, this includes the account holder’s name, account number, IFSC code, account type, transaction records (each with date, amount, transaction type, running balance, and narration), and summary statistics.
The format is structured and machine-parsable, unlike a PDF, which requires pattern recognition to extract values. Every transaction entry has a defined field structure, making it directly compatible with underwriting models, scoring engines, and cash flow analysis tools without any preprocessing.
For lenders building automated underwriting workflows, this structured data is the critical enabler: income identification, EMI detection, and cash flow scoring can all operate directly on the standardized AA data feed.
What Happens When Something Goes Wrong
The AA framework includes defined error handling at each step. If the FIP is unavailable or the borrower’s account is not linked to the AA, the consent request will fail at the FIP validation stage, and the FIU will receive an error response. The borrower is notified and can retry.
If the borrower rejects or modifies the consent request, the FIU receives a rejection or partial-approval response and must decide how to proceed, either requesting a revised consent or proceeding with the available data.
If a data pull fails after consent, the consent remains valid; therefore, the FIU can retry within the consent window. The system handles transient failures without requiring re-consent.
✅ Key Takeaways
- The AA transaction involves five entities: Borrower, FIP (data source), AA (consent and routing), FIU (data consumer), and the underlying Sahamati API infrastructure.
- The process is always borrower-initiated: consent cannot be pulled without the borrower’s explicit, real-time approval. No institution can access your financial data without your knowledge.
- Encryption ensures only the FIU can read the data, not the AA, not the FIP, not any intermediary in the chain.
- The entire process from consent to data delivery typically takes under 60–90 seconds for live FIPs with well-integrated systems.
- Consent is revocable at any time through the AA’s interface, giving borrowers ongoing control over their data.
- The standardized data schema means the output is immediately machine-processable, enabling automated underwriting without manual extraction or parsing steps.
Frequently Asked Questions
From consent request to FIU delivery, the process typically takes 60–120 seconds for fully integrated banks. The borrower interaction itself, reviewing and approving consent, takes approximately 30–60 seconds on a smartphone.
No. The AA framework is consent-first by design. No FIU can initiate a data pull without a valid, borrower-signed Consent Artefact. Any attempt to access data outside the consent parameters would fail at the FIP’s validation step.
Under the AA framework, the FIU may retain data for the period specified in the consent artefact. Once the retention period ends, the data should be deleted. The DPDP Act 2023 reinforces this requirement. Borrowers can also revoke consent to prevent future pulls.
Yes. A borrower can grant consent for multiple accounts, across different banks, in a single consent flow. Each FIP processes the request separately; however, the system delivers all data to the FIU in a single transaction.
The consent screen allows modification before final approval. Once you sign and submit a consent artefact, you cannot edit it; however, you can revoke it and initiate a new request.
Conclusion
The AA framework’s architecture reflects a deliberate design choice: make data sharing frictionless for legitimate use cases while making unauthorized access structurally impossible. The system embeds cryptographic consent artefacts, end-to-end encryption, and standardized schemas at its core, not as add-ons.
For lenders, understanding this architecture matters because it changes the nature of data infrastructure decisions. Integrating with the AA ecosystem means integrating with a regulated, auditable, consent-based pipeline, one that aligns with the direction of India’s data protection framework rather than running against it. The operational and risk benefits are measurable from day one. A closer look at how an account aggregator reduces loan processing time in real-world scenarios shows the scale of this impact.
