MLRO guide

This guide is for the Money Laundering Reporting Officer (MLRO) and the Deputy MLRO. The two roles hold the same permissions; the deputy is the checker for anything the MLRO made, and decides suspicions the MLRO recorded. You can do everything an analyst can, and on top of that you decide suspicions, file reports, approve governed changes and oversee the programme.

1. Before your first decision

1. Enrol a second factor. MFA is mandatory for your role. Set up an authenticator app at Security & MFA (/account/mfa) and, ideally, a passkey at Passkeys. Most of your approvals need step-up — a fresh code no more than five minutes old.
2. Agree the deputy arrangement. You can never decide a suspicion you recorded or approve a change you made. Make sure a Deputy MLRO is enrolled and available.
3. Check your institution's settings with your administrator: the suspicion clock (business days), the business calendar, reason codes and filing deadlines.

2. Your daily view

• Dashboard (/): open alerts, SLA at risk, screening hits and Waiting for you — the four-eyes items you can approve.
• Notifications (the bell) and My approvals (/approvals/inbox): everything waiting for a second pair of eyes, from every module, oldest first. Suspicions awaiting your decision come first under MLRO decisions, each with its decision clock, its goAML readiness and a Decide link.
• MLRO decisions (/approvals): suspicions awaiting your decision, with those due within 24 hours highlighted.
• Reporting (/reporting): filings awaiting hand-off, in correction or overdue.

3. Deciding suspicions

When an investigator records suspicion, the case appears on MLRO decisions with its narrative, grounds, indicators, the transactions selected for the report, the subject, when suspicion was formed, who recorded it and the evidence count. The suspicion clock is running.

For each item:

1. Read the case. Open it for the full workspace, memo and history if needed.
2. Check the goAML readiness. FlowSentry checks each suspicion when the page opens and shows Ready to file or the number of errors; each error names the field, what is wrong and where to fix it (with a link to the case tab or the customer record). File STR stays disabled until the check passes with no errors, and FlowSentry refuses a File decision that would fail validation even if it is sent another way. Warnings do not block filing. Select Check goAML readiness to re-check and to see the data mapping of what was filled from your data and what is missing. Ask for the data to be fixed at source rather than editing the report.
3. Decide:

Decision	What happens
File STR	Step-up, then the decision is recorded and the goAML report is generated from it
Return	The case goes back to the investigator with What more is needed; the suspicion and clock stay on record; they resubmit
Do not file	You record Grounds for not filing; the decision goes to the Internal no-file register and the case's alerts are recorded as non-productive

If you recorded the suspicion yourself, the decision buttons are disabled and the page says the deputy must decide.

The Decision log and Recent decisions list every decision and the goAML report each File decision produced. Report failures shows any report that could not be generated, so you can retry after the data is fixed.

Note: Whether a matter is reported as an STR (specific transactions) or a SAR (activity without transactions) is set on the case's STR draft. Review it before filing.

4. Filing with the FIU

FlowSentry prepares and validates reports and tracks their hand-off; submission to the Financial Reporting Centre is an upload to the goAML portal.

1. On Reporting, review the STR register. View XML opens a report; Download watermarked XML downloads one copy.
2. Under FIU portal hand-off, select reports and Download XML bundle or Download hand-off package (step-up).
3. Upload to the goAML portal.
4. Mark selected as uploaded and record the FIU reference.
5. If the FIU rejects a report, Record rejection with its reason and Return for correction. The replacement is approved by a different MLRO or deputy.

The page states which goAML schema each report was validated against. Export STR register produces the register for governance reporting. Every view and download is audit-logged and watermarked.

Cash transaction reports

Qualifying cash activity is batched daily into draft CTRs. In the CTR register, Review draft, then a second person Releases it — you cannot release a batch you prepared — and Submit follows release. Keep an eye on CTR awaiting release and CTR rejected.

5. Approving governed changes

As MLRO you are the checker for many changes. Each opens on its own screen from My approvals, shows what changes and who proposed it, and needs step-up.

Item	Where you decide
Monitoring rule versions, built-in switch-offs and retirements	The rule's page: Approve / Reject
Proposed true matches and proposed clears	The screening hit: Confirm true match, Approve clear or Reject proposal
Good-guy exclusions and internal list entries	Exclusions (/screening/exclusions) and Watchlists
PEP declassification requests	PEP register (/screening/pep)
KYC changes on live customers	KYC changes (/customers/kyc-changes)
Risk overrides	The customer's risk tab or Customer risk (/risk): Approve override
Risk model versions	Risk models (/risk/models): Activate
Onboarding applications, including high-risk ones	The application's Risk and decision section
EDD cases	EDD workbench (/risk/edd): Approve relationship
Alert-work and screening four-eyes policies	Alert-work policy and Four-eyes policy

You can hold the maker permission too — for example you can author a rule — but you can never check your own item.

6. Overseeing the programme

Dashboards

• Executive overview (/dashboards/executive): alerts, cases opened, SLA compliance, STRs filed, high-risk customers, screening backlog and AI assists against the previous period.
• Transaction monitoring (/dashboards/monitoring): alerts per rule and rule effectiveness, including true positives and precision (shown only to STR-privileged users).
• Operations & SLA (/dashboards/operations): queue depth, ageing, SLA breaches, throughput and analyst productivity.
• Reporting KPIs (/dashboards/reporting): STR, SAR and CTR filing status, timeliness, deadlines and FIU rejections.
• AI usage (/dashboards/ai): AI calls, spend and latency by feature and model.

Every figure drills through to the records behind it, and every export is recorded. See Use dashboards.

Analytics

The Analytics workspace (/analytics) compares typologies period on period and runs a Typology radar for sharply rising typologies, with a suggested draft rule. Drafts still follow rule maker-checker; the radar never activates anything. The Metric designer lets you define metrics with amber and red thresholds and pin them to the executive overview.

Quality assurance

QA review (/qa) shows sampled closures. Use it, or delegate it to QA reviewers and senior analysts, to keep closure quality visible. Returned closures reopen with their history.

Risk assessment

The EWRA page (/risk/ewra) holds the enterprise-wide risk assessment: assessment cycles, the risk register and the inherent-risk heatmap. Complete a cycle at least annually and when your risk profile changes.

7. Tipping-off controls

• STR material — decisions, narratives, the STR register and filing KPIs — is visible only to STR-privileged roles: MLRO, Deputy MLRO and Auditor.
• A case becomes STR-restricted once an STR is involved; only the people already on it keep access.
• Relationship managers never see alerts or cases; they only answer factual information requests.
• Executives see aggregate figures, never case content.
• Exports are watermarked with the viewer's name and audit-logged.

8. Preparing for an examination

• Audit trail (/audit, viewed by auditors and administrators): every governed action by named person, with per-module hash-chain integrity re-verified each time the page opens.
• Regulator reviews (/regulator/reviews): examiner-ready sample reviews with findings recorded by name.
• Rule evidence: each rule's plain-English description, version history with diffs, approvals and backtests.
• Risk model evidence: each model version's Doc pack and every customer's score history with factor breakdowns, reproducible from the model version.
• AI evidence: every model call is logged with the prompt version, model, tokens, cost and the person who asked; what each person did with each draft is recorded.
• No-file register: your reasoned decisions not to file.

See the Compliance and governance guide.

Related

• MLRO and Deputy MLRO
• Draft and file an STR
• Security and access FAQ