In Part One, we established why the CBN’s new Baseline Standards for Automated AML Solutions rank among the world’s best. Here, we examine the risks those Standards create and the hard governance work that genuine compliance requires.

A regulatory framework is only as valuable as the quality of its implementation.

The CBN has been explicit on this point from the opening pages of its new Baseline Standards – they are designed to ensure “demonstrable effectiveness and not merely feature-based compliance or vendor-driven implementation”.

That phrase is both an aspiration and a warning. It tells institutions precisely what the CBN will be looking for when it examines compliance and what will not satisfy it.

Other News

What follows is an analysis of the ten most significant risks embedded in the new framework, explained in terms that non-technical readers can follow, with the supporting detail and specific Standards references that Compliance Officers and Risk Managers need to act on.

Algorithmic Bias

AI models used for customer risk scoring draw on attributes the Standards explicitly reference – geography, occupation, declared income, transaction channel and customer segment (§5.5a.iv). These variables can act as proxies for demographic characteristics.

A model trained predominantly on urban, formally employed, high-income customers will systematically score customers outside that profile as higher risk – not because they are, but because their behaviour looks statistically unfamiliar to the model.

In Nigeria’s context, the practical implications are significant. The country’s financial system serves extraordinary customer diversity – informal traders, agricultural producers, diaspora remittance recipients and mobile money users whose transaction patterns bear no resemblance to a Lagos salary earner. Bias here is not merely an ethical concern; it is a legal one.

The Nigeria Data Protection Act (NDPA) 2023 confers rights on individuals in relation to automated decisions that significantly affect them. Institutions that cannot demonstrate equitable treatment across their customer base carry regulatory and legal exposure that compounds over time.

The Standards require fairness audits and bias testing as part of annual independent model validation (§5.5b.i). What they do not yet specify is a fairness metric, a testing methodology or an acceptable disparity threshold – a gap that institutions must fill in their own governance frameworks.

What institutions must do – Before any AI model is deployed, define the customer dimensions to be tested – at a minimum geography, income band, business type and transaction channel.

Run disaggregated performance analysis across each dimension before go-live and at every validation cycle. Document adverse findings and remediation steps. Report fairness metrics to the Board Risk Committee as a standing agenda item, not as an appendix.

Model Drift

The AI model validated and deployed at the point of compliance will not remain equally accurate indefinitely. Financial crime typologies evolve. Products change. Customer behaviour shifts. Sophisticated financial criminals actively probe detection systems and adapt their methods to evade learned patterns. A model can degrade significantly between annual reviews while continuing to generate alerts and maintaining the outward appearance of function – what practitioners call silent deterioration.

The Standards require annual independent validation covering performance drift (§5.5b.i) and ongoing scenario tuning (§5.5b.iii). Annual validation is the regulatory floor. For institutions with material transaction volumes or rapidly evolving portfolios, it is not sufficient as a stand-alone control.

What institutions must do – Track three metrics monthly between validation cycles – alert generation rate per thousand transactions, true positive rate among investigated alerts and the rate of alerts resulting in Suspicious Transaction Report (STR) or Suspicious Activity Report (SAR) filings. Define threshold values such that material deviation triggers an out-of-cycle review without waiting for the annual schedule. The model governance committee is required under §5.5b. We should review these metrics at every meeting.

Explainability Failure

The more sophisticated an AI model, the harder it typically is to explain what it is doing. A rule-based system is fully transparent; every decision traces to a defined condition. An advanced ensemble model builds complex internal relationships between hundreds of variables whose interactions cannot be reduced to a simple causal account.

The Standards address this directly. Section §5.5a.v requires that where AI and ML are used, the institution must provide “clear, auditable information on the key factors that contributed to the alerts to support human review”. Section §5.4a.iv requires human oversight and explainability as conditions of AI deployment. The NDPA 2023 reinforces this with specific obligations around automated individual decisions – an institution that cannot explain to a regulator or a court why a transaction was flagged or an account action taken carries legal exposure that is difficult to bound.

The post-hoc explainability tools vendors typically provide (mathematical techniques known as SHAP values and LIME, which attempt to describe why a model made a particular decision) are useful approximations but have known limitations. They describe what the model probably considered; they do not provide a definitive causal account and should not be presented as such in regulatory submissions.

What institutions must do – Before deployment, apply a practical explainability test. Sit a senior Compliance Officer in front of a live AI-generated alert alongside the model’s explanation and ask whether they can document the reasoning in terms a CBN examiner would accept? Can they explain it to a customer who disputes the decision? If the answer is consistently no, the model is not operationally ready for that category of decision.

Automated Alert Closure

