When Banks Share Customer Data With Fintechs: Who Is Legally Responsible When Things Go Wrong?

A customer applies for a personal loan through a fintech app. The fintech collects her details and passes them to the partner bank, which approves the loan. The data then moves to a cloud provider that hosts the bank's systems, to a credit analytics vendor that scores the application and, eventually, to a collection agency. If that data leaks at any point in the chain, the customer is unlikely to know which of these entities was at fault. Indian law, however, will expect someone to answer for it.

The short answer is that the bank or NBFC which decides why and how the customer's data is processed will usually bear primary legal responsibility, both under the Digital Personal Data Protection Act, 2023 ("DPDP Act") and under the Reserve Bank of India's expectations for outsourcing. A fintech, cloud provider or vendor acting purely on the bank's instructions is a data processor whose obligations arise mainly through contract. However, a fintech which uses the same data for its own purposes may itself become a data fiduciary, with direct statutory obligations. Hence, the allocation of risk between these parties depends heavily on how their relationship is structured and documented.

This article examines how the DPDP framework interacts with the RBI's requirements when regulated entities share customer data, explains the distinction between data fiduciaries and data processors, and sets out how liability, audit rights, incident reporting and data deletion should be addressed in commercial agreements. It is written for banks, NBFCs, fintechs, technology vendors and their advisers, many of whom will need to revisit existing outsourcing arrangements before the DPDP framework's substantive obligations take effect in May 2027.

The Two Rulebooks: DPDP and RBI

Regulated entities sharing customer data now operate under two overlapping frameworks, which approach the same problem from different directions.

The DPDP Act is a general data protection law. It regulates the processing of digital personal data by all organisations and enforces compliance through the Data Protection Board of India. The Digital Personal Data Protection Rules, 2025 were notified on 13 November 2025 and are being brought into force in phases. The provisions establishing the Board took effect immediately, the consent manager framework applies from November 2026, and the core obligations of data fiduciaries, including security safeguards, breach notification and erasure, apply from May 2027.

The RBI's framework is sectoral and prudential. Its directions on outsourcing of information technology services, issued in 2023, make clear that outsourcing does not reduce a regulated entity's obligations, and require its contracts with service providers to cover oversight, access, audit and business continuity. Its digital lending directions require lenders and their lending service providers to collect only the data that is needed, with the borrower's explicit consent, and to store it in India. On 15 July 2026, the RBI went further and released a Draft Guidance on Regulatory Expectations for Data Governance, which calls for a board-approved, enterprise-wide data governance framework and expects regulated entities to track where their data goes and who handles it, including lending service providers, cloud platforms, KYC vendors and analytics firms.

The two frameworks are complementary rather than alternative. Compliance with RBI directions does not discharge DPDP obligations, and compliance with the DPDP Act does not satisfy the RBI's supervisory expectations.

Data Fiduciary or Data Processor: Why the Label Matters

Under the DPDP Act, a data fiduciary is any person who, alone or in conjunction with others, determines the purpose and means of processing personal data. A data processor is a person who processes personal data on behalf of a data fiduciary. The distinction carries significant consequences:

1. Responsibility stays with the fiduciary. Section 8(1) makes the data fiduciary responsible for complying with the Act in respect of any processing undertaken by it or on its behalf by a data processor, irrespective of any agreement to the contrary.
2. Processors must be engaged under a contract. Under Section 8(2), a data fiduciary may engage a data processor only under a valid contract.
3. Security and breach obligations sit with the fiduciary. The fiduciary must protect personal data in its possession or under its control, including data processed by a processor, through reasonable security safeguards, and must notify the Board and each affected data principal of a personal data breach.
4. Erasure must reach the processor. The fiduciary must erase personal data once its purpose is served, unless retention is required by law, and must cause its processors to do the same.

Thus, a bank cannot contract its way out of DPDP responsibility by pointing to a vendor. What it can do is ensure that the vendor bears the financial and operational consequences of its own failures.

The harder question is classification. A cloud provider hosting a bank's core banking system is plainly a processor. A fintech acting as a lending service provider that collects data solely to originate loans for the bank may also be a processor. However, if that fintech uses the same data to cross-sell its own products, to build its own credit models or to share it with other lenders, it is determining its own purposes and is likely to be a data fiduciary in respect of that processing. In practice, many fintech partnerships involve both roles, and the contract should say so expressly rather than leave the classification to be argued after a breach.

Following the Data: Where Liability Sits at Each Stage

Returning to the loan application, the position at each stage of the chain is broadly as follows.

Two points follow from this. First, the bank's statutory exposure does not diminish as the chain grows longer, so each additional vendor increases its risk unless controls flow down through every contract. Second, the commercial terms of the largest vendors, particularly cloud providers, are often offered on a standard basis with limited liability, which may leave the bank carrying a statutory penalty far larger than anything it can recover.

