Account Aggregator Framework and Commercial Insurance Integration India

The Account Aggregator (AA) framework was established by RBI under the Master Direction on Non-Banking Financial Company - Account Aggregator (Reserve Bank) Directions, 2016, effective September 2021 in its operational form. It is a consent-based financial data sharing infrastructure that allows individuals and businesses to share their financial data (held at one financial institution) with another financial institution, for a purpose they have specifically consented to, for a time period they have defined. It does not allow any party - including the AA itself - to access or store the data beyond what the consent specifies.

The three actors in the AA ecosystem are the Financial Information Provider (FIP), the Financial Information User (FIU), and the Account Aggregator. The FIP is the institution that holds the customer's financial data - a bank (SBI, HDFC Bank), an NBFC, a mutual fund, or a goods and services tax (GST) authority. The FIU is the institution that wants to access the data - a lender, an insurer, or another regulated entity with a specific, consented purpose. The AA sits in the middle: it receives consent instructions from the customer, requests the data from the FIP on the customer's behalf, encrypts and transmits it to the FIU, and maintains a consent artefact as the audit trail.

The AA framework is implemented through a technology standard developed by Sahamati, the industry body for AA ecosystem participants. The standard specifies the API formats for FIP-AA-FIU communication, the consent artefact format (what information a consent request must contain), and the data schemas for different financial data types. As of 2026, the data types available through the AA framework include: bank account statements, mutual fund statements, insurance policy data (as maintained by IRDAI-designated FIPs), tax return data (ITR), GST return data (from GSTN), pension account data (from NPS Trust and EPFO), and securities holding data (from CDSL and NSDL).

The critical regulatory feature is that the AA itself cannot read, store, or use the data it transmits. It is a 'blind' intermediary: it encrypts data at the FIP, transmits it to the FIU in encrypted form, and cannot decrypt it. This architecture addresses the data privacy concern that arises when a centralised data broker has access to sensitive financial data. The DPDP Act, 2023 treats the customer as the 'data principal' with the right to grant, modify, and revoke consent for data sharing through the AA - consent management under the DPDP Act and consent management under the AA framework are designed to be aligned.

IRDAI is one of the financial regulators that has formally engaged with the AA framework, both as a regulator (setting rules for how insurers may participate as FIUs) and as a data user for regulatory supervision. Under the AA framework, insurers are permitted to become FIUs - entities that access a customer's financial data from FIPs, with consent, for underwriting and claims purposes.

IRDAI's interest in the AA framework is primarily driven by the underwriting efficiency opportunity for SME commercial insurance. The central challenge in SME commercial insurance underwriting in India is information asymmetry: the SME applicant typically has financial data held at its bank (cash flows, revenues, overdraft patterns) and the GST authority (turnover, tax compliance), but providing this data to an insurer involves physical document submission, manual extraction, and reconciliation - a process that takes days and is prone to error and fraud. The AA framework allows the insurer-FIU to request this data directly from the SME's bank (FIP) and GSTN (FIP) through the AA, with the SME's consent, in seconds and in a machine-readable format.

IRDAI's exposure draft on using AA data for insurance underwriting (issued in late 2024) specifies the categories of AA data that insurers may request for different insurance products. For a commercial property insurance proposal from an SME, the insurer may request: 12 months of bank account statement data (to assess turnover and cash flow stability), GST returns for the last 8 quarters (to verify declared turnover), and ITR for the last 2 years (to verify business income and asset values). For a trade credit insurance underwriting on a buyer, the insurer may request the buyer's bank statements and GST data through the AA framework to assess payment behaviour and financial health.

The key constraint is consent: the SME must actively consent to each data request, for a specified purpose (underwriting of a specific policy) and a specified duration (the underwriting decision period, not ongoing). An insurer cannot use AA data collected for underwriting purposes to assess the same company's creditworthiness for a different product without a separate consent - this purpose limitation is enforced by the consent artefact format and by the DPDP Act's purpose limitation principle.

