Disclaimer:This article is educational and reflects Fintegrity's understanding of publicly available CBN guidance. It is not legal advice. Verify all regulatory requirements against official CBN and NFIU circulars and consult a qualified compliance professional before making compliance decisions.

Why this matters now

The CBN's AML/CFT Baseline Standards aren't new — but enforcement has shifted. The question regulators are now asking isn't “do you have a policy?” It's “show me the evidence that this transaction was reviewed before it processed.” That shift from policy compliance to evidence-based compliance is what makes the technology layer so important.

For most Nigerian fintechs, the gap between “we have an AML programme” and “we can demonstrate every transaction was reviewed according to it” is large. This guide is about closing that gap — standard by standard.

The key shift:Regulators have moved from asking “do you have a policy?” to “can you prove every transaction was evaluated against it?” That requires technology, not documentation.

The 12 standards at a glance

The CBN's Baseline Standards cover 12 distinct requirements. They range from institutional-level programme requirements (S-01, S-11, S-12) to transaction-level controls (S-04, S-05, S-07, S-08) to recordkeeping and reporting requirements (S-06, S-07, S-09). Not all of them are technology problems — but most of the operational ones are.

S-01

AML/CFT Programme

Fintechs must maintain a documented AML/CFT programme covering policies, procedures, and controls. Technology role: provides the controls infrastructure the programme document references.

S-02

Customer Due Diligence (CDD)

Know your customer — BVN/NIN verification, identity checks, and risk classification at onboarding. Technology role: enforces tier limits based on CDD level at the transaction layer.

S-03

Enhanced Due Diligence (EDD)

Stricter checks for high-risk customers, PEPs, and high-value relationships. Technology role: flags transactions from EDD-classified customers for elevated monitoring and review.

S-04

Ongoing Monitoring

Continuous monitoring of customer transactions for suspicious patterns. Technology role: the core function of a transaction monitoring system operating in real time.

S-05

Transaction Monitoring

Specific requirement for automated monitoring of transactions against configured scenarios. Technology role: automated rule evaluation, pattern detection, and alert generation.

S-06

Suspicious Transaction Reporting (STR)

Timely filing of STRs/SARs for transactions that raise suspicion. Technology role: case management provides the evidence base for STR documentation.

S-07

Currency Transaction Reporting (CTR)

Filing reports for cash transactions above NFIU thresholds (₦5M individuals, ₦10M corporates). Technology role: automatic threshold detection and reporting workflow.

S-08

Sanctions Screening

Screening customers and counterparties against sanctions lists, PEP databases, and watchlists. Technology role: orchestrates screening provider calls and integrates results into the decision.

S-09

Record Keeping

Retention of transaction records, CDD documentation, and STR/CTR filings for prescribed periods. Technology role: append-only evidence store with configurable retention periods.

S-10

Training

Regular AML/CFT training for all relevant staff. Technology role: outside the scope of transaction monitoring technology, but case management workflows build analyst capability.

S-11

Risk Assessment

Institution-level and customer-level risk assessments. Technology role: customer risk profiling and risk state management inform and operationalise the risk assessment.

S-12

Independent Audit

Periodic independent testing of the AML/CFT programme. Technology role: audit trail, evidence packs, and decision records are the primary evidence for independent audit.

The technology-addressable standards in depth

S-04 and S-05: Ongoing monitoring and transaction monitoring

These two standards are where most Nigerian fintechs have the biggest gap. S-04 requires continuous, ongoing monitoring of customer transactions. S-05 goes further: it specifically requires automated transaction monitoring against configured scenarios.

“Automated” is the operative word. A compliance officer manually reviewing a daily report is not automated monitoring — and it's not ongoing. The direction of CBN guidance is toward real-time, pre-authorisation controls that evaluate transactions before they complete.

What “configured scenarios” means in practice: velocity rules (too many transactions in a rolling window), amount thresholds (absolute or relative), structuring patterns (sub-threshold sequences), and account-age rules (new accounts behaving like mule accounts). These scenarios should be configured to your specific business model — the patterns that matter for a digital wallet are different from those that matter for a remittance company.

S-05 requires “automated transaction monitoring.” A compliance officer reading a spreadsheet is not automated monitoring. Technology that evaluates every transaction against configured scenarios before it executes is.

S-07: Currency Transaction Reporting

NFIU requires Currency Transaction Reports (CTRs) for cash transactions above ₦5M (individuals) and ₦10M (corporates), filed within 7 days.Structuring to evade these thresholds — breaking transactions into smaller amounts — is itself an offence under MLPPA 2022.

From a technology perspective, CTR compliance requires three things: threshold detection (identifying transactions at or above the reporting threshold), structuring detection (identifying patterns designed to stay below it), and a workflow for generating and filing the report. All three should be automated, not manual.

S-08: Sanctions screening

Every customer and counterparty should be screened against relevant sanctions lists (OFAC, UN, EU, NFIU), PEP databases, and adverse media sources. The CBN expects this screening to happen at onboarding and at intervals thereafter — and increasingly, on every transaction.

The compliance technology role here is orchestration: not providing the screening data (that's your screening vendor's job), but calling the vendor, handling the response, integrating the result into the transaction decision, and creating a case when a hit is returned. Fintegrity plugs in your existing screening provider and incorporates the results into the real-time decision.

S-09: Record keeping

CBN requires financial institutions to retain transaction records, CDD documentation, STR/CTR filings, and investigation records for prescribed periods. The key word is “retain” — but regulators increasingly expect records that are not just retained but retrievable, structured, and verifiable.

An append-only evidence store where every decision, state change, and case action is written with a server-side timestamp satisfies this requirement in a way that a spreadsheet archive does not.

The standards technology doesn't address

S-10 (training) and parts of S-01 (programme documentation) and S-12 (independent audit) are not technology problems. They require human expertise, internal governance, and qualified compliance professionals.

Fintegrity is explicit about this boundary: we provide the controls infrastructure that your AML programme references and that your auditors test. We're not your MLRO and we don't replace your compliance team. We give them better tools and better evidence.

The compliance technology boundary: Technology addresses the operational and controls requirements (S-04, S-05, S-07, S-08, S-09). Programme documentation, training, and independent audit are governance responsibilities that require qualified human expertise.

A practical implementation roadmap

If you're a Nigerian fintech looking to close your compliance gap, the practical order of priority is usually:

  1. Get the decision layer in place first. A real-time decision API (S-04/S-05) gives you the infrastructure everything else plugs into.
  2. Wire in sanctions screening via your existing provider (S-08). This can be done alongside or immediately after the decision layer.
  3. Configure your rule library to your specific scenarios — velocity, thresholds, structuring patterns (S-05). Start with the highest-risk patterns for your business model.
  4. Build out case management for investigation and STR workflow (S-06). This is where your compliance team lives.
  5. Verify your record-keeping approach covers the retention periods and retrieval requirements of S-09.
This roadmap reflects Fintegrity's product architecture and is not a substitute for qualified compliance advice. The order and scope of implementation should be validated against your specific regulatory classification, licence conditions, and MLRO guidance.

What Fintegrity addresses

Fintegrity's platform is designed to address the technology-addressable standards directly: real-time decision API and transaction monitoring (S-04, S-05), screening orchestration (S-08), automated threshold detection (S-07), case management and STR workflow (S-06), and append-only evidence recordkeeping (S-09). The programme documentation (S-01), training (S-10), risk assessment (S-11), and independent audit (S-12) remain your responsibility — Fintegrity gives your auditors the evidence they need to assess the controls.