운영 및 준수 → AML 정책 및 거래 제어

AML 정책 및 거래 제어

1) 목적과 범위

AML 정책의 목적은 자금 세탁 및 테러 자금 조달을위한 플랫폼의 사용을 방지하여 오 탐지 및 운영 부하를 최소화하는 것입니다. 이 정책은 플레이어의 전체 수명주기에 적용됩니다. 등록 → 예금 → 게임/이전 → 철회; 계열사, 제공자 및 지불 파트너뿐만 아니라

2) 원칙 (위험 기반 및 설계 별 증거)

1. RBA (Risk-Based Approach): 수표 및 임계 값은 위험 프로파일 (국가, 지불 방법, 행동, 금액) 에 따라 다릅니다.
2. 레이어드 컨트롤: CCM/Sanctions/PEP, 행동 분석 및 수동 조사의 조합.
3. 디자인 별 증거: 각 솔루션에는 데이터 소스, 스크린 샷, 로그, 내보낸 보고서 등의 아티팩트가 있습니다.
4. 개인 정보 보호 우선: 개인 데이터 최소화, 마스킹, 역할 별 액세스, 통제 된 보존 정책.
5. 설명 가능성: 규칙과 모델은 해석 가능합니다. ML - 기능/중요도/케이스 예제.
6. 지속적인 개선: 임계 값 설정, MLRO의 피드백 및 복고풍.

3) 역할과 책임

MLRO (자금 세탁보고 책임자): AML 프로세스 소유자, SAR/STR에 대한 최종 결정, 규제 기관/은행과의 커뮤니케이션.
AML Ops: 조사, 플레이어/은행 통신, SLA 사례 제어.
데이터/BI 및 위험 분석: 규칙/모델 지원, 탐지 품질 모니터링.
지불/작성: 한도 준수 및 보류/역 절차, 거래 추적.
보안/DPO: 데이터 보호, 액세스, 개인 정보 보호 문제.

4) 플레이어 및 세그먼트 위험 모델

• Geo/IP/Residency, KYC 문서 및 방법.
• 예금/인출 방법, 다양한 지불 수단.
• 활동: 양, 빈도, vinrate/lossrate, 야간 세션, 다른 계정과의 상관 관계.
• 장치/지문, IP/장치/결제 세부 사항 교차점.

세그먼트: 낮음/중간/높음/금지.
라우팅 엔진: 낮음-단순화 된 점검; 높은 EDD/보류/제한.

5) KYC, 제재 및 PEP

계층 KYC: 'KYC1 (신원) → KYC2 (주소) → EDD (추가 문서/SoF)'.
제재/REP: 등록 중, 예금/결론의 상당 기준 및 세부 사항 변경시 검증.
SoF/SoW: 트리거 (높은 회전, 프로필 불일치, VIP).
보존: 관할권에서 요구하는 문서 보유; 볼트/체크 아웃 제어를 통한 액세스.

6) 거래 제어 (규칙 및 신호)

• 속도: 빠른 퇴적/철수 스파이크; 일련의 작은 퇴적물 → 큰 철수.
• 멀티 악기: 짧은 기간에 다양한 카드/지갑.
• 소스/대상 불일치: 한 기기에서 출력하고 다른 기기로 출력.
• 순환: 보충 → 최소 요금/세탁 보너스 → 철회.
• 분할/구조: 임계 값에서 분할 금액.
• 제휴 남용: 채널에서 비정상적인 유입 + 일반적인 남용 패턴.
• 장치/IP 위험: 장치 변경/프록시/고위험 ASN.

• 낮은 차이에 대한 비현실적인 vinrate, 불만이있는 "콘텐츠 파트너", 이직을 위해 최소한의 위험이있는 게임에 베팅합니다.

7) 코드 제어 (조각)

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) 모델 및 규칙: 공유

우선 순위 지정을위한 규칙 시작시 (빠르게 이해할 수있는) + ML (그라디언트 부스팅/로그/추출 가능한 기능).
Champion/Challenger: 현재 임계 값을 새 모델과 비교합니다.
드리프트 모니터링: 기능 이동 제어, 플래그/홀드 공유, FPR/TPR.
설명 가능성: wwwP/기능의 중요성, 참조 사례.

9) SOP (조각)

SOP: AML 심사

1. 플레이어의 카드를 확인하십시오 (geo, KYC, 위험률, 기록).
2. 데이터 소스 검증 (결제 로그/게임, 장치 연결).
3. '명확한/요청 _ info/hold/EDD/SAR' 을 결정하십시오.
4. 사례 시스템의 작업을 기록하고 상태를 업데이트하십시오.
5. 플레이어와의 커뮤니케이션 (템플릿, 응답 시간).
6. 임계 값/규칙 개정 (많은 FP 인 경우).

SOP: EDD/SoF 요청

1. 문서 요청 (명세서/급여/세금).
2. 플랫폼 동작에 대한지도 합계/주파수/소스.
3. 위험 프로파일을 업데이트하고 제한을 제거/확인하십시오.
4. 증거 및 솔루션 저장 (MLRO 서명).

SOP: SAR/STR 피드

1. 사실학 수집 (타임 라인, 금액, 링크, 스크린 샷).
2. 관할권/은행의 마감일 및 형식을 확인하십시오.
3. SAR/STR 제출, 식별자/시간/채널 수정.

4. 내부 상태 및 계정 제한을 업데이트하십시오