For SME commercial insurance underwriting, the three most valuable data types flowing through the AA framework are bank account statements, GST returns, and income tax returns. Each provides a different dimension of the risk picture, and the combination of the three substantially reduces the information asymmetry that has historically made SME insurance underwriting in India expensive and inaccurate.

Bank account statement data (12-24 months) provides the most granular picture of actual cash flows. For a manufacturing SME, the bank statement reveals the pattern of raw material purchases, the regularity of customer receipts, the peak and trough positions, and any signs of financial distress (repeated overdraft violations, dishonoured cheques, irregular creditor payments). For an insurer pricing a business interruption policy, the bank statement is the most accurate basis for calculating the maximum indemnity period loss, which is typically the most contested element of a BI claim. Accessing this data through the AA framework (rather than through the SME's broker submitting paper statements) eliminates the risk of the SME submitting selectively favourable periods or inadvertently providing incomplete data.

GST return data (GSTR-1, GSTR-3B) flowing through GSTN-as-FIP provides independently verified turnover figures. GSTN became an FIP in the AA framework in 2023, and the availability of GST data has been particularly significant for SMEs that do not have audited financials for recent periods (a common situation for MSMEs with turnover below the audit threshold). For a fire insurance underwriting, the insurer needs to verify declared stock values and turnover to assess the adequacy of sum insured; GST data provides a cross-check that was previously unavailable without a formal audit. The declared GST turnover also serves as a baseline for the 'average clause' assessment if the sum insured is found to be deficient at the time of a claim - a major source of disputes in fire claims in India.

ITR data (from the Income Tax Department as FIP, available through the CBDT-integrated AA mechanism introduced in 2024) provides historical income, asset depreciation schedules, and profit and loss information that are valuable for property insurance underwriting and for directors and officers liability underwriting. For a D&O policy covering an SME's directors, the ITR data of the company reveals the financial trajectory and any unusual transactions that might signal governance concerns - an underwriting factor for which the insurer previously had to rely entirely on self-declared information.

The speed improvement from AA-based data access is material. A traditional commercial insurance proposal involving manual document collection, verification, and underwriting assessment takes 5-15 working days for an SME. AA-based data access reduces the data collection phase to minutes (once consent is granted), with the balance of the underwriting timeline devoted to analysis and decision-making. This speed improvement is not merely an operational convenience: faster underwriting means the insurer can offer shorter quote validity periods, reducing its pricing risk in volatile markets, and the SME gets coverage faster, which is commercially important when the SME needs insurance to satisfy a bank's loan disbursement condition.

The intersection of the AA framework's consent architecture and the DPDP Act, 2023's consent requirements creates a governance layer that insurance companies must navigate carefully. The two consent regimes are not identical, and using AA data for insurance underwriting and claims without full compliance with both creates legal exposure.

The AA framework's consent architecture is technically sophisticated. Every AA data transaction is governed by a consent artefact - a structured, machine-readable record that specifies: the customer (identified by their AA handle, analogous to a UPI ID), the FIP (the bank or GSTN that holds the data), the FIU (the insurer requesting the data), the data type and period (e.g., bank statements for January 2024 to December 2024), the purpose (e.g., underwriting of fire insurance policy), the frequency of access (one-time or recurring), and the expiry of consent. The consent artefact is cryptographically signed by the customer and stored by the AA. It cannot be modified after creation; any change to the consent terms requires a new consent artefact.

The DPDP Act's consent requirements (Section 6) require that consent for processing personal data must be free, specific, informed, unconditional, and given through a clear affirmative action. The AA consent artefact is substantially compliant with these requirements - it is specific (identifying the exact data type and period), informed (the customer is presented with the full details of what is being requested and why), and requires affirmative action (the customer must actively consent through their AA app or portal).

However, there are two areas where insurance companies must take additional steps to ensure DPDP Act compliance alongside AA framework compliance. First, the purpose specification in the consent artefact must align with the DPDP Act's requirement that the purpose be explicitly stated. A consent artefact that says 'insurance underwriting' is too generic; it must specify 'underwriting assessment for [specific product] application dated [date]'. Second, the right of the data principal (SME) to withdraw consent under DPDP Act Section 6(4) must be operationalised alongside the AA framework's consent revocation mechanism. If an SME revokes its AA consent during the underwriting process, the insurer must stop using the data already received and delete it - the DPDP Act's erasure obligation applies even if the AA framework has technically fulfilled the data delivery.

For insurers building AA data pipelines into their underwriting systems, the practical implication is that the consent journey presented to the SME must explain both the AA framework's consent mechanism and the DPDP Act's processing purpose and rights in a single, clear, plain-language interface. Separate disclosures presented sequentially ('first consent to the AA, then consent to DPDP processing') are confusing and increase drop-off rates. A well-designed combined consent interface that satisfies both regulatory requirements simultaneously is an area where insurer technology teams and compliance functions need to collaborate.

The AA framework's value for insurance is not limited to underwriting; it extends to claims verification, which is an equally information-intensive process where data asymmetry between claimant and insurer creates disputes and delays.

Premium payment history is the first claims use case. When a commercial policyholder makes a claim, the insurer must verify that all premiums have been paid and that the policy is in force. Under the traditional paper and bank transfer process, premium payment verification involves cross-referencing the insurer's premium ledger against the policyholder's remittance records - a process that can take days for policies with multiple installment payments or for group policies covering hundreds of sub-locations. Through the AA framework, the insurer can (with consent from the policyholder at the time of claim initiation) pull the policyholder's bank statement for the premium payment period and verify payment in minutes.

Asset value confirmation is the second claims use case. For a commercial property insurance claim, the declared sum insured at the time of policy placement must be verified against the actual value of the asset at the time of loss. In an inflationary environment (construction costs in India rose approximately 8-12% annually from 2022 to 2025), assets insured at values established three years earlier are likely underinsured. The average clause, which reduces claim payments proportionately where the sum insured is below actual value, is one of the most disputed provisions in Indian commercial insurance. AA data - specifically, the depreciation schedules and asset values declared in ITR filings - provides an independently sourced asset value that can serve as a cross-check on the surveyor's reinstatement value estimate. If the ITR data shows that the policyholder has been depreciating assets on a cost basis that substantially exceeds the insured sum, the insurer has a documented basis for applying the average clause.

Financial health verification at claim time is particularly relevant for business interruption claims. A BI claim requires the insurer to calculate the policyholder's pre-loss revenue or profit rate, which is then used to compute the indemnity for the period of interruption. The policyholder presents its own financial records to support the pre-loss rate claim. Through the AA framework, the insurer can cross-check the presented financials against bank statement data and GST return data from the same period - a verification step that takes hours rather than weeks and provides the insurer with an independently sourced baseline for the BI calculation. This reduces the scope for inflated BI claims while also protecting legitimate claimants by providing an objective data basis that speeds the settlement process.

The claims use of AA data requires fresh consent from the policyholder at the time of the claim, separate from any consent given during underwriting. The claims consent artefact should specify that the data is being accessed for the purpose of processing a specific identified claim - not for general monitoring or policy renewal purposes. This scope limitation is both a DPDP Act requirement and good practice for managing the policyholder relationship.

While the AA framework creates significant data availability for insurance underwriting, there are specific regulatory constraints on how this data can be used in pricing that insurance companies must understand and respect.

The first constraint is the prohibition on algorithmic discrimination. IRDAI's Product Filing Guidelines require that insurance pricing not be based on factors that IRDAI considers discriminatory or arbitrary. Using AA data to price insurance on the basis of payment patterns that are correlated with sensitive characteristics (religion, caste, region of origin) would violate IRDAI's anti-discrimination norms even if the correlation is statistically observable. Insurers must ensure that the AA data features used in pricing models are actuarially justified and do not serve as proxies for protected characteristics.

The second constraint is the 'filed rates' regime. IRDAI's de-tariffing of most non-life insurance lines in 2007 gave insurers freedom to price, but pricing must be consistent with filed rates and rating guidelines submitted to IRDAI. An insurer that uses AA data to charge significantly different rates to two SMEs with identical declared risk characteristics (same occupancy, same sum insured, same location) but different bank statement patterns may be required to justify the differential in terms of its filed rating methodology. If the differential is not captured in the filed guidelines, the insurer is technically pricing outside its filed rates - a regulatory compliance issue.

The third constraint concerns the use of AA data for mid-term policy adjustments. If an insurer accesses a policyholder's bank account data through the AA on an ongoing consent basis (rather than a one-time consent at underwriting) and uses adverse changes in the financial data to cancel the policy or refuse renewal, this creates both a regulatory concern (IRDAI's policyholder protection regulations impose constraints on mid-term cancellations and renewal refusals) and a DPDP Act concern (the ongoing data access consent must have been clearly granted for this purpose at the time of policy inception). Ongoing monitoring of policyholder financial data through the AA, without explicit consent for that specific purpose, would be a DPDP Act violation regardless of how valuable the monitoring data might be for the insurer.

