Four Laws, One Bank — The Compliance Overlap Problem Nobody’s Mapping

You have just been appointed Head of Compliance at a mid-tier licensed commercial bank in Sri Lanka. Congratulations. Your first task seems straightforward enough: build a data protection compliance programme for the organisation.

You start with the Personal Data Protection Act No. 9 of 2022. That seems like the obvious place to begin. You read through the Act, you identify the key obligations, and you start sketching a framework. Consent management. Data subject rights. Processing records. A Data Protection Officer appointment.

Then someone from IT sends you the Central Bank’s Technology Risk Management Framework. Then someone from Legal mentions the Banking Act’s secrecy provisions. Then the Head of Digital Banking asks about the new Fintech and Cyber Protection Rules. And suddenly your simple question — “how do we comply with data protection law?” — has become seven overlapping regulatory instruments, administered by at least four different regulators, with conflicting definitions, inconsistent timelines, and no clear hierarchy.

Welcome to the compliance overlap problem. Nobody is mapping it. Everybody is affected by it. And it is going to be one of the defining challenges of PDPA implementation in Sri Lanka.

The Myth of a Single Framework

There is a comforting fiction in the data protection community that the PDPA provides a single, unified framework for personal data protection in Sri Lanka. Read the Act. Comply with the Act. Done.

The reality is considerably more complicated.

Section 3 of the PDPA contains what lawyers call a “prevailing provision” clause. In the event of any inconsistency between the PDPA and any other written law, the provisions of the PDPA shall prevail. This sounds definitive. It sounds like the PDPA sits at the top of the regulatory hierarchy, and everything else falls in line beneath it.

But “inconsistency” is a narrow concept. Two regulatory frameworks can impose different requirements without being technically inconsistent. The PDPA can require you to do X, and the Banking Act can require you to do Y, and as long as doing both X and Y is possible, there is no inconsistency — even if doing both is expensive, operationally complex, and practically absurd.

The prevailing provision in Section 3 resolves direct conflicts. It does not resolve overlaps. And overlaps are where most of the compliance complexity actually lives.

The Banking Sector: A Case Study in Regulatory Stacking

If you want to understand the compliance overlap problem, start with banking. Not because banking is unique, but because banking is where the overlaps are most visible, most documented, and most expensive. A licensed commercial bank in Sri Lanka now faces at least four distinct regulatory layers that touch personal data.

Layer One: The Personal Data Protection Act No. 9 of 2022

This is the baseline. The PDPA applies to every organisation that processes personal data, and banks process an extraordinary amount of it. Customer identification data. Transaction records. Credit histories. Employment verification. Biometric data for digital onboarding. Location data from mobile banking. Communications metadata from customer service interactions.

The PDPA requires lawful bases for processing, data subject rights, processing records, Data Protection Impact Assessments for high-risk processing, Data Protection Officer appointments, breach notification, and cross-border transfer safeguards. Each of these obligations generates operational requirements that must be woven into existing banking processes.

Layer Two: The CBSL Framework on Customer Protection in Respect of Fintech and Cyber Protection Rules (FCPR)

In August 2023, the Central Bank of Sri Lanka issued its Framework on Customer Protection in Respect of Fintech and Cyber Protection Rules. This framework creates a parallel set of data-related obligations for financial institutions that goes well beyond what the PDPA requires.

The FCPR includes specific requirements around data collection disclosures, consent mechanisms for financial products, data sharing between financial institutions, customer complaint handling for data-related issues, and cybersecurity incident reporting. Some of these requirements overlap with the PDPA. Some go further. Some use different terminology to describe similar concepts. And some create obligations that have no equivalent in the PDPA at all.

Here is the critical point: the FCPR is not subordinate to the PDPA. It is issued under the Monetary Law Act and the Banking Act, which give the Central Bank independent regulatory authority. A bank must comply with both — and where the requirements differ, the bank must meet the higher standard.

Layer Three: The Banking Act No. 30 of 1988 — Section 77

Section 77 of the Banking Act creates a statutory duty of secrecy for licensed banks. No director, officer, or employee of a bank shall disclose information relating to any account, deposit, or loan of any customer except in specific circumstances authorised by law.

This is older legislation. It predates the PDPA by decades. But it has not been repealed or amended to align with the PDPA, which creates genuine operational tensions.

Consider a data subject access request under the PDPA. A customer asks for all personal data the bank holds about them. That data includes information about their accounts, deposits, and loans — which is exactly the information Section 77 restricts. Can the bank disclose this information to the data subject? Probably yes — the data subject is the customer, and the PDPA grants them access rights. But what about information that relates to the data subject but also involves third parties? What about joint account information? What about data generated through transactions with other institutions?

Section 77 was not drafted with data subject access rights in mind. The PDPA was not drafted with banking secrecy obligations in mind. Both are valid law. Both must be complied with. The interaction is left as an exercise for the reader — or rather, for the Head of Compliance.

