BUILT FOR THE EXAMINATION · CBN · NFIU
Nine deposits.Twenty hours.One alert that survives audit.
It runs single-tenant inside your own infrastructure. Each deposit sat just under the ₦5,000,000 reporting line; the structuring rule watches the band beneath it, so the pattern trips even though no single deposit does. Then a second officer signs the filing and the hash chain records both of them.
- CBN Baseline Standards for Automated AML Solutions
- NFIU goAML · STR & CTR
- Runs inside your environment
- Maker-checker enforced by policy
ILLUSTRATIVE · SYNTHETIC DATA · NOT A LIVE FEED
AGT-8842077 · ARRIVAL TO FILING
Follow the ₦4,900,000.
01INGEST
It arrives
A ₦4,900,000 cash deposit at 02:14, the ninth in twenty hours, each one just under the ₦5,000,000 CTR reporting line. Re-sending it changes nothing: the reference is unique, so a repeat is recorded as a duplicate and never raises a second alert.
02SCORE
It is scored
Evaluated as it lands, not overnight in a batch. The structuring rule sits at ₦4,500,000, deliberately just below the ₦5,000,000 CTR line, and that gap is the detection logic. The aggregate over twenty hours is what this one trips.
03ALERT
It alerts
A CRITICAL alert opens and the customer snapshot freezes at this moment. A profile edit tomorrow cannot rewrite what the analyst saw today. The SLA clock starts here.
04MAKER · CHECKER
A human owns it
The analyst writes the suspicion narrative; an STR will not submit without at least 100 characters of it. Nothing activates until a second officer approves, and a maker can never approve their own submission.
05FILE
It stays filed
The STR goes to the NFIU in goAML with a reference. Every step you have just read appended to the audit log as it happened. Nothing deletes, nothing edits silently, and when an examiner asks, the audit workspace verifies the hash chain in front of them.
APPEND ONLY · NO ROW IS EVER REMOVED OR REWRITTEN
02PLATFORM
The whole compliance desk, and the examiner's view of it.
Monitoring, screening, cases, rules, reporting, watchlists, country risk and data quality are one system on one audit trail, not eight tools a compliance officer reconciles by hand. The last screen here is the one an examiner is shown.
Six tabs, each answering a different examination question. The first one verifies the hash chain: has this record been tampered with. Everything else in the product produces evidence; this is where it is inspected, and a separate examiner role unlocks restricted STR and SAR content without handing over the rest.
03GOVERNANCE
A maker can never approve their own work.
Separation of duties is enforced by policy, not by a role name someone can edit. Try it: you are signed in as the officer who submitted this change.
Config Change
CTR Threshold: NGN 5,000,000 to NGN 4,000,000
ENFORCED BY POLICY · NOT BY ROLE NAME
- 6d agoF. Adeleke submitted a governed change
A REFUSED APPROVAL IS ITSELF AN AUDIT EVENT
04SECURITY
Built so there is no path for your data to leave.
Data sovereignty here is structural, not contractual. The system installs inside your infrastructure and nothing carries customer data out of it, which satisfies CBN 5.11-b-i and the NDPA by construction rather than by promise. The product implements the CBN Baseline Standards for Automated AML Solutions, BSD/DIR/PUB/LAB/019/002. Inside that boundary, a BVN is still masked by default and revealing it is a permission that leaves a record.
- BVN
- 221••••••18
- NIN
- 701••••••96
NO ACCESS EVENTS YETMASKED IN UI, LOGS AND EXPORTS
01It runs in your environment
Single-tenant, installed inside the institution's own infrastructure. Compact on a single node for a pilot or an OFI, standard-HA on Kubernetes for a bank, from the same signed artefacts with no feature divergence between them.
02No customer data leaves
A hard product property, not a setting someone can get wrong. No replication out, no telemetry, no analytics beacon, and no standing vendor connection into your network. The only sanctioned outbound is signed sanctions and PEP list data coming in.
03Enforced by the build
An egress allowlist assertion runs in CI. If a change introduces any outbound destination other than the configured list providers, the build fails. The invariant is checked mechanically rather than trusted to review.
04You decide what we ever see
When we need diagnostics, you trigger a redacted, audited export. We never pull; you push, deliberately, and the export is recorded in the audit trail. Upgrades are signed artefacts applied on site, not delivered over a network path.
05DOCS
One contract, and it is boring on purpose.
Your core banking team will integrate this, so the interesting questions are what happens when something is sent twice at 3am, and which unit the amount is in. Both answered here, not diagrammed.
POST /api/v1/ingest/transactions
X-Tenant-Id: bank78
X-Kore78-Source-ID: SRC-000016
X-Kore78-Signature: sha256=<hmac of the raw body>
{
"sourceSystemId": "SRC-000016",
"events": [
{
"eventId": "8f1c9a2e-...",
"eventType": "transaction.posted",
"occurredAt": "2026-08-13T02:14:07+01:00",
"transactionReference": "AGT-8842077",
"activityType": "CASH_DEPOSIT",
"channel": "AGENT",
"direction": "CREDIT",
"amount": { "amountMinor": 490000000, "currency": "NGN" },
"sourceCustomerId": "CUST-40118",
"isCash": true
}
]
}
# amountMinor is KOBO. 490000000 is NGN 4,900,000.
# Sending 4900000 means NGN 49,000 and the rule never fires.
- Idempotency
- Per entity, scoped to the source system. Transactions are unique on reference and repeat as duplicates; customers and accounts upsert.
- Amounts
- Minor units, always. NGN 4,900,000 is 490000000 kobo. Sending major units is the single most common integration mistake, and nothing rejects it: the transaction is accepted and simply never matches a threshold.
- Signing
- HMAC-SHA256 over the raw request body, keyed on the API key issued at source registration. The body must not be re-serialised between signing and sending.
- Timestamps
- ISO 8601 with offset. WAT is +01:00 and there is no DST in Nigeria.
- Bulk endpoints
- POST /api/v1/ingest/{customers|accounts|transactions}/upload takes a file and feeds the same canonical pipeline as the JSON push, so idempotency, risk mapping and data-quality holds apply identically to a bulk row.
- History and backfill
- Bulk CSV or XLSX upload alongside the REST path, for one-off loads and for backfilling history at go-live. The same idempotency applies, so re-running a file cannot manufacture duplicate alerts.
- Bulk limits
- 25 MB and 50,000 rows per upload, enforced server-side. Over either, split the file. There is no chunking.
- If REST is not an option
- Adapters run as separate processes and speak your side's protocol: a core banking socket feed, ISO 8583, or CDC. They are read-only observers. They never authorise, route or settle.
- Already on Kore78 core banking
- Then the system feeding this is built by the same company. Integration is a configuration conversation rather than a vendor-to-vendor project.
- Pre-transaction
- The fail-safe default is FAIL_OPEN. A monitoring outage does not stop the bank taking payments.
06CONFORMANCE
Twelve areas in the standard. Eleven live, one named.
Rather than a feature list in a taxonomy we invented, this is the CBN Baseline Standards for Automated AML Solutions, numbered as the circular numbers them, so you can read it beside the document itself.
The monitoring platform itself, deployed single-tenant inside the institution's own environment.
Consumes verdicts from your onboarding stack today. A provider interface for BVN and NIN checks lands at GA.
Pluggable providers with OpenSanctions as the default and ComplyAdvantage supported. Internal watchlist upload and adverse-media monitoring included.
Customer and enterprise risk scoring. The rating map and score bands are themselves a governed change, proposed and approved before they take effect.
Rules-based, evaluated on arrival. Automated closure is deliberately deferred until a customer asks for it, because it triggers a CBN notification regime under 5.5-b-vii.
Not shipping today. The standard requires a roadmap document for this area at our stage, and that is what exists. We would rather you read this line here than discover it in an evaluation.
Alerts grouped into cases, evidence attached, closure governed by maker-checker rather than a status dropdown.
Drafted from the case, exported to the NFIU in goAML, with the filed file checksummed at approval so the copy you download is the copy that was filed.
Append-only, hash-chained audit trail with an examiner-facing workspace whose first tab verifies chain integrity.
REST push, core banking socket feed, ISO 8583 and CDC adapters, plus bulk CSV and XLSX for backfill. Compact on one node, standard-HA on Kubernetes, no feature divergence.
In the single-tenant in-environment deployment, no customer data leaves the boundary, enforced by an egress allowlist assertion in CI. BVN and NIN masked by default, every reveal recorded.
Built dense on purpose, for people who work in it all day rather than for a screenshot.
Runs single-tenant inside your environmentBVN and NIN masked by default
07GETTING LIVE
Six steps, and the order is the hard part.
This is the actual sequence from the setup guide, not a marketing timeline. Each step exists because the one after it depends on it, and the dependency is what makes an implementation stall when people start in the middle.
- 1
A second administrator
Every governed change needs an approver who is not the submitter. A single administrator can submit and will never be able to activate anything, which is the most common cause of a stalled setup.
- 2
Risk mapping
Empty on a new workspace. Until the rating map and score bands are proposed and approved, customer risk is unmapped rather than low.
- 3
Rules
Detection cannot run without them. Start with the four mandatory library rules, which correspond to obligations rather than preferences. Governed, like everything else.
- 4
Settings
Screening providers, source-system registration, SLAs, thresholds and fail mode in one place. Nothing can be ingested until a source system is registered here.
- 5
Data ingestion
Everything above has to be in place first. Push one transaction that should trip a rule you know is active, then confirm the alert appears. That single alert proves the whole chain.
- 6
Watchlists and lists
Independent of the chain above, so this can happen at any point.
08STRAIGHT ANSWERS
The questions that decide it.
These come up on every evaluation, so they may as well be answered here. Where the honest answer has an edge to it, the edge is left on.
No, and that is a decision rather than a gap. This does AML, CFT and CPF monitoring. An examiner grades your AML programme against a specific standard, and a system that does several things adequately tends to fail the one it is measured on. Fraud monitoring is area 5.6 of the CBN standard and it is on the roadmap; you can see exactly where it sits in the conformance matrix above rather than finding out later.
It does not have to be. The product is built to run single-tenant inside your own infrastructure, and in that deployment no customer data leaves your boundary: no replication out, no telemetry, no analytics beacon, and no standing connection from us into your network. The only outbound traffic permitted is signed sanctions and PEP list data coming in, and a check in our build pipeline fails if anyone introduces another destination. If you would prefer we host it instead, that is a different arrangement with different answers, and we would rather put those in writing at the start than have you discover them at an examination.
No. AI can draft a rule from a written description, it is optional, and it runs on your own provider key. A drafted rule is a draft and nothing more: it goes through the same submit-and-approve chain as any other change, and a maker can never approve their own submission. Suspicion narratives on filings are written by your analysts.
The software runs on your infrastructure and the data is already in your estate, so nothing is stranded in a hosting account you do not control and there is no migration to run in a hurry. The honest part: you would still need someone to maintain and update it, as with any licensed system, and that is worth writing into the contract rather than discovering later.
No. The compact profile runs on a single node with Docker Compose, which is what most mobile money operators, PSPs and microfinance banks use. The standard-HA profile runs on Kubernetes for higher volumes. Both are built from the same artefacts with no feature divergence, so the smaller footprint is not a reduced product.
Yes. Bulk CSV or XLSX upload sits alongside the real-time REST path, for one-off loads and backfill. The same idempotency applies, so re-running a file cannot manufacture duplicate alerts: a transaction already stored comes back as a duplicate and skips the monitoring engine entirely.
Kore78, part of 78 Financials, who also build the core banking platform used by financial institutions across the market. That matters practically as well as commercially: if your ledger already runs on Kore78, the system feeding this one is built by the same people, and integration becomes a configuration conversation rather than a project between two vendors.
09GET STARTED
See it against your own typologies.
A working session with your compliance team, not a slide deck. Roughly an hour, and you should bring whoever will have to sign off on it.
The email opens with a short template: institution, your role, and the typologies you want to see. We reply within one business day.
01Controlled environment
The demo runs on synthetic data in an isolated tenant. Nothing from your institution is loaded, and nothing you see belongs to another bank.
02Your typologies
Tell us the patterns you care about ahead of time and they will be configured as rules before the session, so you are watching your own scenarios.
03The awkward questions
Bring your auditor. Deployment inside your own environment, the no-egress guarantee, model governance and the audit chain are the parts we would rather discuss early than late.