순 예금: 계산 및 제어

1) 순 예금이란 무엇이며 왜 필요한가

순 예금 (ND) 은 모든 "역" 현금 흐름을 설명한 후 해당 기간 동안의 순 사용자 투자입니다. 메트릭은 다음에 중요합니다

단위 경제학 (ND와 LTV, ARPPU, NGR의 상관 관계),

책임있는 게임 (한계, 자제력, 자금 출처),

위험 및 준수 (AML/제재, 이상),

거래 (지불 우선 순위 및 남용 방지 보너스).

기본 아이디어

플레이어는 X (예금) 를 제공하고 Y (인출) 를 가져 왔습니다. 플레이어의 "실제로 입금 된 돈" 으로 생태계에 남아있는 모든 것은 순 예금이며, 반품, 청구서, 취소 및 기타 기술 운영에 맞게 조정되었습니다.

2) 공식 및 회계 경계

2. 1. 기본 공식 (제품 수준)

ND = Deposits
− Withdrawals − (successful, paid)
− Refunded Deposits
+ Chargeback Debits
− Chargeback Credits
± Reversal Adjustments

• 예금-캡처/정산 만 가능합니다. 후속 캡처없이 승인-계산하지 마십시오.
• 철수-우리는 유료 (유료/결제) 만 고려합니다. 거부/취소 된 ND 응용 프로그램은 감소하지 않습니다.
• 재정 지원 예금-예금은 동일한 소스 (동일한 방법) 로 반환됩니다.
• Chargeback Debits/Credits-분쟁의 순 효과 (상각/반품).
• 역 조정 - 기술 수정 (예: "잘못된" 지갑에서 반환, 역 복제).

2. 2. 회계 개선

보너스 및 자유 베팅: 예금에 포함되지 않음; 이들은 국내 대출입니다. 그러나 남용 시나리오 (보너스 → 즉시 현금 입금) 는 빠른 철회 및/또는 사기 방지 수정을 통해 ND를 줄여야합니다.
PSP 커미션: 기본적으로 ND (ND- "플레이어 중심" 메트릭) 에서 공제되지 않습니다. 커미션-P & L.
내부 전송/교차 지갑 (스포츠 → 카지노): ND는 변경되지 않습니다 (이것은 균형 내의 움직임입니다).
취소: 취소가 ND를 줄이지 않습니다 (결국 인출이 이루어지지 않음).
프로모션 현금 인출/수동 크레딧: 운영자의 현금 크레딧은 ND를 증가시키지 않습니다.
토큰/암호화: 결제 시점에 해당하는 피아트에 따라 읽으십시오 (다중 통화 참조).
부분/분할 지불: ND는 실제로 해결 된 금액만큼 증가하고 있습니다.

2. 3. 기간 경계

• 활동 기반 ('정산 _ at' 트랜잭션 별). 재무보고에 권장됩니다.
• 요청 기반 ('만든 _ at '/' 요청 된 _ at'): 빠른 제품 분석에는 적합하지만 조정에는 적합하지 않습니다.

3) 다중 통화 및 환율 평가

모든 운영은 결제 시점의 환율로보고 통화 (예: EUR) 에 매핑됩니다.

(PHP 3 = 3.0.6, PHP 4)

암호화의 경우 선택한 소스 'setted _ at' 에서 가중 평균 가격 (VWAP) 을 사용하십시오.
코스를 변경할 때 과거 ND를 과대 평가하지 마십시오. 이벤트 시점에 실제 FX를 유지하십시오.

4) ND 역할 수준

ND _ user는 특정 플레이어의 순 투자입니다.
ND _ 세그먼트-국가, 채널, 결제 제공 업체, 계열사 별.
ND _ cohort - 등록 날짜/첫 예금 날짜.
ND _ 플랫폼은 해당 기간 동안 플랫폼의 총 ND입니다.

5) 정책 및 제외

5. 1. 동일한 방법 규칙 (R)

