Operazioni e Complaens per criteri AML e controllo transazioni

Criteri AML e controllo delle transazioni

1) Obiettivo e ambito

Lo scopo della politica AML è quello di prevenire l'uso della piattaforma per il riciclaggio dei fondi e il finanziamento del terrorismo, riducendo al minimo i falsi effetti e il carico operativo. La politica si applica all'intero ciclo di vita del giocatore: registrazione dei depositi , gioco/traduzione, output; e per affiliati, provider e partner di pagamento.

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

1. Risk-Based Approach (RBA) - I controlli e le soglie dipendono dal profilo di rischio (paese, metodo di pagamento, comportamento, importi).
2. Layered Controlls: combinazione di CUS/sanzioni/RER, analisi comportamentali e indagini manuali.
3. Evidence-by-Design: ogni soluzione dispone di artefatti: origini dati, screenshot, logi, report esportati.
4. Privacy-first: minimizzazione dei PDN, occultamento, accesso ai ruoli, regole di retensing controllate.
5. Esplainability: regole e modelli sono interpretabili per ML - fici/importanti/portaoggetti di esempio.
6. Continuous Improvement: impostazione delle soglie, feedback da MLRO e retromarcia dalle valigette.

3) Ruoli e responsabilità

MLRO (Money Laundering Reporting Officer) - Proprietario del processo AML, decisioni finali su SAR/TR, comunicazioni con regolatori/banche.
AML Ops: indagini, comunicazioni con giocatori/banche, controllo delle valigette SLA.
Data/BI & Risk Analytics: supporto delle regole/modelli, monitoraggio della qualità della rilevazione.
Payments/Ops: rispettare i limiti e le procedure hold/reverse, tracciare le transazioni.
Sicurezza/DPO: protezione dei dati, disponibilità, incidenti di privacy.

4) Modello di rischio del giocatore e dei segmenti

• Geo/IP/residenza, documento e metodo KYC.
• Metodi di deposito/conclusione, molteplicità degli strumenti di pagamento.
• Attività: importi, frequenza, vinrite/losrait, sessioni notturne, correlazione con altri account.
• Dispositivi/fingerprint, intersezioni IP/dispositivi/informazioni di pagamento.

Segmenti: Low/Medium/High/Prohibited.
Motore di instradamento: Low - Controlli semplificati High - EDD/hold/vincoli.

5) KYC, sanzioni e PEP

Tiered KYC: 'KYC1 (identità) → KYC2 (indirizzo) → EDD (documenti aggiuntivi/SoF)'.
Sanzioni/RER: verifica al momento della registrazione, con soglie significative di depositi/conclusioni e quando i dati vengono modificati.
SoF/SoW: trigger (alta rotazione, inadeguatezza del profilo, VIP).
Conservazione dei documenti in conformità con i requisiti di giurisdizione; accesso tramite vault/controllo delle erogazioni.

6) Controllo delle transazioni (regole e segnali)

• Velocity: spine veloci di depositi/conclusioni; Una serie di piccoli depositi è una grande conclusione.
• Multi-impianto: molte carte/portafogli diverse nel breve periodo.
• Fonte/Destinazione mismatch - Deposito da uno strumento, output da un altro.
• Circolarity: rifornimento delle aliquote minime/riciclaggio bonus.
• Split/Strutturing: frazionamento delle somme sotto le soglie.
• Affiliate abuse: flusso anomalo dal canale + tipici pattern di abuso.
• Device/IP risk: cambi di dispositivo/proxy/ASN ad alto rischio.

• Vinrite irrealistiche a bassa dispersione, scommesse «content partner» con lamentele, giochi a minor rischio per il giro d'affari.

7) Controlls-as-Code (sezioni)

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) Modelli e regole: condivisione

Rule-first alla partenza (in modo rapido, spiegabile) + ML per la priorità (sfumatura/logreg/fitta recuperabile).
Campione/Challenger: confronta le soglie attuali con i nuovi modelli nell'ombra.
Monitoraggio Draft - Controllo dello spostamento del fiocco, della quota di flag/hold, FPR/TPR.
Esplainability: SHAP/feature influance, valigette di riferimento.

9) SOP (sezioni)

SUP - Triaggio di attivazione AML

1. Controlla la carta del giocatore (geo, KYC, rischi-scorciatoie, storia).
2. Verifica delle origini dati (login di pagamento/gioco, comunicazioni per dispositivo).
3. Accetta «clear/sollest _ info/hold/EDD/SAR».
4. Fissa le azioni nel sistema delle valigette e aggiorna lo stato.
5. Comunicazione con il giocatore (modello, data di risposta).
6. Revisione della soglia/regola (se ci sono molti FPs).

Richiesta

1. Richiesta di documenti (estratti conto/stipendi/tasse).
2. Mappare importi/frequenze/sorgenti al comportamento della piattaforma.
3. Aggiorna il profilo di rischio, rimuove o conferma i vincoli.
4. Salva l'evidence e la soluzione (firma MLRO).

Alimentazione SAR/STOP

