사용자 대기: 플래그 지정된 거래 자동 해결 (KO)

거래 모니터링에서 가장 어려운 부분은 의심스러운 결제를 잡아내는 것이 아니라 그 다음에 무엇을 하느냐입니다. 완전히 합법적인 유료 고객을 차단하면 즉시 거부됩니다. 그냥 통과시키면 방금 플래그를 지정한 위험을 수락한 것입니다. 대부분의 팀은 수동 대기열로 이를 해결합니다. 분석가가 사용자에게 이메일을 보내고, 문서를 기다리는 데 며칠이 걸리며, 그 동안 거래는 계속 보류됩니다.

Didit의 거래 모니터링 API에는 이러한 공백을 위해 구축된 네 번째 상태인 AWAITING_USER가 있습니다. 이진 승인 또는 거부 대신, 플래그 지정된 거래는 일시 중지되고, 사용자에게 특정 조치(신원 재확인, 자금 증명 제출)를 요청하며, 사용자가 이를 완료하는 즉시 자동으로 재개됩니다. 마찰은 위험이 있는 곳에만 발생하며, 다른 모든 것과 마찬가지로 거래당 $0.02의 비용이 듭니다.

이 가이드에서는 AWAITING_USER 경로가 작동하는 방식과 이를 흐름에 연결하는 방법을 설명합니다.

주요 내용

• AWAITING_USER는 APPROVED, IN_REVIEW, DECLINED와 함께 네 가지 거래 상태 중 하나입니다. 따라서 해결은 우회책이 아닌 최고 수준의 결과입니다.
• 플래그 지정된 거래는 실패하는 대신 일시 중지되고, 사용자에게 단계별 조치를 요청하며, 조치가 완료되면 자동으로 재개됩니다.
• 단계별 조치는 재KYC, 자금 증명 업로드 또는 통합 /v3/ API에서 생성되는 모든 확인 단계일 수 있습니다.
• 웹훅이 루프를 구동합니다. transaction.status.updated는 거래가 AWAITING_USER에 진입하고 나갈 때 발생합니다.
• 동일한 상태가 사례 관리에도 존재하므로, 분석가는 알림을 AWAITING_USER로 이동하고 사용자가 이를 해결하도록 할 수 있습니다.
• 거래당 $0.02, 최소 금액 없음. 해결 중에 생성된 재KYC 또는 AML 확인은 자체 게시된 요금으로 청구됩니다.

AWAITING_USER의 기능

규칙이 실행되면 엔진은 상태를 할당합니다. 네 가지 중 세 가지는 익숙합니다. APPROVED는 거래를 통과시키고, IN_REVIEW는 분석가를 위한 알림을 열고, DECLINED는 거래를 차단합니다. 네 번째인 AWAITING_USER는 다른 작업을 수행합니다. 거래를 일시 중지하고 사용자가 해결하기 전에 무언가를 해야 함을 알립니다.

구체적으로: 송금이 고가 또는 고속 규칙을 위반하면 엔진은 AWAITING_USER를 반환하고, 애플리케이션은 사용자에게 요청된 단계(새로운 활성도 확인, 문서 업로드, 자금 출처 선언)를 완료하도록 프롬프트를 표시하며, 확인 세션은 플랫폼으로 다시 피드백됩니다. 단계가 완료되면 거래는 재평가되고 APPROVED로 이동합니다(또는 새로운 증거가 상황을 악화시키면 에스컬레이션됩니다). 어떤 분석가도 이를 관리할 필요가 없습니다.

중요성

강력한 거부는 비용이 많이 듭니다. 모든 오탐지 차단은 좌절한 합법적인 고객, 지원 티켓, 그리고 종종 이탈한 계정입니다. 그러나 플래그 지정된 결제를 통과시키는 것은 기업이 제재 조치를 받게 되는 방식입니다. 기존의 해결책인 수동 해결 대기열은 분석가 시간, 느린 처리 시간, 며칠 동안 보류되는 거래 등 한 가지 비용을 다른 비용으로 교환합니다.

AWAITING_USER는 이러한 상충 관계를 무너뜨립니다. 사용자는 자신의 거래가 기다리고 있기 때문에 이를 해결하려는 동기가 있는 정확한 시점에 마찰 지점에서 즉시 작업을 수행합니다. 위험을 포착하고, 고객을 유지하며, 문서를 추적하기 위해 분석가에게 비용을 지불하지 않습니다. 고객에게 비용을 발생시키는 규제 통제와 조용히 제 역할을 하는 규제 통제의 차이입니다.

기술 세부 정보

엔진이 해결로 라우팅하는 거래는 AWAITING_USER 상태와 이를 트리거한 규칙과 함께 반환됩니다.