예금 A가 방법 M을 통과 한 경우, 예금 자금의 반환은 M을 통해 순 예금 금액까지 이루어집니다. 이로 인해 AML 및 논란의 여지가있는 교차 지불의 위험이 줄어 듭

5. 2. 내부 조정

모든 수동 조정에는 이유 _ 코드, 감사 추적 및 기본 활동에 대한 참조가 있어야합니다.
조정이 손실 추적/남용을 가리지 않아야합니다.

5. 3. 보너스주기

플래그로 "보너스 중심 ND" (보너스를 활성화 한 예금) 를 표시하십시오. 보너스 관련 예금없이/없이 ND 보고서를 작성하십시오.

6) 이벤트 모델 및 데이터 체계

6. 1. 주요 이벤트

'DEPOSIT _ AUTHORIZED', 'DEPOSIT _ CAPTURED', 'DEPOSIT _ REFUNDED'

'WITHDRAWAL _ REQUESTED', 'WITHDRAWAL _ REJECTED', 'WITHD DRAWAL _ CANCELED'

'CHARGEBACK _ DEBITED', 'CHARGEBACK _ CREDITED'

'ADJUSTMENT _ APPLIED' (ти의 경우: REVERSAL, TECH _ FIX, FRAUD _ CORRECTION). п.)

모든 이벤트는 demempotent ('deidempotency _ key', 'event _ id') 입니다. '이벤트 _ id' 중복을 통해 정확히 한 번 DWH로 배송을 지원합니다.

6. 2. 미니 다이어그램 (단순화)

payments. transactions (
id, user_id, provider, method, type, status,
amount_original, currency_original,
amount_reporting, reporting_currency, fx_rate_at_settle,
requested_at, settled_at, related_tx_id, reason_code, meta
)

types: DEPOSIT    WITHDRAWAL    REFUND    CHARGEBACK_DEBIT    CHARGEBACK_CREDIT    ADJUSTMENT status: PENDING    AUTHORIZED    CAPTURED    PAID    REJECTED    CANCELED    REFUNDED    SETTLED

ND 총계는 필터가 "적용 가능한 경우에만 정산/유료/캡처 된" 필터와 함께 '유형' 및 '상태' 에 따라 집계로 간주됩니다.

7) 데이터 품질 관리 및 조정

7. 1. PSP/Acquirer와의 조정

PSP 보고서 (결제 파일) 를 '트랜잭션' 과 매일 조정합니다.
'provider _ ref', 금액, 결제 날짜, 통화 및 수수료 (P&L) 와 일치합니다.
Ops의 불일치 → 티켓: "누락 된 캡처", "이중 환불", "늦은 프레젠테이션".

7. 2. 안티 더블 및 demopotency

제어: '(공급자, 공급자 _ tx _ id, 유형, 정산 _ day)' 에 의한 고유성.
수동 작업에 대한 별도의 감사 로그 ('ADJUSTMENT _ APPLIED').

7. 3. 비즈니스 규칙 무결

선택한 방법으로 예금 기록이없는 'PAID' 를 표시하는 것은 적기입니다.
동일한 양의 회색 플래그 (보너스 남용) 에 대해 'DEPOSIT _ CAPTURED' → 'WITHD DRAWAL _ PAID' 를 닫습니다.

8) 보고 및 대시 보드

8. 1. 기본 KPI

'ND _ total' 기간 동안; ' ND _ per _ user ',' ND _ median ';

국가, 방법, PSP, 계열사별로 ND의 분해;

등록 코호트에 의한 'ND _ 7/30/90';

현금 변환 래그: 'DEPOSIT _ CAPTURED' 에서 'WITHD DRAWAL _ PAID' 까지의 중앙값.

8. 2. 위험 세그먼트

'ND λ0' 과 높은 이직률을 가진 플레이어는 자금 출처를 확인할 수 있습니다.
빠른 처리 (예금 → 인출) <N 시간-조사 트리거.

8. 3. 분석 비행기

