ოპერაციები და შესაბამისობა ლიცენზიების ტიპები და მოთხოვნები

ლიცენზიის ტიპები და მოთხოვნები

1) ლიცენზიის ტიპების სურათი

• B2C (კამერის): თამაშის შეთავაზების უფლება საბოლოო მომხმარებლებისთვის (casino, live, betting, poker, lotto და სხვ.).
• B2B (მომწოდებელი): ოპერატორებისთვის პლატფორმის/შინაარსის/მომსახურების მიწოდების უფლება (პლატფორმა, თამაშები/RNG, ცოცხალი სტუდიები, გადახდები, როგორც ტექნოლოგიური პროვაიდერი, ჰოსტინგი).

• Casino/Slots, Live Casino, Sportsbook (fixed-odds, in-play), Poker (P2P), Bingo/Lottery, Fantasy/Skill-based.

• საკუთარი ლიცენზია (ოპერატორი/ბრენდის მფლობელი).
• White-Label (B2C კანონი ბრენდის სუბლიცენზიის/ავტორიზაციის პლატფორმის ლიცენზიის საშუალებით).
• Skin/Brand Authorization (დამატებითი ბრენდების დაკავშირება არსებულ ლიცენზიაზე).
• განაწილებული მოდელი (ადგილობრივი ლიცენზია + ჯვარედინი რეგიონალური ინფრასტრუქტურა, სარკეები/edge/მონაცემების ლოკალიზაცია სტანდარტების შესაბამისად).

2) მოთხოვნები: რას ითხოვენ რეგულატორები (ჩარჩო)

იურიდიული/კორპორატიული

ბენეფიციარები, საკუთრების სტრუქტურა, სანქციების არარსებობა/ნასამართლეობა.
ადგილობრივი ყოფნა (იურიდიული პირი/წარმომადგენლობითი ოფისი/პასუხისმგებელი ოფიცერი).
კონტრაქტები პროვაიდერთან (B2B), შინაარსის უფლებები, ჰოსტინგი/მონაცემთა ცენტრი.

ფინანსური

მინიმალური უფლებამოსილი კაპიტალი/რეზერვები, ფინანსური გარანტიები/საბანკო გარანტიები.
ინდივიდუალური კლიენტის ანგარიშები/სახსრების სეგრეგაცია, ანტი-ჩარგებაკის პროცედურები.
აუდიტის ანგარიში, ბენეფიციარების წყაროები (SoF/SoW).

ტექნიკური (პლატფორმა/ინფრასტრუქტურა)

არქიტექტურა, ლოჯისტიკა/დაკვირვება, სარეზერვო, DR/BCP.
თამაშების პატიოსნება: RNG/მათემატიკა, შინაარსის სერთიფიკაცია, ვერსიების შეცვლის კონტროლი.
ინფორმაციის უსაფრთხოება: დაშიფვრა at rest/in transit, IAM, Admin სამოქმედო ჟურნალი.
გეო-შეზღუდვები/მონაცემების ლოკალიზაცია, ბოტებისა და თაღლითობებისგან დაცვა.

RG/KYC/AML

პიროვნებისა და მისამართების ასაკი/გადამოწმება, REP/სანქციები, შეზღუდვები/თვითკმაყოფილება.
გარიგებისა და ქცევის მონიტორინგი (velocity, 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. ოპერაციული ეტაპი (Post-გრანტი)

შესაბამისობა Policy/Controlls-as-Code.
გრაფიკის ანგარიში, რეესტრების ჩატარება (საჩივრები, AML/RG შემთხვევები, ინციდენტები).
ცვლილებების კოორდინაცია: გამოშვებები, ახალი პროვაიდერები, საერთო საცხოვრებლის/დანართის შეცვლა, გადახდის ახალი მეთოდები.

4. 3. გაფართოება (Renewal)

განახლებული RNG/უსაფრთხოების სერთიფიკატები.
აუდიტი პერიოდის განმავლობაში, RG/AML ინდიკატორები, საჩივრების სტატისტიკა.
ფინანსური სტაბილურობის/გარანტიების დადასტურება.

4. 4. ცვლილებები

ვერტიკალური/ბრენდის დამატება, თეთრი-ლაბელის/სკინის, პლატფორმის მიგრაცია.
შეტყობინებები ბენეფიციარების/დირექტორების შეცვლის შესახებ.
ცვლილებები სარეკლამო პოლიტიკაში და აფილატის ქსელში.

5) ვალდებულებების მატრიცა როლზე/ვერტიკალზე (მაგალითი)

