Industry
Risk and AML compliance software for banks in Zambia
A bank in Zambia is licensed and supervised by the Bank of Zambia under the Banking and Financial Services Act No. 7 of 2017, and it carries anti-money laundering obligations under the Prohibition and Prevention of Money Laundering Act and the Financial Intelligence Centre Act. In practice that means periodic prudential returns to the regulator, customer due diligence on every account, continuous screening against sanctions and politically exposed person lists, monitoring of transactions, and suspicious transaction reports to the Financial Intelligence Centre (FIC) through goAML. Most banks also run an enterprise risk register, an internal audit function and an ICT risk programme that the same regulator expects to see.
ERMAML, the Ontech Risk & Compliance Suite, brings those functions into one platform. Its AML module handles screening, KYC, transaction monitoring, case management and goAML report drafting; its ERM module holds the risk register, control assessments, key risk indicators, incident and operational-loss records and the compliance obligations register from which returns are prepared. Both share one audit trail and one role model, so the prudential, AML, ICT and audit teams work from the same record.
Key capabilities
Prudential return preparation
The compliance register pulls figures from the live risk and control data and formats them for the layouts the Bank of Zambia expects, with a filing calendar that flags what is due.
Sanctions and PEP screening
Customers and counterparties are screened against UN, OFAC, EU, UK and OpenSanctions lists, the FIC PEP list and adverse media, at onboarding and on a continuing basis.
Registry-verified customer due diligence
An individual's NRC is checked against the national registry and a company against PACRA and the ZRA taxpayer registry, rather than accepting identity documents at face value.
Transaction monitoring
Seven default detection rules covering structuring, velocity, thresholds and geographic risk, plus anomaly detection, with rule parameters tuned from the interface.
Case management and STR drafting
Alerts become cases with maker-checker disposition and SLA tracking, and a case can be drafted into a goAML-schema suspicious transaction report.
ICT and cyber risk
Cyber Security Act obligations for critical information infrastructure are tracked as controls, with incidents flowing into the risk and control self-assessment.
Operational loss and internal audit
A live operational-loss register with category analytics, and audit findings tracked to closure with four-eyes review.
How it works
- Read-only connectors are wired to the core banking system, the KYC store and the ledger during discovery.
- The customer book is back-loaded, risk-tiered and screened once to establish a baseline.
- Monitoring rules are tuned against historic transactions before real-time screening is switched on.
- Alerts are triaged into cases, reviewed under maker-checker, and either closed or drafted as STRs for the FIC.
- Risk owners maintain the register, run RCSA cycles and answer KRI breaches as they arise.
- Returns to the Bank of Zambia and reports to the board are produced from the same live data.
Benefits
One record for prudential, AML and risk
The figures in a return, the screening decision on a customer and the residual score on a risk all come from the same system.
Fewer hand-built returns
Return layouts are prepared from live data, so quarter-end is spent reviewing rather than rekeying.
Screening that does not stop at onboarding
Continuous rescreening and a detective screening gate over payments catch changes that a one-time check would miss.
Audit-ready evidence
Every decision, policy change and screening result is logged in a tamper-evident chain.
Who it is for
- Commercial banks replacing spreadsheet-based returns and vendor-portal screening.
- Compliance and money laundering reporting officers who need cases, evidence and STRs in one place.
- Chief risk officers and internal audit heads who want one register for operational, ICT and compliance risk.
Zambia-specific considerations
The Bank of Zambia supervises banks and other financial institutions and also regulates payment systems, including mobile money. Banks that offer wallets or agent banking therefore carry customer due diligence obligations across channels, and ERMAML applies the same screening and monitoring rules whatever the channel.
Zambia is a member of ESAAMLG and follows the FATF Recommendations, and the FIC receives suspicious and currency transaction reports through goAML. ERMAML drafts reports in the goAML schema so the reporting officer submits from structured case data rather than a Word document.
How ERMAML addresses this
Prudential and AML in one operational view
The compliance register, the screening gate and the case queue sit in the same platform, so the head of compliance can see returns due, alerts open and STRs filed without switching systems.
Identity verified against national registries
NRC, PACRA and ZRA checks run at onboarding and again at screening time, and an NRC that belongs to someone else forces a manual four-eyes review.
Branch-scoped access and a hash-chained audit trail
Role-based access limits each branch to its own customers, and the audit chain lets an examiner verify that case history has not been altered.
Frequently asked questions
What compliance obligations does a bank in Zambia have?
A bank is licensed and supervised by the Bank of Zambia, submits periodic prudential returns, performs customer due diligence, screens customers against sanctions and PEP lists, monitors transactions, keeps records, and reports suspicious and currency transactions to the Financial Intelligence Centre. It also answers to the Data Protection Act for customer data and to the Cyber Security Act where its systems are designated critical infrastructure.
Can ERMAML prepare Bank of Zambia returns?
ERMAML's compliance register maps obligations to the data that supports them and prepares return layouts from the live register, with a filing calendar and SLA alerts. The bank reviews and submits the return; the platform does not file on its behalf.
Does it screen against international sanctions lists?
Yes. Screening runs against UN Security Council, OFAC, EU and UK lists through the OpenSanctions dataset, alongside the FIC PEP list and adverse media, with fuzzy and transliterated name matching and a four-eyes false-match review queue.
How are suspicious transaction reports handled?
An alert is triaged into a case, investigated with notes and evidence, and dispositioned under maker-checker review. Where a report is warranted the case is drafted into the goAML XML schema the FIC uses, ready for the reporting officer to submit.
Can it connect to our core banking system?
ERMAML integrates through read-only connectors and a documented core banking API, and can also accept batch files. The integration design for banking is described in the platform documentation and confirmed during the discovery phase of an implementation.
Sources
See ERMAML on your own data
Request a demo with Ontech Solutions in Lusaka and see sanctions screening, KYC, transaction monitoring, goAML reporting and the risk register working together in one platform.
Last updated 2026-09-13. Published by Ontech Solutions, Lusaka, Zambia.