1. Raccogli i fatti (timeline, somme, comunicazioni, screen).
2. Controllare deadline e formati di giurisdizione/banca.
3. Invia SAR/TR, fissa ID/ora/canale.
4. Aggiorna gli stati interni e le restrizioni dell'account.
5. Follow up fino alla chiusura/istruzioni del regolatore/banca.

10) Comunicazioni con giocatori e partner

Il tono è neutrale e fattuale, senza rivelazione di regole/modelli interni.
I tempi sono chiari ETA per rispondere, promemoria, fissare il tessuto.
Partner di pagamento: sincronizzazione hold/reverse, scambio valigetta-ID, unico canale AML.

11) Integrazioni e dati

Payments Gateway - Stato delle transazioni, metodo e accessori, restituzioni, conformeback.
Game Platform: giro/vinrate/sessioni/dispersione, anomalie.
Device Graph: fingerprint/connessioni dispositivi/sessioni/IP.
KYC/PEP/Sanctions - provider di screening per eventi e pianificazione.
Case Management: states, SLA, registro delle soluzioni, imballaggio SAR/TR.

12) Indicatori di qualità (KPI/OKR)

• TPR/Recall per valigette confermate, FPR (false bandiere) .
• Precision по High-risk > X%; Auto-clear Rate для Low-risk > Y%.
• Case Priorization Accuracy (N% superiore dà M% di scoperte).

• Time-to-Triage (P95), EDD Turnaround, Hold Duration (mediana).
• SAR/STRA SLA, rimborsi/conformeback dopo le misure AML.
• Model/Rule Draft - all'interno dei corridoi consentiti.

• Perdite causate da frode/riciclaggio di , orologi operativi/valigetta.
• Player Experience: denunce per processi AML, NPS per giocatori onesti.

13) Governance e sicurezza

Criteri di accesso: solo AML/MLRO vedono campi sensibili; verifiche di lettura.
Data di conservazione delle valigette/documenti Pulizia automatica.
Registrazione: tutte le azioni relative alle valigette e alla modifica delle regole/modelli.
Dual Control: le modifiche critiche alle regole/soglie richiedono due conferme.
Test CI: sintassi delle regole, conflittualità delle soglie, script di regressione.

14) Assegno fogli

• I dati delle transazioni/giochi/dispositivi sono stati convalidati.
• Mappati metodi di deposito/ritiro.
• Sanzioni verificate/RER/geo.
• È stato selezionato un tipo corretto di soluzione ('clear/hold/EDD/SAR').
• Registrato ETA e comunicazione al giocatore.

• Timeline completa e importi, collegamenti con altri account.
• Gli artefatti di conferma (screen/login/estratti).
• Formato e canale corrispondono alla richiesta.
• Stati e vincoli interni aggiornati.
• Controllo delle istruzioni successive.

• La soglia/finestra dell'ora è giustificata.
• C'è una valutazione FP/TP, effetto business.
• È configurato il monitoraggio della deriva e dell'autostop.
• Il playbook del triage è stato aggiornato.
• Invertito da MLRO/Compliance.

15) Anti-pattern

Soglie universali «per tutti i paesi» senza RBA.
Hold senza ETA/comunicazione, valigette appese.
Modelli ML privi di spiegabilità e registro versioni.
Scaricamenti manuali/SAR senza modelli evidence e controllo dei tempi.
Mancanza di comunicazione, scarsa integrazione con i pagamenti.
Non c'è un retro regolare per falso funzionamento.

16) Piano di implementazione 30/60/90

• Approva criteri AML, ruoli (MLRO/AML Ops) e matrice RBA.
• Avvia Controlls-as-Code di base (velocity, src/dst mismatch, gaming pattern).
• Abilita KYC tiers + sanzioni/RER, crea modelli SOP (triage/EDD/SAR).
• Immettere il repository evidence e il criterio di retensione.

• Connettere l'aggregatore di rischio-scansione, il routing automatico delle valigette e il report SLA.
• Avvia il campione/challenger per le soglie e l'assistente di priorità ML.
• Integra payments/game/device grafico in un unico profilo del giocatore.
• Istruire i comandi, correggere i modelli di comunicazione, abilitare le regole automatiche.

• Ridurre la FPR del 20% senza perdere Recall; Ridurre il Time-to-Triage del 30%.
• Raggiungere SLA SAR/TR = 100% a tempo; Chiudere tutte le valigette.
• Eseguire un controllo interno del design e dell'efficienza dei controlli Fissare OKR per il prossimo trimestre.

17) FAQ

Q: Come bilanciare sicurezza e UX?
A: routing RBA: per low-risk - pulizia automatica, per medium - richieste facili, per high - EDD/hold. L'ETA e le comunicazioni trasparenti.

Cosa fare con VIP e limiti elevati?
A: EDD obbligatorio, revisione periodica SoF/comportamento, output rigido collegato (source-to-source), limiti aggiuntivi.

Quand'è l'escalation in banca/regolatore?
A: Con le bandiere rosse confermate/sospetti secondo la tempistica giurisdizionale; dopo consultazione MLRO e fissazione evidence.