A Case for Security-First Development
If you build a product that moves money, someone will eventually try to abuse it.
That is not a prediction. It is a condition of building financial technology.
Nigeria’s fintech ecosystem has made payments faster, easier and more accessible. In the first half of 2024 alone, the country recorded more than 22 billion electronic payment transactions worth approximately ₦1.56 quadrillion.
At the same time, fraud remains a significant challenge. Between 2020 and 2025, attempted fraud across Nigeria’s banking and payments ecosystem was valued at approximately ₦187.79 billion, with reported losses of ₦134.48 billion. (Central Bank of Nigeria [CBN], 2026; CBN, n.d.)1
The numbers tell us something important.
Financial technology has become valuable not only to customers and businesses, but also to people looking for weaknesses to exploit.
The question is therefore not whether malicious intent exists.
The question is whether products are designed to make that intent successful.
And that is where security-first development matters.
Attackers do not always need to break into the system
When we hear about a fintech security incident, we often imagine a hacker breaking through a firewall, stealing credentials and gaining access to a database.
That happens.
But some of the most instructive incidents involve something more subtle: legitimate functionality being used for illegitimate purposes.
In 2023, TechCabal reported that Interswitch was attempting to recover approximately ₦30 billion following chargeback fraud associated with a system glitch. More than ₦10 billion had reportedly been recovered at the time of reporting. (TechCabal, 2023)2
A chargeback is a legitimate feature. The vulnerability was not necessarily the existence of the feature, but the possibility of manipulating the rules around it.
This is a crucial lesson for development teams.
Security vulnerabilities are not always holes in the wall. Sometimes they are flaws in the rules of the game.
The same lesson appears in the Flutterwave case. In 2023, certain POS merchants were reported to have abused legitimate access, resulting in approximately ₦19 billion in unauthorised transactions. Flutterwave subsequently sought to recover the funds. (TechCabal, 2024)3
The important question is therefore not simply:
Can an attacker get into the system?
It is:
What can someone do once they have access?
A merchant may be authenticated. An employee may be authorised. A customer may have passed KYC. An API request may be technically valid.
Yet the resulting behaviour can still be malicious.
Authentication tells us who is making a request. It does not tell us whether the request makes sense.
Security should be part of the product
This is where security-first development is often misunderstood.
Security is sometimes treated as something added after the product has been designed. The product team builds the experience, developers implement it, and the security team later tests whether it is safe.
That approach is too late for financial products.
Security needs to influence the product itself.
When designing a merchant payment feature, for example, teams should ask not only whether the merchant can authenticate, but what happens if the account is compromised.
- How much money can it move?
- How quickly can it move it?
- What happens if transaction behaviour suddenly changes?
- Can one compromised account affect thousands of customers?
- Can a legitimate refund process be manipulated?
- Can an employee use legitimate privileges to bypass controls?
- Can a transaction be replayed or duplicated?
- These are not questions that belong exclusively to a security team.
- They are product questions.
- They are engineering questions.
- They are architecture questions.
A great user experience should be secure by default
Security should not be presented as the enemy of a great user experience.
For financial products, security is part of the experience.
Customers should not need to understand cybersecurity to benefit from good security.
They should not need to know what account takeover means before their account is protected against it. They should not need to understand fraud detection before suspicious activity is identified.
The best security is often invisible when everything is normal.
A customer making a familiar transaction from a familiar device should be able to move quickly.
The same customer suddenly attempting an unusually large transaction from a new device and sending money to a new beneficiary should receive a different level of scrutiny.
That is not bad user experience.
That is a better product.
The objective is not to introduce friction everywhere. It is to introduce appropriate protection where the risk changes.
Security should work in the background wherever possible, while becoming more visible when the consequences of an action are greater.
The safest configuration should be the default configuration.
Limit the damage when something goes wrong
Security-first development also means accepting an uncomfortable reality: eventually, something will fail.
A credential will be stolen.
An employee will make a mistake.
A vulnerability will be discovered.
A merchant will behave maliciously.
A system will be misconfigured.
The goal is therefore not simply to prevent every possible compromise.
It is to make sure that one compromise does not become a catastrophe.
This is the idea of reducing the blast radius.
A compromised account that can move ₦50,000 is very different from one that can move ₦5 billion.
An employee with access to one function is different from an employee with unrestricted administrative privileges.
A transaction that can be stopped or reversed is different from one that immediately disappears through multiple accounts.
These are product decisions as much as security decisions.
Good security asks:
If this control fails, what happens next?
Speed should not come at the expense of security
Fintech companies compete on speed.
Customers want instant payments. Merchants want immediate settlement. Businesses want simple APIs and frictionless transactions.
These are precisely the qualities that make fintech valuable.
They are also why security needs to be built into the architecture rather than added as an obstacle.
Nigeria’s payment infrastructure operates at enormous scale. The CBN recorded more than 6.39 billion POS transactions, 11.64 billion internet transfers and 3.49 billion mobile-app transactions in the first half of 2024. (CBN, n.d.)4
At that scale, even a small proportion of malicious activity can create significant losses.
The answer is not to make fintech slow.
The answer is to make fintech secure at speed.
That requires products that can understand context, identify abnormal behaviour, limit risky actions and respond quickly without unnecessarily interrupting normal users.
Security starts with the use case
One practical change development teams can make is to consider an abuse case alongside every normal use case.
If the product requirement says:
A merchant can request a refund.
The team should also ask:
How could a merchant abuse the refund mechanism?
If customers can add beneficiaries:
What happens if an account is compromised?
If employees can approve high-value transactions:
What happens if an employee’s credentials are stolen?
If customers can open accounts quickly:
How could someone manipulate the identity-verification process?
This does not mean treating every customer, employee or merchant as a potential criminal.
It means acknowledging that a well-designed system should account for both intended behaviour and foreseeable abuse.
Security is everyone’s responsibility
Security-first development cannot be delegated entirely to the security team.
Product managers decide what customers can do.
Designers shape the journey.
Developers implement the rules.
Architects determine how systems interact.
Data teams provide the signals needed to identify unusual behaviour.
Security teams bring adversarial thinking and specialised expertise.
Leadership determines how much risk the organisation is willing to accept.
The strongest products bring these perspectives together early.
Security should not be the department that arrives at the end of development and says, “This cannot ship.”
It should be part of the conversation that determines how the product should work.
Malicious intent is inevitable. Successful exploitation is not.
Nigeria’s fintech experience provides a useful reminder of why this matters.
There have been significant incidents, including the reported ₦30 billion Interswitch chargeback fraud and approximately ₦19 billion in unauthorised transactions involving Flutterwave POS merchants.
There have also been examples of detection, containment, recovery and stronger controls limiting the consequences of attacks. (TechCabal, 2023; TechCabal, 2024)5
The lesson is not that fintech products are inherently insecure.
It is that security cannot be separated from product design.
A firewall cannot compensate for flawed business logic.
MFA cannot compensate for excessive privileges.
KYC cannot compensate for unlimited transaction capability.
Monitoring cannot compensate for a product that allows one compromised account to cause enormous financial damage.
Security-first development means thinking about these problems before they become incidents.
It means designing products that assume malicious intent will exist while refusing to assume that malicious intent must succeed.
And that is perhaps the most useful definition of secure fintech:
Products that are delightful to use, secure by default and difficult to abuse.
The customer should not have to choose between convenience and protection.
The development team should not have to choose between elegant product design and sound security architecture.
The goal is to build both.
Because malicious intent may be inevitable.
Successful exploitation is not.
References
- Central Bank of Nigeria. (2026). Nigeria Payments System Vision 2028. Central Bank of Nigeria. ↩︎
- TechCabal. (2023, November 2). Interswitch loses N30bn to fraud. TechCabal report on Interswitch chargeback fraud ↩︎
- TechCabal. (2024, February 8). Flutterwave to recover missing $24 million. TechCabal report on Flutterwave’s unauthorised POS transactions ↩︎
- Central Bank of Nigeria. (n.d.). E-payment statistics. Central Bank of Nigeria. CBN E-Payment Statistics ↩︎
- TechCabal. (2023, November 2). Interswitch loses N30bn to fraud. TechCabal report on Interswitch chargeback fraud
TechCabal. (2024, February 8). Flutterwave to recover missing $24 million. TechCabal report on Flutterwave’s unauthorised POS transactions ↩︎