6) განაცხადის ჩეკის სია (განაცხადის დოსიერი)

კორპორატიული ბლოკი

• საკუთრების სტრუქტურა/ბენეფიციარები/SoF/SoW.
• ადგილობრივი იურიდიული პირი/წარმომადგენელი, ოფიცრების უფლებამოსილება.

ფინანსები

• აუდიტის ანგარიში/გეგმა.
• საბანკო გარანტია/დაზღვევა/ანაბარი.

ტექნიკა

• არქიტექტურა, დაკვირვება/ლოჯისტიკა/აუდიტი, CI/CD, ცვლილების მენეჯმენტი.
• BCP/DR (RTO/RPO, ტესტის ოქმები), უსაფრთხოება (დაშიფვრა, IAM, საიდუმლოებები).
• RNG/შინაარსის სერტიფიკაცია, თამაშის გამოშვებების კონტროლი.

ოპერაციები/პოლიტიკა

• RG/KYC/AML, საჩივრები, ინციდენტები/რეპორტირება, საფოსტო/SLA.
• რეკლამა/აფილატები: წესები, შაბლონები, კრეატიული ბიბლიოთეკა.

მოხსენებები

• გადმოტვირთვის ფორმატები, სიხშირეები, ტესტის ფაილები, საკონტაქტო პირები.

7) გაყიდვების კონტროლი: Policy-/Controlls-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. სალიცენზიო პირობების გადამოწმება (ნებადართულია თუ არა brand authorization).
2. დარეგისტრირება ბრენდი/დომენი/ლოკალიზაცია/ასაკობრივი ეტიკეტები.
3. დააკავშირეთ RG/KYC/AML/Ads პოლიტიკა და მოხსენებები.
4. შეამოწმეთ მოხსენებები, ჩართეთ ჟურნალები.
5. შეატყობინეთ რეგულატორს/ბანკებს (საჭიროების შემთხვევაში), დააფიქსირეთ დრო.

SOP: თამაშის ახალი პროვაიდერის კავშირი

1. შეამოწმეთ პროვაიდერის სტატუსი/სერთიფიკატები რეესტრში.
2. კოორდინირებული შინაარსის ნაკრები/ვერტიკალი, RNG/მეტრიკის/ლოჯისტიკის კონფიგურაცია.
3. ანგარიშის განახლება (თამაშების იდენტიფიკატორები/მიმწოდებელი).
4. გამოუშვეთ გამოშვება პოლიცია-კარიბჭის საშუალებით, შეაგროვეთ ღონისძიება.

9) RACI (ფუნქციები)

10) ვალდებულებების კალენდარი (მაგალითი)

ყოველდღიურად: RG/AML მონიტორინგი, ფაქტების განმეორებითი ინციდენტი.
ყოველკვირეულად: პროვაიდერების/გადახდების ინტეგრაციის ანგარიშები, ალერტების შესაბამისობის შემოწმება.
ყოველთვიურად: მარეგულირებელი გადმოტვირთვები (GGR/bets/RG შემთხვევები), კრიკეტები DWH- ით.
კვარტალი: აუდიტი/უსაფრთხოების სკანერები, პროვაიდერების მოხსენებები, რეპროდუქცია პოლიტიკა/კონტროლი.
ნახევარი წელი/წელი: RNG/IB სერთიფიკატების გახანგრძლივება, კონტროლის ეფექტურობის აუდიტი, ლიცენზიების/ავტორიზაციის გახანგრძლივება.

