GH GambleHub

책임있는 지불 및 플레이어 한도

1) 목표와 원칙

플레이어 보호: 과잉 지출/오버 플레이, 조건의 투명성 및 자체 제어 도구.
라이센스 준수: 제한, 냉각, 자체 배제, 현실 점검에 대한 관할 요건.
재무 안정성: 청구서/부채/운영 위험 감소, 경제성에 대한 올바른 평가.
마찰없는 UX: 양심을 방해하지 않고 쉬운 설정/변경 한계, 이해할 수있는 결과 및시기.

2) 한계 및 보호의 분류

2. 1. 플레이어 제한

예금 한도 (매일/매주/매월).
손실 한도.
베팅/스테이크 제한.
시간/세션 제한.
속도 제한.
마찰 내: 반복 된 결론 전의 냉각, 적용 빈도 제한.
현실 점검: 주기적 시간/결과/균형 알림.

2. 2. 행정 조치

냉각.
자기 배제 (지역/국가 등록 소).
경제성 점검: 재무 포함 평가 (소득/부채/SoF).
임계 값 및 행동 신호에 대한 KYC/SoF/SoW 스텝 업.

2. 3. 결제 및 규정 준수 프레임 워크

동일한 방법/소스로 돌아 가기: 과잉 지출/" 현금 인출 "에 대한 보호

순 예금 (ND): 예금/인출 섹션, 판촉 게이트/인출 부분.
지불금은 위험에 처해 있지만 (RG/AML) 투명한 SLA 및 항소가 있습니다.

3) 방아쇠 및 에스컬레이션 (위험 기반)

임계 값 (일일/30 일 매출, 큰 예금).
행동 신호: 야간 활동, 빠른 예금 반복, 일련의 소프트 감소.
지리/장치: 여러 계정의 국가 변경/ASN/VPN, "가구".
지불 특성: BIN-geo 단 KYC, 고위험 발행자 연속으로 새로운 토큰.
RG 도구의 결과: 빈번한 현실 점검 기각, 자체 제한 위반.

에스컬레이션: 경고 → 하드 한계 → 냉각 → 자체 배제 → 경제성에 대한 수동 평가 (SoF/SoW).

4) 마찰없는 UX 패턴

모든 화면 외에도 RG 도구에 빠르게 액세스합니다.
제한 마법사-기간 → 제한 유형 → 금액 → 유효.
제한 변경: 강화-즉시; 감쇠-진입 지연 (24-168 시간).

현실 점검 모달: 이해할 수있는 KPI (시간/총, 예금/출력/결과), 버튼 "계속 "/" 일시 정지"

평가 된 언어: 비 판단; 짧은 블록 이유 ("일일 예금 제한에 도달").
현지화 및 가용성: ICU 형식, a11y, RTL, 큰 글꼴.

5) 제한 정책: Pseudo-DSL

yaml policy: "rg_limits_v3"
limits:
deposit:
periods: [DAILY, WEEKLY, MONTHLY]
weaken_delay_hours: 72 loss:
periods: [DAILY, WEEKLY, MONTHLY]
weaken_delay_hours: 72 wager:
periods: [DAILY, WEEKLY]
stake_max:
amount: {EUR: 100}
reality_check:
interval_minutes_default: 60 show_metrics: [time_played, net_result, deposits, withdrawals]
cooling_off:
options: ["24h", "7d", "30d"]
immediate_effect: true self_exclusion:
registry: ["local", "national"]
triggers:
- if: net_deposits_30d > 2000 then: "affordability_check"
- if: deposit_velocity_24h >= 3 then: "hard_daily_deposit_cap"
- if: vpn_detected == true then: "deny_until_verified_geo"
payments:
same_method: true allow_nd_withdrawal: true

6) 엔지니어링 및 데이터 모델 (최소)


rg. profiles (
user_id PK, kyc_level, risk_score, country, self_excluded BOOL, cooling_off_until TIMESTAMP
)

rg. limits (
user_id, type -- DEPOSIT    LOSS    WAGER    STAKE    TIME,
period -- DAILY    WEEKLY    MONTHLY    SESSION,
amount NUMERIC, currency TEXT, set_at TIMESTAMP,
weaken_effective_at TIMESTAMP, active BOOL,
PRIMARY KEY (user_id, type, period)
)

