Fintech / Data Sharing

Account Aggregators: Sharing Financial Data with Control

CA Nikhil Gupta·May 2026·3 min readFintech / Data Sharing

Account Aggregators are designed to move financial information with consent, not to become owners of the customer’s money or unrestricted readers of every financial record.

Quick View

Licence

RBI-regulated NBFC-AA

Core object

Consent-based data flow

AA role

Data blind intermediary

User control

Purpose and duration

What Matters Now

The Account Aggregator framework enables financial information to move from a Financial Information Provider to a Financial Information User based on an electronic consent artefact. The AA manages the consent and secure flow; it is not meant to read or store the customer’s financial information in plain form.

A consent request should identify the data, purpose, recipient, frequency and duration. Broad, long-lived requests can expose more information than a one-time loan assessment requires. Users should reject or narrow requests that do not match the service.

For lenders and fintechs, AA data can improve speed and reduce document tampering, but automated analysis still requires fair underwriting, data minimisation, security and a route to correct errors.

How It Works

StageWhat happensControl
RequestA service asks for specified financial data.Check purpose, period, frequency and recipient.
ConsentThe customer approves through the AA interface.Keep the consent receipt.
TransferEncrypted data moves from provider to user.The AA facilitates rather than lends.
RevocationThe customer can manage consent within the framework.Revocation does not erase lawful prior processing automatically.

Decision Framework

Start with the exact decision being made. A payment choice, credit facility, investment, policy, remittance or compliance step should not be judged only by convenience or headline return. For Account Aggregators: Sharing Financial Data with Control, the four useful lenses are licence: RBI-regulated NBFC-AA; core object: Consent-based data flow; aa role: Data blind intermediary; user control: Purpose and duration.

Next, identify the downside before considering the expected benefit. Ask how much money can be lost or delayed, which obligation becomes fixed, who controls the data or asset, what happens when the provider fails, and which official complaint or appeal route remains available. This converts a marketing claim into a testable decision.

Finally, define the review trigger. A rule change, missed payment, benefit revision, sharp market move, data incident, unresolved reconciliation or change in personal cash flow should reopen the decision. Evidence should be collected when the transaction occurs, not reconstructed after a dispute.

  • Request: Check purpose, period, frequency and recipient.
  • Consent: Keep the consent receipt.
  • Transfer: The AA facilitates rather than lends.
  • Revocation: Revocation does not erase lawful prior processing automatically.

Who Bears the Risk

ParticipantPrimary responsibilityFailure to avoid
User or customerRead the terms, authorise deliberately, preserve records and act within personal cash-flow or risk limits.Sharing banking passwords outside the AA flow.
Provider or intermediaryMake accurate disclosures, operate the agreed process, protect data or assets and maintain a usable grievance route.A consent request with no clear purpose.
Adviser or finance teamApply the current rule to the actual facts, separate assumptions from evidence and explain material downside clearly.Continuous access for a one-time service.

Regulation can allocate duties, but it cannot remove commercial or market risk. The safest operating approach is to know which participant owns each step and to escalate an exception before money, data or legal rights become difficult to recover.

Practical Example

A lender needs six months of bank transactions for one credit assessment but requests five years of recurring data access. The customer should question the scope and select a narrower consent where the interface permits. The lender should document why each field and period is necessary.

Action Checklist

  • Confirm the AA and recipient identities.
  • Read every field in the consent artefact.
  • Limit duration and frequency to the purpose.
  • Review active consents periodically.
  • Revoke access that is no longer needed.
  • Challenge decisions based on incorrect data.

Evidence to Keep

  • Consent artefact and timestamp.
  • Purpose and recipient details.
  • Data-access history.
  • Revocation confirmation.
  • Correction or grievance request.

Warning Signs

  • Sharing banking passwords outside the AA flow.
  • A consent request with no clear purpose.
  • Continuous access for a one-time service.
  • An app claiming the AA itself approved the loan.
  • No method to manage or revoke consent.

Frequently Asked Questions

Does an Account Aggregator lend money? â–¼
No. The AA facilitates consent-based financial-information sharing; the lender or service provider makes its own decision.
Should users share net-banking passwords? â–¼
No. Use the authorised AA consent flow rather than giving credentials to a third party.
Can consent be unlimited? â–¼
The artefact should specify scope, purpose, frequency and duration. Users should avoid unnecessary breadth.
Does revocation delete all data already used? â–¼
Not automatically. Retention and lawful prior processing depend on the applicable framework and purpose.