Fifty wallets. Fifty stolen identities. One laundering ring.

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs CEH (Certified Ethical Hacker)

CBN wallet tiers: what the regulation actually says

The Central Bank of Nigeria's tiered KYC framework, operationalised through the CBN Regulatory Framework for BVN Operations and Watch-List for the Nigerian Banking Industry and subsequent AML/CFT guidelines, defines three wallet tiers with explicit transaction limits:

• Tier 1 — Requires only a BVN or a valid phone number. Single-day transaction limit: ₦50,000. Maximum cumulative wallet balance: ₦300,000. No address verification. No document upload. Onboarding can be completed in under two minutes entirely on a mobile device.
• Tier 2 — Requires BVN plus at least one additional verification factor (government-issued ID, NIN linkage, or similar). Higher transaction limits apply. Identity linkage to a verifiable document is mandatory.
• Tier 3 — Full KYC: BVN, government ID, proof of address via utility bill, and in some implementations, liveness check. Suitable for high-value transacting customers.

The vast majority of Nigerian digital fintechs — neobanks, mobile money operators, agent banking platforms, and standalone wallet apps — onboard users at Tier 1 by default. The friction is low, the acquisition funnel converts better, and the regulatory minimum is technically met. The problem is that every control in this framework is scoped to a single account, not to the person behind it.

The cross-pollination attack: mechanics of a Tier 1 ring

BVN data has leaked from multiple Nigerian financial institutions. It is actively traded on Telegram channels and dark-web marketplaces, sometimes in bulk data sets containing BVN, full name, date of birth, and phone number. This is not speculation — NITDA and multiple security researchers have documented specific breach instances. A motivated attacker with ₦200,000 to spend on data acquisition can walk away with hundreds of valid BVN records.

The attack sequence runs as follows:

1. Data acquisition — Attacker purchases 50 valid BVN records from a data broker operating on a private Telegram channel. Each record contains enough PII to pass Tier 1 registration: BVN, linked phone number, date of birth.
2. Account creation — Using a combination of SIM farms, emulators, and VPN exits across different Nigerian mobile carrier subnets (MTN, Airtel, Glo, 9mobile), the attacker registers 50 distinct Tier 1 wallets. Some are created on the same fintech platform; others are spread across competing platforms to reduce per-platform exposure.
3. Funding the mules — A central coordinator account transfers funds in sub-₦50,000 tranches to each mule wallet. Because each individual transfer stays under the Tier 1 single-transaction threshold, no automated alert fires.
4. Accumulation — Each mule wallet accumulates up to ₦300,000 — the Tier 1 balance ceiling — before being used for outbound transfers. Fifty wallets at ₦300,000 each: ₦15 million in usable float, per rotation cycle.
5. Extraction — Mule accounts send funds to aggregation accounts held at tier-1 commercial banks (Guaranty Trust, Zenith, Access), where the funds are mixed with legitimate transaction volume and the trail cools. Mule wallets are then abandoned or handed off to new synthetic identities before any compliance review cycle completes.

The rotation speed is the key variable. A well-run ring cycles through accounts fast enough that by the time a compliance analyst flags an account for manual review, the funds are already two hops away.

Why the ₦300,000 aggregate limit does not contain this

The CBN Tier 1 balance limit was designed assuming one account per person. That assumption collapses the moment an attacker holds multiple accounts under different BVNs — real or synthetic. The ₦300,000 ceiling applies per wallet, not per human being.

A fintech cannot, without deliberate engineering effort, detect that BVN 12345678901 and BVN 98765432109 belong to accounts that share the same physical device, the same registration IP, or the same network of outbound transfers. NIBSS provides a BVN validation API that confirms identity against a given BVN — but it does not expose cross-account linkage signals. Detecting this requires the fintech to build internal correlation logic across its own account population.

Most platforms do not do this. They validate each BVN once at account creation, confirm the phone number matches, and move on. The compliance function sees individual accounts in isolation, not the graph they collectively form.

Network topology of a Tier 1 mule ring

Structurally, these rings follow a consistent pattern. Understanding the topology is necessary before you can instrument for detection.

At the centre is a coordinator account — often a Tier 3 account held at a commercial bank, funded through a legitimate-looking business or from a prior laundering cycle. The coordinator distributes funds to a first layer of mule wallets (the "dispersal layer"). These wallets receive funds in small tranches and hold them briefly.

The dispersal layer accounts then send to a second layer of mule wallets (the "mixing layer"). This introduces a hop that makes graph tracing harder: if you only observe the mixing layer, the coordinator is not visible. The mixing layer wallets look like they are receiving peer-to-peer transfers from ordinary users — because from the vantage point of any single platform, that is exactly what the data shows.

The mixing layer feeds one or more aggregation accounts at large commercial banks. By the time funds reach an Access Bank or Zenith account, the transaction history is a tangle of small transfers from dozens of wallets across multiple platforms. Formal AML typology for this pattern is called layering via smurfing — a documented Financial Action Task Force (FATF) typology that Nigerian fintechs are expected to have controls against under NFIU guidance.

What the transaction data looks like from the inside

Individually, each Tier 1 mule account looks completely normal. Consider the following representative transaction profile:

• Account age: 12 days
• Inbound transfers: 8 transactions, averaging ₦35,000 each — all from different sender accounts
• Current balance: ₦278,000 (just under the ₦300,000 ceiling)
• Outbound transfers: 3 transactions, totalling ₦240,000, all sent to the same destination account
• No single transaction breaches Tier 1 daily limits
• No transaction is flagged by threshold-based rules