5. 폐쇄/규제/은행 지침에 대한 후속 조치.

10) 플레이어 및 파트너와의 커뮤니케이션

톤: 중립적이고 사실적이며 내부 규칙/모델의 공개가 없습니다.
마감일: 응답, 알림, 티켓 고정에 대한 명확한 ETA.
지불 파트너: 보류/역 동기화, 케이스 ID 교환, 단일 AML 채널.

11) 통합 및 데이터

결제 게이트웨이: 트랜잭션 상태, 방법 및 세부 정보, 반품, 요금 환급.
게임 플랫폼: 회전율/vinrate/세션/분산, 이상.
장치 그래프: 지문/장치/세션/IP 통신.
KYC/PEP/제재: 이벤트 및 일정 심사 제공 업체.
사례 관리: 상태, SLA, 의사 결정 로그, SAR/STR 패킹.

12) 품질 지표 (KPI/ODVD)

• 확인 된 사례에 대한 TPR/리콜, FPR (거짓 플래그) ° QoQ.
• 고위험> X%; 자동 클리어 비율은 저 위험> Y% 입니다.
• 사례 우선 순위 정확도 (상위 N% 는 발견의 M% 를 제공합니다).

• P95 (Time-to-Triage), EDD 턴어라운드, 보류 기간 (중앙값).
• SAR/STR SLA (
• 모델/규칙 드리프트-허용 가능한 복도 내에서.

• 사기/인터넷 세탁, 영업 시간/사례 인터넷 손실.
• 플레이어 경험: AML 프로세스에 대한 불만, 정직한 플레이어에 대한 NPS.

13) 거버넌스 및 안전

액세스 정책: AML/MLRO 만 민감한 필드를 볼 수 있습니다. 감사를 읽으십시오.
보존: 사례/문서 보존 기간; 자동 청소.
로깅: 사례 및 규칙/모델 편집에 대한 모든 작업.
이중 제어: 중요한 규칙/임계 값 변경에는 2 개의 확인이 필요합니다.
CI의 테스트: 규칙 구문, 임계 값 충돌, 회귀 시나리오.

14) 점검표

• 거래/게임/장치 데이터 검증.
• 예금/인출 방법이 매핑됩니다.
• 제재/PEP/geo가 확인되었습니다.
• 올바른 솔루션 유형 선택 ('clear/hold/EDD/SAR').
• ETA 및 플레이어 커뮤니케이션이 기록되었습니

• 전체 타임 라인 및 금액, 다른 계정과의 연결.
• 아티팩트 지원 (스크린 샷/로그/문).
• 형식과 채널이 요구 사항을 충족합니다.
• 내부 상태 및 제한이 업데이트되었습니다.
• 후속 명령을 모니터링하십시오.

• 임계 값/시간 창이 정당화되었습니다.
• 비즈니스 효과 인 FP/TP 평가가 있습니다.
• 드리프트 및 가장 자동 모니터링이 구성됩니다.
• 업데이트 된 플레이 북 심사.
• MLRO/준수 검토가 수행되었습니다.

15) 반 패턴

RBA가없는 "모든 국가에 대한" 범용 임계 값.
ETA/통신없이 "매달린" 사례를 유지하십시오.
설명 및 버전 기록이없는 ML 모델.
증거 템플릿 및 날짜 제어없이 수동 업로드/SAR.
데포 짐 부족 vyvod 커뮤니케이션, 지불과의 통합 부족.
오 탐지에 대한 규칙적인 복고풍은 없습니다.

16) 30/60/90-구현 계획

• AML 정책 승인, 역할 (MLRO/AML Ops) 및 RBA 행렬.
• 코드로서의 기본 제어 실행 (속도, src/-불일치, 게임 패턴).
• KYC 계층 + 제재/PEP를 활성화하고 SOP 템플릿 (심사/EDD/SAR) 을 작성하십시오.
• 증거 저장 및 보존 정책을 입력하십시오.

• 위험 애그리 게이터, 자동 라우팅 사례 및 SLA 보고서를 연결하십시오.
• 임계 값 및 ML 우선 순위 지정을위한 런칭 챔피언/챌린저.
• 결제/게임/장치 그래프를 단일 플레이어 프로필에 통합합니다.
• 트레이닝 명령, 디버그 통신 템플릿은 규칙 자동 테스트를 가능하게합니다.

• 리콜 손실없이 FPR을 20% 이상 줄입니다. 타임 투 트라이얼 (Time-to-Triage) 을 30% 이상 줄입니다.
• 성취 SLA SAR/STR = 제 시간에 100%; 모든 "오래된" 사례를 닫습니다.
• 컨트롤의 설계 및 효과에 대한 내부 감사를 수행합니다. 다음 분기에 OKR을 기록하십시오.

17) FAQ

Q: 보안 및 UX의 균형을 맞추는 방법?
A: RBA 라우팅: 저 위험-자동 청소, 중간-쉬운 요청, 높은 EDD/홀드. 투명한 ETA 및 커뮤니케이션.

Q: VIP 및 높은 한계에 대해 어떻게해야합니까?
A: 필수 EDD, 정기적 인 SoF/행동 검토, 소스-소스, 추가 제한.

Q: 언제 은행/규제 기관으로 확대해야합니까?
A: 관할 마감일에 따라 확인 된 적기/의심; MLRO 상담 및 증거 수정 후.