How borrower choice and wider financial data connectivity can improve credit delivery

Account Aggregator interoperability can help NBFCs address a practical obstacle in retailer lending: a borrower may already use an AA that the lender does not support, while that AA may not connect directly to every bank holding the borrower’s accounts. Sahamati’s proposed gateway architecture addresses both gaps. Its commercial value lies in completing more consent journeys and obtaining a fuller, permissioned view of cash flows, rather than merely adding another digital channel. 

What an Account Aggregator does

An Account Aggregator is an RBI-regulated entity that enables customers to share financial information from participating Financial Information Providers (‘FIPs’), such as banks, with authorised Financial Information Users (‘FIUs’), such as lending NBFCs however Sharing of Financial Data requires the customer’s explicit consent. The AA does not lend or make the credit decision, and it does not see or store the underlying financial information. 

For a retailer seeking working capital, consented bank transactions can help an NBFC assess receipts, payment cycles, seasonality and repayment capacity. These insights can supplement bureau records and financial statements. Their usefulness depends on account coverage, data quality and the proportion of business activity reflected in the banking system. Traditionally, data from credit bureaus (i.e. all four CICs) are relied heavily on to make lending decisions, but now, with all financial information in one place, a prudent decision can not only be made in quick time but also improve the quality of credit for lenders.  

Two connectivity gaps that interoperability addresses

On the demand side, the lender’s contracted AA may differ from the AA holding the customer’s Virtual User Address (VUA), or AA handle. Requiring another registration creates friction and multiple handles. The proposed discovery process allows an existing handle at another AA to be located and used. Where multiple handles are returned, the customer should be able to choose a preferred handle.

On the supply side, the customer’s AA may not be directly connected to all relevant FIPs. The draft proposes reaching an unconnected FIP through another AA that already has that connection. This can expand usable coverage without requiring every FIP to establish a separate direct connection with every AA. Availability still depends on participating institutions being ready for interoperability. 

Information and consent in the existing framework

A direct relationship connects the FIU to its contracted AA and that AA to the participating FIP. The borrower grants consent at the AA; the FIP supplies only the permitted information.

Figure 1. Existing direct AA framework. The same AA manages the customer consent and connects the lender with the FIP. Limited direct connectivity can restrict available coverage. 

Information and consent in the interoperable framework

The proposed Sahamati design adds gateway roles across AAs. This illustration shows both demand-side and supply-side transit; a direct connection can omit the corresponding intermediary.

Figure 2. Proposed interoperable route. Consent remains at the Customer AA. The Connected AA provides demand-side transit; the Inter AA provides supply-side transit. 

The connectivity graph and registry support routing, identity and keys; they do not carry customer financial information. User discovery, account linking and bank authentication precede or support these flows and are not shown. This is a working-draft design, subject to final specifications.

A federated design with consent at the customer AA

Sahamati proposes federation among AAs rather than routing all traffic through a central switch. Each AA retains its core consent-management functions and adds two gateway roles: a Demand Gateway for FIU-side interactions across AAs, and a Supply Gateway for access to FIPs through another AA. These are functions within an AA deployment, rather than new regulated participant categories.

The lender’s contracted AA acts as the Connected-AA. The AA holding the borrower’s handle acts as the Customer-AA and remains the consent manager of record. The same Customer-AA is the Origin-AA when requesting information from FIPs. An Inter-AA provides transit where the Origin-AA lacks a direct FIP connection. 

The borrower should retain control

A borrower who already has a handle with the lender’s AA continues through that AA; a borrower with a handle elsewhere can use the existing AA; and a borrower with no handle is directed to fresh onboarding. Interoperability therefore seeks to support existing relationships while accommodating new customers. 

