결론 정책: 타이밍 및 KYC

1) 결론 정책을 공식화하는 이유

• 티켓 및 에스컬레이션 수준을 줄입니다 ("돈은 언제 올까요? »);
• AML/KYC 준수 (연령, 제재, SoF/SoW) 를 보장합니다.
• 사기/청구 및 중재 분쟁을 줄입니다.
• 재무/지원/마케팅을위한 예측 가능한 SLA 제공.

2) 철도 분류 및 예상 속도

3) KYC 수준 및 결론에 미치는 영향

원리: KYC가 높을수록 사용 가능한 레일이 넓어지고 제한/속도가 높아집니다.

기본: 작은 한계; "느린" 또는 내부 핀 만 허용됩니다 (지갑/제한된 A2A 당).
전체 KYC (ID + 주소 + 활력): 표준 한계; 은행 레일, 푸시 투 카드, 지역 고속 계획에 대한 액세스.
EDD (확장): 대량/빈번한 지불; SoF/SoW (자금/상태 소스), 수령인 화이트리스트, 신속한 처리가 필요합니다.

스텝 업 트리거: 대량, 새로운 수령인, 비정형 장치/지오, 초과 속도, 고위험 MCC (iGaming, 준 캐시), 누적 상금.

4) 리드에 대한 제한 및 사기 방지

• 거래 당/일일/주간/월간 한도.
• 속도: N 결제/시간, 슬라이딩 창 금액, 세부 사항 변경 빈도.
• 새로운 수신자: 캡/필수 냉각 오프 감소 (예: 12-24 시간) 및 스텝 업.
• 지리/제재: 목록 거부/허용, 특정 국가/은행 금지.
• 위험 프로필: 클라이언트/세션 점수 제한의 승수.
• 지불 잠금: 검증이 완료 될 때까지 이상/차지 백/ODR 후 임시 차단.

5) 지불 상태 및 운영 모델

• '요청' -사용자 요청
• '대기' -대기 지불
• '처리' -공급자/은행에서 처리
• '전송 된' -철도로 전송 (UTR/ARN/추적이 있음)
• '정착 된' -수령인 클리어/아니오 Finisks
• '실패' -철도/은행 고장
• '반전/반환' -환불 (ACH R 코드, SEPA 반환, FPS 거부)
• 'on _ hold' -규정 준수/EDD/SoF 확인
• '취소' -사용자/연산자에 의해 취소 됨

아티팩트: 'payoutID', 'requestID' (idempotency), 'beneficialID', 'rail', 'm액/화폐', 'UTR/ARN/Trace', 실패 코드.

6) 지불 대기열 및 커널 아키텍처

• 오케스트레이터 (상태 머신): 레일/한계/에서 라우팅.
• 스케줄러: 컷오프/홀리데이 (레일 당/국가 당) 회계.
• 이념성: '요청' + 이벤트 중복의 핵심.
• Webhooks 제공 업체: 서명 된/NMAS, 백오프 된 트레이, DLQ.
• 조정: 레지스터 별 자동 정찰 (일일) + 주기적 정찰; UTR/ARN 스토리지.
• 정책 엔진: CCR/제한/채점 규칙 및 실패 원인 (설명 불가).
• 재무부/유동성: PSP/은행 잔고 모니터링, 고속 레일 프리 팬딩, 재조정.

7) 유동성과 현관

패스트 레일 (RTP/FPS/PIX/Push-to-Card/e-wallet) 은 종종 프리 팬딩이 필요합니다.
공급자에 대한 제한과 계정 간 자동 재조정 (스위프) 을 유지하십시오.
현금 격차: 실제 직불 결제에서 "약속 된" 지불 계정을 분리하십시오.
유동성이 떨어지면 (일시적으로 느린 레일로 전환) 자동 변경 방법을 입력하십시오.

8) 커뮤니케이션 및 UX

레일, 컷오프 및 사용자 TZ를 포함하여 예상 도착 날짜/시간을 보여줍니다.
설명 된 상태: "KYC/SoF 수표", "은행 창을 기다리는 중", "전송: UTR/ARN 번호".
제품 FAQ: 한계, 타이밍, 레일 지원, SoF/SoW, 요청 거부 이유.
새로운 수령인: 홀드/스텝 업 경고, 세부 정보 확인 (마이크로 예금/1 센트 점검, 테스트 지불).
오류 방지 UX: IBAN/BIC 마스크, 형식 검증, BSB/정렬 코드 힌트, 수신자 "템플릿" 저장.
쿨 다운: 투명한 원인이있는 고위험 프로파일을위한 소프트 대기 시간.

9) 준수: KYC/AML/EDD/SoF/SoW

KYC: ID, 주소, 활력; 나이와 지오 블록.
제재/PEP: 온 보딩 및 주기적 심사; 큰 지불 전에-두 번째 수표.
SoF/SoW: 자금/조건의 출처 확인 (은행 명세서, 손익 계산서, 계약).
사례 관리: 의사 결정 로그, SLA 처리, 감사 추적.
책임있는 게임 (iGaming 용): 보너스 인출 보유, 자체 제외 점검, 주간/주 "책임" 제한.