Layer Four: The CBSL Technology Risk Management Framework — Direction No. 16 of 2021

Direction No. 16 of 2021 issued by the Central Bank establishes a comprehensive Technology Risk Management Framework for licensed banks. This framework includes detailed requirements around data classification, access controls, encryption standards, data retention, disaster recovery, and information security governance.

Many of these requirements interact with PDPA obligations. The PDPA requires “appropriate technical measures” to protect personal data — but does not specify what those measures are. Direction No. 16 does specify, in considerable detail. The PDPA requires data retention periods to be proportionate to processing purposes. Direction No. 16 specifies minimum retention periods for certain categories of technology-related records.

What happens when the PDPA says “delete data when no longer necessary” and Direction No. 16 says “retain technology logs for a minimum of five years”? Both are legally binding. Both apply to the same institution. And the compliance officer must navigate the gap.

The Telecoms Sector: A Different Kind of Overlap

Banking is the most complex case, but it is not the only one. The telecommunications sector faces its own version of the overlap problem, and in some ways it is even more acute.

The Telecommunications Regulatory Commission of Sri Lanka (TRCSL) has long been the primary regulator for the sector. The TRCSL issues licences, sets conditions, and enforces compliance. Historically, those licence conditions have included provisions about customer data — how it must be stored, when it can be shared, what security measures are required.

The Telecommunications Amendment Act No. 39 of 2024 added new provisions around data handling, customer consent, and information security that overlap with but are not identical to the PDPA’s requirements. The definitions are different. The consent standards are different. The enforcement mechanisms are different.

And then there is the fundamental tension between data minimisation and data retention. The PDPA’s data minimisation principle requires organisations to collect and retain only the personal data that is necessary for the specified processing purpose. But telecommunications operators face mandatory retention requirements — from TRCSL, from law enforcement frameworks, from the Telecommunications Act itself — that require them to retain customer communications metadata, sometimes for extended periods.

The impact of Part IV of the PDPA adds another dimension. Part IV governs direct marketing — and telecommunications operators are both subject to Part IV (in their own marketing activities) and enablers of Part IV compliance for other organisations (as the infrastructure through which SMS marketing, push notifications, and other electronic communications travel). The regulatory obligations as a data controller and as a data processor diverge significantly, and the TRCSL’s framework does not map neatly onto this distinction.

E-Commerce: The Newest Layer

Just when the overlap map seemed to be stabilising, a new layer appeared.

Direction No. 91, issued under the Electronic Transactions Act, establishes requirements for e-commerce operations that include specific data handling obligations. These obligations cover customer data collection, storage, processing, and cross-border transfer — all areas already governed by the PDPA.

Direction No. 91 was not drafted to align with the PDPA. It uses its own definitions, its own consent standards, and its own compliance requirements. For an e-commerce platform that is also regulated under the PDPA (which is every e-commerce platform), this creates yet another layer of requirements that must be mapped, reconciled, and operationalised.

The irony is that Direction No. 91 was issued with the goal of modernising Sri Lanka’s digital economy regulatory framework. But by adding requirements that overlap with rather than defer to the PDPA, it has made the compliance landscape more complex rather than less.

Where the Frameworks Diverge

Let me be precise about where these frameworks create genuine compliance challenges. The divergences cluster into five categories.

Scope Divergence

The PDPA applies to all personal data. The Banking Act’s secrecy provisions apply to account, deposit, and loan information. The FCPR applies to customer data in the context of fintech services. Direction No. 16 applies to technology-related records. Each framework covers a different (but overlapping) slice of the data a bank holds. Mapping a single customer record across all four frameworks — determining which obligations apply to which data elements — is itself a significant compliance exercise.

Definitional Divergence

The PDPA defines “personal data” broadly as any data relating to an identified or identifiable natural person. The FCPR uses “customer data.” The Banking Act uses “information relating to any account.” Direction No. 16 uses “information assets” and “technology records.” These are not synonymous terms. They do not cover the same scope. And they create different obligations for data that falls within one definition but not another.

Procedural Divergence

The PDPA specifies a breach notification procedure: notify the Authority, then notify affected data subjects if there is a risk to their rights and freedoms. The CBSL frameworks specify a different incident reporting procedure: notify the Central Bank within specified timeframes through specified channels. A bank that suffers a data breach must comply with both procedures simultaneously — different regulators, different formats, different timelines, different content requirements.

Enforcement Divergence

The PDPA is enforced by the Data Protection Authority. The Banking Act is enforced by the CBSL. The Telecommunications Act is enforced by the TRCSL. Direction No. 91 is enforced under the Electronic Transactions Act. Each regulator has its own enforcement powers, its own investigation procedures, its own penalty structures, and its own institutional culture. A single data incident can trigger parallel investigations by multiple regulators, each applying its own framework.

The Prevailing Clause Problem

