Operations and Compliance → AML Policy and Transaction Control

AML Policy and Transaction Control

1) Purpose and scope

The purpose of the AML policy is to prevent the use of the platform for money laundering and terrorism financing, minimizing false positives and operational load. The policy applies to the player's entire life cycle: registration → deposits → game/transfers → withdrawal; as well as affiliates, providers and payment partners.

2) Principles (risk-based & evidence-by-design)

1. Risk-Based Approach (RBA): checks and thresholds depend on the risk profile (country, payment method, behavior, amounts).
2. Layered Controls: a combination of CCM/Sanctions/PEP, behavioral analytics and manual investigations.
3. Evidence-by-Design: Each solution has artifacts: data sources, screenshots, logs, exported reports.
4. Privacy-first: minimization of personal data, masking, access by role, controlled retention policy.
5. Explainability: rules and models are interpretable; for ML - features/importance/case example.
6. Continuous Improvement: setting thresholds, feedback from MLRO and retro by case.

3) Roles and responsibilities

MLRO (Money Laundering Reporting Officer): owner of the AML process, final decisions on SAR/STR, communication with regulators/banks.
AML Ops: investigations, player/bank communications, SLA case control.
Data/BI & Risk Analytics: rule/model support, detection quality monitoring.
Payments/Ops: compliance with limits and hold/reverse procedures, transaction tracing.
Security/DPO: data protection, access, privacy incidents.

4) Player and segment risk model

• Geo/IP/Residency, KYC Document and Method.
• Deposit/withdrawal methods, multiplicity of payment instruments.
• Activity: amounts, frequency, vinrate/lossrate, night sessions, correlation with other accounts.
• Devices/fingerprinting, IP/device/payment details intersections.

Segments: Low/Medium/High/Prohibited.
Routing engine: Low - simplified checks; High - EDD/hold/restrictions.

5) KYC, sanctions and PEP

Tiered KYC: 'KYC1 (identity) → KYC2 (address) → EDD (additional documents/SoF)'.
Sanctions/REP: verification during registration, at significant thresholds of deposits/conclusions and when changing details.
SoF/SoW: by triggers (high revs, profile mismatch, VIP).
Retention: retention of documents as required by jurisdiction; access via vault/check-out control.

6) Transaction control (rules and signals)

• Velocity: fast deposit/withdrawal spikes; a series of small deposits → a large withdrawal.
• Multi-instrument: Many different cards/wallets in a short period.
• Source/Destination mismatch: deposit from one instrument, output to another.
• Circularity: replenishment → minimum rates/washing bonuses → withdrawal.
• Split/Structuring: split amounts under thresholds.
• Affiliate abuse: abnormal inflow from the channel + typical patterns of abuse.
• Device/IP risk: device changes/proxies/high-risk ASNs.

• Unrealistic vinrate on low variance, bets on the "content partner" with complaints, games with minimal risk for the sake of turnover.

7) Controls-as-Code (fragments)

yaml control_id: AML-VELOCITY-DEP-01 scope: deposits risk_weight: 0. 8 trigger:
expr: rolling_sum(amount, 1h) > baseline_30d3
OR count_unique(payment_method, 1h) >= 3
OR count(amount < threshold_structuring, 24h) >= 5 actions:
- flag: aml_review
- limit: withdrawals "hold_24h"
- request: "KYC2_or_EDD"
evidence:
store: s3://evidence/aml/velocity/{player_id}/{ts}
fields: [amounts_1h, methods_1h, ip, device, kyc_level]
owner: mlro review_sla_days: 180

yaml control_id: AML-SRC-DST-02 scope: withdrawals trigger:
expr: payout_method!= last_successful_deposit_method actions:
- limit: withdrawals "require_same_source"
- notify: payments_team
- flag: aml_review exceptions:
- condition: method_type=="bank_transfer" AND policy. allow_bank_payouts==true evidence:
fields: [payout_method, last_deposit_method, policy_ref]

yaml control_id: AML-GAMING-PATTERN-03 scope: gameplay trigger:
expr: turnover_24h / deposits_24h > 10
AND avg_bet_risk_index < 0. 2
AND session_count_24h > 8 actions:
- flag: aml_review
- limit: bonuses "freeze"
- request: "source_of_funds"

yaml control_id: AML-RISK-SCORE inputs: [AML-VELOCITY-DEP-01, AML-SRC-DST-02, AML-GAMING-PATTERN-03, sanctions, pep]
score:
expr: w1velocity + w2srcdst + w3gaming + w4sanctions + w5pep thresholds:
- high: score>=0. 8 -> EDD + hold
- medium: score>=0. 5 -> review
- low: score<0. 5 -> auto_clear

8) Models and Rules: Sharing

Rules-first at the start (quickly, understandable) + ML for prioritization (gradient boosting/logreg/extractable features).
Champion/Challenger: Comparing current thresholds to new models in the shade.
Drift monitoring: control of shift of features, shares of flags/hold, FPR/TPR.
Explainability: SHAP/feature importance, reference cases.

