Introduction: Why Privacy Matters in Open Banking

Open banking is one of the data-sharing schemes, alongside open finance and open data, that allows customers to authorise the secure sharing of their financial data with approved third-party service providers. These providers then use the data to build and offer personalised services such as budgeting tools, investment products, and digital payment solutions. The open banking system operates through Application Programming Interfaces (APIs) that facilitate data sharing between the institutions that hold customer data and those that request access to it with customer consent.

In Nigeria, the Central Bank of Nigeria (CBN) has taken steps to implement open banking by issuing two key regulatory instruments. These are the Regulatory Framework for Open Banking (2021) and the Operational Guidelines for Open Banking (2023). These laws define how customer-permitted data can be accessed, processed, and exchanged.

Open banking participants must also comply with the Nigerian Data Protection Act (NDPA) and other directives issued under the Act, like the General Application and Implementation Directives (GAID), which governs the processing of personal data across all sectors and data processing activities, including in the context of open banking.

Data privacy is central to the success of open banking. Customers must feel confident that their personal and financial information is handled responsibly. Institutions participating in the open banking system, either in the capacity of sharing or accessing data, must therefore establish strong privacy practices to comply with the law, manage risk, and build trust. This article outlines a six-pillar privacy programme that reflects Nigeria’s legal requirements and provides practical steps for implementation.

Understanding the Roles in Nigeria’s Open Banking System

Every participant in Nigeria’s open banking system plays a specific role in how customer data is generated, accessed and shared. Understanding these roles is key to understanding privacy responsibilities. These roles include API Providers, API Consumers, and Customers.

• API Providers are institutions that make financial data or services available through APIs. They include banks, licensed payment service providers, payroll platforms, retailers, and other entities that hold or manage customer data.
• API Consumers are participants that access and use this data to offer services to customers. These can be other financial institutions, fintech companies, data aggregators, or third-party technology providers.
• Customers are the data owners. Their explicit permission is required before any of their data can be shared or accessed. This consent should be properly documented and tracked by API Providers and API Consumers.

Some institutions may act as both API Providers and API Consumers, depending on the type of service they offer. For example, a fintech company may both share its own data and consume banking data for credit scoring.

Every relationship between an API Provider and an API Consumer should be governed by a Service Level Agreement (SLA). The SLA is required to address key issues such as billing arrangements, reconciliation of fees, responsibilities of sponsored third parties, and the processes for resolving disputes.

Another key component of Nigeria’s open banking system is the structure for participant registration and monitoring. To facilitate this, there is the Open Banking Registry (OBR), which is a central platform established by the CBN to oversee and manage the activities of all participants in the open banking ecosystem.

The registry serves several functions. It provides a public record of all registered institutions that participate in open banking. Each participant is uniquely identified using their Corporate Affairs Commission (CAC) registration number.

API Providers are required to register their API Consumers through the OBR. This process ensures that only authorised institutions are involved in data sharing. The registry also includes a technical API interface that enables seamless onboarding and integration.

The OBR improves regulatory oversight by providing the CBN with accurate, real-time information about who is active in the system, the roles they perform, and the APIs they offer. It serves as a central tool for ensuring that data sharing within open banking remains lawful, secure, and subject to effective supervision.

Six Pillars of a Strong Privacy Programme

A comprehensive privacy programme provides a clear operational structure to help API Providers and API Consumers meet their legal obligations, manage privacy risks, and safeguard customer data. The following six pillars outline the essential components of such a programme:

Pillar 1: Data Protection Impact Assessments and Privacy Risk Management

Before launching new products, services, or partnerships that involve customer data, it is helpful for institutions to identify and manage potential privacy risks. This requires a structured approach to privacy risk assessments.

A Data Protection Impact Assessment (DPIA) is a formal process for evaluating how a proposed data processing activity may affect individuals’ privacy rights. They help organisations identify possible harm to individuals, evaluate whether the data processing is lawful, and determine what safeguards should be put in place.

