DocsPrograms

AML/CFT program & training oversight

Updated 2026-10-07

The AML/CFT program screen answers the question an AML/CFT officer is asked at every examination: show me your program, pillar by pillar, and show me the evidence behind each one. It is assembled from the records already in Zovos rather than from a separate narrative document. It sits in the AML/CFT & fraud group of the sidebar beside Fraud losses and the Fraud case log, which give the officer the oversight record for fraud. Training oversight, in the Compliance group, is covered here too because training is one of the pillars and is usually the hardest to evidence.

The screen is organised around the five statutory pillars set out at 31 CFR 1020.210(b): internal controls, independent testing, a designated AML/CFT officer, training, and risk-based customer due diligence including beneficial ownership.

Each pillar is a card. The card is computed from your live registers of controls, monitoring reviews, training programs and risk assessments, so it moves as the program moves. Alongside the pillars, the screen shows the freshness of your BSA/AML risk assessment and your coverage of the FinCEN national priorities.

The pillars are not auto-filled by guesswork. The AML/CFT officer explicitly designates which records evidence which pillar, through Edit designations and Save designations. A pillar with nothing pinned to it reads Not designated rather than showing a plausible-looking score.

That is a deliberate design choice. An examiner asking "what evidences your independent testing pillar" should get the officer's answer rather than the software's inference. Because the designation is a recorded act by a named person, the answer is also defensible a year later.

The BSA/AML risk assessment runs in the assessments register, and Zovos ships assessment content packs for BSA/AML and OFAC so you are not building the question set from a blank page. You can clone one of those packs and edit it, or author your own from scratch, while the shipped pack stays read-only. Assessments run per cycle, capture design and operating effectiveness, and close by attestation. A national-priorities panel shows which FinCEN priorities the assessment addresses and which it does not. See Risk management for how assessments, challenges and attestation work.

Freshness matters as much as content. The program screen surfaces when the risk assessment was last completed, so a stale assessment is visible before an examiner finds it.

The program's other recurring obligations are seeded onto the obligations calendar rather than left to memory. The board's approval of the AML/CFT program and its independent testing are each flagged as a date your institution sets against a frequency the rule fixes. The OFAC blocked-property report sits alongside them, and the rule fixes its date outright.

Generate AML/CFT board report produces the report the board receives and seals its claims into the proof ledger. Every figure in the report resolves back to the records that produced it, so a claim can be re-verified later as unchanged, drifted, or no longer answerable. That is what turns a board report from a snapshot into evidence.

Two screens in the AML/CFT & fraud group give the officer the fraud side of the program. Neither one investigates fraud. They record what happened and what was decided.

Fraud losses is the loss-event register pinned to its two fraud event types, internal fraud and external fraud. It is the same register as Loss events in the Risk group with a fixed filter rather than a copy, so you capture, edit and close a fraud loss here exactly as you would there, and closure still runs through independent approval. See Risk management.

A fraud loss also carries the channel the fraud came through. The channels are check, debit card, credit card, ACH, wire, instant payment, account takeover, new account, loan, cash and other. You can filter the register by channel, and the analytics break fraud losses out by channel, so a shift from check fraud to account takeover shows up in the numbers. Where your institution has key risk indicators fed by a fraud event type, they appear as a strip above the register with their current status.

The Fraud case log is a second-line oversight log of fraud cases escalated for a SAR decision. It is not a case-management system. Investigation and case work stay in your monitoring or case system, and the log records the decision and the trail behind it.

New case records a title, the fraud type, an optional channel, the date the fraud was detected, an optional amount at risk, and an owner. You can add the case reference from your case system, name that system, link the case to a booked loss event in the register, and mark the case as an insider suspect. Every case form tells you not to enter customer names, account numbers or SAR narrative, because those stay in your case system.

The SAR decision is two-person. One member records a recommendation to file a SAR or not to file one, with a required rationale. A different member then decides it, either agreeing and recording the decision or returning it to the recommender, again with a required rationale. Nobody can decide their own recommendation, and the database refuses it as well as the screen. The decision is due 30 calendar days after the detection date, the window 31 CFR 1020.320(b)(3) sets for filing, and a case still waiting for a decision after that date reads overdue. Each case shows where it stands: no decision, awaiting decision, file SAR, SAR filed, or no SAR.

After a decision to file, you record the date the SAR was filed. That date cannot be earlier than the decision or later than today. A case closes only once its decision path is complete, meaning a decision not to file, or a decision to file with its filing date recorded. There is no action to reopen a closed case.

The log is deliberately compartmented. The SAR itself, its narrative and its subject never enter Zovos. What the log holds is the decision, the rationale for it, and the dates. A SAR decision sends no notification, raises no approval in the shared queue, and writes nothing to the decision register or the proof ledger, because each of those would carry the decision outside the people entitled to it. The audit trail entries for a case are withheld from anyone who cannot read the AML/CFT & fraud area.

A case marked as an insider suspect is absent, rather than refused, for any member whose role does not see internal notes, so a suspect cannot learn that the case exists. An examiner whose grant covers the AML/CFT program can read the log, and nobody in an examiner session can write to it.

Training oversight is a register of the training programs your institution runs. It is not a course library. Each program records its audience, its cadence and, most importantly, the audience size. The audience size is the denominator for completion until you import a roster, described below. Without a denominator, a completion percentage means nothing.

You record completions two ways: Record completion for individual entries, and a bulk import of an export from your learning management system, which takes a CSV or an Excel workbook. Re-importing the same file does not double-count anyone. Rows are matched on your learning system's own record identifier where the file carries one, and otherwise on the program, the person's name and the period, so a file with no identifier column still dedupes.

Each program also carries a citation crosswalk to the rules that training actually teaches. When a regulatory change lands, impact analysis follows those links and proposes the training affected, instead of relying on somebody remembering which course covered the rule.

From that, Zovos computes completion percentage and delinquency, which is the audience size minus completions for the current period. Programs carry a status of current, due soon, overdue, unknown, or retired. Unknown is used honestly rather than as a default. A program with no cadence to schedule against has no next due date, so it reads unknown instead of reading as on track. Exam report (PDF) exports the register with its completion figures for the binder, and each program's own drawer exports its completions as a CSV.

A typed audience size gives you a count of delinquent people but not their names, and an examiner asks for the list. Each program's drawer therefore carries a roster of the people expected to complete it. Add person adds one name, and Import roster takes the expected-audience list from your learning or HR system as a CSV or an Excel workbook. Once a roster exists, the completion rate is measured against the people it names rather than the typed headcount, and each person reads completed, delinquent or excused. Someone who has left the institution or whose access is suspended is excused, so they drop out of the denominator instead of counting as delinquent, and the reason is shown beside them. Delinquent only narrows the list, and List (CSV) exports exactly the rows on screen. A program with no roster keeps working from the typed headcount.

Zovos never authors or delivers a course. It records that training happened, to whom, and when. That is the oversight half of the pillar.

Zovos is also not a transaction-monitoring or case-management system, and it is not meant to be. Where you connect an AML case platform, what flows in is program-level oversight metrics, such as alert and case volumes, for reporting and trend analysis. Alerts, SARs and CTRs stay in your AML system of record. Some AML platforms connect by API and others by file import. The choice is deliberate, because this is an oversight seam and not a transactional one.

Independent testing of the AML/CFT program is usually performed by internal audit or an external firm, and the results are tracked as engagements and findings. See Internal audit for that side of the pillar.