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.
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.
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 –
- 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;
- 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.
