The CBN's final automated AML baseline standards were issued on 10 March 2026. Implementation starts on issuance, with full compliance within 18 months for DMBs and 24 months for OFIs. Institutions must submit implementation roadmaps within three months. The final instrument, not the earlier exposure draft, should anchor your programme.
The engineering question is not whether a vendor can generate alerts. It is whether your institution can explain a transaction, a rule and an investigator's decision from end to end. Start by mapping AML & compliance engineering to the underlying customer records, monitoring controls and case workflows, then identify where information or accountability breaks. This article sets out a practical architecture and delivery sequence. It is a systems guide, not a substitute for licence-specific legal advice or a review of the final standards with your compliance function.
Key takeaways
- Use the final 10 March 2026 instrument, not the May 2025 exposure draft. DMBs and OFIs have different full-compliance windows, and the roadmap is an earlier deliverable.
- A monitoring rule is only as useful as its inputs. Trace customer identifiers, beneficial ownership, account relationships and transaction status across the systems feeding it.
- Case management should preserve the evidence behind escalation, closure and reporting. Store the rule version, analyst rationale, approvals and submission receipts together.
- STRs are suspicion-based, not minimum-value reports. Build workflows that support reporting within 24 hours of identifying suspicion, with ownership and escalation clearly assigned.
- Treat compliance as continuing operation: test integrations, review access, reconcile reporting and manage rule changes after the initial implementation is complete.
What changed in the final CBN standards?
The final standards replace uncertainty about a draft with an implementation programme. The 20 May 2025 circular was an exposure draft, not a final twelve-month mandate. The issued standards require attention to real-time monitoring and reporting, integration, customer due diligence, case management and auditable controls. Read those requirements against the institution's actual licence and operating model.
Avoid translating every requirement into a product checkbox. The table below turns common procurement statements into questions about operating evidence:
| Stack claim | What it implies | Evidence to request |
|---|---|---|
| Real-time monitoring | Transactions reach detection rules | Event timestamps, retry logs and latency tests |
| Integrated customer view | Records link consistently | Identifier mapping and reconciliation of missing records |
| Risk-based screening | Lists and risk profiles stay current | Source provenance, update history and review approvals |
| Investigation workspace | Analysts can explain decisions | Case histories, evidence snapshots and escalation records |
| Automated reporting | Filings reach the intended channel | Validated payloads, receipts and rejected-file handling |
| Auditable controls | Changes can be reconstructed | Versioned rules, access logs and approval records |
A dashboard may show a healthy pipeline while one account feed is missing. Reconcile source totals to ingested events and explain cancellations, reversals and duplicates. A small but unexplained gap can undermine confidence in an entire period of monitoring. Give each failed integration an owner, an alert and a controlled replay procedure.
How do you map obligations to your AML stack?
Begin with the regulated activity and its data, not with the vendor presentation. Map obligations to controls, controls to systems, and systems to named owners. Then test what happens when a feed is late, a list update fails or an investigator is unavailable.
Before choosing a platform, ask five questions:
- Which records identify the customer? Customer IDs, ownership links and risk profiles.
- Which events need monitoring? Payments, reversals, transfers and account changes.
- Where is the decision recorded? A case history with evidence and rationale.
- Who can change a detection rule? Named authors, independent approvers and controlled access.
- How is a filing reconciled? Submission status, receipts and exception ownership.
These questions should inform the design of CDD and customer records before monitoring begins. Preserve the source and effective date of identity and beneficial-ownership information, so analysts can distinguish the record available at the time from a later correction. The same discipline belongs in monitoring and case management , where an alert should retain its scenario version and the relevant transaction context. Finally, connect decisions to
regulatory reporting through controlled preparation, validation, approval and submission. Assign each interface an operational owner. Do not assume that a successful API request means the case was filed, accepted or reconciled.
AML controls, workflow by workflow
The control objective stays consistent, but each workflow has different failure modes. Use the following areas to organise implementation discussions with operations, compliance and engineering.
Customer due diligence and ownership
Keep identity, beneficial ownership and risk classifications linked to stable customer identifiers. Record source provenance, review dates and changes. Incomplete records need a queue and an accountable resolver; they should not silently become low-risk customers because a mandatory field is missing.
Transaction monitoring and data quality
Test completeness before tuning scenarios. Compare ledger events with the monitoring feed, including reversals and late arrivals. Agree how the system handles replayed messages so that restoring a feed does not create duplicate cases or conceal events that should have been reviewed.
Sanctions screening and list updates
Define which records are screened, which lists apply and how updates are controlled. A match needs a documented review path, not automatic dismissal based on a name score alone. Retain the list version and relevant matching context so the outcome can be explained later.
Investigation and escalation
Give analysts the relevant transactions, linked accounts and customer history in one case. Record who reviewed the alert, why it was escalated or closed, and what evidence supported the decision. Work queues should reveal overdue cases and absent owners rather than merely count activity.
Reporting and record retention
Separate report preparation, approval and submission where the operating model requires it. Validate the file, capture receipts and reconcile every expected filing to its outcome. Define retention and controlled deletion with compliance and privacy teams rather than allowing storage defaults to decide.
| Workflow | Control evidence | Failure to avoid |
|---|---|---|
| Customer records | Identity links and review history | Orphaned customer identifiers |
| Monitoring | Feed reconciliation and rule versions | Silent gaps in transaction data |
| Screening | List history and match decisions | Unexplained false-positive closure |
| Investigation | Rationale, escalation and approvals | Unowned alerts |
| Reporting | Validated files and receipts | Assuming submission means acceptance |
From transaction to filing: a worked example
Consider a hypothetical payment pattern that creates an alert. The monitoring service receives the transactions, associates them with a customer and records the scenario version. Nothing in this example describes a Sparkr client deployment; it is a way to test architecture before procurement or acceptance.
The aim is simple: an independent reviewer should be able to follow the same chain from source event to the analyst's conclusion. Each step needs a stable reference and a clear owner.
| Step | Proposed control | Evidence retained |
|---|---|---|
| Ingestion | Validate and reconcile source events | Event IDs, totals and exception logs |
| Matching | Resolve account and customer relationships | Mapping version and unmatched records |
| Detection | Run a controlled scenario | Rule version and triggering data |
| Investigation | Review linked activity | Analyst rationale and evidence snapshot |
| Approval | Apply the reporting decision process | Approver identity and decision timestamp |
| Submission | Validate and send through the agreed channel | Payload reference and submission receipt |
| Reconciliation | Resolve rejection or missing acknowledgement | Final status and exception closure |
Keep two distinct reference points in view. The CBN AML/CFT/CPF Regulations 2022 provide the wider framework for due diligence, monitoring, reporting, records and internal controls, while NFIU goAML is the reporting platform on which reporting entities register. An integration is not an endorsement by either authority.
Test the unhappy paths before acceptance: rejected payloads, expired credentials, a reporting approver on leave and a missed acknowledgement. These are operational conditions, not unusual edge cases. Document fallback steps and verify that they preserve the audit trail without bypassing approval or confidentiality controls.
Related work · Cybersecurity conceptSysthems: an independent cybersecurity website conceptView the project Why does evidence matter more than a dashboard?
An attractive alert count does not establish that monitoring is complete or decisions are timely. The NFIU STR guidance makes clear that suspicious transaction reporting is based on suspicion rather than a minimum amount. Under the reporting regime, STRs must be reported within 24 hours of identifying suspicion. Systems should make that decision point visible, with escalation and accountable cover when the usual reviewer is absent.
Do not merge that workflow with currency transaction reporting. The CBN AML/CFT/CPF Regulations 2022 set CTR thresholds above ₦5 million for individuals and ₦10 million for bodies corporate, with reporting within seven days. These reporting thresholds are distinct from cash-payment restrictions.
Evidence should show what the institution knew, which control ran and who acted. The final automated AML standards should therefore inform acceptance tests, not just procurement language. Ask for traceable results using representative data and approved scenarios. Record any manual dependency explicitly, including its owner and monitoring arrangements, so a temporary workaround cannot quietly become a permanent blind spot.
One control model for compliance, engineering and audit
Each team needs a different view of the same control chain. Keep identifiers and evidence consistent so reviews do not depend on reconciling competing spreadsheets:
| Audience | What they check | Supporting evidence |
|---|---|---|
| Compliance | Are alerts reviewed and reporting decisions explained on time? | Case history, rationale, escalation and receipts |
| Engineering and operations | Are feeds complete and changes controlled? | Reconciliation logs, tests and release approvals |
| Internal audit | Can the institution reconstruct how a control operated? | Versioned evidence and accountable review records |
Use one requirements register and connect it to delivery tickets, test results and operational procedures. A fixed project may suit bounded integration work; an ongoing delivery model may suit continued tuning and backlog changes. The commercial trade-offs are set out in software development as a service versus a fixed project..
Should monitoring and case management be designed together?
Yes. Detection without a usable investigation workflow creates a queue rather than a control. Agree the analyst's evidence view, escalation path and decision states alongside the event schema. A case must distinguish a new alert, an investigation, an approval request and a filing, instead of treating all work as an interchangeable status update.
Design access boundaries at the same time. Separate permission to view sensitive customer data from permission to close a case, alter a rule or approve a report. Test those permissions through the API as well as the interface, and make exceptional access visible to reviewers.
Independent security assessment should cover these workflows without disrupting live reporting. Agree the environment, permitted actions and evidence-handling rules in advance. Useful findings need reproducible detail and an explicit retest outcome, as described in what a regulator-ready VAPT report contains..
When should implementation work begin?
Implementation starts from issuance on 10 March 2026. The roadmap is due within three months; full-compliance windows are 18 months for DMBs and 24 months for OFIs.
| Stage | Immediate priority | Avoid deferring |
|---|---|---|
| Applicability review | Confirm licence, obligations and accountable sponsor | Legal and compliance interpretation |
| Roadmap | Baseline gaps, dependencies, milestones and owners | Evidence behind delivery estimates |
| Implementation | Data integration, workflow controls and testing | Operational procedures and exception handling |
| Acceptance | Demonstrate controls against the agreed requirements | Retesting and unresolved-risk decisions |
Incident readiness should follow the same evidence discipline as NDPA breach response and the operational design principles in internal tools people actually use. Scope and delivery estimates should follow a review of source systems, data quality, transaction flows and integration constraints. Avoid a universal price or completion promise: the amount of remediation depends on what the institution already operates and what the assessment finds.
What to look for in an AML engineering partner
The right partner asks for the control framework, data dictionary and reporting process before proposing a platform. Evaluate the delivery team's approach against these practical questions:
- They examine the source data: they reconcile identifiers, event states and known feed gaps before proposing monitoring rules.
- They can explain the obligation-to-control map: in language compliance and engineering can both challenge.
- They design exception handling explicitly: rejected files, failed feeds and absent reviewers have owners.
- They connect build work to operating evidence: tests, access decisions and runbooks are delivery outputs, not later additions.
- They separate support from endorsement: no claim of CBN approval, NFIU endorsement or guaranteed compliance.
Ask who owns each integration after go-live and how rule changes will be reviewed. Those questions belong in the scope of AML & compliance engineering..
Checklist: is your AML delivery plan defensible?
- The requirements register cites the final standards and the relevant institutional scope.
- Roadmap milestones have owners, dependencies and evidence-based acceptance criteria.
- Source events reconcile to the monitoring pipeline, including reversals and rejected records.
- Customer identifiers, ownership information and risk history remain traceable through each case.
- Rule changes and access permissions follow documented approval paths.
- Reporting workflows retain validation results, approvals, receipts and reconciliation outcomes.
- Operations can explain what happens when a feed fails or a reviewer is unavailable.
A defensible AML stack connects regulatory expectations to evidence that people can actually review. It is not a claim that a tool guarantees compliance. Start with your institution's operating model and the relevant requirements for Banking & Financial Services or explore our AML & compliance engineering. If fragmented records, reporting handoffs or legacy integrations are making that work difficult, let's discuss the scope.
