운영 및 준수 → 라이센스 유형 및 요구 사항

라이센스 유형 및 요구 사항

1) 라이센스 유형 사진

• B2C (운영자): 최종 사용자 (카지노, 라이브, 베팅, 포커, 로또 등) 에게 게임을 제공 할 권리.
• B2B (제공자): 운영자 (플랫폼, 게임/RNG, 라이브 스튜디오, 기술 제공 업체로서의 지불, 호스팅) 에게 플랫폼/컨텐츠/서비스를 제공 할 권리.

• 카지노/슬롯, 라이브 카지노, 스포츠 북 (고정 확률, 인플레이), 포커 (P2P), 빙고/복권, 판타지/스킬 기반.

• 독점 라이센스 (운영자/브랜드 소유자).
• White-Label (브랜드 하위 라이센스/인증 기능이있는 플랫폼 라이센스를 통한 B2C).
• 피부/브랜드 승인 (추가 브랜드를 기존 라이센스에 연결).
• 분산 모델 (로컬 라이센스 + 지역 간 인프라, 미러/에지/규제 데이터 현지화).

2) 요구 사항: 규제 기관이 요구하는 것 (프레임 워크)

법률/기업

수혜자, 소유권 구조, 제재/유죄 판결 없음.
현지 존재 (법인/대표 사무소/책임자).
공급자 계약 (B2B), 콘텐츠 권한, 호스팅/데이터 센터.

재무

최소 승인 된 자본/준비금, 재무 보증/은행 보증.
별도의 고객 계정/자금 분리, 청구 방지 절차.
감사 회계, 수혜자 자금원 (SoF/SoW).

기술 (플랫폼/인프라)

건축, 로깅/관찰 가능성, 중복성, DR/BCP.
게임 무결성: RNG/수학, 콘텐츠 인증, 버전 변경 제어.
정보 보안: 휴식/운송 중 암호화, IAM, 관리 활동 로그.
지리 제한/데이터 현지화, 봇 및 사기에 대한 보호.

RG/KYC/AML

신원 및 주소의 연령/검증, POP/제재, 제한/자체 제외.
트랜잭션 및 동작 모니터링 (속도, SoF), EDD 절차.
자체 배제 레지스터/블랙리스트, 직원 교육.

마케팅/광고/제휴

연령 면책 조항, "위험이없는" 약속 금지, 채널/시간 슬롯의 제한.
KYB 계열사, 크리에이티브 라이브러리, UTM/트래픽 소스 추적.

보고 및 감사

정기/실시간 업로드 (GGR, RG 사례, 불만, AML/SAR).
외부/내부 감사: 기술 감사, 게임/RNG 감사, 보안/개인 정보 감사.
사건보고 (규제 기관/은행/플레이어의 SLA 알림).

3) 라이센스 등록 데이터 모델 (YAML)

yaml license_id: B2C-CASINO-<COUNTRY>-<NNN>
role: b2c      # b2c      b2b verticals: [casino, live, betting]
jurisdiction: <ISO-2>
holder: <legal_entity>
brands: [brandA, brandB]
local_presence: required  # required      optional      none valid_from: YYYY-MM-DD valid_to: YYYY-MM-DD financial_guarantee: {type: bank_guarantee, amount: <currency_amount>}
tech_requirements:
rng_cert: true siem_logs: true dr_rto: "30m"
data_localization: false rg_kyc_aml:
kyc_levels: [basic, address, edd]
self_exclusion: registry aml_ruleset: "v3. 1"
ads_affiliates:
disclaimers: [age, wagering_conditions]
restricted_channels: [tv_daytime]
reporting:
frequency: monthly formats: [csv, api]
realtime: [rg_cases]
contacts:
compliance_officer: email@domain mlro: aml@domain review_sla_days: 180 status: active

4) 라이센스 수명주기 및 의무

4. 1. 라이센스 청구 (응용 프로그램)

Pre-DD: 구조, SoF/SoW, 현지 회사/에이전트, B2B 계약.
기술 패키지: 아키텍처 체계, 보안, BCP/DR, 릴리스/변경 프로세스, 로깅/감사.
내용: RNG/수학, 제공자 목록, 통합.
운영 정책: RG/KYC/AML, 사건, 광고, 불만.
재무: 자본/보증, 사업 계획, 보고 및 세금 예측.

4. 2. 부여 후

정책/코드 규정 준수.
일정보고, 레지스트리 유지 보수 (불만, AML/RG 사례, 사건).
변경 사항 승인: 릴리스, 새로운 제공 업체, 호스팅/데이터 센터 변경, 새로운 지불 방법.

4. 3. 갱신

RNG/보안 인증서가 업데이트되었습

이 기간 동안의 감사, RG/AML 지표, 불만 통계.
재무 안정성/보증 확인.

4. 4. 변형

수직/브랜드 추가, 화이트 라벨/스킨, 플랫폼 마이그레이션.
수혜자/이사의 변경 알림.
광고 정책 및 제휴 네트워크의 변화.

5) 역할/수직 약정 행렬 (예)

6) 응용 프로그램 서류

기업 단위

• 소유권 구조/수혜자/SoF/SoW.
• 지역 법인/대표, 임원의 권한.

금융

• 감사보고/계획.
• 은행 보증/보험/보증금.

기술

• 아키텍처, 관찰 가능성/로깅/감사, CI/CD, 변경 관리.
• BCP/DR (RTO/RPO, 테스트 프로토콜), 보안 (암호화, IAM, 비밀).
• RNG/컨텐츠 인증, 게임 릴리스 제어.

