Open banking, as a concept, changes how financial data is accessed, shared, and utilised. It enables customers to permit banks and other financial institutions to share their account and transaction data with third-party providers through secure Application Programming Interfaces (APIs). This transition moves financial services away from institution-centric data silos toward a user-authorised, networked data environment. 

In India, open banking is not the product of a single statute or mandate. Instead, it has emerged through a combination of digital public infrastructure, regulatory experimentation, and consent-based governance mechanisms. While this framework has accelerated innovation and financial inclusion, it has also introduced new risks across the data supply chain. APIs while efficient expose sensitive financial data to multiple actors, increasing the surface area for security breaches, misuse, and regulatory non-compliance. Managing these risks has become a central concern for regulators, banks, fintech firms, and users alike. 

Why Open Banking and API Security Have Gained Regulatory Attention 

Open banking has entered regulatory focus globally due to the scale at which sensitive financial data is now exchanged across institutional boundaries. In October 2024, the U.S. Consumer Financial Protection Bureau issued its final Personal Financial Data Rights Rule under Section 1033 of the Dodd-Frank Act, formally recognising open banking as a core use case for data portability. Similarly, Europe’s PSD2 regime offers a useful case study in calibrated, risk-based financial data governance rather than blanket deregulation. The Revised Payment Services Directive (PSD2), implemented across the European Union in 2018, mandates banks to share customer account data with licensed third-party providers (TPPs) only with explicit user consent. This access is channelled exclusively through secure APIs, supervised by national regulators and coordinated at the EU level by the European Banking Authority (EBA). Crucially, PSD2 does not treat data-sharing as an absolute right of fintech firms; instead, it embeds strong customer authentication (SCA), liability allocation for unauthorised transactions, and regulatory licensing as preconditions. The core inference from the European Union’s PSD2 framework formally, the Revised Payment Services Directive is that interoperability in financial data sharing cannot be left to spontaneous market coordination; it must be legally structured and institutionally supervised. PSD2 does not merely promote open access to banking data. Rather, it constructs a regulated ecosystem in which access is conditional, standardised, and monitored. 

The broader lesson is that innovation and stability are not opposites. PSD2 rejects the binary between openness and control by demonstrating that data portability works only when accompanied by enforceable technical standards, defined liability regimes, and institutional supervision. For jurisdictions such as India contemplating open banking models, the takeaway is clear: trust in financial data ecosystems emerges from legal architecture, not deregulated competition. 

In India, the issue has gained renewed relevance following the enactment of the Digital Personal Data Protection Act, 2023. The DPDP Act establishes a statutory foundation for consent-based data processing and introduces the concept of Consent Managers across sectors. This coincides with the rapid expansion of India’s Account Aggregator (AA) ecosystem, which has processed over 140 million consent requests by December 2024.  

Evolution of Open Banking and Data Governance in India 

India’s open banking framework rests on a distinct institutional trajectory. Early data protection norms under the Information Technology Act, 2000 were limited in scope. India developed the Data Empowerment and Protection Architecture (DEPA), conceptualised by NITI Aayog in 2020. DEPA operationalises consent as a technological and governance mechanism, enabling individuals to control how their data is shared. Within the financial sector, this vision materialised through the RBI-regulated Account Aggregator framework. Unlike traditional data-sharing models, AAs neither store nor process financial data; they function as neutral intermediaries facilitating consent-driven data transfers between Financial Information Providers and Financial Information Users. 

This layered approach constitutional recognition of privacy, statutory data protection, and infrastructure-level consent systems distinguishes India’s open banking model from purely mandate-driven regimes. 

Legal Architecture Governing Open Banking APIs 

The DPDP Act establishes consent as the lawful basis for personal data processing, subject to principles of purpose limitation, data minimisation, storage limitation, and security safeguards. For open banking, this means that financial data accessed via APIs must be processed strictly for specified purposes authorised by the data principal. The Act also mandates data protection by design and default, placing technical and organisational obligations on entities handling personal data. 