What Happens When Something Goes Wrong

Consider a breach in which a fintech partner's misconfigured storage exposes loan applicants' records.

Under the DPDP Act, the bank as data fiduciary must notify the Data Protection Board and each affected customer, and under the DPDP Rules a detailed report must reach the Board within 72 hours of the fiduciary becoming aware of the breach. That timeline is achievable only if the fintech is contractually required to inform the bank immediately, and to supply the facts the bank needs. Separate reporting obligations may apply in parallel, as entities covered by the Computer Emergency Response Team (CERT-In) directions of April 2022 must report specified cyber incidents within six hours, and the RBI expects regulated entities to report cyber incidents to it promptly.

The financial stakes are considerable. The schedule to the DPDP Act provides for penalties of up to ₹250 crore for failing to take reasonable security safeguards to prevent a breach, up to ₹200 crore for failing to notify a breach, and up to ₹50 crore for other contraventions. These penalties are imposed on the data fiduciary. A bank which has a weak indemnity, a low liability cap or no audit trail against its fintech partner may therefore find itself bearing a penalty caused entirely by another party's failure.

Allocating the Risk in Commercial Agreements

Since statutory responsibility cannot be transferred, the contract is the bank's main tool for managing it. Existing outsourcing and partnership agreements should be reviewed against the following points:

1. Role and purpose. The agreement should state whether the partner acts as a processor, a fiduciary or both, describe the permitted purposes, and prohibit any use of the data for the partner's own purposes unless expressly agreed.
2. Liability and indemnity. Liability for data protection breaches should sit outside, or above, the general liability cap, and the indemnity should expressly cover regulatory penalties to the extent the law permits, investigation costs and customer compensation.
3. Security standards. The partner should be required to maintain safeguards at least equivalent to those the DPDP Rules require of the fiduciary, including encryption, access controls and the retention of logs for at least one year.
4. Incident reporting. The partner should notify the bank of any actual or suspected breach within hours, not days, so that the bank can meet its own 72-hour, CERT-In and RBI obligations.
5. Audit and access. The bank, its auditors and the RBI should have rights of access and audit over the partner's systems and sub-processors, consistent with the RBI's outsourcing directions.
6. Sub-processing. Onward transfers to sub-contractors should require the bank's prior approval and back-to-back terms.
7. Deletion and return. The agreement should set out when the partner must delete or return data, how deletion is certified, and how this interacts with retention periods that banking and anti-money laundering laws impose on the bank.
8. Localisation and cross-border transfers. The contract should reflect RBI storage requirements, such as those for digital lending and payment system data, and any restrictions the Central Government may impose on transfers abroad under the DPDP Act.

Why Existing Outsourcing Arrangements Need Revisiting Now

Many current outsourcing and fintech partnership agreements were drafted before the DPDP Act, around RBI requirements and general confidentiality obligations. They often treat data protection as one item within a broader confidentiality clause, subject to the same liability cap as the rest of the contract, with incident reporting periods measured in days and no clear position on deletion.

The May 2027 deadline may appear distant, but renegotiating dozens of vendor agreements, particularly with large cloud providers and fintech partners with their own commercial leverage, takes time. In addition, the RBI's draft data governance guidance signals that supervisors will look for evidence of control over third-party data flows, and regulated entities are likely to pass those expectations down to their partners through contracts and audits. Hence, banks and NBFCs which begin reviewing their agreements now will be in a far stronger position than those which wait for the deadline or, worse, for a breach.

Practical Takeaways

1. Map the data flows first. Identify every partner which receives customer data, what it receives and what it does with it.
2. Classify each relationship. Decide whether each partner is a processor, a fiduciary or both, and reflect that in the contract.
3. Separate the data protection cap. Ensure that liability for data breaches is not confined to a general cap set for ordinary commercial risk.
4. Align reporting timelines. Build incident reporting obligations around the shortest regulatory deadline the bank faces.
5. Plan for deletion. Set clear rules for deletion and return, and reconcile them with legal retention requirements.
6. Start renegotiation early. Prioritise the partners holding the largest volumes of sensitive data, particularly lending, KYC and cloud providers.

Conclusion

So, who is legally responsible when shared customer data goes wrong? In most cases the bank or NBFC, as data fiduciary, will answer to the Data Protection Board and to the RBI, whichever entity in the chain actually caused the failure. A fintech or vendor which processes data on the bank's behalf will usually answer to the bank through contract, while one which uses the data for its own purposes may face direct statutory liability as well. Thus, the real question for regulated entities is not whether they can avoid responsibility, but whether their agreements ensure that the partner at fault bears the consequences. With the substantive DPDP obligations taking effect in May 2027 and the RBI sharpening its expectations on data governance, the time to answer that question is before a breach occurs.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.