운영/정책

• RG/KYC/AML, 불만, 사건/보고, 지원/SLA.
• 광고/제휴: 규칙, 템플릿, 크리에이티브 라이브러리.

보고

• 형식, 주파수, 테스트 파일, 연락처를 다운로드하십시오.

7) 판매 통제: Policy-/Controls-as-Code

yaml control_id: RG-LIMIT-LOSS-DAILY scope: bets trigger: loss_today > limit_loss_daily actions:
- block: further_bets
- notify: player_template_rg_limit evidence:
fields: [loss_today, limit, messages_sent, ack]
overrides:
- country: <ISO>
set: {limit_loss_daily: <amount>, cool_off_hours: <N>}
owner: rg_officer review_sla_days: 180

yaml control_id: AML-VELOCITY-01 scope: deposits trigger:
expr: rolling_sum(amount, 1h) > baseline_30d3 OR count_unique(payment_method,1h)>=3 actions:
- flag: aml_review
- limit: withdrawals "hold_24h"
- notify: mlro evidence:
store: s3://evidence/aml-velocity/{player_id}/{ts}
owner: mlro

yaml policy_id: RELEASE-GATE-COMPLIANCE require:
- country_overrides_present: true
- report_schemas_valid: true
- rg_controls_enabled: true
- ads_templates_localized: true on_fail: block_release

8) 라이센스 변경 관리 (SOP, 단편)

SOP: 새로운 브랜드 추가 (피부)

1. 라이센스 조건을 확인하십시오 (브랜드 승인 허용 여부).
2. 브랜드/도메인/현지화/연령 태그를 등록하십시오.
3. 링크 RG/KYC/AML/광고 정책 및보고.

4. 테스트 보고서 (브랜드 분할), 로깅 가능

5. 알림 규제 기관/은행 (필요한 경우), 증거 기록.

SOP: 새로운 게임 제공 업체 연결

1. 레지스트리에서 공급자의 상태/인증서를 확인하십시오.
2. 컨텐츠 세트/verticals에 동의하고 RNG/metrics/logging을 설정하십시오.
3. 업데이트보고 (게임/공급 업체 ID).

4. 정책 게이트를 통해 릴리스하고 증거를 수집하십

9) RACI (기능)

10) 규정 준수 일정 (예)

매일: RG/AML 모니터링, 사실보고.
주간: ISP/결제 통합 보고서, 경고 준수 점검.
월간: 규제 업로드 (GGR/베타/RG 사례), DWH와의 조정.
분기 별: 기술 감사/보안 스캔, 제공자 보고서, 정책/제어 검토.
반년: RNG/IS 인증서 갱신, 통제 효과 감사, 라이센스 갱신/승인.

11) 반 패턴

"나중에 라이센스-프로세스가 있습니다": 코드 제어, 보고서 및 증거 부족.

진실의 두 가지 버전: Excel 보고서

데이터에 브랜드 분할 부족, 메트릭의 "공통 힙합".
규제/타이밍 및 로깅이없는 수동 EDD.
KYB 및 크리에이티브 라이브러리가없는 제휴사를 통한 광고.
RNG/게임에 대한 DR 테스트/변경 로그가 없습니다.

12) 성숙도 지표

제어 범위: 중요 포인트의 95% 이상 (등록/예금/비율/결론/보너스).
SLA보고: 업로드의 적시성은 98% 이상이며 회로도 오류 = 0입니다.
증거 완전성: 올바른 패키지가있는 경우의 98% 이상.
RG/AML KPI: 예방/에스컬레이션 된 사례의 비율, 허위 긍정적 QoQ.
감사 결과 TTR: 90 일 마감.
정책 검토 SLA 연장 개정 = 0.

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

• 역할/수준별로 라이센스 및 요구 사항 분류 기록을 작성하십시오.
• 기본 Controls-as-Code 세트 (RG/AML/보고) 를 올립니다.
• Application Dossier 템플릿 작성 (기업/금융/기술/운영).
• CI에서 릴리스 게이트 준수 사용

• 보고 쇼케이스를 연결하고 업로드를 자동화하십시오 (브랜드 분할, 국가 분할).
• RG/KYC/AML을 제품 흐름에 통합; 디자인 별 증거를 실행하십시오.
• 라이센스 RTO/RPO에 대한 최초의 내부 기술 감사 및 DR/BCP 테스트를 수행하십시오.

• 중요한 지점의 95% 를 제어하고 SLA를보고하면 98% 를 커버하십시오.
• RACI 및 약정 일정을 공식화하십시오. KPI를 ODVD 명령에 바인딩합니다.
• 라이센스 확장/변형 (브랜드/수직 변형) 을위한 패키지를 준비하십시오.

14) FAQ

Q: 무엇을 선택해야합니까? 자신의 라이센스 또는 화이트 라벨?
A: 자체 라이센스-자체 라이센스/용어보다 높지만 제어 및 비즈니스 평가는 더 높습니다. 화이트 라벨-빠른 출시, 낮은 유연성/등급, 라이센스 소유자에 대한 의존성.

Q: 응용 프로그램에서 거부 위험을 최소화하는 방법?
A: 강력한 기술 패키지 (보안/DR/관찰 가능성), 재무 보증, 투명한 SoF/SoW, 성숙한 RG/AML 프로세스 및 설계 별 증거.

Q: 공급자/컨텐츠 변경을 관리하는 방법?
A: 변형 절차를 통해: 사전 승인, 게임/RNG 버전 제어, 보고 및 릴리스 로깅.