The NDPA and GAID list various circumstances when a DPIA should be conducted. These include profiling and scoring, automated decision-making, systematic monitoring, the use of sensitive data, digital financial services, deployment of new applications or software for data processing, and software development for communication with data subjects. Open banking activities fit into some of these areas.

Institutions should use the standard DPIA template set out in Schedule 4 of the GAID for the assessment. This includes information on the nature and purpose of data processing, legal justifications, the categories of personal data involved, the risks identified, and proposed mitigation measures. The DPIA should be signed off by an accredited Data Protection Officer (DPO) and submitted as part of the institution’s Compliance Audit Returns to the Nigeria Data Protection Commission.

Institutions should also assess the privacy and operational risks of onboarding third parties. Before engaging such partners, institutions should conduct a full due diligence review, covering the partner’s data governance structure, technical systems, past compliance history, and exit arrangements in case the relationship ends.

All identified privacy risks should be recorded in a central risk register. This register should include the risk description, responsible officers, action plans, target deadlines, and status updates. The risk register should be reviewed at risk committee meetings and used to inform executive-level reporting. Risk mitigation efforts should also be linked to internal control reviews, audit findings, and incident response protocols to ensure consistency.

Pillar 2: Governance Structure and Internal Accountability

Privacy compliance is not solely a legal function. It requires involvement from across the organisation and should be driven from the top. Institutions need a governance structure that clearly defines who is responsible for privacy, how decisions are made, and how performance is monitored.

The first step is to assign formal responsibility for data protection. This could be a Data Protection Officer or a senior official within the risk or compliance team. The person should have the authority to influence key decisions and should report directly to senior management or the board.

Second, institutions should form a cross-departmental Privacy Governance Committee. This group should include representatives from legal, compliance, IT, operations, and product teams. It is responsible for reviewing privacy risks, approving assessments, monitoring implementation, and resolving internal data-sharing issues.

The board of directors should formally approve core documents such as the Data Governance Policy and Data Ethics Framework. These documents should reflect the organisation’s privacy values and establish clear expectations for all staff. It is also crucial for relevant board committees, such as the risk or compliance committee, to be assigned oversight of privacy governance performance indicators.

To strengthen oversight, institutions should use a three-line defence model. The first line involves operational teams that manage data on a daily basis. The second line includes compliance and risk teams who provide guidance and monitor implementation. The third line, usually the internal audit, provides independent evaluations.

Pillar 3: Policy Frameworks and Operational Procedures

Privacy compliance must be embedded in daily operations through clear and enforceable policies and procedures. These policies and procedures define expectations, standardise practices, and ensure that all staff understand their roles.

Some key policies that participants are required to maintain include:

• A Data Governance Policy, which sets rules on how data is collected, used, stored, and shared. This policy should explain roles and responsibilities, data quality controls, and classification systems for different types of data.
• A Data Ethics Framework, which outlines the institution’s approach to fairness, transparency, and non-discrimination in the use of customer data, especially for automated decision-making tools.
• An Information Security Policy, which describes technical controls used to protect data. This includes access control, encryption, user monitoring, and third-party security requirements.
• A Data Breach Response Plan, which explains how the institution will detect, respond to, and report data breaches. It should include timelines for notification, escalation procedures, and incident analysis steps.

Additional procedures should cover data loss prevention, encryption and pseudonymisation protocols, identity and access management procedures, data retention and secure destruction guidelines, and business continuity and disaster recovery plans.

Documentation should also include a data map that shows where customer data resides across systems and third-party platforms, as well as a catalogue of all APIs and the risks associated with each one.

Institutions must ensure that all documents are version-controlled, regularly reviewed, and stored in accessible digital platforms. A central policy register should be maintained to track all documents, assign responsibility, and monitor updates.

Staff should undergo mandatory training on applicable policies and procedures and complete attestations confirming awareness and understanding.

