On this page · 12 sections
- What the SRO recognition actually changes
- The five roles, and which one you actually are
- The FIP-first mandate catches lenders by surprise
- The consent workflow, endpoint by endpoint
- What data you can actually get
- Certification, audits and the ongoing cost
- The DPDP consent manager overlap
- India-specific considerations
- A realistic build sequence
- FAQ
- How eCorpIT can help
- References
Summary. The Reserve Bank of India recognised Sahamati as the self-regulatory organisation for the Account Aggregator ecosystem on 5 June 2026, the first Indian SRO covering a cross-sectoral framework spanning four financial regulators. The network it now governs is large: 1,120 live regulated entities, 176 Financial Information Providers, 1,020 Financial Information Users and 17 operational Account Aggregators, with more than 450 million consent requests fulfilled and 294 million linked accounts. For engineering teams, the SRO changes who sets the standards you build against, not the standards themselves. The harder constraints are older and rarely mentioned in launch coverage: you cannot become a Financial Information User unless RBI, SEBI, IRDAI or PFRDA regulates you; if you hold financial information you must join as a Financial Information Provider too; and CASParser, a vendor that sells a competing statement-parsing API, puts a first-year Account Aggregator build at ₹5-25 lakh over 5-10 months.
If you are scoping an Account Aggregator (AA) integration this quarter, the SRO announcement is not the fact that should drive your plan. Eligibility, data coverage and the November 2026 DPDP consent manager deadline should.
What the SRO recognition actually changes
Sahamati is the member-driven industry alliance and ecosystem coordinator for India's AA framework. On 5 June 2026 the RBI formally recognised it as the SRO for the framework, following a call for applications the central bank issued on 12 March 2025. The recognition gives an existing coordinator statutory standing rather than creating a new rulebook.
As SRO-AA, Sahamati is responsible for developing operational and technical standards, facilitating dispute resolution, supporting interoperability, and coordinating engagement across participants. Read that list carefully against your backlog. None of it changes the ReBIT API contract you code against today. What it changes is the escalation path when an FIP breaks a schema, and the body that will arbitrate when two participants disagree about whose implementation is wrong.
R. Gandhi, Former Deputy Governor of the Reserve Bank of India and Chairman of Sahamati, framed it this way in the announcement: "The establishment of an SRO introduces an important layer of institutional trust for the ecosystem. It creates a mechanism through which industry participants can collectively uphold standards, strengthen responsible market conduct, and ensure that the ecosystem evolves in a manner that remains secure, interoperable, and consumer-centric."
Sahamati is the first SRO in India representing a cross-sectoral ecosystem spanning multiple financial regulators. That matters for a practical reason: the AA framework was built jointly by the RBI, SEBI, IRDAI and PFRDA, with the Department of Revenue added later for GST data. Before June 2026, a dispute crossing two regulators had no single industry forum. Now it has one.
The plain engineering read: the SRO is a governance upgrade, not an API change. Do not re-plan a roadmap around it.
The five roles, and which one you actually are
Most integration confusion comes from teams assuming they are the FIU when they are not eligible to be one.
| Role | What it does | What it cannot do |
|---|---|---|
| FIP (Financial Information Provider) | Holds customer financial data; validates the consent artefact and encrypts data for release | Cannot refuse a valid consent-backed request for data types it has activated |
| AA (Account Aggregator) | RBI-licensed consent manager; routes the consent artefact and encrypted payload | Cannot view, store or sell customer data; does not hold the decryption key |
| FIU (Financial Information User) | Requests consent, fetches and decrypts data to deliver a service | Cannot be an unregulated entity; cannot pull data outside the consent purpose and duration |
| TSP (Technology Service Provider) | Builds and operates the FIU or FIP module on behalf of a regulated entity | Cannot itself be the licensed participant or hold the statutory obligation |
| Central Registry | Publishes participant identifiers used for discovery and routing | Not a data path; no financial information passes through it |
The AA sits in the middle and is deliberately blind. Data flowing through an AA is encrypted end to end, and the AA does not hold the decryption key. This is the design property that makes the framework defensible under privacy law, and it is also why AA outages look like routing failures rather than data-loss events.
If your company is not registered with the RBI, SEBI, IRDAI or PFRDA, you cannot directly become an FIU. A pure-play fintech startup without an NBFC licence, lending licence or investment advisory registration has two options: obtain a licence, or partner with a regulated entity that acts as the FIU while you build the product on top. Teams routinely discover this in month three of a build. Check it in week one.
The FIP-first mandate catches lenders by surprise
Under a November 2023 change to the RBI Master Direction, an RBI-regulated entity joining the AA ecosystem as an FIU must also join as an FIP if it holds financial information falling within the FIP definition. The RBI issued this because entities eligible to be FIPs had onboarded only as FIUs, consuming data from other FIPs without contributing their own.
The engineering consequence is that a lender planning a one-directional "pull bank statements for underwriting" integration is actually scoping two modules: an FIU module that requests and decrypts, and an FIP module that receives consent artefacts, validates them, and serves your own loan data to competitors who ask with valid consent. Budgets built on the first module alone are wrong by roughly half.
The Master Direction governing all of this is dated 2 September 2016 and has been amended repeatedly since, adding GSTN as an FIP in 2022, NPS Central Recordkeeping Agencies in 2023, and CCIL in 2024. Each expansion of the FIP definition is a new integration surface.
The consent workflow, endpoint by endpoint
ReBIT, a wholly owned subsidiary of the RBI, publishes the technical specifications at api.rebit.org.in. The consent flow is a fixed sequence, and Sahamati's developer documentation names the calls precisely.
The FIU starts by retrieving the FIP identifier from the Central Registry, constructing the x-request-meta header for router compatibility, and posting the consent request. The request specifies the type of financial data, the duration, and the purpose for which access is required.
# 1. FIU -> AA (via Router): request consent
POST /Consent
x-request-meta: <base64 routing metadata built from Central Registry identifier>
Content-Type: application/json
# 2. AA internal: create artefact in pending state
POST /Consent/create
# 3. AA internal: render artefact to the user for approval
GET /Consent/read
# 4. AA internal: user approves; artefact status updated and stored
POST /Consent/accept
# 5. AA -> FIU and FIP (via Router): notify that consent was granted
POST /Consent/Notification
x-request-meta: <routing metadata>
# 6. FIU -> AA (via Router): fetch the artefact for use in FI requests
POST /Consent/fetch
x-request-meta: <routing metadata>
# 7. User-initiated, any time: revoke
POST /Consent/revoke
Three details decide whether your implementation survives certification.
Account discovery and linking is a prerequisite the user completes before any consent request can execute. If your onboarding funnel assumes consent is the first screen, it will fail in production for every customer who has not yet linked accounts to an AA handle.
The /Consent/Notification call is delivered to the FIU and the FIP. The FIU uses it as a trigger to fetch the artefact; the FIP stores it to validate later financial information requests. Teams that treat the notification as informational, and skip the /Consent/fetch step, end up making FI requests the FIP rejects.
Revocation is a first-class flow, not an edge case. The customer can view active consents and revoke at any time, which means your data pipeline needs to handle a consent going invalid between two scheduled fetches without dropping into an error state that pages someone at 02:00.
What data you can actually get
The RBI Master Direction defines more than 20 categories of financial information, and Sahamati reported in March 2025 that 16 financial information types can be shared through AAs. Availability is uneven, and the gap between "defined in the spec" and "a bank will actually serve it" is where roadmaps break. The assessment below is CASParser's, published in March 2026; the company sells a competing CAS-parsing product, so treat the framing as interested and the underlying coverage claims as checkable against Sahamati's own FIP-AA mapping dashboard.
| Data type | Status on AA (as of March 2026) | Practical impact for builders |
|---|---|---|
| Savings accounts, singly held | Live across all 72 banks listed | The reliable core of any underwriting use case |
| Equities, MF units, ETFs, AIFs, REITs | Live via CDSL and NSDL, both on 13 AAs | Broad coverage; demat transaction history capped at 2 years |
| Mutual fund folios | Live via CAMS and KFin RTAs, both on 13 AAs | Broad coverage for holdings |
| GSTR 1 and 3B | Live via GSTN on 13 AAs | Usable for MSME cash-flow lending |
| Fixed and recurring deposits | Live but roughly 40% of banks | Plan for silent gaps, not errors |
| Insurance policies | 57 insurers live, many on only 1-2 AAs | Discoverable only if insurer and customer share an AA |
| Bonds, G-Sec, CP, CD, EPF, PPF | Proposed; no FIPs serving, no production schemas | Do not scope features against these |
| Joint accounts, NRE/NRO, non-proprietor current accounts | Excluded | Whole customer segments are invisible |
The joint-account exclusion deserves a line of its own. No bank supports joint account discovery. If your product serves households, family wealth or co-borrowers, a material share of your target balance sheet cannot be seen through AA at all, and no amount of engineering closes that gap.
Ecosystem coverage also varies by AA. Not every FIP connects to every AA, so a customer whose bank is on one AA and whose insurer is on another cannot assemble a complete picture through either. The backbone entities (CDSL, NSDL, CAMS, KFin, GSTN) are each connected to 13 AAs, so investment and tax data is broadly reachable; banking and insurance connectivity is where the fragmentation bites.
Certification, audits and the ongoing cost
Building the module is the short part. Staying certified is the long part.
Certification is performed by a Sahamati-empanelled auditor and covers security specification conformance, API schema conformance, financial information schema conformance, and Central Registry integration. It is tied to a specific version of the ReBIT technical specification, so a spec revision triggers re-certification.
After go-live, the obligations continue: quarterly self-tests re-running the certifier's tool and declaring that production matches the certified environment, and an information systems audit every two years by a CISA-certified external auditor under the RBI Master Direction. Any production code change technically requires confirming conformance.
Sahamati does not publish standardised pricing; costs are negotiated commercially between participants. CASParser's March 2026 estimate puts total first-year cost at ₹5-25 lakh or more depending on scope and whether you use a TSP or build in-house, with a 5-10 month integration timeline. That estimate comes from a vendor with a commercial interest in AA looking expensive, so treat it as an order of magnitude rather than a quote. The direction is consistent with the compliance load described above.
The real cost here is rarely the code. It is the licence, the certification cycle and the FIP module you did not plan to build.
The DPDP consent manager overlap
This is the part most 2026 roadmaps get wrong, and the deadline is close.
Section 6(7) of the Digital Personal Data Protection Act, 2023 creates the consent manager: an entity through which a Data Principal can give, review and withdraw consent, acting as a single point of contact on an interoperable platform. Parliament enacted the Act on 11 August 2023, and MeitY notified the DPDP Rules, 2025 in November 2025 with an 18-month phased compliance timeline. The Rules require consent managers to be Indian companies. Compliance trackers place consent manager registration and the penalty framework at the twelve-month mark in November 2026, with full compliance on consent, notice, security and data-principal rights at the 18-month mark in May 2027.
An Account Aggregator does exactly what the DPDP Rules describe a consent manager doing, but under RBI authority rather than the Data Protection Board.
| Dimension | RBI AA Master Directions | DPDP consent manager regime |
|---|---|---|
| Regulator | RBI, with SEBI, IRDAI, PFRDA and DoR participating | Data Protection Board |
| Scope of data | Financial information only, as defined in the Directions | Any personal data |
| Reading underlying data | Prohibited for the AA | Prohibited for the consent manager |
| Consent logs | Required | Required |
| Standards body | ReBIT technical specifications | Standards to be prescribed by the DPB |
| Other business activity | AA restricted to account aggregation only | No equivalent restriction stated |
| Grievance recourse | Open to all customers, including non-natural persons | Limited to natural persons |
Sahamati's own position, published in March 2025, is that the two regimes can be read harmoniously by registering AAs as consent managers for the financial sector, since nothing in the DPDP regime requires a consent manager to handle every kind of personal data. Its submission to MeitY argued that the DPB should adopt the existing ReBIT standards for financial data rather than write new ones, to avoid disrupting a live network.
That is the industry's preferred outcome, not a settled fact. Until the DPB publishes its standards and its treatment of existing AAs, a fintech building today faces genuine ambiguity about whether its consent architecture will need a second implementation. MeitY has clarified that Data Fiduciaries are not required to integrate with consent managers, which lowers the risk for FIUs specifically.
The defensible engineering position is to keep the consent artefact, its logs and its purpose and duration metadata in a storage layer you own, modelled on the ReBIT artefact but not welded to the AA transport. If the DPB adopts ReBIT standards, you have lost nothing. If it does not, you are changing an adapter rather than a data model. Teams working through the wider obligations will find our note on DPDP consent manager framework readiness and the DPDP compliance cost breakdown for Indian startups useful alongside this.
India-specific considerations
The AA framework is a pillar of the Data Empowerment and Protection Architecture, built across the RBI, SEBI, IRDAI and PFRDA. Sahamati reported in March 2025 that around 2.12 billion of India's more than 3.5 billion financial accounts, roughly 60%, could share data and manage consents through AAs, and that 140 million consent requests had been fulfilled as of December 2024. By the June 2026 SRO announcement the cumulative figure had passed 450 million, with more than 290 million monthly data shares.
That growth rate is the argument for building now. The counter-argument is coverage: the same ecosystem excludes joint accounts entirely and serves fixed deposits from under half of banks.
B.G. Mahesh, CEO of Sahamati, described the framework's position in the June announcement: "India's Account Aggregator ecosystem is among the earliest examples globally of how digital public infrastructure can enable consent-led data mobility at population scale."
For teams already working across India's public rails, the sequencing question is usually AA against payments. Our analysis of UPI transaction caps and what they mean for fintech builders covers the adjacent decision.
A realistic build sequence
Confirm eligibility first. Establish which regulator licenses your entity, or identify the regulated partner who will be the FIU of record. Nothing else matters until this is settled.
Scope both modules. If you are RBI-regulated and hold financial information, budget the FIP module alongside the FIU module from day one.
Pick AAs by FIP coverage, not by pricing. Your customers' data is only reachable through AAs their FIPs have integrated with, and the Sahamati FIP-AA mapping dashboard is the source of truth.
Decide TSP against in-house early. A TSP shortens time to certification and carries the spec-version treadmill; building in-house keeps the consent layer under your control. Most teams under 20 engineers should take the TSP.
Model the consent artefact in your own schema. Store purpose, duration, scope and revocation state independently of the AA transport, for the DPDP reasons above.
Test revocation and expiry as primary paths. A consent that dies between scheduled fetches is normal operation, not an incident.
FAQ
How eCorpIT can help
eCorpIT builds regulated fintech products for Indian and global teams from Gurugram, with senior engineering teams who work through eligibility, consent architecture and certification scope before a line of integration code is written. We design applications aligned with DPDP and RBI Account Aggregator requirements, including the consent artefact modelling that keeps your options open ahead of the November 2026 consent manager deadline. If you are weighing a TSP against an in-house build, or scoping the FIP module you did not budget for, talk to us about the sequencing. Our fintech app development service covers the delivery side.
References
- RBI Recognition of Sahamati as Self-Regulatory Organisation, Marks New Phase for India's Account Aggregator Ecosystem - Sahamati press release, 5 June 2026.
- RBI press release on SRO recognition - Reserve Bank of India.
- RBI recognises Sahamati Foundation as SRO for account aggregator ecosystem - Business Standard.
- Master Direction - Non-Banking Financial Company - Account Aggregator (Reserve Bank) Directions, 2016 - Reserve Bank of India, dated 2 September 2016.
- RBI mandate: regulated entities joining the Account Aggregator ecosystem as FIP - summary of the November 2023 FIP-first directive.
- Consent workflow - SahamatiNet developer documentation, ReBIT consent APIs.
- NBFC-AA API specification (core) - ReBIT technical specification.
- Reconciling the Account Aggregator and Consent Manager Frameworks - Sahamati, 18 March 2025.
- State of Account Aggregator in 2026: what founders actually need to know - CASParser, 3 March 2026. Vendor of a competing CAS-parsing product.
- Consent Managers under India's DPDP Act and DPDP Rules - AZB & Partners.
- Fragmented consent and fractured rights: resolving the Account Aggregator-Consent Manager paradox under DPDP Rules - SCC Online, 26 June 2026.
- Account Aggregator Framework - Department of Financial Services, Ministry of Finance.
- Government notifies DPDP Rules to empower citizens and protect privacy - Press Information Bureau, MeitY, 14 November 2025. Confirms the 18-month phased compliance timeline and that consent managers must be Indian companies.
- DPDPA compliance timeline: phase 1, 2, 3 deadlines explained - phase dates for consent manager registration and full compliance.
- Digital Personal Data Protection Rules, 2025 - Ministry of Electronics and Information Technology.
- How to join the Account Aggregator network - Sahamati.
Last updated: 17 July 2026.