{
  "transaction_id": "txn_77c9e2",
  "status": "AWAITING_USER",
  "risk_score": 71,
  "triggered_rules": [
    { "name": "High-value transfer — first 30 days", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "required_action": "PROOF_OF_FUNDS",
  "alert_id": "alrt_5e3f10"
}

사용자에게 프롬프트를 표시하고 통합 /v3/ API에서 확인 단계를 생성하여 응답합니다. 단계가 완료되면 웹훅이 거래가 진행되었음을 알려줍니다.

# webhook payload: transaction.status.updated
{
  "event": "transaction.status.updated",
  "transaction_id": "txn_77c9e2",
  "previous_status": "AWAITING_USER",
  "status": "APPROVED"
}

웹훅. transaction.created 및 transaction.status.updated를 구독합니다. 상태 업데이트 이벤트는 거래가 AWAITING_USER에 진입할 때와 나갈 때 모두 발생하므로, 폴링 없이 원장과 UI가 동기화됩니다.

가격. 거래당 $0.02. 해결 단계 자체는 자체 게시된 요금으로 청구됩니다. 사용자 확인 요금에 따른 재KYC, 플래그 지정된 당사자에 대한 AML 확인은 $0.20입니다.

해결 루프, 단계별

1. 규칙 트리거. 거래가 정책에서 거부 대신 해결되어야 한다고 명시한 임계값을 초과합니다. 예를 들어, 새 계정에서 첫 번째 고가 송금.
2. 실패 대신 일시 중지. 엔진은 DECLINED 대신 AWAITING_USER를 반환하며, 필요한 조치가 첨부됩니다.
3. 사용자에게 프롬프트. 애플리케이션은 단계별 조치(활성도 재확인, 문서 업로드, 자금 출처 선언)를 표시하고 확인 세션을 생성합니다.
4. 사용자 완료. 사용자는 이미 진행 중인 흐름 내에서 단계를 완료합니다.
5. 자동 재개. 거래는 새로운 증거로 재평가되고 APPROVED로 이동합니다(또는 증거가 위험을 증가시키면 IN_REVIEW/DECLINED로 에스컬레이션됩니다). transaction.status.updated 웹훅은 어떤 경우든 백엔드에 알립니다.

동일한 AWAITING_USER 상태가 사례 관리에도 존재하므로, IN_REVIEW 알림을 처리하는 분석가는 직접 해결하는 대신 사용자에게 다시 푸시할 수도 있습니다. 알림은 OPEN → INVESTIGATING → AWAITING_USER를 거쳐 사용자가 응답하면 해결됩니다.

사용 사례

• 핀테크 — 최근 온보딩된 계정에서 첫 번째 고가 송금이 고객을 차단하는 대신 자금 증명을 위해 일시 중지됩니다.
• 암호화폐 — 노출도가 높은 지갑으로의 외부 송금이 정산되기 전에 자금 출처 선언을 위해 일시 중지됩니다.
• 대출 — 합성 신원 신호를 트리거하는 지급액이 재KYC 활성도 확인을 위해 일시 중지됩니다.
• 마켓플레이스 — 속도 규칙을 트리거하는 판매자 지급액이 자금이 해제되기 전에 재확인을 위해 일시 중지됩니다.
• iGaming — 입금 속도 급증이 단계별 확인을 위해 일시 중지되며, 이는 책임감 있는 게임 접점으로도 사용됩니다.

Didit 통합 방법

1. 해결 정책 결정. 비즈니스 콘솔에서 어떤 규칙이 DECLINED 대신 AWAITING_USER로 라우팅되는지, 각 규칙이 어떤 단계별 조치를 요청하는지 설정합니다.
2. 거래 전송. 자금이 이동함에 따라 POST /v3/transactions/를 사용하여 안정적인 transaction_id와 각 사용자와 연결되는 vendor_data를 보냅니다.
3. 일시 중지 처리. 거래가 AWAITING_USER를 반환하면 사용자에게 프롬프트를 표시하고 /v3/ API에서 확인 단계를 생성합니다.
4. 재개 청취. 사용자가 단계를 완료하면 transaction.status.updated에 반응하여 거래를 해제하거나 보류합니다.

모든 것이 통합된 /v3/ API에 있으므로, 플래그 지정된 거래가 생성하는 해결 KYC는 사용자를 온보딩하는 데 사용하는 KYC와 동일합니다. 즉, 하나의 신원 및 사기 플랫폼이 처음부터 끝까지 사용됩니다.

자주 묻는 질문

AWAITING_USER는 무엇인가요?

네 가지 거래 상태 중 하나입니다. 강력한 거부 대신, 플래그 지정된 거래는 일시 중지되고 사용자 조치(재확인 또는 자금 증명)를 요청한 다음, 사용자가 이를 완료하면 자동으로 재개됩니다.

거래가 자동으로 재개되나요?

예. 요청된 단계가 완료되면 거래는 재평가되고 자동으로 APPROVED로 이동합니다(또는 새로운 증거가 위험을 증가시키면 에스컬레이션됩니다). 변경 시 transaction.status.updated 웹훅이 발생합니다.

단계별 조치는 무엇이 될 수 있나요?

통합 /v3/ API의 모든 확인 단계. 재KYC 활성도 확인, 문서 재확인, AML 확인 또는 자금 증명 업로드.

분석가가 개입해야 하나요?

아니요. 자동 해결 루프는 분석가 없이 실행됩니다. 그러나 동일한 AWAITING_USER 상태가 사례 관리에도 존재하므로, 분석가가 원할 때 알림을 사용자에게 다시 푸시할 수도 있습니다.

비용은 얼마인가요?

거래당 $0.02. 해결 단계는 자체 요금으로 청구됩니다. 사용자 확인 요금에 따른 재KYC, AML 확인은 $0.20.

시작할 준비가 되셨나요?

문서에서 거래 모니터링 개요를 읽고, 거래 모니터링 제품 페이지에서 플랫폼의 나머지 부분과 어떻게 맞는지 확인하고, 가격 책정 페이지에서 투명한 통화당 가격을 확인하세요. 준비가 되면 무료로 시작하세요. 매월 500회의 무료 KYC 확인과 통화당 $0.02의 거래 모니터링이 제공됩니다.