Pillar 4: Customer Consent and Individual Rights

In open banking, data cannot be shared without customer permission. Consent must be informed, specific, and revocable at any time.

Institutions should create consent forms that clearly explain what data is being shared, for what purpose, and for how long. Customers should be able to choose which types of data to share and should not be forced to accept all permissions in a single step.

Consent should be recorded using the same method as the agreement. This can include digital, written, audio, or video formats. All records should be timestamped and linked to an encrypted token that verifies the customer’s approval.

Systems should be set up to let customers manage their consent in real time. This includes mobile apps and web portals that allow users to approve, revoke, or update permissions. Notifications should be sent when permissions are added, changed, or about to expire.

Institutions should also build consent expiry and revalidation rules into their systems. If a customer is inactive for 180 days or more, the consent should automatically expire, and data sharing should stop.

Customer service staff should be trained to explain these processes and help customers exercise their rights.

Consent logs should be securely stored, traceable to each API call, and made available for audit or regulatory inspection upon request.

Institutions should also allow customers to download a record of their consent history and data-sharing activities via secure digital channels.

Where customer consent is refused or revoked, systems should automatically disable access permissions and trigger an internal review of any associated service dependencies.

Pillar 5: Security Controls and Breach Response

Protecting customer data from loss, theft, or misuse requires layered and proactive security controls.

Systems should be built using internationally recognised standards such as ISO/IEC 27001. Access to data should be limited to authorised personnel, and all activity should be logged in tamper-proof audit systems.

APIs should use secure protocols, including OAuth 2.0 for user authorisation, TLS 1.2 or higher for encrypted connections, and JSON Web Tokens for session management.

Institutions should enforce strict access policies, including password complexity rules and regular reviews of system privileges. Unused accounts and excessive access rights should be identified and removed.

Security should also extend to physical infrastructure. Data centres should have restricted entry, surveillance systems, and visitor logs.

In case of a security breach, there should be a documented incident response plan. This should include clear roles, escalation procedures, and timelines for notifying the CBN and affected customers. The incident should be followed by a root cause analysis and steps to prevent recurrence.

Institutions are also required to report major incidents to the Nigeria Data Protection Commission and maintain a record of incident reports, investigation findings, and remediation actions. Penetration testing, vulnerability scanning, and security patch reviews should also be conducted on a scheduled basis and after major system changes.

Pillar 6: Customer Redress and Complaints Resolution

Trust depends on more than just compliance. Customers need to feel that their concerns are taken seriously and that they can exercise their rights with ease.

Institutions should provide a 24-hour help desk that can be reached through multiple channels, including phone, email, and live chat. The helpdesk should be able to handle complaints related to privacy, consent, and data sharing.

Complaints should be tracked through a central system. Customers should receive a unique reference number and updates on the status of their case. Most complaints should be resolved within 48 hours, and delays should be explained.

Customers should be informed of their right to escalate unresolved complaints to the CBN’s Consumer Protection Department. Institutions should explain this process clearly in their complaint policies.

It should also be clear who is responsible if data is misused. Institutions should not shift all liability to customers or partners without justification. SLAs should include joint responsibilities for dispute resolution, redress, and compensation.

Institutions should also educate customers about their data rights. This includes materials on how to give or withdraw consent, how to manage permissions, and how to lodge complaints. These materials should be written in plain language and provided in multiple Nigerian languages.

Customer education should begin at onboarding and continue through periodic reminders using channels such as email, SMS, and app notifications.
Training should be provided to all customer-facing staff to ensure accurate and consistent handling of privacy-related queries.

Conclusion

The success of open banking in Nigeria depends on strong privacy safeguards. This six-pillar privacy programme offers practical steps that institutions can take to meet their legal obligations, manage privacy risks, and build public trust. Each pillar reflects a critical component of privacy compliance. They provide a comprehensive framework for secure, transparent, and user-centred data sharing in Nigeria’s open banking system.