Section 3’s prevailing clause resolves direct inconsistencies in favour of the PDPA. But as I noted earlier, most of these frameworks do not directly contradict the PDPA. They add to it. They complement it. They run alongside it. The prevailing clause does not help when the problem is not conflict but accumulation — when compliance means meeting the PDPA’s requirements and the CBSL’s requirements and the Banking Act’s requirements and the Technology Risk Management Framework’s requirements, all simultaneously.

The Institutional Coordination Problem

The regulatory overlap problem is not just a legal problem. It is an institutional problem.

The PDPA establishes a Data Protection Authority with broad jurisdiction over personal data processing. But the Central Bank of Sri Lanka has constitutional independence in its regulatory functions. The TRCSL has its own statutory mandate. These institutions do not have a formal coordination mechanism for data protection issues.

The difference between consultation and coordination matters enormously here. Consultation means one regulator asks another for its views before making a decision. Coordination means regulators jointly develop approaches, align their requirements, and present a unified framework to regulated entities. Sri Lanka currently has neither — but the sector desperately needs the latter.

The Central Bank’s independence is particularly relevant. The CBSL derives its regulatory authority from the Monetary Law Act and the Banking Act, not from the PDPA. It is not subordinate to the Data Protection Authority on matters within its regulatory mandate. If the CBSL issues a direction that creates data handling obligations for banks, and those obligations differ from what the PDPA requires, the resolution is not straightforward. Section 3 resolves “inconsistency,” but the CBSL could reasonably argue that its directions are not inconsistent with the PDPA — they are additional requirements issued under separate statutory authority.

This is not a theoretical concern. It is going to be a practical problem the moment a bank faces a situation where the CBSL’s expectations point in one direction and the Data Protection Authority’s expectations point in another. And it will be the bank — not the regulators — that bears the risk of getting the balance wrong.

Practical Guidance: Five Principles for Navigating the Overlap

The overlap problem is not going to be resolved quickly. Regulatory alignment takes years, even in jurisdictions with mature data protection frameworks. The EU is still working through its own sectoral overlap issues two decades after the original Data Protection Directive. Sri Lanka will need to develop its own approach, and that approach will evolve over time.

In the meantime, organisations that operate in regulated sectors need practical guidance. Here are five principles that I believe will hold regardless of how the regulatory landscape evolves.

Principle One: Map Before You Build

Before designing a compliance programme, map every regulatory framework that applies to your organisation’s data processing activities. Do not assume the PDPA is the only relevant framework. Do not assume your sector regulator’s requirements are subsumed by the PDPA. Map every obligation, from every source, against every data processing activity. The map will be messy. That is the point. You cannot navigate a landscape you have not charted.

Principle Two: Design for the Most Stringent Standard

Where multiple frameworks impose overlapping but different requirements, design your compliance programme to meet the most stringent standard. If the PDPA requires breach notification “without undue delay” and the CBSL requires notification within 24 hours, design for 24 hours. If the PDPA requires consent and the FCPR requires informed, documented consent with specific disclosure elements, design for the FCPR standard. Meeting the higher standard automatically satisfies the lower one. The reverse is not true.

Principle Three: Separate Your Records by Regulatory Basis

When you maintain compliance records — processing records, consent records, incident reports, audit trails — structure them so that you can demonstrate compliance with each regulatory framework independently. Do not create a single “compliance file” that mixes PDPA records with CBSL records with sector-specific records. Each regulator will want to see evidence of compliance with its own framework, in its own terms, using its own definitions. Structure your records accordingly.

Principle Four: Build Relationships with Every Relevant Regulator

Do not wait for a data incident to introduce yourself to your regulators. Engage proactively. Ask questions. Seek guidance. Attend consultations. In a regulatory environment where formal coordination mechanisms do not yet exist, informal relationships become critical. The organisation that has a working relationship with both the Data Protection Authority and the CBSL will navigate conflicts far more effectively than the organisation that meets its regulators for the first time during an investigation.

Principle Five: Plan for Divergence, Not Convergence

It is tempting to assume that over time, these regulatory frameworks will converge — that the Data Protection Authority and the CBSL and the TRCSL will eventually align their requirements and present a unified framework. This may happen eventually. Do not build your compliance programme on the assumption that it will happen soon. Design for a world where multiple frameworks coexist indefinitely. Build flexibility into your compliance architecture so that you can adapt to new requirements from any regulatory direction without redesigning the entire programme.

The compliance overlap problem is real. It is complex. And it is not going away. But it is also, in a strange way, an opportunity. The professionals who can navigate multiple regulatory frameworks simultaneously — who can map the overlaps, identify the tensions, and build programmes that satisfy every regulator without drowning in bureaucracy — those professionals are going to be the most valuable people in the Sri Lankan compliance community for the next decade.

The Head of Compliance who started this article with a simple question now has a much more complicated one. But they also have a much clearer understanding of what “compliance” actually means in a multi-regulatory environment. That clarity is worth more than any single framework could provide.