A compliance analyst reviewing this account in isolation sees a new user receiving regular transfers and sending money to one person. This could be a market trader receiving payments from customers and remitting to their supplier. Nothing about the individual account screams fraud.

The pattern only becomes visible when you look across accounts simultaneously — specifically when you ask: how many other accounts share the same registration device? How many other accounts send to the same destination? Were any of those accounts registered within the same six-hour window from the same IP block? These are graph questions, not single-account questions, and they require your data model to support them.

Detection signals: what to build into your platform

Each of the following controls closes a different detection gap. Implement them in layers — no single signal is definitive, but in combination they make a ring extremely difficult to operate undetected.

Device fingerprint deduplication

Collect a stable device fingerprint at registration. On mobile (Android/iOS), this is a combination of hardware identifiers, screen resolution, OS version, installed font set, and accelerometer calibration data. On web, TLS fingerprinting (JA3 or JA4) combined with browser canvas and audio context fingerprints is sufficient for most cases.

Persist the device fingerprint hash against the account record. Run a deduplication query at every new account registration: if a fingerprint has been seen before, flag it for review rather than auto-approving. A single device fingerprint appearing in more than one account registration within a 30-day window should escalate to Tier 2 verification before the second account is activated.

IP and network clustering

Log the full registration IP, the ASN (autonomous system number), and the mobile carrier where applicable. Group registrations by /24 subnet and by ASN. A cluster of five or more Tier 1 accounts registered from the same /24 subnet within a two-hour window is a strong signal — especially if those accounts have no prior transaction history and are not linked by referral codes.

MTN, Airtel, Glo, and 9mobile each operate predictable NAT subnet ranges for their mobile data traffic. Attackers using SIM farms rotate SIMs but often share the same carrier, which clusters their egress IPs within identifiable ASN ranges. Cross-referencing registration ASN against known Nigerian carrier ASN blocks lets you weight the signal correctly — a registration from MTN's ASN is not suspicious on its own, but ten registrations from MTN's ASN within thirty minutes, all to fresh accounts, warrants a second look.

Transaction graph analysis

Model your accounts and transactions as a directed graph. Each account is a node; each transfer is a directed edge from sender to recipient. Run the following queries periodically (daily or near-real-time for high-velocity platforms):

• Common destination clustering — Find all accounts that have sent funds to the same destination account within a 14-day window. If more than five source accounts share a single destination and those source accounts were each created within a short time window, flag the cluster.
• Registration co-location clustering — Group accounts by registration device fingerprint and registration IP/ASN. If accounts A and C share a registration device and both send to account B, flag A, B, and C as a cluster regardless of whether A and C have any direct relationship.
• Temporal registration bursts — Flag any group of more than three accounts registered within a one-hour window that share any two of: same device fingerprint, same IP subnet, same outbound destination within seven days of creation.

In PostgreSQL, the common destination cluster query can be expressed with a simple GROUP BY on the transfers table. The registration co-location query requires joining on a device fingerprints table. Recursive CTEs handle the multi-hop graph traversal for the layered ring structure described above. You do not need a graph database to start — you need a schema that stores device fingerprints and an index on the destination account ID column in your transfers table.

Per-device velocity limits, not per-account

Velocity limits scoped to the account are trivially bypassed by the ring structure described. Move your velocity checks upstream to the device fingerprint. A rule such as "no more than ₦100,000 in aggregate outbound transfers in 24 hours across all accounts sharing this device fingerprint" collapses the per-account limit evasion entirely. This is implementable in Redis with a sliding window counter keyed on the device fingerprint hash.

Proactive controls: the exact fixes

Compliance guidelines name the obligation; the following is the technical implementation:

• Bind device fingerprint at registration — Store a hash of the device fingerprint in a device_registrations table with a foreign key to the account. Index on fingerprint hash. At every new registration, query this table before account creation completes. Do not rely on client-supplied device IDs; compute the fingerprint server-side from the registration request headers and any mobile SDK telemetry you collect.
• Alert on multiple registrations per fingerprint within 30 days — Set a hard rule: a second account registration from a known device fingerprint within 30 days requires Tier 2 verification before the account is activated. A third registration within the same window should be blocked pending manual review. Implement this as a synchronous check in your account creation flow, not as an async background job — by the time an async job runs, the account may already be active.
• Query NIBSS BVN validation for platform-level uniqueness — Before account creation, check whether the presented BVN is already associated with an active account on your platform. This is a first-party check against your own database, not a new NIBSS API call. If a BVN is already linked to an existing account, require the user to verify through the existing account flow rather than creating a new one. If they insist on a second account (legitimate business/personal split), escalate to Tier 2 immediately.
• Auto-elevate accounts that hit 80% of their Tier 1 limit within 7 days of creation — An account that accumulates ₦240,000 within its first week is either a high-value legitimate user who deserves a better tier, or a mule account. Either way, Tier 2 verification is the correct response. Implement this as a scheduled job that runs nightly against all accounts opened in the last seven days, computes their current balance as a percentage of the ₦300,000 ceiling, and flags those above the threshold for a compliance hold on outbound transfers until Tier 2 documentation is submitted and cleared.

None of these controls require a compliance team to manually review each account. They automate the escalation decision and route the edge cases to human review — which is the correct architecture for a high-volume onboarding funnel.

Related reading

Blog: KYC and BVN data security in fintech · BVN spoofing and liveness bypass on Tier 1 onboarding

Guides: CBN compliance security guide

Services: API security testing · Secure architecture review