· OmniGuard360
CBN AML/CFT/CPF · Nigeria · 2026
· OmniGuard360
CBN AML/CFT/CPF · Nigeria · 2026
CBN Automated AML Standards 2026
It will ask whether you can show that your AML controls work: what happened, who approved it, and why the system did what it did. The CBN’s 2026 Baseline Standards for Automated AML/CFT/CPF Solutions are built around that question. This is a practical guide to all 12 standards, what each one means operationally, and the evidence an examiner will ask you to produce.
The short version
In March 2026 the CBN issued Baseline Standards for Automated AML/CFT/CPF Solutions covering 12 areas, from customer due diligence to audit trails.
AI is not required, but your controls must be defensible (you can prove what happened), governed (you can prove who owns, approves, changes and validates them) and effective (they actually detect, investigate and report suspicious activity). Deposit money banks must comply fully by 10 September 2027. Other financial institutions have until 10 March 2028.
For every standard this page uses the same four steps: the CBN requirement, what it means operationally, what your AML system should do, and what you can show an examiner. Use it as a self-assessment.
Who must comply, and by when
The Baseline Standards apply to banks and other financial institutions under CBN supervision. The standards were issued on 10 March 2026 and set minimum functional, governance and control requirements for automated AML, CFT and CPF solutions (anti-money laundering, countering the financing of terrorism, and countering proliferation financing).
Two points need care. The roadmap deadline has gone. Institutions were asked to submit an implementation roadmap within three months, by 10 June 2026. If yours has not been finalised, that is the first gap to close, and it is easier to close in writing now than to explain later. The CBN’s roadmap template asks for current state, target state, actions, owners, dates, status and available evidence.
Microfinance banks should be careful with dates. MFBs should treat the 24-month timeline for Other Financial Institutions as their working implementation deadline, subject to their specific CBN classification and any later supervisory direction. Confirm your classification with your CBN supervisor rather than relying on a general reading.
The standards do not replace existing law. They sit alongside:
The biggest change
The CBN expects the system to judge activity in the context of the customer’s KYC and KYB information, risk classification and wider profile.
It says plainly that an AML solution without effective linkage to CDD/KYC/KYB information and customer risk assessments will not be regarded as compliant. If your monitoring tool receives transactions from core banking and nothing else, this is the change that affects you most.
AI is not the requirement
The standards are technology-neutral. Rules-based systems, machine learning, hybrid approaches and other technologies are all open to you, provided the implementation demonstrably meets the regulatory expectations. The CBN also says it does not approve or certify AML vendors. Compliance is assessed at the level of the institution: governance, configuration and effectiveness. A vendor cannot sell you compliance, and “we bought an AI-powered system” is not an answer an examiner can accept.
The three things the CBN’s Guidance Note keeps returning to
The Guidance Note of 31 March 2026 emphasises three questions. We have built this guide around them.
At a glance
One idea that applies to all 12
Think of an evidence room: the set of things your compliance team could put in front of an examiner without a scramble.
Policies, named owners, committee minutes, approvals.
Scenarios, thresholds, rule changes and who approved them.
Alert volumes, false positives, false negatives, back-testing, model validation.
Cases, decisions, escalations, written rationale.
STRs, SARs, CTRs, FTRs, submission records.
Architecture, integrations, data flows, APIs.
Immutable logs, user actions, timestamps, configuration history.
Having a capability and being able to evidence it are different things. The CBN’s own roadmap template treats unsupported claims of capability as insufficient. Each standard below ends with the evidence to put in the room.
Standard 1
The AML solution must support, at minimum, customer identification and verification, customer risk assessment, sanctions and watchlist screening, PEP and high-risk screening, transaction monitoring, case management, regulatory and internal reporting, audit and governance, and data protection and security. It must be proportionate to your size, complexity, customer base and risk profile, with appropriate resilience and disaster recovery.
What it means operationally. The question is not “do we have an AML vendor?” It is whether your technology gives you an integrated AML control environment. A screening tool in one place, a monitoring tool in another and case notes in spreadsheets may each work. Together they usually do not produce a single trail an examiner can follow.
What your system should do
Evidence for examination
Standard 2
The CBN requires end-to-end support for customer due diligence (CDD), enhanced due diligence (EDD), KYC and KYB, including risk profiling, historical data, behavioural analysis and continuous linkage between KYC/KYB, customer risk and transactions. Your transaction monitoring system should know who the customer is.
A ₦10 million transaction means different things depending on who sends it:
Without KYC and KYB data inside the monitoring logic, the system sees an amount. It cannot see the mismatch. This is the practical meaning of the CBN’s linkage requirement.
What your system should do
Evidence for examination
Where examiners sample
Corporate accounts deserve extra attention. Beneficial ownership is where weak KYB shows up fastest, and examiners tend to pick corporate accounts when they sample.
Standard 3
The CBN expects relevant domestic and global sanctions and watchlists, matching logic that handles name variations, timely list updates, internal watchlists, PEP and high-risk lists, adverse media monitoring, and the ability to interdict or block confirmed sanctions matches.
Distinguish screening capability from screening evidence. Having a list is capability. Showing what happened to a specific hit is evidence. An examiner should be able to ask you:
If you can answer all five from the system in a few minutes, you are in good shape. If answering means asking someone to search emails, you are not.
What your system should do
Evidence for examination
Standard 4
The CBN expects dynamic risk assessment, not a static rating assigned at onboarding. The system should reassess risk as new customer data, behaviour, external risk factors, transaction patterns and business-line risk change, and produce evidence showing why a customer’s classification changed.
A customer opens an account and is rated Low Risk. Six months later their transaction volume has increased materially, their counterparties have changed, funds are arriving from a new geography, there are unusual cross-border flows, and their behaviour no longer matches the profile they gave you. A static rating still says Low Risk. A dynamic one should have moved, and should be able to tell you which factors moved it.
The second half matters as much as the first. An examiner will ask why a rating changed. “The model said so” is not a reason.
What your system should do
Evidence for examination
Standard 5 · the largest requirement in practice
This is the largest requirement in practice, and the one most institutions underestimate.
A CBN-aligned transaction monitoring system should monitor transactions and customer activity using risk-based scenarios, configurable rules, customer segmentation, behavioural analysis and relevant KYC/KYB information. It should identify potentially suspicious ML/TF/PF activity, generate alerts, support investigation and keep an auditable record of decisions. The CBN also expects it to be integrated with customer risk information rather than relying on raw transaction feeds alone.
The CBN references predictive analytics, anomaly detection, behavioural pattern recognition and automated risk scoring where appropriate. In practice that breaks into four capabilities.
1. Rule-based monitoring
Scenarios for unusual transaction size, rapid movement of funds, velocity, structuring, unusual cash activity, unusual geographic activity, dormant-account activity and unexpected account behaviour. Rules remain the backbone because they are transparent and easy to explain to an examiner.
2. Behavioural monitoring
Compare expected behaviour (from KYC, segment and history) with observed behaviour. A rule that fires at ₦5 million treats a market trader and a mining company identically. Behavioural monitoring asks whether this is normal for this customer.
3. Customer segmentation
Thresholds should differ for retail, SME, corporate, high-net-worth, PEP, high-risk sectors and high-risk geographies. One set of global thresholds is hard to defend.
4. Network analysis
The CBN specifically requires support for related-party mapping, network analysis and peer grouping. Monitoring one account at a time can miss coordinated activity spread across many. Each account looks ordinary. The pattern only appears when you look at the links between them.
Why account-by-account rules are not enough
That is the gap Autogon’s own pilot work has been designed to expose. In a 90-day pilot, OmniGuard360 identified six mule and structuring networks, covering 240 accounts and about ₦310 million (roughly $230,000) in transaction volume, that the institution’s existing rule-based monitoring had not detected. This is a single pilot at a single institution, but it shows why account-by-account rules are not enough.
Does CBN require AI for automated AML?
No. The Guidance Note states the standards are technology-neutral. The requirement is demonstrable effectiveness. AI and machine learning become relevant in anomaly detection, behavioural analysis, risk scoring, adaptive learning and model calibration. But the CBN pairs any use of them with conditions you need to be able to meet:
If you cannot meet those conditions for a model, a well-governed rules-based approach is the safer position.
False positives and false negatives
Too many alerts and your team drowns. Too few and you may be missing real activity. The CBN requires you to define, document and periodically review false-positive and false-negative thresholds that fit your risk profile. You must also document scenario parameters, thresholds and tuning decisions.
False negatives are the harder half. You cannot count what you did not detect, so you need a method: back-testing, sampling, typology exercises, or independent review. Whatever method you choose, write it down and apply it consistently.
Can AML alerts be automatically closed?
Only under tightly defined conditions. The CBN allows automated closure for clearly low-risk scenarios where specified conditions are met. They include approved rules, transactional and KYC/KYB context, a stable low-risk classification, and no unresolved alerts or open cases for the customer. Back-testing and governance apply. Auto-closure is not a shortcut for alert backlogs. It is a governed control that you have to test.
Evidence for examination
Standard 6
A unified AML and fraud platform is not universally mandated by the CBN. Where the same platform is used for both, fraud capabilities must be logically separated and governed. Higher-risk institutions, and those with material electronic or card transaction volumes, are expected to have a credible roadmap towards a unified financial-crime architecture.
Be careful not to read this as “you must buy one platform for AML and fraud.” That is not what it says. The practical point is simpler. Fraud and money laundering share signals. A mule account is a fraud problem and a laundering problem at once. If your fraud team and AML team cannot see each other’s alerts, you will investigate the same account twice, or miss it entirely. Institutions with significant electronic and card volumes should be able to show a credible path towards bringing those views together.
What your system should do
Evidence for examination
Standard 7
Detection is not compliance. Investigation is where the control becomes defensible. The CBN explicitly requires enterprise case management and a full audit trail of case actions. An alert that fired but cannot be shown to have been reviewed is not a control.
What your system should do
Evidence for examination
The test
Whether you can reconstruct an investigator’s work from the system alone.
Standard 8
The CBN requires timely, accurate and complete regulatory submissions, with internal governance over reporting. Covered reports include suspicious transaction reports (STRs), SARs, currency transaction reports (CTRs), foreign transaction reports (FTRs) and other applicable AML/CFT/CPF returns.
Generating a report is not enough. The report must be traceable back to the underlying investigation and data. When an examiner picks an STR, they should be able to follow it backwards: report, case, alert, scenario, transaction, customer record. If any link depends on someone’s memory, that link is a finding.
What your system should do
Evidence for examination
Standard 9 · the one that decides the rest
The CBN requires tamper-proof, immutable audit trails covering system activity, configuration changes, access, alert dispositions and report generation, with forensic linkage across customer data, transaction data, alerts, user actions and regulatory returns.
This is the standard that decides whether everything else is credible. If the logs can be edited, nothing built on them is evidence.
What evidence will CBN examiners ask for
What your system should do
Governance sits next to this. Someone must own each control, someone else must approve changes, and there must be a record of committee oversight.
Standard 10
The CBN requires secure, bidirectional integration with core banking, KYC and other relevant systems, with real-time or near-real-time exchange of customer, account and transaction information.
For institutions with high or above-average risk, the CBN says standalone transaction feeds are unacceptable. Those institutions need integration with KYC/KYB repositories and customer risk profiles. The flow the standards describe looks like this:
What your system should do
Evidence for examination
Standard 11
The CBN includes encryption, role-based access control (RBAC), multi-factor authentication (MFA), data protection under the Nigeria Data Protection Act (NDPA), data sovereignty, retention and destruction, and resilience (RTO, RPO and business impact analysis) in the AML system baseline.
AML systems hold some of the most sensitive data in the institution: identity records, beneficial ownership, transaction history and suspicious-activity decisions. Access should be narrow, logged and reviewed. Where the data sits also matters, so ask any vendor where it is stored and who can reach it.
Evidence for examination
Standard 12
The least glamorous standard, and the one that determines whether compliance staff can run the system without constant IT support. Analysts should be able to see alerts, customer context and history in one view. Compliance should be able to adjust scenarios, thresholds and workflows within governance controls, with every change recorded and approved.
If every threshold change needs a vendor engagement, your ability to tune against false positives, which the CBN requires you to review periodically, is limited by someone else’s schedule.
Evidence for examination
Self-assessment · 25 questions
Try answering these without opening an email thread. Where you cannot answer one in a few minutes, you have found a gap.
Risk and monitoring
Effectiveness and models
Cases and reporting
Screening and audit
Integration and resilience
Readiness
Vendor due diligence · 20 questions
The CBN does not certify vendors, so the burden of due diligence is yours. These 20 questions are written to surface evidence, not marketing claims.
Ask for a demonstration against your own scenarios, not a slide. Question 20 is the one most often skipped, and the one you will care about most if things go wrong.
Get the checklist
The structure of the CBN’s roadmap template is the structure you should use to track your own readiness. Our workbook follows it, one row per requirement, across these columns:
Status values use the CBN’s own terms:
How an integrated platform helps
The responsibility sits with the financial institution, not with the vendor. No product makes an institution compliant. What a platform can do is give your compliance team the controls, integration and evidence trail to demonstrate compliance.
OmniGuard360, by Autogon, is built for that role. It is an API-first decision layer that sits in front of existing core banking and payment systems rather than replacing them, with on-premise and hybrid deployment options for institutions with data-residency requirements. It covers real-time transaction monitoring, sanctions, PEP and adverse-media screening, and structured reporting in goAML format. Here is how that maps to the framework.
The right-hand column is the point. Every row has something only you can do. A platform that tells you otherwise is overselling.
Where to start
KYC linkage, audit trails, case-to-report traceability and documented tuning. Deposit money banks have until 10 September 2027, other financial institutions until 10 March 2028, and the implementation roadmap was due on 10 June 2026.
Real-time transaction monitoring, sanctions, PEP and adverse-media screening, network analysis and structured goAML reporting, with the audit trail an examiner can follow end to end.
Explore OmniGuard360 → Free sanctions and PEP screeningSanctions, PEP and enforcement screening on a consolidated global list, free to try. A quick way to see the matching logic Standard 3 asks for in action.
Try the watchlist →To see how OmniGuard360 supports an integrated AML and FRAML control environment against your own requirements, speak with the Autogon team.
Frequently asked questions
Minimum requirements across 12 areas: AML solution functionality, CDD/KYC/KYB, sanctions and PEP screening, risk assessment, transaction monitoring, fraud monitoring, case management, reporting, audit and governance, integration and scalability, security and data protection, and user interface and customisation. They were issued on 10 March 2026.
See the table near the top of this page. Each standard is also broken out in full below it.
The Baseline Standards set requirements for automated AML solutions, including transaction monitoring, for institutions under CBN supervision. Proportionality applies, so the scale and sophistication expected depends on your size, complexity and risk profile. Confirm the position for your institution type with your supervisor.
No. The standards are technology-neutral. Rules-based, machine learning and hybrid systems are all acceptable if they demonstrably meet the expectations. If you use AI/ML, independent validation is required at least annually and on significant change.
10 September 2027 for deposit money banks and 10 March 2028 for other financial institutions. The implementation roadmap was due on 10 June 2026.
Treat 10 March 2028 as the working deadline, subject to your CBN classification and any later supervisory direction. Complete a gap assessment against the 12 standards, file or update your implementation roadmap, and prioritise KYC-to-monitoring linkage, case management and audit trails.
For higher-risk institutions, the CBN says standalone transaction feeds are unacceptable. Monitoring needs to be linked to KYC/KYB repositories and customer risk profiles.
Secure, bidirectional integration with core banking, KYC and other relevant systems, with real-time or near-real-time exchange of customer, account and transaction data.
Relevant domestic and global lists, name-variation matching, timely updates, internal watchlists, PEP and high-risk lists, adverse media monitoring, and the ability to block confirmed matches.
Tamper-proof, immutable trails covering system activity, configuration changes, access, alert dispositions and report generation, with linkage across customer data, transactions, alerts, user actions and returns.
Only for clearly low-risk scenarios meeting defined conditions: approved rules, transactional and KYC/KYB context, stable low-risk classification and no open alerts or cases. Back-testing and governance are required.
Enterprise case management with full audit trails of case actions.
Not universally. Where one platform is used for both, fraud capabilities must be logically separated and governed. Higher-risk institutions and those with material electronic or card volumes are expected to have a credible roadmap towards a unified financial-crime architecture.
See the examiner question table under Standard 9.
Build the evidence room, answer the self-assessment questions above, and close gaps in the order that matters most: KYC linkage, audit trails, case-to-report traceability and documented tuning.
This guide is an operational summary of the CBN’s 2026 Baseline Standards for Automated AML/CFT/CPF Solutions and the accompanying Guidance Note, written to help compliance teams self-assess. It is not legal advice and does not replace the CBN’s own documents or your supervisory correspondence. Confirm your institution’s classification, deadlines and specific obligations with your CBN supervisor. Figures from Autogon pilot work reflect a single engagement and are shared as illustration, not a performance guarantee.