The consent flow is the foundation of the Account Aggregator framework’s regulatory architecture. Every data transfer through the AA pipeline begins and ends with consent, and the design of that consent mechanism determines whether the entire system is trustworthy, usable, and legally defensible. To understand this better, here’s what the account aggregator framework is and why consent is central to it.
For developers building AA integrations and compliance officers assessing data governance, understanding the consent flow in detail is essential. This guide covers the technical structure of the consent artefact, the API sequences that govern the flow, and the key design decisions that affect both borrower experience and regulatory compliance.
What the Consent Artefact Is
The system first creates a digitally signed JSON consent artefact for each data-sharing agreement. It generates this artefact after borrower approval and then uses it to authorize the data pull.
The artefact, in turn, records a unique consent ID and clearly identifies the FIU, AA, and FIPs. It also specifies the data types, date range, purpose, data life, and consent expiry, thereby ensuring that every data exchange remains precise, auditable, and within the agreed scope. Understanding the roles of FIP and FIU in the consent and data-sharing process is essential here.
The artefact is signed using the borrower’s digital signature (via the AA’s authentication mechanism) and the AA’s own signing key. Any modification to the artefact after signing invalidates the signature, making tampered artefacts immediately detectable by the FIP’s validation layer.
The Consent Request API Sequence
Step 1: FIU Initiates Consent Request
The FIU calls the AA’s consent request API with the consent parameters: FIU ID, customer ID (the borrower’s AA handle, typically their mobile number linked to the AA), data range, data types requested, purpose, and frequency (one-time or recurring). The AA validates the FIU’s credentials and the format of the request, then generates a pending consent object with a unique consent handle.
Step 2: AA Notifies the Borrower
The AA sends a consent request notification to the borrower via the AA’s mobile app, SMS, or a deeplink to the FIU’s interface (if the FIU has embedded the consent flow). The notification includes a summary of the request and a link to the consent review screen. To see how this fits into the full system, here’s how the account aggregator process works step-by-step.
Step 3: Borrower Reviews and Acts on Consent
The borrower sees the full consent details: which institution is requesting the data, what data is being requested, for what purpose, and for how long. They can approve, reject, or modify the request. If they approve, they authenticate (via PIN, biometric, or OTP), and the AA generates the signed Consent Artefact.
Step 4: FIU Polls or Receives Callback
The FIU either polls the AA’s consent status API or receives a webhook callback when the consent status changes. Once the artefact is generated (status: ACTIVE), the FIU can proceed to initiate a data session.
Step 5: FIU Initiates Data Session
The FIU calls the AA’s data session API with the consent ID and the specific data pull parameters (date range within the consented window and account types). The AA generates a session key and forwards the data request to the relevant FIPs.
Step 6: FIP Returns Encrypted Data
Each FIP validates the consent artefact, ensuring it is active, unexpired, and covers the requested data. Then, the FIP retrieves the data, encrypts it with the FIU’s public key, and sends it to the AA. Finally, the AA routes the encrypted data to the FIU, ensuring secure end-to-end transfer without exposing data.
Consent Revocation: How It Works
Consent revocation is a core feature of the AA framework, not an edge case. Borrowers must be able to revoke any active consent at any time through the AA’s interface.
When a borrower revokes consent, the AA updates the consent artefact status to REVOKED. Any subsequent data pull attempt by the FIU will be rejected by the AA, the FIP will not receive the data request. Data already delivered under the consent is not affected by revocation, but no new pulls are possible.
The FIU receives a notification (via webhook or polling) that the consent has been revoked, and must update its records accordingly. Best practice for FIUs is to display a clear consent status indicator in the borrower’s account, showing which consents are active and providing a direct link to the AA’s consent management interface.
Key Design Decisions That Affect Compliance
Several design choices in the consent flow have direct compliance implications:
Consent presentation clarity: The consent screen must clearly specify what is being requested in plain language. Vague purpose descriptions (“for financial assessment”) may not satisfy DPDP Act requirements for specific consent. Explicit purposes (“to assess income stability for a personal loan of Rs. 5 lakhs”) are both better UX and cleaner compliance.
Consent bundling: Requesting more data than necessary for the stated purpose violates the data minimization principle under DPDP. FIUs should request only the account types and date range actually needed for the specific assessment. This is exactly how consent-based data sharing works for NBFCs and lenders in practice.
Recurring consent management: For revolving credit facilities or ongoing monitoring, recurring consents require the borrower to understand they are granting ongoing data access, not a one-time pull. The consent screen must make the recurring nature explicit.
Consent record retention: FIUs must retain the consent artefact for the duration of the data retention period, as it serves as the legal authorization for the data collected.
✅ Key Takeaways
- The consent artefact is a cryptographically signed JSON object that encodes all data sharing parameters and serves as the authorization token for every AA data pull.
- The consent flow follows a six-step API sequence from FIU request initiation to FIP data delivery, all within a regulated pipeline where no party can access data outside the consented parameters.
- Consent revocation stops future data pulls immediately and is a non-negotiable feature of any compliant AA integration.
- Consent design decisions, clarity of purpose, data minimisation, recurring consent transparency, have direct implications for DPDP Act compliance.
- Every consent event is timestamped and auditable, providing both regulatory compliance evidence and a clear data access history for the borrower.
Frequently Asked Questions
The system creates a digitally signed JSON consent artefact that records data scope, accounts, purpose, duration, and consent. It serves as the cryptographic authorization token for each AA data pull.
No. Borrowers explicitly grant each consent. They must approve recurring consents upfront with clear disclosure. Lenders cannot renew or extend consent without borrower action.
Consent validity is determined by the consent artefact’s expiry date, which is set at the time of consent creation within parameters agreed by the AA and the FIU. For loan underwriting, typical consent windows are 7–30 days. For ongoing credit monitoring, consents may extend for the loan tenure.
If the borrower rejects the consent request, the artefact status is set to REJECTED and no data pull is possible. The FIU receives a rejection notification and must decide how to proceed, typically by requesting an alternative document or reconsidering the application.
The consent flow is app-based and requires the borrower to interact with a digital consent screen. Offline or WhatsApp-based collection of financial data falls outside the AA framework. Hybrid journeys, where a loan officer helps a borrower initiate the AA consent on their smartphone, are operationally possible.
Conclusion
The consent flow is where AA’s regulatory design meets operational reality. A strong flow stays fast for borrowers, is legally sound, and handles revocation and errors cleanly.
For developers and compliance teams, the consent artefact forms the audit trail for every AA transaction. Therefore, systems must generate, store, and honor these artefacts correctly to ensure compliance and build a trustworthy lending data infrastructure.This is how an account aggregator improves trust and reduces friction in lending ecosystems.