The introduction of Consent Managers under the DPDP Act is particularly significant. This framework aligns closely with the existing AA model in finance, suggesting regulatory convergence rather than duplication. The Act’s emphasis on revocable, granular consent directly addresses risks arising from persistent or overbroad data access. 

RBI’s Account Aggregator Directions 

Issued in 2016, the RBI’s NBFC-AA Directions regulate the core operational aspects of financial data sharing. AAs operate under strict licensing conditions, enforce end-to-end encryption, and are prohibited from monetising or retaining data. Consent mechanism are central to this framework, ensuring traceability and auditability of data flows. 

From an API security perspective, the AA system reduces reliance on insecure practices such as screen scraping, replacing them with standardised, authenticated API interactions. This significantly lowers credential exposure risks and improves accountability across the data supply chain. 

International Regulatory Benchmarks 

Globally, PSD2 in the European Union mandates strong customer authentication and restricts data access to licensed third-party providers. The GDPR supplements this by imposing strict obligations on data controllers and processors, including breach notification and data subject rights. Australia’s Consumer Data Right extends similar protections beyond finance, while the U.S. Section 1033 rule introduces use-limitation obligations for fintechs without extending full GLBA coverage. 

These frameworks show that open banking must be accompanied by enforceable API security standards, defined accountability, and limits on secondary data use. 

API Security as a Systemic Risk Vector 

APIs are foundational to open banking but introduce unique security vulnerabilities. Unlike conventional web interfaces, APIs expose business logic and sensitive objects directly. The OWASP API Security identifies recurring risks such as broken object-level authorisation, improper authentication, unrestricted resource consumption, and unsafe consumption of third-party APIs. 

In the context of open banking, these risks translate into concrete threats:  

• Unauthorised access to account data, excessive data extraction,  

• Automated abuse of payment initiation services,  

• Downstream misuse of financial information.  

The interconnected nature of open banking amplifies these risks, as a single weak link whether a fintech application or aggregator can compromise the entire data supply chain. 

Gaps in the Current Open Banking Security Framework 

Despite institutional design, several gaps persist. First, uneven adoption among financial institutions results in fragmented data availability and inconsistent API performance. Second, variations in data standards such as transaction timestamps and descriptors undermine reliability and increase operational risk. Third, users often struggle to fully comprehend consent scopes, raising concerns about meaningful consent and potential overreach by data users. 

From a security standpoint, not all participants demonstrate uniform maturity in API governance. Smaller fintechs may lack resources for continuous security testing, while legacy institutions may struggle with scalability. Additionally, the absence of explicit statutory guidance on permissible secondary uses of financial data under the DPDP Act, beyond “reasonably necessary” processing, creates interpretive uncertainty. 

Strengthening Risk Mitigation Across the Data Supply Chain 

Enhancing API security in open banking requires a multi-layered approach. Technically, strong authentication mechanisms such as OAuth 2.0, mutual TLS, and tokenisation must be universally adopted. Schema validation, rate limiting, and real-time monitoring are essential to detect anomalous behaviour and prevent automated abuse. 

Conclusion 

Open banking has reshaped the flow of financial information within the digital economy where users are now at the heart of data management. India has anchored this change on a consent-based, infrastructure-based model backed by DPDP Act, DEPA and Account Aggregator model. Although this architecture has permitted a fast uptake and inclusion of finances it has also increased the significance of a sound API security.    

In reducing risks in the financial data supply chain, it is necessary to maintain law, technology interrelationship and institutional practice alignment. Secure APIs are treated as well as governance tools, not technical ones, but they operationalise privacy, consent, and accountability. With the maturity of India open banking ecosystem, ensuring that API security is reinforced with the help of established legal frameworks, interoperable frameworks, and conscious user control will be necessary to maintain the trust and long-term innovation.    

For any queries, Connect with us.