We recently received a query from a mutual fund distributor (MFD). He wanted to build a financial planning tool. To get the client’s financial data, he was looking to tie up with an Investment Adviser (RIA) who was using the Account Aggregator (AA) framework. His query was simple, “Can I enter into an agreement with the RIA who can help me fetch the clients’ data?”
When we think of an Investment Adviser (RIA) using the Account Aggregator framework, the use case seems fairly straightforward.
An adviser needs a reasonably complete picture of the client’s financial position before providing meaningful advice. Today, that often means collecting bank statements, mutual fund statements, demat statements and other financial information from the client.
The Account Aggregator (AA) ecosystem can make this process significantly more seamless.
But there is another angle that is becoming interesting.
Is RIA registration, for some businesses, becoming attractive not only because of the ability to provide investment advice, but also because of the ability to participate as a Financial Information User (FIU)?
That question becomes even more interesting when we look at how MFDs and third-party fintech platforms are exploring the AA ecosystem.
Before getting into that, it is useful to understand the ecosystem itself.
Account Aggregator — the basics
The Account Aggregator framework enables customers to share their financial information digitally through a consent-based mechanism.
A customer may have financial information spread across several institutions — banks, mutual funds, securities intermediaries, insurance companies and other financial institutions. These institutions holding the information are the Financial Information Providers (FIP).
The eligible regulated entity seeking the information is the Financial Information User (FIU). Entities regulated by financial-sector regulators i.e. SEBI, IRDA, RBI, PFRDA can participate as FIUs, subject to the applicable framework and eligibility requirements.
The Account Aggregator facilitates the transfer of information based on the customer’s consent.
The AA is therefore not simply a database of financial information. It facilitates the consent-based flow of information between the relevant participants.
So why are RIAs becoming particularly relevant to this discussion?
Why are RIAs becoming FIUs?
For a genuine advisory business, the use case is clear.
An adviser needs financial information to understand the client’s financial position and provide appropriate advice. Access to that information through AA can reduce the manual effort involved in collecting and consolidating statements.
But there is another business possibility.
Traditionally, the thought process would be:
I want to provide investment advice → I need RIA registration.
The emerging thought process could sometimes look like:
I want access to a particular financial-data ecosystem → I need to be an eligible regulated entity → which regulatory registration fits my business?
This does not mean that RIAs are taking registration only for this purpose. Nor does becoming an FIU automatically make an entity an RIA.
The point is different.
Regulatory eligibility itself can become commercially valuable.
And that is where the business model becomes interesting.
The RIA–MFD–AA triangle and beyond
MFDs are one example of a broader business model emerging around the AA ecosystem.
An MFD may have the client relationship and want to offer a more consolidated view of the client’s financial position. Similarly, a third-party fintech platform may want to build a dashboard, analytics product or financial-planning interface using consented financial information.
The challenge is that these businesses may not themselves be eligible FIUs for the intended use case.
This is where a regulated entity, such as an RIA, can potentially become part of the structure.
The MFD or platform has the customer interface. The RIA has regulatory status. The AA provides the infrastructure, and the customer provides consent.
Commercially, the arrangement can make sense.
But the regulatory question is not simply whether the technology works.
Who is actually seeking the information? Who ultimately uses it? And is the RIA using the information for its own regulated activity, or is its FIU status enabling another business to access the AA ecosystem?
Technology partner or regulatory gateway?
An unregulated technology company is not automatically a concern. The AA ecosystem itself recognises Technology Service Providers (TSPs) that support FIPs and FIUs with technology and implementation.
The important distinction is the role the third party actually plays.
If the platform is providing technology to an RIA and supporting the RIA’s own regulated activity, that is very different from the platform being the substantive user of the financial information.
So the question is not merely:
Is the third party regulated?
It is:
Is the third party enabling the FIU, or is the FIU’s regulatory status enabling the third party?
That distinction becomes particularly relevant where the RIA is effectively the route through which another business accesses financial information.
Consent is important. But is it the complete answer?
Customer consent is at the heart of the AA framework, but it is not simply a blanket permission to access financial information.
The consent artefact captures, among other things, the nature of the financial information being requested, the purpose for which it is being collected and the identity of the recipient, where applicable. The information is also required to be used or disclosed in accordance with the terms of that consent.
This becomes particularly relevant in an RIA–MFD or RIA–fintech arrangement.
If the RIA clearly identifies the third-party recipient and the purpose for which the information will be used, and the customer consents to it, that addresses an important part of the transparency question.
But does it, by itself, resolve the regulatory question?
Not necessarily.
There are two separate questions:
Has the customer consented to the stated purpose and recipient?
And:
Is that recipient otherwise entitled to use the information for that purpose, or is the RIA’s FIU status effectively being used as the route through which that access is obtained?
This is why the entire data journey needs to be understood — from consent to ultimate use, and not merely from consent to API.
Perhaps the most useful question for all parties is:
If a regulator followed the data from the customer’s consent all the way to its ultimate business use, would the commercial reality and the regulatory structure tell the same story?
Because the real question may no longer be just who can access the data, but who is actually using it — and under whose regulatory status?