AML Transaction Monitoring Software in Nigeria
The CBN's 2026 AML technology standards give deposit money banks until September 2027 and other financial institutions until March 2028. This is what the platform actually has to do, how to decide between building and buying, and what each route costs.
250+
Projects Delivered Since 2020
5
Capabilities The CBN Mandates
Sep 2027
Banks · Mar 2028 OFIs
₦15M–₦60M
Typical Build Range
We reply on WhatsApp within minutes.
The Mandate, and the Clock You Are Actually On
On 10 March 2026 the Central Bank of Nigeria issued circular BSD/DIR/PUB/LAB/019/002 setting technology standards for anti-money-laundering systems. It stopped treating AML monitoring as a policy question and made it an engineering requirement with dates attached.
| Stage | Who | By when |
|---|---|---|
| Submit a detailed implementation roadmap to the CBN | All covered institutions | 10 June 2026 — passed |
| Full compliance | Deposit Money Banks | 10 September 2027 |
| Full compliance | Other Financial Institutions — payment service providers, mobile money operators, international money transfer operators | 10 March 2028 |
Why this is urgent even though 2027 sounds far away. An AML platform is not a procurement, it is a data project. Before a single alert fires you need every transaction-producing system feeding one place in a consistent shape, historical data loaded so risk scoring has a baseline, thresholds tuned against your own book so your team is not buried in false positives, and your compliance officer trained on a workflow that will be examined. Institutions that start twelve months before the deadline are the ones that spend the last quarter arguing with a vendor instead of tuning a live system.
The Five Capabilities the Circular Requires
1. Real-time transaction monitoring
Anomalies detected in near real time rather than in a monthly batch. That means an event pipeline your core banking, switch, wallet and card systems publish into, a rules engine evaluating each transaction against typology scenarios as it happens, and the ability to hold or flag before settlement where your policy requires it. Structuring, rapid pass-through, dormant accounts waking up, round-tripping, velocity spikes and mismatches against the customer's declared profile all need to fire while the money is still traceable.
2. Dynamic customer risk assessment
Not a score set at onboarding and never revisited. Risk recalculates continuously across the customer lifecycle from behaviour, geography, product mix, counterparties, occupation and screening outcomes. A customer who moves from small regular inflows to large irregular international transfers should be re-rated automatically, and the re-rating should change their monitoring thresholds and their due-diligence requirements without anyone remembering to do it.
3. Sanctions and PEP screening
Automated screening at onboarding, on every relevant transaction, and on a schedule against the whole book as lists change. Fuzzy matching tuned for Nigerian naming conventions — multiple spellings, order variation, shared surnames — because a screening engine tuned for Western names produces either a flood of false positives or silence. Match disposition is recorded with a reason and a reviewer.
4. Enhanced KYC due diligence
Tiered verification with BVN and NIN, document and liveness capture, beneficial-ownership capture for corporate customers, source-of-funds and source-of-wealth for higher-risk relationships, and periodic refresh driven by risk rating rather than by a calendar everyone ignores. The workflow has to produce evidence an examiner can follow, not just a tick.
5. Structured STR generation
Alerts flow into a case, the case accumulates the transactions, the customer history, the screening results and the analyst's narrative, and the Suspicious Transaction Report is generated in the structure the NFIU expects rather than retyped into a form. Every decision, including a decision not to report, is recorded with its reasoning. The audit-ready trail is the point.
And the thing they do not list: tuning
A monitoring system that generates four thousand alerts a month for a five-person compliance team has failed, whatever its feature list says. Threshold tuning against your actual book, alert scoring so the worst surface first, and suppression of known-benign patterns are what make the difference between a working control and an expensive dashboard nobody opens.
Build, Buy or Integrate
We build software and we will still tell you that a large bank should probably licence an established platform. Here is the honest comparison.
| Licence a global AML platform | Custom build | Hybrid | |
|---|---|---|---|
| Best for | Deposit money banks and large OFIs with the budget and an existing vendor relationship | Mid-sized OFIs, PSPs, MFBs and fintechs whose products do not fit a bank-shaped product | Most institutions, in practice |
| Cost shape | Licence in dollars, usually per customer or per transaction, plus a substantial implementation fee | One-off build in naira plus support | Licence the screening data, build the pipeline and case management |
| Strength | Mature typology libraries, vendor takes regulatory-change risk | Fits your actual products and data, no per-transaction cost as you scale | You never rebuild sanctions data; you control the parts that are specific to you |
| Weakness | Priced in dollars against naira revenue, slow to change, and often poorly fitted to Nigerian products like agency banking, USSD and wallet float | You own the typology library and the regulatory-change burden | Requires clear ownership of the boundary |
The hybrid is what we most often recommend and most often build: subscribe to a sanctions and PEP data provider, because nobody should maintain those lists themselves, and build the ingestion pipeline, rules engine, risk scoring, case management and STR generation around your own systems. That keeps the expensive, fast-moving reference data with a specialist while the parts that depend on knowing your products stay with you.
One warning about off-the-shelf products in this market. Many were designed around retail banking in other jurisdictions, and Nigerian financial products break their assumptions: agency banking where an agent's till aggregates hundreds of customers, USSD transactions with thin metadata, wallet float, POS terminals with a merchant behind them, and multi-bank virtual accounts. If a vendor cannot show you how their model handles agency banking, they have not worked here.
The Engineering That Decides Whether It Works
Get the data in first
Every source that creates a transaction — core banking, the switch, wallets, cards, USSD, agency banking, third-party rails — publishing into one event stream with a consistent schema. This is normally sixty per cent of the project and it is the part that overruns. Start here, not with the rules.
Identity resolution
One customer may hold several accounts, a wallet, a card and a merchant profile. If your monitoring treats them as five customers, structuring across them is invisible. A single customer view with proper entity resolution is what makes the detection meaningful.
Rules your compliance officer can change
Thresholds, scenarios and risk weights as configuration with versioning and an approval step, not as code. Your compliance function must be able to tighten a threshold on Monday without a release, and must be able to show an examiner exactly what the rule was on any past date.
Case management that survives examination
Queues by risk and age, assignment and escalation, service levels on investigation, four-eyes review before closure or filing, and an immutable audit trail on every action. Examiners look at the alerts you closed, not the ones you escalated.
Test it like a control, not a feature
Replay historical data and confirm the system would have caught known cases. Run red-team scenarios where someone deliberately structures below your thresholds. Measure false-positive rate and tune. Model validation is increasingly what supervisors ask about.
And a data-protection point that is frequently missed: an AML platform concentrates BVNs, identity documents, transaction histories and behavioural profiles for your whole customer base. That makes it one of the highest-sensitivity systems you operate under the Nigeria Data Protection Act, with NDPC registration and annual compliance audit obligations. See NDPA compliance audit and CAR filing, and consider a virtual CISO if no one currently owns security for it.
Cost, Timeline and Where to Start
Monitoring core
₦15,000,000 – ₦28,000,000
Ingestion pipeline from your existing systems, single customer view, rules engine with configurable scenarios and thresholds, alert generation, case management and audit trail. Four to seven months. Enough to demonstrate real capability against the circular.
Full five-capability platform
₦30,000,000 – ₦45,000,000
Adds dynamic customer risk scoring, sanctions and PEP screening integrated with your chosen data provider, tiered KYC and periodic refresh workflow, structured STR generation, and management and board reporting. Seven to twelve months.
Group / multi-entity
₦45,000,000 – ₦60,000,000
Several regulated entities on one platform with segregated data and per-entity rules and reporting, plus model validation tooling and a regulator-facing evidence pack. Ten to sixteen months.
Start with the data pipeline and the single customer view. They are required under every option, they are the part that overruns, and they are worthless to no one — even if you later licence a vendor platform, it needs exactly that feed. Building it first means the deadline pressure lands on tuning rather than on plumbing.
Musskart Technology Limited is a registered Nigerian software company in Asaba with an Abuja office and 250+ projects delivered since 2020, building fintech, microfinance, agency banking and payments platforms. To be clear about the boundary: we build technology. We are not a regulator, an accredited body or a compliance consultancy, and we do not file returns or give legal opinions on your AML obligations. Your compliance function and your advisers own the policy; we build the system that lets them evidence it.
Related Musskart Pages
Who this applies to
The circular covers deposit money banks and other financial institutions including payment service providers, mobile money operators and IMTOs. If you run one, see also microfinance core banking, agency banking platforms and remittance and IMTO platforms.
- Fintech App Development in Nigeria — wallets, payments and the systems AML monitors
- Microfinance Banking Software — core banking for licensed MFBs
- Agency Banking Platform Development — the product most AML tools model badly
- NDPA Compliance Audit & CAR Filing — the data obligation an AML platform creates
- Virtual CISO & Managed Cybersecurity — security ownership for a system this sensitive
- Bureau de Change Software — AML at the BDC counter
Frequently Asked Questions
Start With the Pipeline, Not the Deadline
Tell us which institution type you are, what core systems you run and where you are against the circular. We will scope the ingestion layer and single customer view first — the part every option depends on.
