NDPC compliance for fintechs: what the 2023 Act actually requires

If you operate a fintech in Nigeria — payments, lending, savings, wallets, anything that touches customer data — you fall squarely inside the Nigeria Data Protection Act (NDPA) 2023. The Nigeria Data Protection Commission (NDPC) it created has been issuing enforcement actions throughout 2024-2026, including fines into the tens of millions of Naira for documented breaches and non-compliance.

The Act is real. The regulator is active. And most fintechs we’ve reviewed are not fully compliant — usually not because they’re trying to skirt the rules, but because the obligations aren’t intuitive to engineers who aren’t lawyers, and the public summaries online are either too vague or too dense.

This is a practical breakdown of what the NDPA 2023 actually requires you to do, in the order it makes sense to do it.

This is operational guidance, not legal advice. For binding interpretations or representation in front of NDPC, work with qualified counsel. We focus on the systems and processes — what your tech and operations teams need to build.

---

The five obligations that catch fintechs out

If you do nothing else, get these five right.

1. Lawful basis for every piece of personal data you process

NDPA requires you to have a lawful basis for processing each category of personal data. The bases are similar to GDPR’s:

• Consent — the customer actively, specifically agreed
• Contract — processing is necessary to deliver the service they signed up for
• Legal obligation — required by Nigerian law (e.g., AML/KYC under CBN regulations)
• Vital interests — protecting someone’s life
• Public interest — narrow, mostly applies to government
• Legitimate interest — your interest as a business, balanced against the customer’s privacy rights

What fintechs get wrong: treating “we collected it during signup” as sufficient. It isn’t. For each category of data — transaction history, location data, contact lists, device fingerprints, behavioral analytics — you need a documented basis.

What to build:

• A data inventory mapping every field you collect to its lawful basis
• Update your privacy policy to reflect those bases in plain language
• For consent-based processing, store proof of consent (timestamp, version of T&Cs accepted, IP)

2. Data subject rights — and the 30-day clock

Customers have specific, enforceable rights under NDPA:

• Access: they can request a copy of everything you hold about them
• Rectification: they can correct inaccurate data
• Erasure: they can request deletion (subject to legal hold requirements)
• Portability: they can request their data in a machine-readable format
• Restriction: they can pause your processing while disputes are resolved
• Object: they can object to processing based on legitimate interest

The 30-day response clock is hard. Once a Data Subject Access Request lands in your inbox, you have 30 days to respond — including delivering the data, refusing with reasons, or requesting an extension. Miss the deadline, and you’ve automatically breached the Act.

What to build:

• A dedicated DSAR email alias (typically privacy@yourcompany.com) and an internal SLA
• A way to actually produce a customer’s data on demand — most fintechs can’t, because the data is spread across PostgreSQL, Redshift, third-party tools (Mixpanel, Hotjar, Sentry), and SaaS vendors
• A workflow for handling each right with a documented audit trail

The “produce on demand” part is the technical work. If your customer data lives in five places, you need a way to assemble it into a coherent export in under 30 days every time. Build the tooling once. (This is the same underlying problem as report consolidation — one of the five signs your business has outgrown spreadsheets, just with a regulatory clock attached.)

3. Cross-border transfer rules

NDPA restricts where you can send personal data. You can transfer data internationally only if:

• The destination country has been deemed adequate by NDPC (very few countries currently), OR
• You’ve put in place appropriate safeguards (typically Standard Contractual Clauses or NDPC-approved Binding Corporate Rules), OR
• You have explicit consent for the specific transfer, OR
• It’s necessary for a contract with the data subject

What fintechs get wrong: assuming “we use AWS Frankfurt” is fine because EU data protection is strong. It isn’t automatically — you still need documented safeguards. Same for using Stripe (US data), Mixpanel (US), Hotjar (US), Intercom (US), SendGrid (US), Twilio (US). Each of these is a cross-border transfer.

What to build:

• A data flow diagram showing where customer data goes, including every third-party processor
• SCCs or equivalent contracts with each cross-border processor
• A consent mechanism for transfers that don’t fit consent-or-contract bases
• A documented decision log for why each transfer is lawful

4. Data Protection Impact Assessments (DPIAs) before risky processing

NDPA requires a formal DPIA before you launch any high-risk processing activity. “High risk” includes:

• Large-scale processing of financial data (basically any fintech feature)
• Automated decision-making (credit scoring, fraud detection ML models)
• Combining datasets from multiple sources
• Processing biometric data (face/fingerprint for KYC)
• Behavioral tracking for advertising or personalization

In practice, most fintech product launches require a DPIA.

A DPIA isn’t a paperwork exercise — it’s structured thinking that should change how you build:

• What’s the purpose of the processing? Is it proportionate?
• What’s the data flow? Where does the data live, who accesses it, how long is it retained?
• What risks does this create for the customer? How do those risks compare to the business benefit?
• What mitigations are in place? Are they sufficient?

What to build:

• A DPIA template tied to your product launch process (no launch without sign-off)
• A library of completed DPIAs as institutional memory
• DPIA refresh triggers (every 12 months, or whenever data flows change materially)

5. Breach notification within 72 hours

