NBFC-AA API Compliance: Adoption Timeline and Submission Guidelines for FIUs & FIPs 2026
- Nishant Shah
- Feb 12, 2025
- 8 min read
Updated: Jul 30
For many banks and NBFCs, joining India’s Account Aggregator ecosystem was once treated as an integration project. By 2026, the harder job is staying aligned as ReBIT changes API specifications, financial-information schemas, error handling, and transition deadlines.
An endpoint can return a technically valid response and still fail interoperability because the consent, FI type, schema version, joint-holder data, encryption, or decommissioning logic is wrong. That is why NBFC AA API Compliance must be managed as a coordinated migration across compliance, product, engineering, security, operations, and partner institutions.
This is an Indian framework. US-based founders, investors, and technology leaders should use this guide when supporting an India-regulated entity—not as a substitute for US open-banking rules. Exact obligations should be confirmed with the applicable regulator, ReBIT guidance, connected AAs, and qualified counsel.
What Was the NBFC AA Adoption Timeline in 2026?RBI-regulated FIPs were expected to become production-ready by April 25, 2026, go live with joint and corporate account specifications between April 25 and May 10, and decommission the applicable previous version before May 10. FIUs were expected to adopt Deposit, RD and TD schema version 3.0.0 before April 25, support both versions during May 10–24, and decommission the previous schema before May 24, 2026. |
What NBFC Account Aggregator API Compliance Means
The Account Aggregator network has three principal roles. An NBFC-AA manages customer consent and facilitates secure financial-data transfer. A Financial Information Provider, or FIP, holds customer information. A Financial Information User, or FIU, requests and uses that information for a regulated financial service.
According to Sahamati’s onboarding guidance, only entities regulated by RBI, SEBI, IRDAI, or PFRDA may participate directly as FIPs or FIUs. Technology vendors can build the product layer, but the regulated participant remains responsible for its role.
A compliant architecture usually sits inside a wider fintech software development program covering consent, source-system integration, encryption, observability, customer experience, and evidence—not only API connectivity.
Why NBFC AA API Compliance 2026 Was Different
The September 25, 2025 ReBIT guideline expanded the ecosystem toward joint and corporate bank accounts. It published FIP and AA API Specification version 2.2.0, Deposit/RD/TD schema version 3.0.0 for joint accounts, and new Corporate Deposit, Corporate RD, and Corporate TD schemas version 1.0.0.
These changes reach beyond an API gateway. Joint accounts affect holder information, account discovery, linking, consent validation, and support. Corporate accounts introduce organizational identifiers, authorized users, commercial-banking source systems, and business-account data.
Teams should track the AA, FIP, and FIU API catalogues separately from FI-type schema versions. A platform may support API 2.2.0 but still produce or consume the wrong deposit schema.
NBFC AA Adoption Timeline: Key 2026 Milestones
Date | Entity | Published requirement |
Nov. 25, 2025 | Ecosystem | Six-month adoption monitoring started. |
To Mar. 24, 2026* | FIPs | Monthly progress reports on the Tuesday in the fourth week. |
Mar. 25–May 10 | FIPs | Weekly progress reports on Tuesdays. |
By Apr. 25 | FIPs | RBI-regulated FIPs production-ready. |
Before Apr. 25 | FIUs | Deposit, RD and TD schema 3.0.0 live. |
Apr. 25–May 10 | FIPs | Go live for joint and corporate accounts; submit confirmation after the relevant change. |
Before May 10 | FIPs | Previous applicable version decommissioned. |
May 10–24 | FIUs | Both relevant schema versions supported. |
Before May 24 | FIUs | Previous Deposit, RD and TD schema decommissioned. |
The published ReBIT PDF says monthly reports run “from December 1, 2026 till March 24, 2026,” which is chronologically inconsistent. The surrounding timeline suggests December 2025, but entities should confirm the operative calendar directly with ReBIT at aa-apirelease@rebit.org.in. |
FIP Requirements Under NBFC API Compliance Guidelines
A FIP needed more than versioned URLs. Its platform had to support account discovery and linking, receive and store consent, validate the FI request against that consent, retrieve data from source systems, encrypt it, notify the AA when data was available, and return the correct financial information.
Source-system and schema readiness
The FIP should verify that internal systems can produce accurate holder information, account status, balances, transactions, deposit details, timestamps, and mandatory fields for joint and corporate accounts. Automated schema validation should run before data leaves the organization.
Production readiness and decommissioning
Production readiness means code deployed, security and performance tests passed, monitoring active, partner connectivity verified, runbooks approved, support trained, rollback tested, and reporting ownership assigned. Decommissioning should happen only after version traffic and partner migration are confirmed.
FIU FIP API Compliance: What FIUs Needed to Change
An FIU should be able to request consent, process acceptance or rejection notifications, store the consent artefact, request financial information, receive the data-ready notification, fetch and decrypt the data, validate its schema, and restrict use to the approved purpose.
Dual-version processing
During the transition window, the FIU needed to detect the incoming schema version and route it to the correct parser. The version should remain visible in audit logs and operational dashboards. Failure rates should be monitored separately before the old parser is retired.
Corporate account adoption
The 2025 guideline described FIU adoption of the new corporate deposit schemas as recommended within the timeframe. Each FIU should assess its business-banking use cases, connected FIP coverage, underwriting needs, analytics compatibility, and customer roadmap.
For lenders, the AA data flow should connect cleanly with the loan management system so consented information, underwriting inputs, decisions, and audit evidence remain traceable without allowing AA data to spread into uncontrolled systems.
NBFC AA Submission Guidelines for FIPs
FIUs and FIPs do not have identical submission duties. ReBIT’s general major-version strategy requires AAs and FIPs to submit a Plan of Action and periodic Adoption Progress Reports. FIU progress is tracked through integration status supplied by AAs. The joint and corporate account guideline specifically requests periodic and one-time reports from FIPs.
Plan of Action
For a major API release, the entity should download the current ReBIT template, complete it on signed letterhead, and submit it within 30 days of publication. Major, minor, and patch releases should not be treated as interchangeable.
Adoption Progress Report
The report should reconcile implementation stage, development, testing, AA integration, production readiness, dependencies, risks, mitigation, target dates, and accountable owners. Every completion claim should have evidence such as a test result, release record, security approval, sandbox result, or partner confirmation.
Adoption Confirmation Report
For the 2026 joint and corporate account cycle, the one-time confirmation was to be submitted between April 25 and May 10 after decommissioning the previous joint-account schema and/or adopting the latest corporate-account specification. Submissions and questions were directed to aa-apirelease@rebit.org.in.
FIU FIP Compliance 2026 Testing Checklist
A successful sandbox call is not enough. Test discovery with no match and multiple matches, OTP success and failure, expired and revoked consent, data outside the permitted range, duplicate requests, callback delays, retries, encryption failures, partial source-system outages, incomplete data, and schema-validation errors.
Joint and corporate scenarios should be tested separately. Teams should also test with more than one AA because one sandbox cannot prove network-wide interoperability.
Sahamati recommends certification by an empanelled certifier before FIP or FIU modules go live. Certification should be described as recommended unless a regulator, contract, or onboarding arrangement makes it mandatory for that entity.
Account Aggregator Compliance for NBFCs: Governance and Evidence
The organizations that handle an API migration well usually have one shared control model. Compliance interprets the published requirement, engineering owns the technical change, product identifies customer impact, information security validates protection and access, operations prepares support, and an authorized senior owner approves the reported status. Without that structure, the progress report can say “complete” while partner testing, monitoring, or decommissioning is still unfinished.
Maintain a version and obligation register
The register should record the participant role, API catalogue, semantic version, FI type, schema version, connected AA, environment, implementation owner, test status, production status, deprecation date, decommission date, and supporting evidence. Keep regulatory instructions separate from internal target dates. This makes it easier to see, for example, that an FIP API change is complete while the Deposit schema or one connected AA remains on an earlier version.
Create an evidence pack for every reported milestone
A strong evidence pack can include the approved impact assessment, architecture decision, schema mapping, pull request, release record, automated test results, sandbox logs, AA confirmation, security approval, performance results, production dashboard, support runbook, rollback test, and decommissioning record. Evidence should be readable by compliance and audit teams, not understandable only to the developer who performed the work.
Protect consent and financial data beyond the API
The FIU should enforce the consent purpose, permitted FI types, frequency, date range, expiry, and revocation throughout downstream processing. The FIP should validate the consent before retrieving information from its source systems. Both sides should mask sensitive information in logs, restrict production access, protect cryptographic keys and secrets, monitor abnormal failures, and define retention and deletion. A technically successful data fetch is not compliant if the information is later used outside the authorized purpose.
Make the customer journey operationally resilient
Customers will experience failures that do not fit a perfect demonstration: an unsupported institution, an expired OTP, a consent rejection, a delayed callback, a partial data set, or an unavailable source system. The product should explain what happened without exposing technical details, preserve the customer’s progress where appropriate, prevent duplicate requests, and give support teams enough traceability to investigate. Retry logic must not bypass consent or create repeated financial-information requests.
Plan decommissioning as carefully as go-live
Before retiring a previous version, review traffic by AA and schema, confirm that no active partner still depends on it, complete regression testing, prepare rollback criteria, and communicate the cutover. After decommissioning, monitor failures and retain evidence of the final status. This final step matters because a new version can be live while old-version traffic still exists; deployment alone is not proof that migration is complete.
Common Account Aggregator Compliance Mistakes for NBFCs
Treating API 2.2.0 as an endpoint-only change while leaving schemas and source systems untouched.
Assuming FIUs and FIPs submit the same reports.
Reporting progress percentages that cannot be supported with evidence.
Testing with one AA and treating that as full interoperability.
Using live or replicated customer data in UAT.
Removing the old version before partner migration is confirmed.
Silently correcting an unclear official date instead of requesting written clarification.
What to Do If the 2026 Deadline Was Missed
Because the principal April and May 2026 dates have passed, an incomplete entity should start with an honest gap assessment. Identify the affected API, schema, partner, consent flow, and customer journey. Separate work that is undeveloped from work that is deployed but untested.
Escalate the status to compliance and senior management, contact ReBIT and connected AAs, submit accurate information using the applicable template, preserve correspondence, and agree a controlled remediation plan. Do not declare production readiness until test, security, partner, deployment, monitoring, and decommissioning evidence exists.
Conclusion
NBFC AA API Compliance 2026 was not simply about adopting version 2.2.0. It required role-specific implementation, schema readiness, consent enforcement, interoperability testing, reporting evidence, dual-version support, production rollout, and retirement of previous versions.
The strongest operating model gives compliance one calendar, engineering one version inventory, product one customer-impact view, security one evidence set, and leadership one truthful status report.
A focused readiness assessment can identify which obligations apply, what evidence is missing, and which integrations remain at risk. FintegrationFS supports financial workflow engineering, regulated API integration, lending systems, and implementation planning for fintech products operating across India and global markets.
Frequently Asked Questions
1. What is NBFC AA API Compliance?
It means implementing the applicable ReBIT API specifications, FI data schemas, consent controls, security measures, version transitions, testing, and reporting obligations for an entity’s role in India’s Account Aggregator ecosystem.
2. What did RBI-regulated FIPs need to adopt in 2026?
FIPs were expected to support version 2.2.0 for joint and corporate accounts, implement the applicable schemas, become production-ready, go live in the prescribed window, decommission prior versions, and submit the required progress and confirmation reports.
3. What was the 2026 FIU deadline?
FIUs were expected to go live with Deposit, RD and TD schema version 3.0.0 before April 25, support both relevant versions during May 10–24, and decommission the previous schema before May 24, 2026.
4. Do FIUs submit Adoption Progress Reports directly to ReBIT?
ReBIT’s general strategy says FIU progress is tracked through integration status reported by AAs. The joint and corporate account guideline specifically requested reports from FIPs. FIUs should confirm whether any separate direction applies to them.
5. Where should FIP adoption reports be submitted?
The published guidelines direct applicable reports and submission questions to aa-apirelease@rebit.org.in. Entities should use the latest ReBIT template, obtain the required signature, and retain the report, email, acknowledgement, and supporting evidence.