An existing consent maintained by the Customer-AA should not be treated as blanket authorisation for other AAs. Where a Connected-AA merely relays encrypted messages without changing the authorised FIU, purpose, information scope or validity period, its involvement may not, by itself, require a fresh consent artefact. However, the Customer-AA must assess whether the existing consent, customer agreement and disclosures accommodate such intermediary routing under the applicable interoperability requirements. Fresh customer approval must be obtained where the proposed arrangement exceeds the original authorisation. Any necessary update to contractual terms or disclosures should be distinguished from renewal or replacement of the consent artefact.

Why this matters for retailers and MSME lending

Higher application completion. Allowing a retailer to use an existing AA handle can remove a repeat registration step. Better FIP reach can also reduce journeys that fail because the selected AA lacks a bank connection. These are concrete routes to reducing abandonment, although the impact must be measured in production.

A more complete view of cash flows. A retailer may receive sales collections in one bank and pay suppliers or service debt from another. Wider connectivity can help the NBFC obtain a more representative picture, subject to the borrower consenting to share the relevant accounts. Underwriting should distinguish sales receipts from transfers between accounts and avoid treating every credit as business turnover.

Faster decisions and lower processing costs. Automated retrieval can reduce statement collection, manual verification and follow-up work. Retaining existing AA relationships while extending reach can reduce pressure for repeated integrations. 

More suitable working-capital products. Better visibility into collections, supplier payments and seasonal variation can support inventory finance, cash-flow-based limits and repayment schedules aligned with business activity. The NBFC must still assess affordability, fraud risk, existing obligations and the limitations of the available data.

Lending economics and cost of funding

The direct economic opportunity is lower friction per completed loan. NBFCs should compare processing savings and additional completed applications against data charges, integration expenditure, support costs and credit outcomes. 

Interoperability does not directly reduce an NBFC’s borrowing rate. Better underwriting and demonstrably stronger portfolio performance may, over time, support discussions with banks, co-lending partners and securitisation investors. Any funding benefit depends on realised credit performance, the NBFC’s financial position and market conditions.

How NBFCs should prepare

First, agree with a readiness plan with AA partners covering discovery, customer selection of handles, redirection to an unconnected Customer-AA, encrypted transit, callback handling and key management. The draft explicitly lists these FIU changes. Its principle of least change should be understood as limiting disruption, rather than eliminating implementation work. 

Second, test complete journeys for borrowers with a local handle, a handle at another AA and no handle. Include multiple handles, partial account coverage, failed callbacks and permitted failover. Establish clear operational responsibilities, service levels and escalation routes across the participating entities.

Third, pilot defined retailer cohorts and compare completion rates, decision turnaround, cost per disbursal and subsequent credit performance. Preserve KYC, fraud controls, consent restrictions and applicable lending requirements. Scale only when connectivity improvements produce measurable customer and portfolio benefits.

Implementation status and conclusion

ReBIT published the technical API specifications for Account Aggregator interoperability on 14 October 2026 and subsequently revised the adoption deadline from 31 December 2026 to 1 December 2026. AAs, FIPs and FIUs should align their implementation with the published specifications and applicable RBI Directions. Existing customer consents must also be assessed to ensure that intermediary routing remains within the original authorisation; interoperability does not create blanket consent across AAs.

For NBFCs, interoperability offers an opportunity to reduce borrower friction, broaden access to consented financial information and strengthen cash-flow-based retailer lending. Its practical benefits will depend on participant readiness, reliable connectivity, effective consent controls and disciplined underwriting. Lower processing costs and improved conversion should be validated through pilots, while any funding advantage will depend on demonstrated portfolio performance.

References

[1] Sahamati, AA Interoperability Functional description and API specification. Supplied PDF titled Interoperability_AA Categories_by Sahamati.pdf, 50 pages. Working draft for technical review, September 2026

[2] Reserve Bank of India, Account Aggregator Facility. Public explanation of secure sharing and the AA’s inability to see or store financial information. https://rbikehtahai.rbi.org.in/AccountAggregatorFacility.html

[3] Department of Financial Services, Government of India, Account Aggregator Framework. Overview of the RBI-regulated framework and the requirement for explicit customer consent. https://www.financialservices.gov.in/account-aggregator-framework