Treat consent scope as a control, not a formality. This working summary is not a legal opinion. The RBI Account Aggregator framework is governed by the Master Direction on Non-Banking Financial Company - Account Aggregator (Reserve Bank) Directions, 2016 (updated), the AA Technical Standards, and associated circulars. Lenders should take specific compliance questions to their legal and compliance teams. We have read the framework from the operating perspective of a lender acting as a Financial Information User.
The checklist reflects the framework as of late 2025. RBI clarifications and updates may change implementation requirements, so lenders should monitor RBI notifications and discuss Technical Standards changes with their Account Aggregator partner.
FIU Registration and Technical Certification
A lender accessing financial information through the AA framework must register as a Financial Information User. The RBI process requires evidence of compliance with the AA Technical Standards, an agreement with a licensed Account Aggregator, and the data security baseline set by the framework.
FIU registration checklist:
- FIU registration with RBI is complete and remains active
- Agreement with at least one licensed Account Aggregator is executed
- Technical integration has been tested in the AA sandbox environment
- Consent flows follow the AA Technical Standards version currently in effect
- FIU certificate is current, with certificate requirements verified with the AA partner
- Data security compliance is documented, including encryption in transit and at rest, access controls, and incident response
Consent Design and Parameterization
Each AA data fetch requires borrower consent that meets the framework. Implementation problems often begin with broad parameters that request unnecessary information, or with one consent being reused for different use cases.
Consent design checklist:
- Every consent names a permitted purpose code, such as loan processing and creditworthiness assessment for underwriting, with separate codes for other uses
- Requested data types are limited to what the stated purpose requires
- The historical date range requested stays within the credit policy for that product
- Fetch type identifies one-time or periodic access correctly; ongoing monitoring must not use one-time consent
- Periodic consent frequency reflects the operating need without unnecessary fetching
- Consent validity is limited to the shortest period needed for the use case
- The data life parameter is defined and aligned with the retention policy
- Separate consent templates are maintained for each product and purpose combination
Consent Lifecycle Management
Consent has a lifecycle, beginning with initiation and moving through active use, possible revocation, and expiry. The lender needs an operating process for every stage, rather than treating approval as the end of the control.
Consent lifecycle checklist:
- The system captures the initiation timestamp and parameters for every application
- Borrower approval is confirmed before any fetch is attempted
- Revocation notices from the AA are received and acted on within the required response window
- Revocation stops fetches, records the incomplete data state, and informs the underwriting team
- Expired consent cannot initiate another data fetch
- Consent records are retained for the required audit period
- Borrowers have a way to view and manage consents, typically through the AA app, and are told that this exists
FIU Audit Logging Requirements
FIUs must maintain audit logs for data access under the AA framework. These records may be inspected and should show that every access stayed within a valid, active consent.
FIU audit logging checklist:
- Log each consent initiation with its timestamp, consent ID, and parameters
- Log every successful and failed fetch with timestamp, consent ID, FIP, account reference, and result
- Record each received revocation with its timestamp and the action taken
- Record every consent expiry
- Keep logs secure and tamper-evident
- Meet the framework's log retention period
- Make logs searchable enough to produce a consent's complete access history within a reasonable response time for an audit or regulator request
Data Minimization in Practice
Data minimization means accessing only what the stated purpose needs. Convert each credit policy into defined data scope parameters instead of requesting the widest possible dataset under a general "credit assessment" purpose. For example, an NBFC credit team in Pune reviewing a 3-month salary query on an AA-connected HDFC Bank account should be able to explain that scope.
Data minimization checklist:
- Each lending product documents the necessary financial information types and the reason for each
- Product consent templates include only the documented data types
- A review process checks data scope documentation for new products before launch
- Production access is monitored against consent scope; accessing more than consented breaches the framework
Data Retention and Deletion
The consent artifact contains a data life parameter. When that period ends, the lender must delete or anonymize financial data fetched under that consent. This remains an ongoing management task, especially where application volumes are large.
Data retention checklist:
- The retention policy states the maximum period for AA-sourced financial data
- Expired data life records trigger automated deletion or anonymization
- Deletion is auditable, showing when data was removed and the relevant consent expiry
- Deletion checks cover production systems, analytics environments, backups, and third-party processors
Third-Party Processor Obligations
When a lender uses a bank statement analysis vendor or credit risk platform to process AA-sourced data, the lender keeps its FIU obligations for that information. The processor may use the data only for consented purposes, within the data life period, and subject to the framework's security requirements.
Third-party processor checklist:
- Agreements with processors handling AA-sourced data state purpose limits and security requirements
- Processors understand data life requirements and can delete data on expiry
- The lender can audit the processor's compliance with these duties
This is a practical review starting point, not an exhaustive checklist. The framework continues to evolve. We are not saying that a checklist replaces legal advice or a full compliance audit; we are saying it can help a lender identify where its operating controls need review.