How do suspicious transaction reports and goAML work in Zambia?

What makes a transaction suspicious

Suspicion is about fit. A transaction is suspicious when it does not make sense for the customer as the institution understands them, and no reasonable explanation emerges on enquiry. Common red flags in general AML practice include cash deposits structured just below a reporting threshold, funds moving in and out of an account faster than any business purpose explains, activity in a long-dormant account, transactions with high-risk jurisdictions, and customers who are reluctant to explain source of funds.

None of these is proof. They are prompts for a closer look, and the closer look is what the institution must document.

From alert to case

Most STRs begin as an alert from transaction monitoring, a screening hit, or a concern raised by front-line staff. An analyst gathers the customer's KYC file, transaction history and any screening results, and writes up what was found. If the activity is explained, the alert is closed with reasons. If not, it becomes a case and is escalated to the compliance officer, who decides whether the grounds for suspicion are reasonable.

Two features of this stage matter to a supervisor: that the reasoning is written down, and that more than one person was involved in the decision. A maker-checker step, where the analyst drafts and the compliance officer approves, satisfies both.

Drafting the report

A useful STR tells the FIC who the subject is, what happened, why it is suspicious and what the institution has done. Identifiers matter: full names, NRC or passport numbers, TPINs for businesses, account numbers and the transaction references. Vague narratives and mis-keyed names slow the FIC's analysis and may generate follow-up requests.

• Subject details, including beneficial owners where a company is involved.
• A chronological description of the activity with dates and amounts.
• The specific indicators that triggered suspicion.
• Supporting documents attached or referenced.

Filing through goAML

goAML is the electronic system through which the FIC receives reports. Reporting entities register for access, then submit reports either by completing forms in the goAML web portal or by uploading XML files that follow the goAML schema. Institutions with case-management systems typically generate the XML from case data so that the same identifiers and narrative are used throughout. Registration, schema versions and submission rules are set by the FIC, and its website is the authoritative source for current requirements.

Threshold and other prescribed reports

Alongside STRs, the FIC prescribes reports for cash and certain other transactions above set thresholds, commonly called currency transaction reports (CTRs). These are objective reports driven by amount rather than suspicion. The thresholds, the transaction types covered and the filing frequency are set by the FIC and should be taken from its current directives rather than from any secondary source, including this guide.

After filing

Once a report is filed the institution must keep the report, its supporting file and the record of the decision for the retention period the law prescribes. Staff must not tell the customer that a report has been made; this prohibition on tipping off is a standard feature of AML law. The institution should also decide, on its own risk assessment, whether to continue the relationship, apply enhanced monitoring or exit the customer.

How ERMAML handles this

ERMAML, the Ontech Risk & Compliance Suite, links alerts to cases with a four-eyes disposition, then auto-drafts goAML-schema XML from the case data, pulling the subject's NRC, PACRA and TPIN details from its registry-verification records so the identifiers are complete. Case notes and decisions are held in a tamper-evident audit trail. See regulatory reporting and goAML STR and CTR reporting.