운영 및 준수 → 제재 심사 및 PEP 필터링

제재 스크리닝 및 PEP 여과

1) 목적과 지역

법적/재정적 위험을 줄이고 라이센스 준수를 보장하십시오. 승인 된 사람/조직을 제거하고 PEP 및 관련 사람을 식별하며 부정적인 매체를 고려하고 비례 조치를 취하십시오. 개인 데이터/금융에 액세스 할 수있는 플레이어 (KYC), 파트너 (KYB), 공급자 및 직원에게 적용됩니다.

2) 이용 약관

제재: 개인/조직/법원/법원과의 상호 작용에 대한 금지/제한.
PEP (정치적으로 노출 된 사람): 공무원 및 가장 가까운 관련자들 (RCA).
부작용 미디어: 상당히 부정적인 출판물 (금융 범죄, 부패 등).
일치-프로필 항목은 목록 항목 (정확한/확률 적) 과 일치합니다.

RCA (친척 및 친척): 배우자, 자녀, 비즈니스 파트너 등

3) 원칙

1. RBA (Risk-Based Approach): 검증 깊이와 빈도는 위험 프로파일 (국가, 지불 방법, 금액, 역할) 에 따라 다릅니다.

2. 설명 가능한 일치: 비교 규칙은 투명합니다. 솔루션 정당성이 저장됩니다

3. 디자인 별 증거: 각 히트/미스에는 인공물이 수반됩니다.
4. 개인 정보 보호 우선: 최소 개인 데이터, 엄격한 액세스, 법률 별 유지.
5. 지속적인 상영: 이벤트 → 즉각적인 재 크리닝; 정기적으로-배치 점검.
6. 진실의 하나의 출처: 선별 결과 및 결정의 단일 등록 (감사 추적).

4) 출처 및 업데이트

제재 및 통제 목록: 글로벌/지역/국가; 산업/영토; 캐리어/용기 목록 (필요한 경우).
PEP/RCA: 다단계 (국가/지역/국제).
부작용 미디어: 위험 분류가있는 집계 된 소스.
업데이트: 매일/매주; 참고서 버전과 로딩 시간을 유지하십시오.

5) 심사 정책 (프레임 워크)

확인시: 첫 번째 예금/인출 전, 지불 세부 정보를 변경할 때, 목록을 업데이트 할 때 프로필/주소/문서를 변경할 때 회전율 임계 값에 도달합니다.
우리가 확인하는 사람: 플레이어 (KYC), 파트너/제공 업체 (KYB), 액세스 할 수있는 직원 (HR/KC).
일치하는 경우: 심사 → 확인/제외/에스컬레이션 → 측정: 거부/보류/EDD/폐쇄.

yaml policy_id: SANC-PEP-POL-001 scope: players, partners, employees triggers:
- on_event: signup, pre_deposit, pre_payout, kyc_update, payout_destination_change
- on_list_update: sanctions    pep    adverse_media risk_bands:
low: [EU_ trusted methods]
high: [high_risk_geo, multiple_payment_methods, turnover>threshold]
actions_by_match:
sanctions_confirmed: block_all & report & freeze_payouts pep_confirmed: edd & enhanced_monitoring adverse_media_high: manual_review & edd review_sla_days: 180 owner: head_of_compliance

6) 알고리즘 일치

정확한 비교: 이름 + DR/문서/국가.
퍼지 매핑: 토큰 화, 정규화, 음역/별칭, 행 거리; 발음학 (예: Soundex/Metaphone과 같은).
상황 무게: 생년월일> 시민권> 주소> 별칭> 국가.
잘못된 일치의 감소: "필수" 필드, 이름 유형별 유사성 임계 값, 빈번한 단어 무시.
지리적 감도: 고위험 지오의 경우 임계 값이 퍼지 속도로 낮습니다.
만료 된 흰색 목록: 원인 및 용어가있는 임시 예외 (흰색 목록).

7) 재구성 트리거

목록 버전을 업데이트합

프로필 이벤트: 전체 이름/주소/문서 변경, 새로운 출력 방법.
임계 값/회전율, 한계 증가, VIP 상태.
AML/위험 신호: 속도, 소스 간 불일치, 장치/IP 이상.

8) 통합 및 데이터

KYC/KYB: IDV/dock/registry 제공 업체; 파트너의 UBO/이사.
지불: "사전 지불" 차단 및 보류/역전 협상.
사례 관리: 일치 카드, 상태 및 의사 결정 로그.
DWH/BI: 적중률/정밀도/품질 드리프트로 케이스를 표시합니다.

9) 코드 제어 (조각)

yaml control_id: SANC-PEP-SIGNUP scope: player_profile trigger:
expr: event in {signup, pre_deposit, pre_payout}
actions:
- screen: sanctions    pep    adverse_media
- block: payout if match_score>=0. 85 until triage_done evidence:
fields: [list_version, query_payload, top_matches]
owner: compliance_ops

yaml control_id: SANC-PEP-RESCREEN scope: population trigger:
expr: sanctions_list. version_changed==true OR pep_list. version_changed==true actions:
- enqueue: rescreen_batch(population_segments=[high_risk, active_payouts])
- notify: compliance_channel

yaml control_id: PEP-MONITOR-01 scope: players trigger:
expr: pep_status==confirmed actions:
- require: edd & source_of_funds
- monitor: payouts frequency>=weekly
- set: limits=pep_limits_schema

yaml control_id: ADV-MEDIA-HI scope: players    partners trigger:
expr: adverse_media. severity in {high, severe}
actions:
- flag: manual_review
- limit: payouts "hold_24h"
- collect: additional_evidence

10) SOP (조각)

SOP: 제재 일치 심사/REP

