عملیات و انطباق → انواع مجوز و الزامات

انواع مجوز و الزامات

1) تصویر انواع مجوزها

• B2C (اپراتور): حق ارائه بازی به کاربران نهایی (کازینو، زندگی می کنند، شرط بندی، پوکر، لوتو، و غیره).
• B2B (ارائه دهنده): حق ارائه پلت فرم/محتوا/خدمات به اپراتورها (پلت فرم، بازی/RNG، استودیوهای زنده، پرداخت به عنوان ارائه دهنده فناوری، میزبانی).

• کازینو/شکافها, کازینو زنده, Sportsbook (ثابت شانس, در بازی), پوکر (P2P), یکنوع بازی شبیه لوتو/قرعه کشی, فانتزی/مهارت های مبتنی بر.

• مجوز اختصاصی (اپراتور/صاحب نام تجاری).
• برچسب سفید (B2C درست از طریق مجوز پلت فرم با نام تجاری sublicense/مجوز).
• مجوز پوست/نام تجاری (اتصال مارک های اضافی به مجوز موجود).
• مدل توزیع شده (مجوز محلی + زیرساخت های بین منطقه ای، آینه/لبه/محلی سازی داده های نظارتی).

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. درخواست مجوز (درخواست)

قبل از 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) کنترل در فروش: سیاست/کنترل به عنوان کد

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/Ads را پیوند دهید.
4. گزارش های تست (نام تجاری تقسیم)، ورود به سیستم را فعال کنید.
5. تنظیم کننده/بانک ها را مطلع کنید (در صورت لزوم)، مدارک را ثبت کنید.

SOP: اتصال یک ارائه دهنده بازی جدید

1. بررسی وضعیت/گواهی های ارائه دهنده در رجیستری.
2. در مورد مجموعه محتوا/عمودی توافق کنید، RNG/metrics/logging را پیکربندی کنید.
3. به روز رسانی گزارش (شناسه بازی/فروشنده).
4. انتشار از طریق دروازه سیاست، جمع آوری شواهد.

9) RACI (توابع)

10) تقویم انطباق (به عنوان مثال)

روزانه: نظارت RG/AML، گزارش حادثه در حقایق.
هفتگی: گزارش ادغام ISP/پرداخت، بررسی انطباق هشدار.
ماهانه: آپلود نظارتی (موارد GGR/بتا/RG)، آشتی با DWH.
سه ماهه: ممیزی های فنی/اسکن های امنیتی، گزارش های ارائه دهنده، بررسی سیاست/کنترل.
نیم سال/سال: تجدید گواهی RNG/IS، ممیزی اثربخشی کنترل، تجدید مجوز/مجوز.

11) ضد الگوهای

«مجوز وجود دارد - فرآیندهای بعد»: عدم کنترل به عنوان کد، گزارش ها و شواهد.
دو نسخه از حقیقت: گزارش اکسل ≠ سیاهههای مربوط تولیدی.
عدم تقسیم نام تجاری در داده ها، «پشته مشترک» معیارها.
EDD های دستی بدون تنظیم/زمان بندی و ورود به سیستم.
تبلیغات از طریق شرکت های وابسته بدون KYB و کتابخانه های خلاق.
بدون تست DR/تغییر سیاهههای مربوط برای RNG/بازی.

12) معیارهای بلوغ

پوشش کنترل: ≥ 95٪ از نقاط بحرانی (ثبت نام/سپرده/نرخ/نتیجه گیری/پاداش).
گزارش SLA: به موقع بودن آپلود ≥ 98٪، خطاهای شماتیک = 0.
شواهد کامل: ≥ 98٪ موارد با بسته های صحیح.
RG/AML KPI ها: نسبت موارد جلوگیری/تشدید، مثبت کاذب ↓ QoQ.
TTR یافته های حسابرسی: بسته شدن ≤ 90 روز.
بررسی سیاست بازنگری SLA عقب افتاده = 0.

13) 30/60/90 - طرح اجرایی

• ایجاد یک ثبت مجوز و طبقه بندی الزامات توسط نقش/verticals.
• بالا بردن کنترل به عنوان کد مجموعه ای اساسی (RG/AML/گزارش).
• ساخت پرونده برنامه قالب (شرکت های بزرگ/مالی/تکنولوژی/عملیاتی).
• فعال کردن انطباق release-gate در CI.

• اتصال ویترین گزارش و خودکار آپلود (نام تجاری تقسیم، کشور تقسیم).
• ادغام RG/KYC/AML به جریان محصول ؛ اجرای شواهد توسط طراحی.
• انجام اولین حسابرسی فنی داخلی و آزمون DR/BCP برای مجوز RTO/RPO.

• پوشش 95٪ از نقاط بحرانی با کنترل ≥، گزارش SLA ≥ 98٪.
• RACI و تقویم تعهد رسمی ؛ KPI را به دستورات OKR متصل کنید.
• آماده سازی بسته برای گسترش مجوز/تنوع (نام تجاری/تغییرات عمودی).

14) سوالات متداول

س: چه چیزی را انتخاب کنید: مجوز خود یا برچسب سفید ؟

A: مجوز خود - بالاتر از САРЕХ/term، اما کنترل و ارزیابی کسب و کار بالاتر است. برچسب سفید - راه اندازی سریع تر، انعطاف پذیری/امتیاز پایین تر، وابستگی به صاحب مجوز.

س: چگونه می توان خطرات رد در برنامه را به حداقل رساند ؟

پاسخ: بسته فنی قوی (امنیت/DR/مشاهده پذیری)، ضمانت های مالی، SoF/SoW شفاف، فرآیندهای بالغ RG/AML و شواهد با طراحی.

س: چگونه تغییرات ارائه دهنده/محتوا را مدیریت کنیم ؟

A: از طریق روش های مختلف: قبل از تصویب، کنترل نسخه بازی/RNG، گزارش و ورود به سیستم.