Operacje i zgodność → Polityka AML i kontrola transakcji

Zasady AML i kontrola transakcji

1) Cel i zakres

Celem polityki AML jest zapobieganie wykorzystywaniu platformy do prania pieniędzy i finansowania terroryzmu, minimalizując fałszywe pozytywy i obciążenie operacyjne. Polityka dotyczy całego cyklu życia gracza: rejestracja → depozyty → gra/transfery → wycofanie; jak również podmioty stowarzyszone, dostawcy i partnerzy płatniczy.

2) Zasady (oparte na ryzyku i dowodach)

1. Podejście oparte na ryzyku (RBA): kontrole i progi zależą od profilu ryzyka (kraj, metoda płatności, zachowanie, kwoty).
2. Kontrola warstwowa: połączenie CCM/sankcji/PEP, analityki behawioralnej i badań ręcznych.
3. Evidence-by-Design: Każde rozwiązanie posiada artefakty: źródła danych, zrzuty ekranu, dzienniki, eksportowane raporty.
4. Privacy-first: minimalizacja danych osobowych, maskowanie, dostęp do roli, kontrolowana polityka retencji.
5. Możliwość wyjaśnienia: zasady i modele są interpretowalne; dla ML - cechy/znaczenie/przykład przypadku.
6. Ciągła poprawa: ustalanie progów, informacje zwrotne z MLRO i retro w poszczególnych przypadkach.

3) Role i obowiązki

MLRO (sprawozdawca ds. prania pieniędzy): właściciel procesu AML, ostateczne decyzje w sprawie SAR/STR, komunikacja z organami regulacyjnymi/bankami.
AML Ops: dochodzenie, gracz/komunikacja bankowa, kontrola sprawy SLA.
Dane/BI & Risk Analytics: wsparcie zasady/modelu, monitorowanie jakości wykrywania.
Płatności/Operacje: przestrzeganie limitów i procedury blokady/odwrotnej, śledzenie transakcji.
Bezpieczeństwo/DPO: ochrona danych, dostęp, incydenty związane z prywatnością.

4) Model ryzyka gracza i segmentu

• Geo/IP/rezydencja, Dokument i metoda KYC.
• Metody wpłat/wypłat, mnogość instrumentów płatniczych.
• Aktywność: kwoty, częstotliwość, winrat/lossrate, sesje nocne, korelacja z innymi kontami.
• Urządzenia/odciski palców, skrzyżowania IP/urządzenia/szczegółów płatności.

Segmenty: niski/średni/wysoki/zabroniony.
Silnik trasujący: Niskie - uproszczone kontrole; Wysoki - EDD/hold/restrykcje.

5) KYC, sankcje i PEP

KYC wielopoziomowe: „KYC1 (tożsamość) → KYC2 (adres) → EDD (dokumenty dodatkowe/SoF)”.
Sankcje/REP: weryfikacja podczas rejestracji, przy znaczących progach depozytów/wniosków oraz przy zmianie szczegółów.
SoF/SoW: przez wyzwalacze (wysokie wersje, niedopasowanie profilu, VIP).
Zatrzymanie: przechowywanie dokumentów zgodnie z wymogami jurysdykcji; dostęp poprzez kontrolę skarbca/check-out.

6) Kontrola transakcji (zasady i sygnały)

• Prędkość: skok szybkiego depozytu/wypłaty; seria małych depozytów → duża wypłata.
• Multi-instrument: Wiele różnych kart/portfeli w krótkim okresie.
• Źródło/niedopasowanie miejsca przeznaczenia: depozyt z jednego instrumentu, wyjście do innego.
• Krążenie: uzupełnienie → minimalne stawki/premie prania → wycofanie.
• Podział/strukturyzacja: dzielone kwoty w ramach progów.
• Nadużycie partnerskie: nieprawidłowy napływ z kanału + typowe wzorce nadużyć.
• Urządzenie/ryzyko IP: zmiana/proxy/ASN wysokiego ryzyka.