1. 문맥 확인: 전체 이름/DR/시민권/별명/문서.
2. 검증 소스 (레코드 id, 업데이트 날짜, 법적 상태).
3. 해결책: '확인/거짓 _ 양성/결정적이지 않음'.
4. '확인 된': 조치 (블록/EDD/보고서) 를 적용하고 정당성을 수정하십시오.
5. '결정적이지 않은' 경우: 추가 데이터를 요청하십시오 (문서/주소 확인).

6. 사례를 닫고 화이트리스트/블랙리스트 (해당되는 경우) 를 업데이트하고 증거를 첨부하

SOP: 목록을 업데이트 할 때 재구성

1. 자동 배치 시작, 세그먼트: 활성 결제, 고위험.
2. 새로운 경기 보고서, 사례 할당 SLA.
3. 별도의 대기열에서 간접 관련 계정 (RCA).

SOP: 플레이어/파트너와의 커뮤니케이션

1. 내부 기준을 공개하지 않고 중립 문구.
2. 요청 된 문서의 날짜 및 목록 (EDD가 필요한 경우).
3. 이 경우 커뮤니케이션 수정, 알림 및 마감일.

11) 개인 정보 보호, 보안, 감사

RBAC/ABAC: Compliance/MLRO 만 일치 세부 정보 및 문서에 액세스 할 수 있습니다.
보존: 관할 기간별로 결과와 증거를 유지하십시오. 자동 청소.

암호화: 운송 중/휴식 중; HSM/Vault의 키

감사: 읽기/결정 로그, 규칙/임계 값 버전, 가장 적절한 결과.

12) 대시 보드 및 메트릭

심사 개요: 수표 양, 세그먼트 별 적중률, 퍼지 점유율.
품질: 확인 된 사례의 정밀/리콜, 거짓 긍정적 인 비율, 시간 간 간 (P50/P95).
대기 시간: 공급자의 응답 시간, 대기열 재 구성.
드리프트: 이름/지리 분포 변경, 불확실한 일치의 비율 증가.

준수: 보고서 및 에스컬레이션에 대한 SLA 준수

• 제재에 대한 정확도는 95%, PEP는 90% 입니다.
• P95 (Time-to-Triage)
• 리콜 손실없이 잘못된 긍정적 인 비율 인터넷 QoQ
• 업데이트 할 때 SLA 재 크리닝은 정시에 98% 이상으로 표시됩니다.
• 증거 완전 98%

13) 점검표

• 목록 소스가 연결되고 버전이 기록됩니다.
• RBA 정책이 승인되었고 퍼지 임계 값이 동의했습니다.
• 프로세스 및 역할 (규정 준수/MLRO) 이 할당됩니다.
• 통합: KYC/KYB/결제/사례 도구.
• 대시 보드 및 경고가 배포되었습니다.

• 키 필드 (전체 이름/DR/시민권/별칭) 가 매핑됩니다.
• 체크 소스 및 레코드 날짜.
• 결정과 조치가 수정되었습니다. 알림이 전송되었습니다.
• 증거 첨부, 화이트리스트/블랙리스트 업데이트 (필요한 경우).

• 규칙/임계 값 자동 테스트가 통과되었습니다.
• 의사 결정에 대한 분기 별 감사 (샘플링).
• 드리프트 모니터링은 정상입니다. 임계 값이 수정되었습니다.

14) 반 패턴

지오 및 데이터 품질에 관계없이 "모두를위한 하나의 임계 값".

목록 버전 및 솔루션 이유에 대한 로그인이 없습니

만료 및 원인이없는 영구 화이트리스트.
진실의 두 가지 버전: Excel 솔루션과 prod의 별도 로그.
ETA 및 통신없이 부당한 지불 지연.

목록 업데이트를 위해 재 크림을 사용하지 않습니

15) 30/60/90-계획

• SANC-PEP 정책 승인, 일치하는 임계 값, 역할 및 SLA.
• 목록 제공 업체를 연결합니다. '리스트 _ 버전' 을 기록합니다.
• 'SIGNUP', 'PRE _ PAYOUT', 'RESCREEN' 의 세 가지 기본 컨트롤을 사용하십시오.
• 사례 관리, 대시 보드 및 증거 저장소를 배포하십시오.

• RCA/주소 미디어, 고위험 및 VIP 세그먼트를 추가하십시오.
• 퍼지 (음역/별칭) 를 최적화하고 FPR을 20% 이상 줄입니다.
• 이벤트 및 목록 업데이트로 재 크리닝을 자동화하십시오.
• 품질 샘플링 및 분기 별 감사를 포함하십시오.

• Precision/Recall 및 Time-to-Triage 대상 KPI 달성.
• AML (EDD/SoF) 및 지불 게이트 (소스-소스) 와 통합하십시오.
• KPI를 명령 OKR에 포함 시키십시오. 외부/내부 감사를 수행하십시오

16) FAQ

Q: 실제 경기에서 이름을 어떻게 말합니까?
A: 확인 필드 (DR/문서/시민권), 지리적 맥락 및 별칭 사용; 경계선-신뢰 임계 값이있는 수동 심사.

Q: 계열사와 UBO를 선별해야합니까?
A: 예. KYB 필수: UBO/감독 + 제재/PEP + 네거티브 미디어; UBO를 변경할 때-재신앙과 재 크리닝.

Q: 확인 된 제재로 어떻게해야합니까?
A: 관할 요구 사항에 대한 즉각적인 차단, 동결 지불, 규제 기관/은행에 알림, 전체 증거 패키지 보유.

Q: 제재가있는 경우 왜 불리한 매체입니까?
A: 종종 제재 이전의 초기 위험 신호입니다. EDD/모니터링 및 예방 제한에 사용하십시오.