rg. events (
id PK, user_id, kind -- LIMIT_HIT    RC_SHOW    COOLING_ON    SEFLEX_ON    UNLOCK_REQ,
payload JSONB, created_at TIMESTAMP
)

rg. affordability (
user_id PK, status -- NOT_REQUIRED    REQUESTED    PASSED    FAILED    EXPIRED,
sof_required BOOL, sow_required BOOL, requested_at TIMESTAMP, decided_at TIMESTAMP
)

finance. net_deposits (
user_id, currency, nd_total NUMERIC, nd_30d NUMERIC, updated_at TIMESTAMP,
PRIMARY KEY(user_id, currency)
)

payments. activity_rollup (
user_id, day DATE, deposits NUMERIC, withdrawals NUMERIC,
wagers NUMERIC, losses NUMERIC, sessions_minutes INT
)

7) 후속 (온라인 수표)

예금: 기간별로 DEPOSIT/Loss/Wager 한도 확인; 속도 캡.
게임에서: 타이머에 의한 시간/세션 및 현실 점검; 스테이크 _ max.
출력: ND 섹션, 동일한 방법, 냉각/자체 제외.
한계를 완화 할 때: '약한 _ 효과적인 _ at' 를 존중하십시오.
경제성 트리거를 사용하면 "확인하기 전에" 블록 또는 제한 한계가 있습니다.

8) SQL 템플릿

8. 1. 일일 예금 한도에 도달했습니까?

sql
WITH d AS (
SELECT COALESCE(SUM(amount),0) AS dep_day
FROM payments. activity_rollup
WHERE user_id=:uid AND day=CURRENT_DATE
)
SELECT (d. dep_day +:incoming_amt) <= l. amount AS allowed
FROM d, rg. limits l
WHERE l. user_id=:uid AND l. type='DEPOSIT' AND l. period='DAILY' AND l. active=true;

8. 2. 출력에서 ND 및 RG 상태 확인

sql
SELECT
(nd. nd_total >= 0) AS nd_ok,
(p. same_method_ok) AS same_method_ok,
(NOT pr. self_excluded) AS not_excluded,
(COALESCE(pr. cooling_off_until, now()) <= now()) AS not_in_cooling
FROM finance. net_deposits nd
JOIN payments. payout_context p ON p. user_id=nd. user_id AND p. currency=nd. currency
JOIN rg. profiles pr ON pr. user_id=nd. user_id
WHERE nd. user_id=:uid AND nd. currency=:ccy;

8. 3. 현실 점검 슬라이스

sql
SELECT user_id,
SUM(sessions_minutes) AS mins,
SUM(deposits) AS dep,
SUM(withdrawals) AS wd,
SUM(wagers - withdrawals + deposits) AS net_result
FROM payments. activity_rollup
WHERE user_id=:uid AND day BETWEEN CURRENT_DATE - INTERVAL '1 day' AND CURRENT_DATE;

8. 4. 구호 요청 및 연기 된 출입 제한

sql
UPDATE rg. limits
SET amount=:new_amount,
weaken_effective_at = now() + INTERVAL '72 hours'
WHERE user_id=:uid AND type='DEPOSIT' AND period='DAILY';

8. 5. 저렴한 트리거

sql
WITH m AS (
SELECT SUM(deposits - withdrawals) AS nd_30d
FROM payments. activity_rollup
WHERE user_id=:uid AND day >= CURRENT_DATE - INTERVAL '30 days'
)
INSERT INTO rg. affordability(user_id, status, sof_required, sow_required, requested_at)
SELECT:uid, 'REQUESTED', true, false, now()
FROM m WHERE m. nd_30d > 2000
ON CONFLICT (user_id) DO NOTHING;

9) KPI 및 대시 보드

보호 된 플레이의 공유: 1 이상의 한계를 가진 활성 플레이어의 공유.
적중률 제한: 유형 별 작동 빈도 (예금/손실/시간).
냉각/자체 배제 속도 및 일시 정지 후 반환.

저렴한 TAT (p50/p95),

ND <0 공유 및이 지표에 대한 한계의 영향.
한도를 구현하기 전후에 Chargeback bps/Refund 요율.
RG 잠금 장치 (가드 레일 메트릭) 로 인한 지불 중단.
현실 점검 참여: 요율, RC 이후 행동 인정.