9) SOP (fragments)

SOP: AML triage

1. Check the player's card (geo, KYC, risk rate, history).
2. Verify data sources (payment logs/games, device connections).
3. Decide 'clear/ request_info/hold/EDD/SAR'.
4. Record the actions in the case system and update the status.
5. Communication with the player (template, response time).
6. Threshold/rule revision (if many FPs).

SOP: EDD/SoF request

1. Request for documents (statements/salary/tax).
2. Map sums/frequencies/sources to platform behavior.
3. Update risk profile, remove/confirm restrictions.
4. Save evidence and solution (MLRO signature).

SOP: SAR/STR feed

1. Collect factology (timeline, amounts, links, screenshots).
2. Check deadlines and formats of jurisdiction/bank.
3. Submit SAR/STR, fix identifier/time/channel.
4. Update internal statuses and account restrictions.
5. Follow-up to closure/regulator/bank instructions.

10) Communication with players and partners

Tone: neutral and factual, no disclosure of internal rules/models.
Deadlines: clear ETAs for response, reminders, fixation on the ticket.
Payment partners: hold/reverse synchronization, case-ID exchange, single AML channel.

11) Integrations and data

Payments Gateway: transaction statuses, method and details, returns, chargeback.
Game Platform: turnover/vinrate/sessions/variance, anomalies.
Device Graph: fingerprint/device/session/IP communication.
KYC/PEP/Sanctions: Event and Schedule Screening Provider.
Case Management: statuses, SLAs, decision log, SAR/STR packing.

12) Quality indicators (KPI/OKR)

• TPR/Recall for confirmed cases, FPR (false flags) ↓ QoQ.
• Precision по High-risk > X%; Auto-clear Rate для Low-risk > Y%.
• Case Prioritization Accuracy (upper N% give M% of finds).

• Time-to-Triage (P95), EDD Turnaround, Hold Duration (median).
• SAR/STR SLA (submission of ≤ deadlines), returns/chargeback after AML measures ↓.
• Model/Rule Drift - within acceptable corridors.

• Losses from fraud/ ↓ laundering, operating hours/case ↓.
• Player Experience: complaints about AML processes, NPS on honest players.

13) Governance and Safety

Access policies: only AML/MLRO see sensitive fields; read audits.
Retention: case/document retention periods; automatic cleaning.
Logging: all actions on cases and rule/model edits.
Dual Control: critical rule/threshold changes require 2 confirmations.
Tests in CI: rule syntax, threshold conflict, regression scenarios.

14) Checklists

• Transaction/game/device data verified.
• The deposit/withdrawal methods are mapped.
• Sanctions/PEP/geo verified.
• Correct solution type selected ('clear/hold/EDD/SAR').
• ETA and player communication recorded.

• Full timeline and amounts, connections with other accounts.
• Supporting artifacts (screenshots/logs/statements).
• The format and channel meet the requirement.
• Internal statuses and restrictions have been updated.
• Monitor subsequent instructions.

• Threshold/time window justified.
• There is an FP/TP valuation, a business effect.
• Drift and autotest monitoring is configured.
• Updated playbook triage.
• MLRO/Compliance review conducted.

15) Anti-patterns

Universal thresholds "for all countries" without RBA.
Hold without ETA/communication, "hanging" cases.
ML models without explainability and version history.
Manual uploads/SARs without evidence templates and date control.
Lack of depozit↔vyvod communication, poor integration with payments.
There is no regular retro on false positives.

16) 30/60/90 - implementation plan

• Approve AML policy, roles (MLRO/AML Ops) and RBA matrix.
• Run basic Controls-as-Code (velocity, src/dst mismatch, gaming pattern).
• Enable KYC tiers + sanctions/PEP, create SOP templates (triage/EDD/SAR).
• Enter evidence storage and retention policy.

• Connect risk aggregator, auto-routing cases and SLA reporting.
• Launch champion/challenger for thresholds and ML prioritization assistant.
• Integrate payments/game/device graph into a single player profile.
• Train commands, debug communication templates, enable rule autotests.

• Reduce FPR ≥ 20% without loss of Recall; reduce Time-to-Triage by ≥ 30%.
• Achieve SLA SAR/STR = 100% on time; close all "stale" cases.
• Conduct an internal audit of the design and effectiveness of controls; record OKR for the next quarter.

17) FAQ

Q: How to balance security and UX?
A: RBA routing: for low-risk - auto-cleaning, for medium - easy requests, for high - EDD/hold. Transparent ETAs and communications.

Q: What to do about VIPs and high limits?
A: Mandatory EDD, periodic SoF/behavior review, source-to-source, additional limits.

Q: When to escalate to a bank/regulator?
A: With confirmed red flags/suspicions according to jurisdictional deadlines; after MLRO consultation and evidence fixation.