If you have a personal data breach — unauthorized access, accidental disclosure, ransomware, lost laptops with customer data — you have 72 hours to notify NDPC. If the breach is likely to result in high risk to data subjects, you also have to notify the affected customers without undue delay.

What fintechs get wrong: assuming “we’ll figure it out when it happens.” You won’t — 72 hours is brutal when you’re in the middle of an incident.

What to build:

• An incident response plan with the NDPC notification step explicitly included
• A predefined notification template (the legal language Inc-resident counsel signs off on once, used during every incident)
• A monitoring/detection layer that catches breaches in hours, not weeks (because the clock starts when you should have known, not when you actually did)
• A 24-hour decision tree: at hour 0, hour 12, hour 24 — what’s confirmed, what’s still being investigated, are we notifying?

---

The systems-level requirements

Beyond the five obligations above, NDPA mandates certain technical and organizational measures. The Act doesn’t prescribe exact tools — it requires “appropriate” measures relative to the risk. For a fintech, “appropriate” is interpreted generously by regulators.

Encryption

• In transit: TLS 1.2+ everywhere, certificate pinning for mobile apps, no plaintext anywhere on the wire
• At rest: Encrypted database storage, encrypted backups, encrypted log archives
• In application: Sensitive fields (PII, financial account numbers) encrypted at the column level using a key management service, not the same key as the database

Access controls

• Principle of least privilege documented and enforced
• Two-factor authentication required for any staff with access to customer data
• Access reviews quarterly — who has access to what, do they still need it, document the review
• Privileged access auditing — every action a database admin takes against customer data should be logged

Retention and deletion

• Documented retention periods for each data category (KYC: typically 7 years post-relationship per CBN; behavioral logs: shorter; backups: also have a defined lifecycle)
• Actual deletion when retention expires — most fintechs fail this one. Data has a way of sticking around in S3 forever. Build the deletion pipeline.

Vendor management

• Data Processing Agreements with every vendor that processes personal data on your behalf
• Vendor security assessments before onboarding
• Audit rights in the DPA so you can verify compliance, not just trust it

---

The order in which to implement, if you’re starting from zero

We’ve helped fintechs work through this. Doing everything at once doesn’t work — the team gets overwhelmed and stalls. Here’s the order that gets you from “non-compliant and don’t know it” to “compliant and can prove it” in roughly 90 days.

Days 1-30: data inventory and lawful bases

• Map every field of customer data you collect, where it lives, who accesses it, why
• Assign a lawful basis to each
• Rewrite your privacy policy in plain language tied to the inventory
• Identify obvious red flags (unused data sitting around, transfers without basis)

Days 31-60: rights handling and DSAR process

• Set up privacy@yourcompany.com and an internal workflow
• Build the data export tooling — practice running it on test accounts
• Document the rights procedures and train customer-facing staff

Days 61-90: breach response, DPIAs, cross-border

• Write the incident response plan including the 72-hour notification path
• Identify the highest-risk processing activities (probably your scoring model and your fraud detection) and run DPIAs on each
• Inventory cross-border transfers and execute SCCs with the relevant vendors

After 90 days you’re 80% of the way there. The remaining 20% is ongoing: DPIAs for each new feature, periodic access reviews, vendor onboarding, retention enforcement.

---

Three patterns we see go wrong

1. “We have a privacy policy, so we’re compliant.” The privacy policy is the customer-visible output of compliance. It’s not the compliance itself. Most fintechs have a policy that doesn’t accurately describe what they actually do with data. NDPC can — and does — request evidence of the underlying practice, not just the policy.

2. “We use AWS, so security is taken care of.” AWS is one of your processors. You’re still the controller. NDPA places the obligation on the controller. The cloud provider’s SOC 2 doesn’t substitute for your own compliance program.

3. “We’ll sort this out when we raise the next round.” NDPC enforcement actions have happened to fintechs at every stage. The cost of being unprepared in a breach scenario — the 72-hour clock, the customer notifications, the regulatory fines, the reputation damage — vastly exceeds the cost of building the compliance program proactively.

---

What a compliance-ready fintech actually looks like

Concretely, here’s what’s true of a fintech that would pass an NDPC audit:

• Privacy policy reflects the actual data inventory; both are owned by a named person
• Customer can request and receive a data export within 30 days, automatically generated
• DSARs are tracked with a documented response time
• Every product launch has a DPIA on file
• Cross-border transfers are documented with executed SCCs
• Breach response plan exists, has been tabletop-tested, includes the NDPC notification template
• Encryption in transit and at rest is verified, not assumed
• Vendor list is current; DPAs are on file for each
• Retention schedules exist and are actually enforced
• Access to customer data is logged, periodically reviewed, and limited to those who need it

If most of those are true at your fintech today, you’re ahead of the market. If most aren’t, the 90-day plan above gets you there.

---

If you’re a fintech (or any business handling regulated personal data) and want help building the systems side of NDPA compliance — the data inventories, DSAR tooling, DPIA processes, breach response automation, vendor management — start a conversation. We’ve built compliance-ready architectures into ERPs (see our analysis of true ERP costs in Nigeria — compliance configuration is one of the seven hidden buckets), multi-tenant SaaS platforms (like DevOS for real estate), and citizen-facing services. The pattern is repeatable. The cost is much lower than the alternative.