Depozitlar va yo’qotishlar limitlari

1) Nega limitlar kerak

Limitlar - Responsible Gaming (RG) ning asosiy vositasi boʻlib, oʻyinchilarga xarajatlar va vaqtni nazorat qilish, operatorlarga esa shikoyatlar, chorjbeklar va operatsion tavakkalchiliklarni kamaytirgan holda litsenziya va axloqiy majburiyatlarni bajarish imkonini beradi.

• Zararlar va impulsiv xarajatlarning oldini olish.
• Xarajatlarning shaffofligi va bashorat qilinishi.
• Tartibga soluvchilar/to’lov sheriklari talablariga muvofiqligi.

2) Limitlar turlari va atamalar

Izoh: ko’plab yurisdiksiyalarda depozit va/yoki yo’qotishlar limiti minimal bo’lishi shart.

3) «Sovutish» va limitlarni o’zgartirish qoidalari

Limitni pasaytirish - darhol kuchga kiradi.
Ko’tarilish - faqat «sovutish» davridan keyin (24-168 soat, siyosat/yurisdiksiyaga bog’liq).
Limitni bekor qilish = «cheklovlarsiz» → ham «sovutish» orqali.
O’zgarishlar tarixi o’zgarmas jurnalda saqlanadi (vaqt, IP/qurilma, kanal).

4) Hisob-kitobning halol formulalari

4. 1 Depozitlar limiti

Belgilangan davrda muvaffaqiyatli toʻldirilgan mablagʻlarni kuzatib bormoqdamiz.
Bekor qilingan/qaytarilgan depozitlar haqiqiy sarfni oshirmaydi, lekin mahalliy normalarni hisobga oling (bekor qilish urinish sifatida hisoblanganda).

allowed_today = daily_deposit_limit - sum(successful_deposits[today])
allowed_today = max(0, allowed_today)

4. 2 Yo’qotishlar limiti (Net Loss)

Net Loss = (davrning Σ depozitlari) − (davrning Σ xulosalari) − (davr boshidagi balans − davr oxiridagi balans) − (pul ekvivalentidagi bonus hisobdan chiqarish)

Valyuta konvertatsiyasini va davrning vaqtinchalik chegaralarini (lokal TZ) hisobga oling.
Chegaraviy nazorat: 80 %/100% ga yetganda - yangi stavkalar/depozitlarni blokirovka qilish (siyosat bo’yicha).

4. 3 Aylanma limiti

Barcha stavkalarni jamlaymiz (shu jumladan, agar siyosatda shunday yozilgan bo’lsa, pul ekvivalentidagi frispinlar).
Stavkalarni qaytarish/bekor qilish chegiriladi.

5) UX-patternlar va tayyor matnlar

Foydalanish imkoniyati: limitlar profilda ko’rinadi (1-2 ta bosish), onbordingda - limit belgilash bo’yicha yumshoq tavsiya.

• "Xarajatlarni nazorat qilish uchun limitlarni tanlang. Pasayish - darhol, oshish - 48 soatdan keyin (sovutish davri)"

• "Bugun siz 200 evrodan 120 evroga (60%) hissa qo’shdingiz. 80 € qoldi"

• "Kunlik limitga erishildi. Ertaga soat 00:00 da hisobni to’ldirishingiz mumkin"

• "Kunlik limitni €300 ga oshirish 48 soatdan keyin kuchga kiradi. Tasdiqlash?"

• "Siz kunlik yo’qotishlar limitining 80 foiziga erishdingiz. Taym-aut 24 soat yoki limitlarni sozlashni ko’rib chiqing"

Antipatternlar: «qorong’u» patternlarsiz, limitlar ekranlarida promosiyasiz, variantlarning ko’rinishi teng.

6) Boshqa RG asboblari bilan aloqa

Taym-autlar va o’z-o’zini istisno qilish: to’g’ridan-to’g’ri limitlar ekranidan foydalanish mumkin.
Reality Checks: limitlar bo’yicha taraqqiyotni ko’rsatadi; oshganda - yumshoq/qattiq pauza.
Marketing suppression: muddati tugagan o’yinchi rag’batlantiruvchi offeralarni olmasligi kerak.

7) To’lovlar, bonuslar va kazino yadrosi bilan integratsiya qilish

Payments: limit hisobdan chiqarishga urinishdan oldin qo’llaniladi; mavjud qoldiqni koʻrsatyapmiz.
Bonus Engine: bonus-depozitlar va freebet hisob-kitobga kiritilganligini aniqlang («bepul» metrikani emas, balki pul ekvivalentini hisoblashni tavsiya qilamiz).
Game Server: Limitga yetganda (idempotent, reason code) stavkalarni blokirovka qilish.
Multivalyuta: hisob-kitobni referens valyutasida saqlang; yaxlitlash - o’yinchi foydasiga.

8) Arxitektura (referens)

Limits Service: limitlar, davrlar, qoldiqlarni saqlaydi; hodisalarda qayta sanaydi.
Event Bus: `deposit. succeeded`, `withdrawal. completed`, `bet. placed`, `bet. settled`, `bonus. applied`.
Policy Engine: «sovutish», eskalatsiya (taym-aut) qoidalari.
Gateway Guards: depozit/stavkadan oldingi predikatlar.
UI/Notifications: onbording, limitlar markazi, haqiqat-chek.
Audit/WORM: oʻzgarmas oʻrnatish/oʻzgartirish/bloklash jurnallari.