• Nierealistyczny winrat na niskiej wariancji, zakłady na „content partner” ze skargami, gry z minimalnym ryzykiem dla dobra obrotu.

7) Kod kontroli (fragmenty)

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) Modele i zasady: dzielenie się

Zasady-pierwszy na początku (szybko, zrozumiałe) + ML do priorytetyzacji (zwiększenie gradientu/logreg/funkcje ekstrakcyjne).
Champion/Challenger: Porównanie obecnych progów do nowych modeli w cieniu.
Monitorowanie dryfu: kontrola przesunięcia funkcji, udziały flag/hold, FPR/TPR.
Możliwość wyjaśnienia: znaczenie SHAP/funkcji, przypadki referencyjne.

9) SOP (fragmenty)

SOP: triage AML

1. Sprawdź kartę gracza (geo, KYC, wskaźnik ryzyka, historia).
2. Weryfikuj źródła danych (dzienniki płatności/gry, połączenia urządzeń).
3. Zdecyduj "jasne/ request_info/hold/EDD/SAR'.
4. Zapisz działania w systemie przypadku i zaktualizuj status.
5. Komunikacja z odtwarzaczem (szablon, czas odpowiedzi).
6. Zmiana progu/reguły (jeśli wiele PR).

SOP: żądanie EDD/SOF

1. Wniosek o dokumenty (zeznania/wynagrodzenie/podatek).
2. Mapa sumy/częstotliwości/źródła do zachowania platformy.
3. Zaktualizuj profil ryzyka, usuń/potwierdź ograniczenia.
4. Zapisz dowody i rozwiązanie (podpis MLRO).

SOP: pasza SAR/STR

1. Zbieranie faktologii (linia czasu, kwoty, linki, zrzuty ekranu).
2. Sprawdź terminy i formaty jurysdykcji/banku.
3. Prześlij SAR/STR, naprawić identyfikator/czas/kanał.
4. Aktualizuj wewnętrzne statusy i ograniczenia konta.
5. Kontynuacja zamykania/regulatora/instrukcji bankowych.

10) Komunikacja z graczami i partnerami

Ton: neutralny i faktyczny, brak ujawniania wewnętrznych przepisów/modeli.
Terminy: wyczyścić ETA odpowiedzi, przypomnienia, utrwalenie na bilecie.
Partnerzy płatniczy: synchronizacja przytrzymana/odwrotna, wymiana danych identyfikacyjnych, pojedynczy kanał AML.

11) Integracja i dane

Brama płatności: statusy transakcji, metoda i szczegóły, zwroty, obciążenie zwrotne.
Platforma gry: obroty/winrat/sesje/wariancja, anomalie.
Wykres urządzenia: odcisk palca/urządzenie/sesja/komunikacja IP.
KYC/PEP/Sankcje: dostawca kontroli zdarzeń i harmonogramów.
Zarządzanie sprawami: statusy, SLA, dziennik decyzji, pakowanie SAR/STR.

12) Wskaźniki jakości (KPI/OKR)

• TPR/Recall dla potwierdzonych przypadków, FPR (fałszywe flagi)
• Precyzja ма Wysokie ryzyko> X%; Automatyczne przezroczyste SzybkośćNiskie ryzyko> Y%.
• Dokładność ustalania priorytetów (górna N% daje M% znalezisk).

• Czas do triażu (P95), obrót EDD, czas trzymania (mediana).
• SAR/STR SLA (złożenie ≤ terminów), zwrot/obciążenie zwrotne po wprowadzeniu środków AML
• Model/reguła Drift - w akceptowalnych korytarzach.

• Straty wynikające z oszustwa/prania brudnych pieniędzy, godziny pracy/sprawa
• Doświadczenie gracza: skargi na procesy AML, NPS na uczciwych graczy.

