What transaction monitoring actually is
Transaction monitoring is the ongoing evaluation of customer transactions against a set of rules designed to surface money-laundering, fraud, or sanctions-evasion patterns. It is not the same thing as KYC (which happens at onboarding) or sanctions screening (which checks identities against lists) — though all three feed into the same overall compliance picture, and a mature setup evaluates them together rather than as disconnected systems.
In practice, transaction monitoring for a Nigerian fintech has three layers: the rules that evaluate each transaction, the customer risk state that contextualises the evaluation, and the workflow that turns a rule firing into an investigated, documented decision.
The rule types that actually matter
Most monitoring programmes converge on a similar core rule set, tuned to the business model:
- Velocity rules — flag an unusual number or value of transactions in a rolling window, relative to the customer's own baseline, not a flat threshold.
- Structuring detection — identify sequences of transactions designed to stay under reporting thresholds.
- New-account monitoring — apply elevated sensitivity to accounts in their first 30–90 days, where mule-account abuse concentrates.
- Counterparty aggregation — treat transactions to the same counterparty across a window as one economic event, not isolated data points.
- Behavioural anomaly — compare a transaction to the customer's own historical pattern, not just a fixed rule.
None of these rules work well in isolation. A velocity rule without counterparty aggregation misses structuring across multiple recipients. New-account monitoring without behavioural baselines can't distinguish a legitimately active new customer from an abusive one. The rules need to work as a system.
From alert to decision
A rule firing is not, by itself, a compliance outcome — it's the start of a workflow. What happens next determines whether monitoring is actually effective:
- The rule fires and a decision is returned — ideally before the transaction settles, not after.
- The decision routes to the right place. A CLEAR decision needs no human involvement. FLAGGED proceeds but opens a case for review. HELD_FOR_REVIEW or BLOCKED requires action before or instead of execution.
- An analyst investigates with the evaluation context already attached — which rule fired, the customer's risk state, related transaction history — rather than starting from a raw transaction log.
- A disposition is recorded — the case is closed, escalated, or results in an STR filing, and that decision itself becomes part of the evidence record.
What a regulator actually expects to see
When the CBN or NFIU asks about a specific transaction or customer, the answer that holds up is a contemporaneous record: what rules evaluated the transaction, what the customer's risk state was at that moment, what decision was made, and when — not a narrative reconstructed after the fact from scattered logs and spreadsheets.
This means the evidence requirement isn't just about generating alerts — it's about writing an immutable record of every evaluation, including the CLEAR decisions that never became alerts. A regulator asking “how was this specific transaction handled?” deserves an answer for the clean transactions too, not just the flagged ones.
Where to start if you're building this today
If your fintech is still relying on manual review or a basic rules list, the practical starting point isn't a complete rebuild — it's:
- Get a real-time decision in the critical path for your highest-risk transaction types first.
- Establish one authoritative customer risk state, rather than scattered flags across systems.
- Make sure every decision — including CLEAR — writes to an evidence record automatically, not manually.
- Build the case-management workflow before you need it for an examiner request, not during one.
This is exactly the architecture Fintegrity is built around — see how our transaction monitoring works or how it fits specifically for the Nigerian market.