제품 (스포츠/카지노/라이브): ND가 가장 "건강한" 위치.
지불 방법: 특정 방법의 사기 트래픽 중 ND 실패.
캠페인/보너스: ND 향상 및 효과 후 취소.

9) 사기 방지 및 책임있는 놀이 정책

예금 제한 (매일/매주/매월) -ND에서 별도의 준수 지표를보고합니다.
속도 규칙: n 분 단위의 X 예금 + 빠른 캐시 아웃 = 블록/수동 점검.
제재/PEP/SoF: 임계 값 이상의 ND 성장 → 필수 자금 출처.
다국적 화: 지리/방법/은행 국가를 KYC 국가와 비교하십시오.
자기 배제: 제외 후 ND는 엄격하게 0이어야합니다. 모든 시도-경고.

10) 프로세스 및 SLO

ND 대시 보드 계산의 SLO: T + 1, 보고 영역의 09:00 로컬 TZ까지 준비.

• PSP 결제 파일이 누락되었습니다
• 중복되면 세그먼트 ND가 잘못됩니다
• FX 질량 불일치.
• DRP: 결정적 순서로 기간 동안 이벤트를 다시 수정하여 ND를 다시 처리합니다.

11) SQL 예 (템플릿)

11. 1. 사용자와 일별 ND 계산

sql
WITH base AS (
SELECT user_id,
DATE(settled_at) AS d,
SUM(CASE WHEN type='DEPOSIT'     AND status IN ('CAPTURED','SETTLED') THEN amount_reporting ELSE 0 END) AS dep,
SUM(CASE WHEN type='WITHDRAWAL'   AND status='PAID'           THEN amount_reporting ELSE 0 END) AS wd,
SUM(CASE WHEN type='REFUND'     AND status='SETTLED'         THEN amount_reporting ELSE 0 END) AS ref_dep,
SUM(CASE WHEN type='CHARGEBACK_DEBIT'  AND status='SETTLED'        THEN amount_reporting ELSE 0 END) AS cb_deb,
SUM(CASE WHEN type='CHARGEBACK_CREDIT' AND status='SETTLED'        THEN amount_reporting ELSE 0 END) AS cb_cr
FROM dw. transactions_flat
WHERE settled_at >=:from AND settled_at <:to
GROUP BY 1,2
)
SELECT user_id, d,
dep - wd - ref_dep + cb_deb - cb_cr AS nd
FROM base;

11. 2. 빠른 회전의 깃발 (남용)

sql
SELECT t_dep. user_id, t_dep. id AS dep_id, t_wd. id AS wd_id,
EXTRACT(EPOCH FROM (t_wd. settled_at - t_dep. settled_at))/3600 AS hours_between,
t_dep. amount_reporting, t_wd. amount_reporting
FROM dw. transactions_flat t_dep
JOIN dw. transactions_flat t_wd
ON t_dep. user_id = t_wd. user_id
AND t_wd. type='WITHDRAWAL' AND t_wd. status='PAID'
AND t_wd. amount_reporting BETWEEN t_dep. amount_reporting0. 9 AND t_dep. amount_reporting1. 1
WHERE t_dep. type='DEPOSIT' AND t_dep. status IN ('CAPTURED','SETTLED')
AND t_wd. settled_at - t_dep. settled_at <= INTERVAL '24 hours';

11. 3. 방법/PSP에 의한 세분화