13) Zarządzanie i bezpieczeństwo

Polityka dostępu: tylko AML/MLRO widzą pola wrażliwe; czytać audyty.
Zatrzymanie: okresy zatrzymania sprawy/dokumentu; automatyczne czyszczenie.
Rejestrowanie: wszystkie działania dotyczące spraw i edycji reguł/modeli.
Podwójna kontrola: zmiany reguły krytycznej/progu wymagają 2 potwierdzeń.
Testy w CI: składnia reguł, konflikt progowy, scenariusze regresji.

14) Listy kontrolne

• Zweryfikowane dane dotyczące transakcji/gier/urządzeń.
• Metody wpłaty/wypłaty są mapowane.
• Sankcje/PEP/geo zweryfikowane.
• Wybrany poprawny typ rozwiązania („clear/hold/EDD/SAR”).
• Zarejestrowana komunikacja ETA i odtwarzacza.

• Pełny harmonogram i kwoty, powiązania z innymi rachunkami.
• Artefakty pomocnicze (zrzuty ekranu/dzienniki/oświadczenia).
• Format i kanał spełniają wymagania.
• Wewnętrzne statusy i ograniczenia zostały zaktualizowane.
• Monitorowanie kolejnych instrukcji.

• Uzasadnione okno progowe/czasowe.
• Istnieje wycena FP/TP, efekt biznesowy.
• Konfigurowane jest monitorowanie dryfu i autotestu.
• Aktualizacja triage playbook.
• Przeprowadzony przegląd MLRO/zgodności.

15) Anty-wzory

Uniwersalne progi „dla wszystkich krajów” bez RBA.
Trzymaj się bez ETA/komunikacji, „wiszących” przypadków.
Modele ML bez możliwości wyjaśnienia i historii wersji.
Ręczne przesyłanie/SAR bez szablonów dowodów i kontroli daty.
Brak komunikacji depozytowej, słaba integracja z płatnościami.
Nie ma zwykłego retro na fałszywych pozytywów.

16) 30/60/90 - plan realizacji

• Zatwierdza politykę AML, role (MLRO/AML Ops) i matrycę RBA.
• Uruchom podstawowe sterowanie-as-Code (prędkość, niedopasowanie src/dst, schemat gier).
• Włącz poziomy KYC + sankcje/PEP, utwórz szablony SOP (triage/EDD/SAR).
• Wprowadź zasady przechowywania i przechowywania dowodów.

• Podłącz agregator ryzyka, przypadki automatycznego routingu i raportowanie SLA.
• Mistrz startu/challenger dla progów i asystent priorytetyzacji ML.
• Zintegruj wykres płatności/gier/urządzeń z jednym profilem gracza.
• Polecenia pociągu, szablony komunikacyjne debugowania, włączają autotesty reguły.

• Zmniejszenie FPR ≥ 20% bez utraty Recall; zmniejszenie czasu do triażu o ≥ 30%.
• Osiągnięcie SLA SAR/STR = 100% na czas; zamknij wszystkie „nieustanne” przypadki.
• przeprowadzenie audytu wewnętrznego projektu i skuteczności kontroli; rekord OKR za następny kwartał.

17) FAQ

P: Jak zrównoważyć bezpieczeństwo i UX?
Odp.: RBA routing: dla niskiego ryzyka - automatyczne czyszczenie, dla średnich - łatwe żądania, dla wysokiej - EDD/hold. Przejrzyste ETA i komunikacja.

P: Co zrobić z VIP-ami i wysokimi limitami?
Odp.: Obowiązkowy EDD, okresowy przegląd SoF/zachowania, źródło do źródła, dodatkowe limity.

P: Kiedy przejść do banku/regulatora?
Odp.: Z potwierdzonymi czerwonymi flagami/podejrzeniami zgodnie z terminami jurysdykcyjnymi; po konsultacjach z MLRO i utrwaleniu dowodów.