Section §5.5b.vii of the Standards permits institutions to close certain low-risk alerts automatically (without human investigator review), subject to strict conditions –

  1. The alert must be generated by a governance-committee-approved rule;
  2. The closure decision must draw explicitly on both transactional context and current KYC/KYB data.
  3. The customer’s risk classification must be Low and unchanged within the preceding review period; and
  4. No prior unresolved alerts may exist for that customer.

The CBN requires board-approved ceilings on the proportion of alerts eligible for this treatment, CBN notification, and mandatory escalation when those ceilings are materially exceeded.

The operational logic is sound – high-volume monitoring systems generate alert volumes that would overwhelm even well-resourced compliance teams without some automation. But the conditions’ precision is also their vulnerability. A financially sophisticated actor with sufficient patience can engineer a profile meeting every criterion and then use it to move money through a window the system treats as safe.

What institutions must do – Set the automated closure ceiling conservatively at initial deployment. Record it in the Board minutes. Define back-testing methodology in advance – minimum sample size, look-back period and the adverse finding threshold triggering mandatory out-of-cycle review. Any quarter in which actual automated closures materially exceed the approved ceiling must be escalated to the Board and reported to the CBN as required under §5.5b.vii.

Training Data Quality and Adversarial Risk

AI models are bound by the quality and representativeness of the data on which they are trained. Historical AML/CFT data in Nigeria may be incomplete, inconsistently labelled or reflective of past investigative priorities rather than current risk typologies. A model trained on this data inherits its gaps and distortions.

The Standards’ requirement in §5.4a.vi to incorporate credible external data sources to enhance risk scoring is sound policy, but it expands the risk surface. External feeds introduce data provenance questions – a feed that is poorly maintained, commercially motivated or (in an adversarial scenario) deliberately manipulated to influence model outputs can corrupt risk scoring in ways that standard validation does not easily detect. Adversarial manipulation of ML systems is a recognised and studied attack vector in cybersecurity research.

What institutions must do – Document data lineage (provenance, labelling standards, update frequency and quality metrics) for all training and calibration data. Maintain a risk register for external data feeds, treating each as a potential control vulnerability. Cross-reference feeds where possible to prevent single-source dependency. ISO 42001, which §6d makes mandatory, provides the governance framework for this discipline.

False Positive Overload

Alert fatigue is one of the most consistently documented failure modes in global AML compliance. When compliance investigators spend their working day reviewing high volumes of alerts that turn out to be innocent, two things happen –  they become conditioned to process cases quickly rather than carefully and genuine suspicious cases get buried, reviewed late or handled superficially. This is how financial criminals pass through systems that are, on paper, fully operational.

The Standards require institutions to define and document false positive and false negative thresholds (§5.5b.ii) and justify threshold settings at least annually (§5.5b.iii). The burden of calibration rests on the institution. Vendor defaults configured for a different market are not an adequate starting point.

What institutions must do – Before go-live, obtain from the vendor empirical false positive rate data from comparable deployments in similar market contexts. Define an internal alert quality metric (the proportion of investigated alerts resulting in genuine escalation or STR filing) set a minimum acceptable threshold and track it monthly. Sustained underperformance is a governance trigger requiring mandatory recalibration, not a note for the next annual review.

Vendor Dependency

Most Nigerian Financial Institutions will procure rather than build their AML solutions. This is entirely practical. But it creates a structural dependency that the Standards only partially resolve through §6a (Vendor and Third-Party Management Policy), §6b (Third-party compliance obligations), §6d (ISO 42001 adherence) and §6e (heightened due diligence). The fundamental accountability position remains unchanged. The institution, not the vendor, is accountable to the CBN for system performance.

If a vendor cannot produce the technical artefacts needed for independent validation, that exposure belongs to the institution. If the system cannot be configured to the institution’s specific customer base and risk profile, the system is not compliant, regardless of how well it works elsewhere.

What institutions must do -Three contractual provisions are non-negotiable in any AML software procurement –

  1. The vendor must commit to providing model documentation and validation artefacts on regulatory request. “The model is proprietary” is not an answer a CBN examiner will accept, and it must not be accepted in a contract;
  2. The institution must have genuine configuration rights; and
  • A tested exit plan must exist before go-live.

A contract that does not contain all three should not be signed.

Legacy System Integration

Section 4 of the Standards states without qualification that AML solutions without effective linkage to CDD/KYC/KYB data are non-compliant. Section §5.10d reinforces this: institutions rated High or Above Average risk that operate AML solutions on stand-alone transaction feeds (disconnected from KYC repositories and customer risk profiles) are explicitly unacceptable to the CBN.

For institutions running legacy core banking infrastructure not designed for real-time, bidirectional data exchange, this is the most technically demanding requirement in the entire framework and the most likely source of underestimated implementation timelines. A technically connected but functionally inadequate integration (one delivering stale or incomplete KYC data to the monitoring system) satisfies the architectural requirement on paper while failing it in practice.