10) 레일에서 오류 및 반환 (고려해야 할 사항)

ACH: 반품 (R01... R10), NACHA 창, 블록 목록.
SEPA: 거부/반환/리콜; IBAN 검증, 코드 이유 (AC04, AG01 등).
FPS/RTP/PIX: 일반적으로 최종; 반환-별도의 카운터 작업.
푸시 투 카드: 발행자는 지연/제한 편차가있을 수 있습니다.
SWIFT: 특파원 수수료, "리프팅 수수료", 수령 은행 준수 지연.

11) 경제 및위원회

요금 모델: 수정/백분율, 금액에 대한 임계 값, FX 마진, 고속 레일에 대한 별도의 관세.
KYC- 레벨 요율: VIP/EDD-커미션/우선 순위 미만; 기본-더 높은 유지 보수 비용.
사기 방지 비용: 검사/투자 비용, 수익/거부 비율.
최적화: 그룹화 지불 (배치), 피크가 아닌 "느린" 레일 일정, 금액/국가/시간별 레일 선택.

12) 관리를위한 KPI/메트릭

SLA 준수: 약속 된 날짜에 도착한 지불금의%.
현금화 시간: '정착 된' 중간/95 백분위 수 시간.
레일 및 이유 (코드) 에 대한 반환/거부 속도.
철도 별 공유: 방법 별 분포 및 승인/해결.
ODR/지연/실패 불만.
보류/EDD 요율: 수동 검증에 해당하는 지불 비율; 평균 결정 시간.
유동성 가동 시간: 빠른 레일을 사용할 수있는 시간.
지불금 당 비용은 FX 영향입니다.

13) 결론 정책 출시 점검표

1. 철도 매트릭스: 국가/통화/제한/마감일/컷오프/휴일-설정 서비스.
2. 정책 엔진: 설명 로그가있는 KYC/제한/속도/EDD 규칙.
3. 지불 오케 스트레이터: 대기열, retrai, demempotency, HMAC 웹 후크.
4. 재무부: 패스트 레일 프리 팬딩, 자동차 재조정, 공급자 제한.
5. KYC/AML/SoF/SoW: 공급자, 플레이 북, SLA, 에스컬레이션.
6. UX/통신: 철도, 상태 별 ETA, UTR/ARN, 보유/실패의 이해 가능한 이유.
7. 정찰: 매일 자동 정찰 + 정찰; "레지스트리없이 성공", "노화 지불" 에 대한 경고.
8. 모니터링: KPI 대시 보드, 유동성/고장/반환 성장 경보.
9. 테스트 패키지: 각 레일의 e2e (성공/실패/반환), 새로운 수신자, 대량, 공급자 타임 아웃.

14) 정책 섹션 템플릿 (ToS/wiki 용)

• SEPA: T + 1 BD (오후 3 시까 지 CET), SEPA 인스턴트-보통 30 분 이내에.
• FPS/PIX/RTP: 일반적으로 분 모드이지만 새 수신자는 최대 24 시간 검사가 가능합니다.
• ACH: T + 1-T + 2 BD; 같은 날 ACH-컷오프 뱅크 전에 봉사 할 때.

• 최대 € X/day-기본, 이상-ID + 셀카 필요; € Y 이상-SoF/SoW.
• 새로운 수령인-최대 24 시간 안전 유지.

• Per-txn:..., Daily:..., Weekly:... (동적 수준/위험 별).

• SEPA/FPS-..., SWIFT-... (+ 특파원 수수료), 푸시 투 카드-....

• 거부/반환의 경우 자금은...; 알림 (코드/설명) 의 이유에 대해 알려드립니다.

15) 지원에 대한 빠른 답변

돈은 언제옵니까? -{ rail} 의 경우 {ETA} 까지 예상하십시오. UTR/ARN은 {코드} 입니다.
왜 붙잡아? -보안 규칙이 트리거되었습니다 (새 수신자/금액/지오). {SoF/ID} 문서를 다운로드하십시오.
더 빨리 가능합니까? -{ fast rail} 에서는 프리 팬딩/기타 제한이 필요합니다. 다른 방법을 제안합니다.

왜 거절? -수령인의 은행이 거부되었습니다 (코드 {X}). 세부 사항을 확인하거나 다른 레일을 선택하

요약

강력한 추론 정책 = 투명 타이밍 + 예측 가능한 KYC 제한 + 신뢰할 수있는 레일 오케스트레이션 설정에 규칙을 저장하고 설명 로그가있는 정책 엔진을 사용하고 demempotency/Recon/Webhooks를 보장하며 유동성 및 프리 팬딩을 관리하며 사용자와 정확한 ETA + UTR/ARN을 통신하십시오. 따라서 지불 속도를 희생하지 않으면 서 위험을 줄이고 준수를 유지하며 신뢰를 높입니다