AML policy and anti-money laundering

1) Purpose and coverage

The purpose of AML policy is to prevent money laundering and terrorist financing, ensure compliance with regulatory requirements and protect the platform, players and partners. The policy applies to all legal entities of the group, employees, outsourcing teams, as well as to third parties (PSP, affiliates, content providers) interacting with cash flows and customer data.

• Products: casino/betting, P2P transfers, tournaments, bonuses/cashback, marketplace services.
• Channels: web, mobile applications, API integrations, crypto-on/off-ramp.
• Geographies: all countries/states served, taking into account local requirements.

2) Regulatory support and principles

The basis of the policy is FATF recommendations (risk-oriented approach, KYC/KYB, sanctions, monitoring, reporting), local AML/CFT laws (Europe - AMLD directives, UK - MLR, USA - BSA/Patriot Act, etc.), as well as data protection requirements (GDPR/similar).

• RBA (Risk-Based Approach): Resources focus on higher risks.
• Proportionality: Measures are consistent with customer/transaction/product risk.
• Accountability-Solution capture, auditing, and traceability.
• Privacy by Design: minimum data, legality of processing, security.

3) Roles and responsibilities (management)

Board: approves policy, risk appetite, periodic report.
Senior Management: provides resources, KPIs, implementation.
MLRO/AML Officer: process owner, regulatory reporting, SAR/STR, monitoring methodology, interaction with LEA.
Compliance Team: KYC/KYB, sanctions/PEP, case management, training.
Risk & Analytics: scoring models, scenarios, rule calibration.
Engineering/Security: provider integrations, logs, access control, encryption.
Operations/Payments: lead control, manual checks, data quality.

RACI (упрощенно): Board — A, MLRO — R/A, Compliance — R, Risk — R, Eng — C/R, Ops — C/R, Internal Audit — I/C.

4) RBA: risk model

• Client (country, residency, profession, PPE/sanctions, behavioral risk).
• Product (casino/betting, P2P, crypto, high limits, cross border).
• Channel (online onboarding, no presence, anonymous tools).
• Geography (high-risk jurisdictions, sanctions regimes).
• Transactions (volume, turnover rate, cashing patterns).

Rating: starting speed on onboarding + dynamic factors (history, devices, payment patterns) ⇒ segmentation into low/medium/high risk and selection of the level of measures: CDD/EDD/SOW.

5) KYC/KYB and sanction screening (association with AML)

KYC for individuals: document + liveness, address, age, sanctions/REP, Adverse Media.
KYB for companies/affiliates/providers: registration, UBO/directors, sanctions/POP, verification of activities and sources of funds.
Sanctions/REP: primary and periodic screening, fuzzy match, manual clearing.
SOW/SOF: with high limits and anomalies - confirmation of the origin of funds/wealth.
Re-KYC: scheduled and event-triggered.

6) Transaction monitoring and behavioral analytics

• Fast deposit → withdrawal cycle without real game risk.
• Adhesions by amounts/frequency, split payments ("smurfing").
• Mismatch of country IP/BIN/address, frequent change of payment methods.
• Atypical night/mass traffic, device clusters (device graph).
• Using anonymizers/VPN, proxy farms, OS/browser spoofing.
• Suspicious bonus patterns, multiaccounting, chargeback cycles.

ML/behavioral models: probabilistic anomalies, graph connections, risk speed of players/affiliates, high-roller segmentation.

Case management: alert generation → qualification → request for documents/explanations → decision (escalation/blocking/SAR).

7) "Red Flags" (iGaming-specificity)

Regular deposits from third parties/many single cards per player.
P2P/tournament transfers between linked accounts.
Strong misalignment of profiles (age, profession vs turnover).
Inter-jurisdictional migration for no explicable reason.
Systematic cashing out with no gaming activity or minimal margins.
Attempts to bypass the limits of CUS/outputs/bonuses, "farm" accounts.
Aphiliates with unclear source of traffic or abnormally high CR→WD.

8) SAR/STR: internal investigations and reporting

Suspicion threshold: "reasonable suspicion" regardless of amount.
Process: alert → fact collection → MLRO solution → SAR/STR submission on time, without tipping-off.
Escalation: temporary blocking, freezing of funds at the request of the LEA/regulator, communication plan with the client.
Documentation: event timelines, data sources, team actions, decisions, and rationale.

9) Data storage and security

Terms: as a rule, at least 5 years after the termination of the relationship (specified locally).
Target storage: profiles, documents, alerts, SAR/STR, access log, evidence base.
Security: at-rest/in-transit encryption, HSM/secret storage, RBAC/ABAC, immutable logs (WORM), monitoring access and employee actions.