Fail-safe: Limits Service mavjud bo’lmaganda - xavfni oshirishni talab qiladigan operatsiyalarni (stavkalar/depozitlar) doimo taqiqlash yoki qat’iy siyosat bo’yicha oxirgi belgilangan qoldiqni qo’llash.

9) Limitlar siyosati (wiki uchun skelet)

1. Viloyat: kimga taalluqli, qaysi mahsulotlar/kanallar.
2. Limitlar turlari va davrlar; ta’rifi va formulasi.
3. Limitlarning o’zgarishi: pasayishi - darhol; oshirish - «sovutish».
4. Hisob-kitobning shaffofligi: misollar, vaqt zonasi, multivalyuta.
5. Istisnolar (mintaqaviy normalar, tekshirishlar kuchaytirilgan VIP-tartib-taomillar).
6. Maʼlumotlar va maxfiylik: minimallashtirish, tarixni saqlash, profillash uchun DPIA.
7. Apellyatsiyalar: kontur-odam, javob muddatlari, reason codes.

10) Hisob-kitob namunalari (illyustrativ)

Kunlik depozit limiti €200.
Ertalab: + €120 → qoldiq €80.
Kechqurun: urinish + €100 → rad etildi, taklif + €80 (mavjud qoldiq).
Yo’qotishlar limiti €100/kun.
Depozitlar: €150; Xulosalar: €20; Balans 00:00 - €50; Balans hozir 40 yevro.
Net Loss = 150 − 20 − (50 − 40) = 120 − 10 = €110 → limit oshgan, stavkalar bloki.

11) Metrika va SLO

Adoption Rate limitlari (maqsad: faol o’yinchilarning 30-50 foizini ≥).
Limit Breach Prevention: limitga erishgandan keyin oldini olingan urinishlar ulushi (→ ~ 100%).
Time-to-Enforce: hodisadan blokirovkagacha (<1-2 sek).
Increase Cool-off Adherence: kechikishga 100% rioya qilish.
Harm Reduction: 30 kundan keyin takroriy «zararli» patternlarni kamaytirish.
Complaint/Chargeback Rate: amalga oshirilgandan keyin pasayish.
System Availability (Limits): ≥99. 9% degradatsiya alertlari bilan.

12) RACI (roli va javobgarligi)

13) Chek-varaqlar (operatsion)

Boshlashdan oldin

• Limitlar turlari va davrlar aniqlandi; formulalar hujjatlashtirilgan.
• «Sovutish» sozlangan; A/B matnlar va onbording tayyor.
• Payments/Game/CRM/Bonus bilan integratsiyalashuv QA tomonidan amalga oshirildi.
• WORM auditi, SLO/metrik dashbordlar kiritilgan.

Foydalanishda

• Hisob-kitoblar va taymzonlarning to’g "riligi bo’yicha haftalik audit.
• false declines/false allows monitoringi.
• Cheklangan o’yinchilar uchun suppression kampaniyalarini tekshirish.

Hodisalar

• Degradatsiya rejasi (read-only, pre-approved limits).
• Nosozliklarda o’yinchilarga aloqa qilish, qoldiqlarni tuzatish.

14) Tez - tez xatolar va ulardan qanday qochish mumkin

Vijdonsiz net loss (xulosa/balans hisobga olinmaydi) → formulani tuzatib, misollarni joylashtiring.
Asta-sekin foydalanish → shina va sinxron predikatlar orqali voqealar.
→ Yuqori tartibga solish xavfi oshganda «sovutish» ning yo’qligi.
Maxfiy chegaralar ekranlarini profil, futer, onbordingga joylashtiring.
CRM/ads.
Hech qanday jurnal yo’q → muvofiqligini isbotlab bo’lmaydi (WORM’ni qo’shing).

15) Joriy etish yo’l xaritasi (6 qadam)

1. DPIA siyosati: limitlar, formulalar, «sovutish» turlarini aniqlash.
2. Arxitektura: Limits Service, Event Bus, guards, idempotency.
3. Integratsiyalar: Payments/Game/Bonus/CRM; multivalyuta.
4. UX va matnlar: onbording, limitlar markazi, reality-checks.
5. Kuzatilishi: SLO metrikasi, alerta, WORM-audit.
6. Yaxshilanishlar: A/B xabarlar, chegaralarni kalibrlash, shikoyatlar/hodisalarni tahlil qilish.

Jami

Depozitlar va yo’qotishlar limitlari sozlamalardagi «belgi» emas, balki nazorat konturi orqali amalga oshiriladi: aniq formulalar, tezkor va ishonchli blokirovkalar, qorong’u patternlarsiz halol UX, taym-autlar/o’z-o’zini istisno qilish bilan aloqa va qat’iy kuzatish. Bunday yondashuv futbolchilarni himoya qiladi, komplayensni mustahkamlaydi va biznesning barqarorligini oshiradi.