Every Nigerian product that touches identity or payments eventually collects some combination of a Bank Verification Number, a National Identification Number, or card details. These fields tend to get treated like any other piece of user data on the way in: captured in a form, saved to a column, logged when something goes wrong so a developer can see what happened. That habit is the single most common compliance mistake we see, and it is almost always introduced in week one, long before anyone is thinking about compliance at all.
The fix is not a compliance review before launch. By the time a review happens, the field is already in a dozen log lines, a support team's screen-share history, and possibly a third-party analytics payload. The fix is deciding, at the schema design stage, which fields are regulated and building the handling rules around them before the first row is ever written.
Start from data minimisation, not data collection
The instinct in early product development is to collect broadly, on the theory that data might be useful later. For regulated identity fields specifically, that instinct is backwards. The right default question is not "might we need this," it is "does this specific feature fail without it." A KYC flow genuinely needs a BVN. A referral programme almost certainly does not need to see it at all, even if the same user record has one attached elsewhere in the system. Minimisation is not a legal nicety, it is the simplest possible risk reduction: a field that was never collected cannot leak.
Masking has to happen before the field reaches a log line, not after
The most common place regulated data actually leaks is not the database, which usually has reasonable access controls. It is logs, error messages, and queue payloads, which typically do not. A stack trace that includes a full request body because that was the easiest way to debug an issue three months ago is a live BVN or card PAN sitting in a log aggregator that half the engineering team can search.
The only reliable fix is structural: sensitive fields get masked or excluded at the point where a request first enters the system, before they are available to be accidentally included in a log statement, an error payload, or a message on a queue. This has to be a property of the framework or middleware layer, enforced automatically, not a discipline every engineer is expected to remember on every request handler they write. Discipline fails under deadline pressure. Structure does not.
Design for the erasure request before one arrives
The Nigeria Data Protection Act gives users a real right to request that their data be deleted. Most systems are not built to honour that request cleanly, because deletion was never a first-class operation, it is something bolted on when the first request actually arrives, usually under time pressure. By then, a user's data has typically propagated into backups, analytics exports, and any number of joined tables that a single DELETE statement will not reach.
The cleaner approach is to design the data model from the start around the assumption that erasure is a real, expected operation: know which tables hold personal data, know what it means to erase a user's record without breaking the referential integrity of a transaction history that legitimately needs to persist, and decide up front whether erasure means deletion or anonymisation for each category of data. That decision is far cheaper to make once, on a whiteboard, than to make under deadline when a user has invoked their legal right and the clock on your response has already started.
Breach notification is a process, not a form
Regulatory frameworks generally require notifying affected users and, in serious cases, a regulator, within a defined window after a breach is discovered. Teams that have never thought about this in advance lose most of that window figuring out what actually happened, because they cannot quickly answer basic questions: which systems held the affected data, who had access, what the blast radius actually was. Designing for this in advance means maintaining a real, current map of where regulated data lives and who can reach it, not reconstructing that map for the first time during an incident, while the notification clock is already running.
None of this is exotic
Everything here is standard practice in any market with a mature data protection regime. The mistake Nigerian teams make is not a lack of technical capability, it is treating compliance as a category of feature to schedule later, after the product works, rather than a set of default handling rules baked into the schema from the start. The second approach costs a few extra hours in week one. The first approach costs considerably more, usually at the worst possible time, in front of the worst possible audience.
Written by
Akintola Stephen Iyanu, founder and engineer at Zynterra. More about the studio.