sql
SELECT method, provider,
SUM(CASE WHEN type='DEPOSIT'  AND status IN ('CAPTURED','SETTLED') THEN amount_reporting ELSE 0 END) AS dep,
SUM(CASE WHEN type='WITHDRAWAL' AND status='PAID'          THEN amount_reporting ELSE 0 END) AS wd,
SUM(CASE WHEN type='REFUND'   AND status='SETTLED'         THEN amount_reporting ELSE 0 END) AS ref_dep,
SUM(CASE WHEN type='CHARGEBACK_DEBIT' AND status='SETTLED'     THEN amount_reporting ELSE 0 END) AS cb_deb,
SUM(CASE WHEN type='CHARGEBACK_CREDIT' AND status='SETTLED'     THEN amount_reporting ELSE 0 END) AS cb_cr,
SUM(CASE WHEN type='DEPOSIT'  AND status IN ('CAPTURED','SETTLED') THEN amount_reporting ELSE 0 END)
- SUM(CASE WHEN type='WITHDRAWAL' AND status='PAID'          THEN amount_reporting ELSE 0 END)
- SUM(CASE WHEN type='REFUND'   AND status='SETTLED'         THEN amount_reporting ELSE 0 END)
+ SUM(CASE WHEN type='CHARGEBACK_DEBIT' AND status='SETTLED'     THEN amount_reporting ELSE 0 END)
- SUM(CASE WHEN type='CHARGEBACK_CREDIT' AND status='SETTLED'     THEN amount_reporting ELSE 0 END) AS nd
FROM dw. transactions_flat
WHERE settled_at BETWEEN:from AND:to
GROUP BY 1,2
ORDER BY nd DESC;

12) 경고 및 트리거 (운영 체제)

스파이크 ND 방법: ND 드롭> 30% d/d-PSP 사고 및 잠금 장치를 확인하십시오.
스파이크 ND 세그먼트 별: ND 성장> 50% w/w-새로운 aff가있을 수 있습니다. 소스 또는 재설정 체계.
높은 회전율 ND λ0-강제 KYC/SoF 확인.
ND에서 환불/Chargeback의 비정상적인 점유율-" depozit → igra → vyvod "체인의 감사.

13) 모범 사례 (짧은)

1. 정산 날짜별로 ND를 읽고 정착 시점에 FX를 수정하십시오.
2. 플레이어 돈에서 내부 이체를 엄격하게 분리하십시오.
3. 이유 _ 코드 및 감사와 함께 모든 수동 편집.
4. 빠른 U 턴 및 교차 방법에 대한 사기 방지 규칙.
5. 두 가지 보고서: T + 1 운영 및 재무 마감 (월/분기).
6. 논리적 버전 지정: 역사적 상점의 마이그레이션이있는 ND v1/v2.

14) 빈번한 질문

Q: 전복 된 결과가 계산됩니까?
A: 아니요. 'WITHDRAWAL _ PAID 만 ND를 줄입니다.

Q: 승인되었지만 캡처되지 않은 보증금으로 어떻게해야합니까?
A: ND에 포함되지 마십시오. 이들은 실제 영수증이 아닙니다.

Q: 결론이 이미 내려진 후에 청구서를 반영하는 방법은 무엇입니까?
A: 'CHARGEBACK _ DEBIT' 는 부정적인 플레이어 기여 (본질적으로 플랫폼이 손실 됨) 를 추가하고 ND는 직불 결제 증가하지만 최종 재무 보고서에는 청구서에 손실/비용이 표시됩니다.

Q: PSP 커미션을 ND에서 공제해야합니까?
A: 아니요, ND는 플레이어 중심 메트릭입니다. 커미션-P & L.

15) 구현 점검표

• demotency 및 배송 보증이있는 이벤트 버스
• 통합 유형/상태의 'traveles _ flat' 쇼케이스
• 정착 된 원본 스토리지에 대한 FX 정규화
• PSP 상태 매핑 규칙 → 상태
• PSP 및 델타 경고와의 일일 조정
• ND 대시 보드 (전체, 방법 별, 세그먼트 별, 코호트 별)
• 책임있는 플레이 정책 및 ND 기반 SoF 트리거
• ND v1 공식 문서 및 진화 계획 v2

요약

Net Deposits는 시스템에서 플레이어의 "실제" 돈의 중심 지표입니다. 올바른 ND에는 엄격한 인식 규칙 (정산 날짜), 정확한 다중 통화, 이벤트 demempotence, PSP와의 정기적 인 조정 및 내장 사기 방지 트리거가 필요합니다. 단일 상태 가이드 및 운영 유형을 구성하면 ND는 재무 및 책임있는 수익 창출에 대한 신뢰할 수있는 지원이 될 것입니다.