AML case file checklist for iGaming, the exact notes, evidence, and timestamps auditors look for

If an auditor opened one of your AML cases right now, would they see a clear story or a messy desk drawer?

An AML case file checklist is less about having “more documents” and more about having the right proof, tied together with clean notes and precise timestamps. In iGaming, that proof has to explain player behavior, payments, controls, and decisions in a way that stands up to scrutiny.

This guide breaks down the exact case file components auditors commonly look for, what to write in your notes, what evidence to attach, and how to structure timestamps so your case reads like a timeline, not a mystery novel.

What an iGaming AML “case file” really is (and what it isn’t)

A case file is your defensible record of how you detected risk, assessed it, and decided what to do. Auditors don’t just check whether you had a policy. They check whether your team followed it in real situations.

A strong iGaming AML case file usually needs three things to be obvious within minutes:

• Why the case exists (the trigger and risk context)
• What you did (reviews, outreach, EDD, escalation, decisions)
• How you can prove it (immutable logs, attachments, and timestamps)

If your case file can’t answer “who did what, when, and why,” the auditor will keep pulling threads until something unravels.

The core AML case file checklist structure (the evidence matrix)

Think of your case file like a courtroom binder with tabs. Every tab should contain (1) a short note, (2) supporting evidence, and (3) timestamps that match system logs.

Here’s a practical checklist, written the way auditors tend to review cases:

Case header and scope (the “front page”)

• Case ID, alert ID(s), player ID(s), brand, jurisdiction, product (sportsbook, casino)
• Owner and roles: analyst, reviewer, MLRO (or equivalent)
• Dates: opened, first action, last action, closed (with time zone)

Trigger and alert context (why this case exists)

• What triggered the case (rule name, scenario, manual escalation, VIP flag)
• Why the trigger matters in iGaming (fast in/out, bonus abuse patterns, third-party funding)
• A link or snapshot of the rule logic or alert details (including threshold)

Tip: If your triggers come from monitoring rules, keep a stable reference to how rules are designed and maintained. This pairs well with a documented ruleset like Simple transaction monitoring rules for iGaming.

Customer profile and KYC status (what you knew at the time)

• Verification status at the moment the alert fired (pending, verified, failed, expired)
• Screening results (sanctions, PEP, adverse media if used)
• Source of funds or affordability checks (where required), including outcomes
• Any prior AML cases, prior closures, and prior risk-rating changes

If you’re tightening your KYC evidence and audit readiness, this iGaming KYC workflow audit guide is a helpful companion because auditors often connect weak KYC trails to weak case files.

Transaction and gameplay evidence (what happened)

Auditors want raw facts, not summaries that can’t be validated:

• Deposits and withdrawals (amounts, timestamps, method, instrument tokens, PSP references)
• Velocity and pattern indicators (rapid deposits, quick withdrawals, circular behavior)
• Bonus and promotion usage (bonus issuance, wagering progress, bonus conversion events)
• Gameplay markers that support context (minimal play before withdrawal, unusual session bursts)

EDD and escalation (what extra checks were done)

• EDD trigger reason (high-risk geography, unusual funding, VIP, structuring pattern)
• What was requested from the player (and when)
• What was received (documents, explanations), and how it was checked
• Any internal escalation notes and outcomes (compliance lead, MLRO review)

Decision, rationale, and next steps (what you decided and why)

• Decision: monitor, restrict, close, offboard, report
• Rationale tied to your risk assessment and evidence
• Controls applied: limits, freezes (if permitted), payout holds, enhanced monitoring
• SAR/STR decision record (including “not filed” rationale)

For a broader view of how examiners think when they test BSA/AML workpapers, the IRS manual on BSA examination techniques is useful context, even if your regulator is different.

The exact notes auditors want (and the phrases that trigger follow-up)

Auditors read case notes like they’re cross-checking a witness statement. Vague notes create extra questions. Clean notes close loops.

A strong narrative usually follows this simple structure:

