Fraud Detection Architecture for Nigerian Financial Applications

The CBN's directive requiring real-time transaction monitoring for payment service providers¹ is not the reason Nigerian financial applications need fraud detection. The reason is that Nigerian payment fraud is substantial, sophisticated, and increasing in sophistication faster than most rule-based defences can track.

The losses are documented: the Nigerian Inter-Bank Settlement System (NIBSS) e-fraud report records billions of naira in electronic fraud annually.² The breakdown is instructive: social engineering (the customer is deceived into authorising a fraudulent transaction) represents a larger share than system compromise (the application itself is breached). This distinction matters for architecture — a system hardened against technical attack that does nothing to detect socially-engineered transactions addresses a minority of the actual fraud exposure.

Categories of Fraud in Nigerian Financial Applications

Account takeover: Attacker gains access to a legitimate customer's account through credentials obtained via phishing, SIM swap, or purchased from data breach marketplaces. Then initiates withdrawals or transfers.

SIM swap fraud: Attacker convinces a mobile network operator to transfer the victim's phone number to a SIM card the attacker controls. This defeats SMS-based OTP authentication. Nigeria's CBN has directives requiring MNO notification protocols, but SIM swap remains a significant attack vector.

Social engineering / authorised push payment fraud: Victim is deceived — through fake investment platforms, impersonation of bank officials, romance scams, or business email compromise — into voluntarily authorising transfers to attacker-controlled accounts. The transaction is technically authorised by the legitimate customer, which defeats authentication controls.

Synthetic identity fraud: Attacker constructs a fake identity using a combination of real and fabricated data, opens an account, builds a superficially legitimate transaction history, then withdraws funds or obtains credit before abandoning the identity.

Merchant fraud / refund abuse: For platforms with merchant-initiated transactions or refund capabilities, manipulation of refund flows or merchant account abuse.

Enumeration and credential stuffing: Automated attacks that attempt to access accounts using credential lists obtained from data breaches, or enumerate valid account numbers through API responses.

The Layered Detection Architecture

No single fraud detection mechanism is sufficient. Effective systems layer mechanisms at different points and with different detection goals:

Layer 1: Authentication Hardening

This is not fraud detection per se, but it closes the most common entry point. The minimum for a Nigerian financial application handling customer funds:

TOTP-based multifactor authentication (Google Authenticator, Authy) as an alternative to SMS OTP — or SMS OTP with SIM swap detection via the MNO APIs
Device registration: flag and require additional verification for logins from previously unseen devices
Behavioural biometrics at login: typing patterns and touch dynamics differ between legitimate users and attackers using credential stuffing tools
Login notification via an out-of-band channel (push notification, email) for any new device or location — not just a security feature, a customer trust feature

Layer 2: Rule Engine

A rule engine applies deterministic checks against transaction and session data. Rules express business-logic fraud signals:

Velocity rules: Three failed PIN attempts in five minutes. Five transactions in ten minutes from the same account. Two transactions over ₦500,000 within six hours.

Pattern rules: Transaction to a new beneficiary over a threshold value. First international transfer from this account. Transfer to a beneficiary not appearing in the beneficiary whitelist.

Contextual anomalies: Transaction at 3am where this account has no transaction history outside business hours. Transaction from geographic location far from the account's registered address.

Trigger actions: Rules trigger on a spectrum from "log for review" to "require additional authentication" to "block and alert". High-value rules block. Medium-confidence rules challenge (require OTP, biometric re-authentication, or agent call). Low-confidence signals log for subsequent behavioural review.

A rule engine without tuning produces either too many false positives (blocking legitimate transactions — the operational failure that customers feel directly) or too few detections (fraud passing undetected).

Layer 3: Risk Scoring and Machine Learning

Rule engines catch known patterns. Machine learning models detect anomalies relative to each account's established behaviour — deviations that no pre-written rule would capture.

The inputs to an account risk score:

Device fingerprint: browser/app characteristics, IP address, geolocation
Behavioural data: time of day, transaction velocity vs historical patterns, session navigation patterns vs normal session
Network signals: IP reputation, VPN usage, Tor exit node detection
Transaction data: amount vs historical distribution, beneficiary familiarity, method of authentication used
Account cohort signals: does this transaction resemble patterns associated with accounts that were later confirmed fraudulent?

An ML model trained on confirmed fraud and legitimate transaction data produces a probability score per transaction. This score is used to tier transaction risk, triggering different friction levels.

A critical point about ML in the Nigerian context: training data from US or European fraud datasets does not transfer cleanly to Nigerian transaction patterns. Unusual behaviour for a Nigerian account may look unremarkable by US training data standards. Models should be trained on Nigerian market data or heavily fine-tuned on local samples.

Layer 4: Network Analysis