10) 경고

제한 적중 스파이크: 국가/채널별로 트리거> X% d/d 상승.
경제성 백 로그: TAT> SLA, 큐> 임계 값.
냉각 누출: 일시 정지 기간 동안의 지불 시도 (P1).
자체 배제 불일치: 외부 레지스트리와의 불일치.
정책 드리프트: 한도를 확인하지 않고 지불/요금.
제한이없는 플레이어의 ND 네거티브 서지 → 자동 제한을 제공합니다.

11) 법률 및 준수 (요약)

투명한 텍스트: 한계의 영향, 진입 조건, 약화 취소에 대한 간단한 설명.
지역 규범: 기간/유형의 한계 및 현실 점검 형식에 따른 차이; 국가 자체 배제 레지스터와의 동기화.
개인 정보 보호: 데이터 경제성 최소화, 결정의 증거 저장 (감사 추적).
보고: 라이센스/시장별 제한/예외 별 집계.

12) 경제와 영향

결제 사고 (CB/환불) 및 적색 항공권 감소.
LTV 안정화: 더 적은 "불태운" 지갑, 더 건강한 코호트 지표.
운영 비용: 경제성/수동 케이스를위한 용량 계획, 스텝 업 자동화.

13) A/B 및 단계별 구현

테스트 복사 및 UX 제한, 실제 확인 간격, 약한 _ 지연, 스테이크 _ max.
Guardrails: AR/Abandonment, CB bps, ND <0 Share, 불만 제기 지원.
납 지연/TT에 의한 데이터 동결; GEO/채널에 의한 층화.

14) 모범 사례 (짧은)

1. 기본 RG 도구, 지갑 및 체크 아웃에서 빠른 액세스.
2. 한계의 이완 - 지연으로 만; 증폭-즉시.
3. 이해할 수있는 메트릭 "순수한 결과" 로 기본적으로 현실 점검 (60 분).
4. 임계 값 및 신호에 의한 위험 기반 스텝 업 (경제성/SoF) 은 모두 연속적인 것은 아닙니다.
5. 지불 정책과의 통합: ND, 동일한 방법, 출력시 냉각.
6. 전체 원격 측정-각 솔루션을 정책 버전 및 증거와 함께 저장하십시오.
7. 현지화 및 a11u, 투명한 텍스트 및 공정한 마감일.
8. 라이센스 및 외부 레지스터 준수에 대한 정기적 인 감사.

15) 구현 점검표

  • 쿼터 및 기간 맵; 약화 지연; 기본적으로 현실 점검.
  • 의사 -DSL 정책, 버전, 감사.
  • 온라인 예금/놀이/인출 게이트; ND는 같은 방법입니다.
  • 저렴한 트리거 및 프로세스 (SoF/SoW), SLA 및 경고.
  • UX: 제한 마법사, 현지화, a11y; 의미있는 사본.
  • KPI 대시 보드 및 가드 레일; 경고 및 사건 플레이 북.
  • 자기 배제 기록과의 조정; 로케일 별 법적 텍스트.
  • AR/CB/LTV 및 지원로드에 미치는 영향에 대한 정기적 인 감사 후.

요약

"책임있는 지불 및 한도" 는 시스템 스택: 정책 및 UX, 지불/게임/출력의 온라인 제어, 위험 기반 에스컬레이션 (경제성/KYC/SoF), ND/동일한 방법에 대한 구속력 및 전체 원격 측정입니다. 이 방법은 동시에 플레이어의 피해를 줄이고 P & L을 안정화 시키며 라이센스 요구 사항을 준수합니다.

Contact

문의하기

질문이나 지원이 필요하시면 언제든지 연락하십시오.우리는 항상 도울 준비가 되어 있습니다!

통합 시작

Email — 필수. Telegram 또는 WhatsApp — 선택 사항.

이름 선택 사항
Email 선택 사항
제목 선택 사항
메시지 선택 사항
Telegram 선택 사항
@
Telegram을 입력하시면 Email과 함께 Telegram에서도 답변드립니다.
WhatsApp 선택 사항
형식: +국가 코드 + 번호 (예: +82XXXXXXXXX).

버튼을 클릭하면 데이터 처리에 동의하는 것으로 간주됩니다.