The fourth constraint is the sector-specific requirement that IRDAI has imposed on the use of third-party data in commercial underwriting: all data sources and their contribution to the rating decision must be documentable, auditable, and explainable to the policyholder if requested. An insurer that uses AA bank statement data as a black-box input to a machine learning pricing model, without being able to explain which features of the bank statement drove the premium level, may face regulatory challenge from IRDAI if the policyholder disputes the pricing and IRDAI investigates.

The Open Network for Digital Commerce (ONDC) - operated by the ONDC Network, a Section 8 not-for-profit set up with support from the Department for Promotion of Industry and Internal Trade and DPIIT - is creating a new digital commerce infrastructure that intersects with the AA framework in ways that are directly relevant to commercial insurance.

ONDC is an open protocol network (analogous to UPI for commerce) that allows any buyer app and any seller app to transact with each other without being locked into a single proprietary marketplace. Insurance distribution is one of the verticals that ONDC has opened: IRDAI-licensed insurance companies and brokers can list products on the ONDC network, and buyer apps (banks, fintech apps, commerce platforms) can surface insurance products to their users within the ONDC framework.

The AA-ONDC intersection is at the underwriting and policy customisation layer. When an SME buyer on the ONDC network is purchasing commercial insurance, the ONDC buyer app can (with the SME's consent) pull AA data - bank statements, GST returns - and present it to the insurance FIU on the ONDC seller side. This creates a frictionless, data-enriched insurance purchase journey within the ONDC commerce flow: the SME gets a quote that is based on its actual financial data rather than self-declared estimates, and the insurer gets verified data without a separate data collection exercise.

For embedded insurance use cases on ONDC - for example, a seller on the ONDC network automatically getting cargo insurance for each shipment - the AA framework provides a mechanism to verify the seller's transaction history and financials for pricing the embedded cover without requiring the seller to complete a separate insurance proposal. This is particularly valuable for high-frequency, low-value commercial insurance (transit cover, trade credit insurance for individual invoices) where the cost of a traditional proposal process would make the insurance commercially unviable.

The regulatory framework for AA-ONDC insurance transactions is still developing. IRDAI's web aggregator regulations (IRDAI Insurance Web Aggregators Regulations, 2017) and the Insurance Broking Regulations, 2018 were not designed with the ONDC protocol architecture in mind, and IRDAI is working on a framework for 'ONDC insurance participants' that addresses the distribution, disclosure, and advice obligations of the various entities in an ONDC insurance transaction. Until this framework is finalised, insurance transactions on ONDC operate under the existing distribution licensing framework, with buyer apps required to obtain appropriate IRDAI licences or to partner with licensed intermediaries.