Fraud rings operate across multiple accounts and beneficiaries. Network analysis maps relationships between accounts — shared devices, shared IPs, shared beneficiaries, shared registration data — and detects cluster patterns that individual account analysis would not flag.

A single account making unusual transactions may look like a false positive in isolation. The same account, connected to twelve other accounts that all transacted with a common beneficiary in the past month, becomes a strong fraud signal.

Network analysis is computationally intensive and typically runs asynchronously rather than inline with transaction processing. It is post-event detection rather than pre-authorisation blocking, but it is effective for identifying fraud rings and enabling retroactive account suspension.

In our experience building fraud detection for Nigerian fintech clients, the most impactful pattern is not the most sophisticated — it is the combination of device fingerprinting with BVN verification that catches the majority of synthetic identity fraud attempts before they reach the transaction layer. The four layers above are all necessary, but if you are prioritising implementation order, getting device fingerprinting and BVN cross-referencing right will block more fraud in the first month than a partially trained ML model will in six.

The False Positive Problem

In the Nigerian market, overly aggressive fraud detection is a business failure mode with direct revenue impact. Nigerian customers who experience a declined transaction when they are attempting legitimate activity do not escalate to customer service — they route around the block (use a different bank, a different app) and disengage.

The false positive threshold question: at what risk score level does a transaction get blocked vs challenged vs allowed? This is a business decision, not a purely technical one. The relevant inputs are:

Loss rate from fraud: What percentage of transaction volume are fraudulent transactions representing loss?
Cost of false positives: What is the value of legitimate transactions blocked, and the customer churn cost?
Operational capacity for challenge: If every medium-risk transaction requires an agent call, does the operation have the agent capacity?

Most financial applications start with a deliberately conservative challenge threshold — requiring additional authentication for medium-risk transactions — rather than blocking. Challenging a transaction adds friction for legitimate customers but not a hard stop. The balance point shifts as the model is trained on more data and false positive rates become more measurable.

Regulatory Obligations

CBN AML/CFT guidelines: Require customer due diligence, suspicious transaction reporting to the NFIU, transaction monitoring programmes. Under NFIU guidelines, Suspicious Transaction Reports (STRs) must be filed within 24 hours for certain transaction categories,³ with broader reporting obligations that vary by transaction type and risk level.

NFIU STR filing: The fraud detection architecture must connect to a compliance case management system that tracks flagged transactions through to disposition — legitimate, suspicious (STR filed), confirmed fraud (asset recovery and law enforcement engagement).

Customer notification obligations: Under CBN consumer protection guidelines, customers must be notified of transaction blocks affecting their funds within defined timeframes and must have a clear dispute and reversal process.

The compliance architecture is distinct from but integrated with the fraud detection architecture: detection flags transactions; compliance processes determine regulatory reporting obligations based on the disposition.

Implementation and Calibration

Building a fraud detection system from scratch is a multi-month project. For most Nigerian financial applications, the practical path:

Buy or integrate a fraud detection layer initially: Stripe Radar, Sardine, or similar have pre-built models. Integrate via API, collect data, understand the Nigerian-specific false positive patterns.
Build custom rules on top: The pre-built model handles common patterns; your custom rule layer handles Nigeria-specific signals (known fraud beneficiary account patterns, specific MNO SIM swap signals, internal risk data).
Build a labelled dataset: Tag confirmed fraud and confirmed legitimate transactions in production. This becomes training data for a custom model that outperforms the generic provider on your traffic.
Train and deploy a custom model: After six to twelve months of data collection, validate and deploy a custom risk score model. Operate both the provider model and the custom model during transition, comparing outputs.
Continuous calibration: Fraud patterns evolve. Monthly or quarterly model retraining with the latest labelled data prevents model decay.

The fraud losses prevented in year one rarely justify the build cost in isolation. The justification is long-term: fraud prevention capability is a competitive differentiator, a CBN compliance requirement, and a risk management obligation. It is infrastructure, not a feature.

Business Email Compromise: The Attack Costing Nigerian Businesses Billions — A deep dive into BEC, the social engineering fraud category that bypasses technical controls by targeting human decision-making in payment authorisation.
From Reactive to Proactive: Security Automation That Pays for Itself — Automated detection patterns including failed authentication alerting and impossible travel detection that complement transaction-level fraud monitoring.
The CFO's Guide to Security ROI: Quantifying Breach Prevention — How to build the financial case for fraud detection investment using annualised loss expectancy modelling.

Sources

Central Bank of Nigeria (CBN), Risk-Based Approach to AML/CFT — KYC/AML regulations
Nigeria Inter-Bank Settlement System (NIBSS) — nibss-plc.com.ng
Nigeria Financial Intelligence Unit (NFIU), STR filing guidelines
CBN, Bank Verification Number (BVN) Operations Framework