11) ანტი შაბლონები

„ლიცენზია არსებობს - პროცესები შემდეგ“: კონტროლის არარსებობა-as-Code, მოხსენებები და მოვლენები.
სიმართლის ორი ვერსია: Excel ანგარიშები - პროდუქტიული ლოგოები.
Brand-split- ის არარსებობა მონაცემებში, „საერთო თაიგული“ მეტრიკა.
სახელმძღვანელო EDD რეგულაციების/ვადების და ჟურნალების გარეშე.
რეკლამირება აფილიატების გარეშე KYB და შემოქმედებითი ბიბლიოთეკის გარეშე.
RNG/თამაშებისთვის არ არსებობს DR ტესტები/ჟურნალები.

12) სიმწიფის მეტრიკა

Coverage მაკონტროლებლები: კრიტიკული წერტილების 95% (რეგისტრაცია/ანაბარი/განაკვეთები/გამომავალი/პრემია).
Reporting SLA: გადმოტვირთვის დროულობა 98%, სქემატური შეცდომები = 0.
Evidence completeness: საქმეების 98% -ზე სწორი პაკეტებით.
RG/AML KPIs: პრევენციული/ესკალირებული შემთხვევების პროპორცია, False positive - QoQ.
Audit findings TTR: დახურვა 90 დღე.
Policy მიმოხილვა SLA: ვადაგადაცილებული გადასინჯვები = 0.

13) 30/60/90 - განხორციელების გეგმა

• შექმენით ლიცენზიების რეესტრი და მოთხოვნების ტაქსონომია როლებს/ვერტიკალებზე.
• გაზარდეთ ძირითადი ნაკრები Controlls-as-Code (RG/AML/ანგარიში).
• შეაგროვეთ აპლიკაცია Dossier შაბლონები (კორპორატიული/ფინანსური/ეს/ოპერაციული).
• ჩართეთ release-gate თამაში CI- ში.

• დააკავშიროთ საანგარიშო ფანჯრები და ავტომატიზაცია მოახდინეთ გადმოტვირთვაზე (brand-split, country-split).
• ინტეგრირება RG/KYC/AML სასურსათო flow- ში; დაიწყეთ გამოჩენა.
• ჩაატარეთ პირველი შიდა აუდიტი და DR/BCP ტესტი ლიცენზირებული RTO/RPO.

• კრიტიკული წერტილების 95% -ით დაფარვა, Reporting SLA - 98%.
• ფორმალიზება RACI და ვალდებულებების კალენდარი; დაუკავშირეთ KPI OKR გუნდებს.
• მოამზადეთ პაკეტი ლიცენზიის გახანგრძლივების/ცვალებადობისთვის (ბრენდების/ვერტიკალების ვარიაციები).

14) FAQ

Q: რა უნდა აირჩიოთ: საკუთარი ლიცენზია ან თეთრი ლაბორატორია?
A: საკუთარი ლიცენზია უფრო მაღალია, ვიდრე SAREH/ვადა, მაგრამ კონტროლი და ბიზნესის შეფასება უფრო მაღალია. White-label - უფრო სწრაფი გაშვება, მოქნილობა/შეფასება, დამოკიდებულება ლიცენზიის მფლობელისგან.

Q: როგორ შევამციროთ განაცხადის უარის თქმის რისკები?
A: ძლიერი ტექნიკური პაკეტი (უსაფრთხოება/DR/დაკვირვება), ფინანსური გარანტიები, გამჭვირვალე SoF/SoW, სექსუალურ RG/AML პროცესები და „evidence-by-design“.

Q: როგორ გავაკონტროლოთ პროვაიდერების/შინაარსის ცვლილებები?
A: variation პროცედურების საშუალებით: წინასწარი კოორდინაცია, თამაშის ვერსიების კონტროლი/RNG, მოხსენებები და გამოცემების ჟურნალები.