10) Training, quality control and audit

Training: annual for everyone, in-depth - for employees of risk functions; tests and certification.
QA/diagnostics: selective case reviews, double checks (4-eyes), retro on erroneous decisions.
Internal audit: independent assessment of compliance with policies, regulatory requirements and process effectiveness.
Stress-tests: incident exercises (sanctions, large typology, mass alerts).

11) Crypto and VASP (if applicable)

Travel Rule: exchange of sender/receiver attributes between providers.
Blockchain analytics: risk rate of addresses, clusters, sanctions/mixer tags.
It/off-ramp control: wallet owner compliance, data matching, limits and external address log.
Price dynamics/volatility: special rules for amounts, marking of "unusual" conversions.

12) Interaction with third parties

PSP/banks/KYC providers: contracts, SLA, DPIA, fault tolerance test plans.
Affiliates: KYB, traffic quality monitoring, prohibition of risk sources, post-click audit.
Correspondent relations: in-depth verification of partners, periodic review.

13) AML solution architecture (recommendations)

Integrations: CUS/sanctions providers, PSP, anti-fraud, blockchain analytics.
Event bus: all transactions/events fall into a thread (Kafka/equivalent) with unchangeable storage.
Rules engine + ML: online scoring (milliseconds) and offline revisions (batch/near-real-time).
Case system: prioritized queues, customer request templates, SLA, integration with mail/instant messengers.
Observability: logs, metrics, traces; rule/model version and effect.
Degradation: safe simplification (fail-open/close by policy), backup providers, retrai/quorum.

14) Performance Metrics and KPIs

SAR Conversion Rate: Proportion of alerts that have become SAR/STR.
Time-to-Alert/Time-to-Decision: speed of detection and decision.
False Positive Rate/Precision-Recall in alerts.
Coverage: percentage of transactions monitored/screened.
Rework/Appeals: share of cases with solution revision.
Training Completion:% of employees with relevant training.
Vendor SLA: uptime providers, TTV on CUS/sanctions.

15) Checklists

• KYC/KYB, age/geo, sanctions/PEP, Adverse Media.
• RBA scoring, basic limits, device fingerprint.
• Consent, privacy, reporting of checks.

• Re-sanction screening, SOF/SOW if necessary.
• Matching the owner of the payment instrument.
• Behavioral validation and transaction history.

• Collecting facts and documents.
• Internal MLRO opinion.
• Report submission on time; prohibition of tipping-off.
• Post-sea, updating rules/models.

16) Typical mistakes and how to avoid them

Blind KYC checkbox without RBA: strengthen dynamic analytics and limits.
Lack of feedback in models: implement a decision → outcome loop.
Ultra-hard "derisking" instead of risk management: use EDD/SOW and controlled limits rather than total bans.

Failure to take into account regional rules/sanctions: maintain "geo-profiles."

Weak Decision Log: Standardize rationale and artifact storage.

17) AML policy structure template (for your wiki)

1. Introduction and scope

2. Definitions and terms (AML/CFT, CDD/EDD, SOF/SOW, PEP, etc.)

3. Regulatory framework and references to local laws

4. Management and Roles (Board, MLRO, RACI)

5. RBA methodology and risk appetite

6. KYC/KYB and sanction screening

7. Transaction monitoring (rules + ML) and case management

8. "Red Flags" and iGaming Scripts

9. SAR/STR Procedures and Regulatory Interactions/LEA

10. Data storage, privacy, security

11. Staff training and awareness

12. Vendors and Third Parties (SLA, Audit)

13. Audit, QA and continuous improvement

14. Appendices: checklists, forms, letter templates, metrics

18) Example of risk matrix (fragment)

Outcome: low/medium/high risk → measures: CDD/EDD + SOF/SOW/limitations/yield.

19) Implementation and maintenance plan

Identify process owners and SLAs.
Integration map (PSP, KYC, sanctions, analytics).
Run with basic rule set + FP/FN control.
Quarterly scenario calibration, annual policy review.
Curricula and pass control.
Regular Board/Management reports (KPIs, incidents, risk changes).

Total

An effective AML policy is not a "document on the shelf," but a living cycle: risk assessment → control measures → monitoring → investigation → reporting → improvement. Build a process around the RBA, ensure a strong KYC/KYB and sanctions loop, implement high-quality monitoring of transactions with case management and comply with the discipline of data storage, training and auditing - this way you will reduce regulatory and reputational risks, while maintaining conversion and business sustainability.