• What we saw: objective facts (transactions, timing, status)
• Why it’s a concern: the risk theory (based on your risk assessment)
• What we did: actions taken and evidence reviewed
• What we decided: decision and rationale, including approvals
• What’s next: monitoring plan or closure justification

Example of a tight case note (adapt it to your own style):

On 2025-12-18 (UTC), alert A-18433 triggered due to deposit-to-withdrawal pattern within 2 hours. Player was KYC-verified on 2025-11-02 (UTC) and had no prior AML cases. We reviewed deposits (card) and withdrawal request (e-wallet) and observed minimal wagering before withdrawal. We requested source-of-funds evidence at 2025-12-18T14:22:10Z; documents received at 2025-12-19T09:05:44Z and validated against stated income. Case escalated to MLRO at 2025-12-19T10:12:03Z. Decision: continue monitoring with lower withdrawal limits due to resolved SoF concerns; no SAR filed because funds origin and activity were reasonably explained and corroborated.

Short, specific, and timestamped beats long and dramatic.

Evidence that holds up: what to attach (and how to label it)

Auditors don’t only want screenshots. They want reproducible proof, plus enough metadata to show the evidence wasn’t cherry-picked.

Common “good evidence” items include:

• Exported transaction ledger entries (CSV or PDF), including references and timestamps
• Monitoring alert details (rule version, threshold, and alert payload)
• KYC verification artifacts (verification outcome, doc validation result, vendor response)
• Communication records (inbound, outbound), with timestamps and channel
• EDD artifacts (SoF docs, checks performed, validation steps, results)
• Approval records (reviewer sign-off, MLRO decision, overrides)

For industry expectations around AML controls and documentation quality, the American Gaming Association’s AML best practices guide is a credible reference point.

Two practical evidence habits that reduce audit pain:

• Name files consistently (CaseID_EvidenceType_YYYYMMDD) so retrieval is fast.
• Store source references (report IDs, query parameters, and system-of-record) so you can recreate the same view later.

Timestamp discipline: the timeline auditors reconstruct

Auditors don’t only ask “did you act.” They ask “did you act promptly,” and they verify it by lining up times across systems.

Use consistent timestamps (ideally ISO 8601) for these events:

• Alert created (system time)
• Case created (system time)
• First analyst touch (first view or first note timestamp)
• Customer contact sent (message timestamp)
• Customer response received (inbound timestamp)
• EDD started and completed
• Escalation to MLRO (and MLRO decision time)
• Case closed (with closure reason)

Two easy mistakes to avoid:

• Mixing local times without a time zone.
• Having “case actions” that don’t match the immutable system log.

If you’re preparing for an audit, an AML audit readiness overview like Get ready for your AML audit can help you pressure-test whether your timing, evidence, and governance line up.

What auditors check in the audit log (the “who changed what” test)

Even a perfect narrative can fail if the governance trail is weak.

Auditors commonly look for:

• Maker-checker control: reviewer approval for high-risk closures or “no SAR” decisions
• Edit history: what changed, who changed it, and when
• Override reasons: why a rule was overridden, with approval
• Access control: who can view, edit, export, delete, and whether deletion is restricted

If your platform allows deletion or silent edits to notes, expect questions.

A fast pre-audit check you can run on any case

Pick five closed cases and test this:

• Can you explain the trigger in one sentence, with evidence?
• Do the notes reference specific transactions and dates?
• Do outreach records match message logs?
• Does the decision show approvals where required?
• Could a new analyst understand the case in 3 minutes?
• Are time zones consistent across the file?
• Can you reproduce the key reports used?
• Is the closure reason tied to your risk policy?

If even one case fails, your process will fail under sampling pressure.

Conclusion: make your case file tell the truth, fast

Audits don’t reward long case files, they reward clear ones. When your notes are specific, your evidence is easy to verify, and your timestamps form a clean timeline, auditors spend less time hunting and more time confirming.

Use this AML case file checklist as your standard for every alert type, not just the scary ones. The best time to fix documentation is before the next regulator meeting lands on your calendar.