What institutions must do – Conduct an honest technology architecture assessment before the roadmap is submitted. Map every integration point, identify data quality and latency requirements at each point and produce a realistic engineering timeline. The roadmap submitted to the CBN should reflect that timeline honestly, including defined interim controls for any period where full integration is not yet operational. The CBN is highly unlikely to penalise honest phasing but is most likely (understandably) to penalise the appearance of compliance that turns out to be hollow.

Personal Accountability

This risk is different in kind from the others. Section 7 of the Standards ties sanctions to named accountable individuals (Executives and, in certain circumstances, Board Members) where AML controls are found to be ineffective. The Standards’ requirement for a documented governance framework with named individual accountability for system ownership, configuration, model validation, change management, access rights and incident handling (§5.9b.i) means that accountability must be specific and named.

For Boards, this creates a direct governance obligation that goes beyond approving a policy document and receiving quarterly updates. It extends to interrogating the evidence behind management’s assurances – understanding what the last independent validation actually found, what the false positive rate is and whether automated closure thresholds have been breached.

What institutions must do – Map accountability for every significant aspect of AML system governance to named individuals before the roadmap is submitted. Boards must exercise substantive oversight requiring evidence, not accepting assertions and understanding what the institution’s compliance posture actually is, not merely what management reports say about it.

Surface Compliance

The risk that connects all the others. An institution can deploy a system that meets every technical requirement on paper, while the underlying controls are not genuinely effective. The CBN has explicitly anticipated this risk and stated what it will do about it – assess demonstrable effectiveness, not feature-based conformity.

When a genuine financial crime case surfaces that the system should have caught and did not, the institution that claimed compliance is in a materially worse regulatory position than one that was honest about its gaps from the outset.

What institutions must do – Build a genuine effectiveness test into the deployment plan. Before go-live, validate that the system can detect the financial crime typologies most prevalent in the institution’s specific risk profile using typology guidance published by the NFIU and FATF, not just vendor defaults. After deployment, conduct periodic red-team exercises presenting the system with scenarios that should trigger alerts and confirming that they do. Where they do not, treat this as a Board-level governance matter.

Three Areas Where Further CBN Guidance Would Strengthen the Framework

In the spirit of constructive engagement with what is genuinely strong regulatory work, three areas merit attention in future CBN guidance.

  1. Generative AI tools (large language models being actively marketed to compliance teams for drafting Suspicious Transaction Reports (STRs), generating case narratives and summarising investigation outcomes) are not addressed in the Standards. They introduce hallucination risk and third-party data confidentiality exposure that the current framework does not contemplate. Supplementary guidance is needed before institutions deploy these tools in a regulatory context.
  2. The fairness and bias testing requirements in §5.5b.i are the right requirements but are not yet supervisable in any consistent way. Without a specified methodology, defined characteristics and an acceptable disparity threshold, well-resourced institutions will conduct rigorous testing and smaller ones will not, and the CBN will have no consistent basis to distinguish between them.
  3. Practical proportionality guidance for smaller institutions (Microfinance Banks, Payment Service Providers, Smaller Fintechs) should arrive early in the implementation window, not at its end. The gap between the Standards’ requirements and the current capabilities of these institutions is real, and acknowledging it with practical guidance is both fair and in the interest of the financial system.
Conclusion

The CBN has produced a framework of genuine international standing, technically rigorous, carefully structured and backed by enforcement provisions that make the stakes clear. The institutions that implement it seriously will be stronger, better protected and more credible to international partners as a result.

The roadmap submission due in June is not the finish line. It is the first accountability moment in a compliance commitment that will determine, in practical terms, whether Nigeria’s financial crime controls are as strong as the framework that governs them.

The CBN has been clear about what it expects. What happens next is up to the institutions.

This article draws on the CBN Baseline Standards for Automated Anti-Money Laundering Solutions (Circular BSD/DIR/PUB/LAB/019/002, 10 March 2026); FinCEN’s Notice of Proposed Rulemaking on AML Programme Effectiveness (June 2024); the EU Anti-Money Laundering Regulation 2024/1624; the EBA SupTech Report (August 2025) and EBA Fifth Biennial AML Opinion (July 2025); the New York City Bar Association Compliance Committee Report on AI and Machine Learning in AML/CFT (March 2024); and publicly available reporting on AML regulatory developments in Ghana, Kenya and South Africa. It does not constitute legal or regulatory advice.

Henry Nduka Onyiah is a Cyber Risk Advisor and an Independent Non-Executive Director of a Nigerian Financial Institution. He writes in a personal capacity.

The views expressed are entirely his own and do not represent the position of any institution with which he is associated. He welcomes reactions, views and engagement. He can be reached at onyiah@tuta.io or on LinkedIn at linkedin.com/onyiah.