Platform
What is transaction monitoring software?
Transaction monitoring software examines an institution's transactions, as they happen or in batches, against rules that describe suspicious behaviour, such as cash deposits structured to stay under a threshold or funds that arrive and leave within hours, and against statistical models that flag activity unlike a customer's normal pattern. Hits become alerts, alerts are investigated as cases, and cases that prove suspicious are reported to the financial intelligence unit.
ERMAML, the Ontech Risk & Compliance Suite, ships with seven default detection rules that compliance teams tune from the user interface, an anomaly-detection model that scores transactions at ingest, a suppression engine to limit repeat alerts, and an alert-to-case-to-STR workflow with maker-checker review, developed by Ontech Solutions in Lusaka for institutions in Zambia.
Key capabilities
Seven default rules
Structuring, rapid movement, velocity spike, high-risk geography, round-trip, dormant reactivation and threshold breach, each with parameters the institution sets.
Tuning without a restart
Thresholds, look-back windows and rule scope are adjusted from the interface, and changes take effect without redeploying the system.
Anomaly detection
An isolation-forest model scores every transaction at ingest, catching outliers that no fixed rule describes.
Alert lifecycle
Alerts carry the rule, the evidence and the customer context, and move to triage, case or closure with the disposition recorded.
Suppression engine
Repeat hits on the same pattern are grouped so analysts are not buried in duplicates.
Backtesting
Rules are tested against historic data during implementation to calibrate false-positive rates before go-live.
Customer 360
Every alert is viewed alongside the customer's transactions, screening history, risk tier and open cases.
How it works
- Transactions are ingested from the core system, ledger or mobile-money switch through read-only connectors.
- Each transaction is evaluated against the active rules and scored by the anomaly model.
- Hits become alerts with the rule, evidence and customer context attached, and duplicates are suppressed.
- Analysts triage alerts and open cases for those that warrant investigation, under maker-checker control.
- Cases that meet the reporting standard are drafted as STRs in the goAML schema.
- Rule performance is reviewed against dispositions and thresholds are tuned from the interface.
Benefits
Patterns caught as they form
Structuring and rapid movement are detected as transactions arrive rather than after month-end review.
Rules the compliance team owns
Tuning is done by the people who see the alerts, not by raising a change request with IT.
Fewer duplicate alerts
Suppression and customer-level grouping keep the queue manageable.
Investigations that lead somewhere
Alerts, cases and STRs are one workflow, so the evidence gathered in triage is the evidence in the report.
Who it is for
- AML analysts and MLROs at banks, MFIs and money-transfer operators.
- Mobile-money and telecom operators watching subscriber money flows.
- Insurers monitoring premium and claim payments for unusual patterns.
- Compliance teams moving from month-end batch reviews to continuous monitoring.
Zambia-specific considerations
Zambian reporting entities are required to identify and report suspicious transactions to the Financial Intelligence Centre, and examiners from the Bank of Zambia and other supervisors look at whether monitoring is systematic and documented. A rule engine with recorded dispositions demonstrates that far better than a spreadsheet review.
Cash and mobile money remain central to how money moves in Zambia, so rules for structuring, velocity and threshold breaches matter as much as cross-border scenarios. ERMAML's default rules cover these domestic patterns and are tuned to the institution's own data during backtesting.
How ERMAML addresses this
Rules and a model, not one or the other
The seven default rules catch known patterns and the anomaly model catches the unknown ones, and both feed the same alert queue.
Alert to STR without re-keying
The case built from an alert is the source of the goAML-schema STR draft, so nothing is transcribed into a separate report.
Pipeline health you can see
Ingest rate, screening latency and alert queue age are monitored so a stalled feed is noticed before the regulator asks about it.
Frequently asked questions
What is transaction monitoring in AML?
It is the systematic review of transactions against rules and models that describe suspicious behaviour, so that unusual activity is flagged, investigated and, where warranted, reported to the financial intelligence unit. It complements customer due diligence by watching what the customer actually does after onboarding.
Which rules does ERMAML include by default?
Structuring, rapid movement of funds, velocity spike, high-risk geography, round-trip transactions, dormant account reactivation and threshold breach. Each has parameters the institution sets, and additional rules can be configured.
Can we change rule thresholds ourselves?
Yes. Rules are tuned from the user interface by the compliance team and the change takes effect without a system restart. Every change is logged on the audit trail.
How does anomaly detection differ from rules?
Rules describe known patterns with fixed conditions. The anomaly model scores each transaction on how unusual it is relative to the customer's history and the population, so it can surface behaviour that no rule anticipated. Both produce alerts into the same queue.
Does monitoring run in real time or in batches?
Transactions are evaluated as they are ingested, so alerts appear as activity happens. Historic data can also be run in batch during implementation to backtest the rules.
How are false positives controlled?
Through backtesting during setup, tuning of thresholds from the interface, suppression of repeat hits on the same pattern, and recorded dispositions that show which rules generate alerts that never become cases.
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.