클로드와 암호화폐 거래소 온보딩 의사결정 순서

주요 내용

• Claude는 암호화폐 거래소의 온보딩 결정을 조정할 수 있지만, 고객은 채팅 내부가 아닌 Didit이 호스팅하는 검증 UI에서 KYC 캡처를 완료합니다.
• didit_session_create는 기존 workflow_id를 필요로 합니다. 이 함수는 거래소가 고객에게 제공할 URL을 반환합니다.
• didit_transaction_screen_wallet은 심사 결과만 반환합니다. 자금을 보류하거나, 케이스를 생성하거나, 규정 준수 팀에 알리지 않습니다.
• didit_transaction_create는 최상위 수준에서 transaction_id, transaction_category, transaction_details, subject를 필요로 합니다. 거래 필드는 카테고리별로 다릅니다.
• 운영자의 가치는 의사결정 순서에 있습니다: 올바른 증거를 수집하고, 거래소 정책에 따라 해석하고, 각 결정을 기록하고, 모든 후속 조치를 명시적으로 트리거합니다.

암호화폐 거래소는 하나의 온보딩 결정을 내리지 않습니다. 일련의 결정을 내립니다: 이 사람이 신원 확인을 시작할 수 있는가, 호스팅된 확인이 완료되었는가, 이름 심사 결과가 검토를 필요로 하는가, 정책상 지갑 결과가 무엇을 의미하는가, 제출된 거래를 모니터링을 위해 수락해야 하는가?

Didit 모델 컨텍스트 프로토콜(MCP) 서버는 Claude가 하나의 인증된 도구 표면을 통해 이러한 단계를 조정하도록 합니다. 고객 경험을 대화로 축소하지 않으며, 위험 대응을 자동 자금 제어 시스템으로 바꾸지 않습니다. 유용한 패턴은 명시적인 핸드오프와 명시적인 조치를 사용하는 운영자 코파일럿입니다.

이 기사는 이러한 운영 순서에 중점을 둡니다. 메커니즘은 이미 MCP를 통한 KYC, MCP를 통한 지갑 심사, MCP를 통한 거래 모니터링에 대한 전용 가이드를 가지고 있습니다.

결정 0: 고객을 접촉하기 전에 범위 설정

운영자는 didit_context_get으로 시작합니다. 이 도구는 인증된 사용자에게 사용 가능한 조직 및 애플리케이션을 나열하므로, Claude는 고객이나 환경을 혼합하지 않고 의도된 운영 컨텍스트를 확인할 수 있습니다.

거래소는 또한 기존 검증 워크플로우를 필요로 합니다. 워크플로우 설계는 고객 핸드오프 전에 이루어지며 어떤 검사를 실행할지 결정합니다. 일반적인 암호화폐 온보딩 흐름의 경우, 신원 확인, 수동 생체 인식, 얼굴 일치 및 IP 분석이 포함될 수 있습니다. 이러한 검사에 대한 공개된 전체 KYC 번들 가격은 $0.33입니다.

MCP 호출은 “워크플로우 구성”을 받지 않습니다. didit_session_create는 이미 존재하는 workflow_id를 받습니다. 이 구분은 운영자의 첫 번째 질문을 구체화합니다: 어떤 승인된 워크플로우가 이 고객 및 시장에 적용되는가?

결정 1: 고객을 호스팅된 KYC 흐름으로 보냅니다.

Claude는 선택된 워크플로우와 안정적인 고객 참조를 사용하여 세션을 생성합니다. 응답에는 session_id, url, session_token이 포함됩니다.

didit_session_create로 확인 세션 생성:
{
  "workflow_id": "<기존-암호화폐-온보딩-워크플로우-uuid>",
  "vendor_data": "customer_18427",
  "callback": "https://exchange.example/onboarding/complete",
  "language": "en"
}

URL을 고객에게 반환하고 의사결정 조회를 위해 session_id를 유지합니다.

고객은 해당 URL을 열고 Didit이 호스팅하는 UI에서 필요한 캡처를 완료합니다. 신분증 이미지와 셀카는 그곳에 제출됩니다. Claude 채팅 내부에 남아있지 않습니다.

고객이 완료한 후, Claude는 session_id를 사용하여 didit_session_get_decision을 호출합니다. 이 도구는 구성된 워크플로우에 대한 전체 검증 결정 및 추출된 데이터를 반환합니다. 그러면 운영자는 실제 응답에 거래소의 검토 정책을 적용할 수 있습니다. 이것은 핸드오프 및 검색 루프이며, Approved가 모든 다운스트림 규정 준수 문제를 해결한다는 주장이 아닙니다.

결정 2: 신원 증거와 이름 위험 분리

신원 확인과 자금세탁방지(AML) 심사는 다른 질문에 답합니다. 확인된 신원 데이터를 읽은 후, Claude는 해당 개인의 전체 이름을 사용하여 didit_verify_aml을 호출할 수 있습니다. 생년월일 및 국적과 같은 선택적 입력은 일치 정확도를 향상시킬 수 있습니다. AML 심사는 1,300개 이상의 목록에 대해 검사당 $0.20입니다.

운영자의 결정은 단순히 “일치 또는 불일치”가 아닙니다. 결과는 확인된 고객 데이터와의 비교, 추론 문서화 또는 거래소 정책에 따른 수동 검토를 필요로 할 수 있습니다. 운영자가 케이스가 필요하다고 결정하면 didit_case_create는 별도의 명시적 도구 호출입니다. KYC 세션의 어떤 것도 자동으로 해당 케이스를 생성하지 않습니다.

이러한 분리는 감사 추적을 읽기 쉽게 유지합니다:

• KYC 증거: 호스팅된 확인 워크플로우가 반환한 내용.
• AML 증거: 이름 심사 응답이 반환한 내용.
• 운영자 결정: 거래소 정책이 이러한 응답을 승인, 검토 또는 거부로 매핑한 방법.

결정 3: 지갑 심사 후 조치 결정

didit_transaction_screen_wallet은 wallet_address, blockchain, 그리고 선택적 direction을 허용합니다. blockchain 열거형은 혼합된 자산 또는 체인 식별자입니다: BTC, ETH, SOL, TRX와 같은 체인 식별자와 USDT, USDC와 같은 자산 식별자를 포함합니다. USDT와 USDC는 자산이지 블록체인이 아닙니다.

다음은 정확한 MCP 페이로드 형태를 가진 실행 가능한 Claude 프롬프트입니다. 예시 주소를 고객의 지갑으로 교체하십시오:

didit_transaction_screen_wallet을 정확히 이 페이로드로 호출:
{
  "wallet_address": "0x0000000000000000000000000000000000000000",
  "blockchain": "ETH",
  "direction": "deposit"
}

응답 필드 risk_score, severity, sanctions_hit, 그리고 보고된 자금의 출처와 목적지를 반환합니다. 자금을 보류하거나, 케이스를 생성하거나, 누구에게도 알리지 마십시오.
심사 결과를 요약한 후 명시적인 후속 지침을 요청하십시오.

응답 형태는 심사 결과입니다: risk_score, severity, sanctions_hit, 그리고 자금의 출처/목적지 정보. 거래 모니터링의 심사 구성이 사용할 수 없을 때 이 도구는 409 응답을 반환할 수 있습니다.

제품 카탈로그에서 KYT(Know Your Transaction)라고도 불리는 지갑 심사는 검사당 $0.15입니다. 결과 자체는 돈을 움직이지 않습니다. 보류, 해제, 케이스, 에스컬레이션 또는 알림은 거래소 자체 정책에 속하며 별도의 시스템 또는 도구 조치를 필요로 합니다. 예를 들어, Claude는 운영자 또는 승인된 정책 계층이 해당 조치를 명시적으로 선택한 후에만 didit_case_create를 호출할 수 있습니다.

결정 4: 실제 스키마로 거래 제출

didit_transaction_create는 모니터링 및 규칙 평가를 위해 거래를 제출합니다. 필요한 최상위 필드는 다음과 같습니다:

• transaction_id: 거래소의 고유 거래 식별자.
• transaction_category: finance, kyc, travel_rule, user_event를 포함한 문서화된 카테고리 값 중 하나.
• transaction_details: 카테고리별 거래 페이로드.
• subject: 거래를 시작하는 당사자.

선택적 최상위 객체에는 counterparty, travel_rule_details, network_snapshot, custom_properties가 포함됩니다. 이 도구는 거래 해시, 출발지 주소, 목적지 주소, 자산 또는 금액을 보편적인 최상위 필드로 정의하지 않습니다. 이러한 값이 카테고리 데이터의 일부인 경우, 관련 카테고리별 객체 내에 속합니다.

didit_transaction_create의 최상위 계약은 다음과 같습니다:
{
  "transaction_id": "<거래소-고유-거래-ID>",
  "transaction_category": "finance",
  "transaction_details": { "<finance-category fields>": "<values>" },
  "subject": { "<initiating-party fields>": "<values>" },
  "counterparty": { "<other-party fields>": "<values>" },
  "transaction_at": "<ISO 타임스탬프>"
}

플레이스홀더는 의도적입니다. MCP 스키마는 transaction_details와 subject가 transaction_category에 의존한다고 명시합니다. 하나의 보편적인 중첩 페이로드를 게시하지 않습니다. 운영자는 발명된 암호화폐 스키마를 복사하는 대신 구성된 카테고리에 대해 정의된 필드를 사용해야 합니다.

travel_rule의 경우, 동일한 최상위 계약이 적용되며, transaction_details에는 카테고리별 전송 데이터가, subject에는 시작 당사자가, counterparty에는 다른 당사자가, travel_rule_details에는 Travel Rule 데이터가 포함됩니다. 이 도구에는 metadata 필드가 없습니다. travel_rule을 선택하는 것은 카테고리별 페이로드를 식별하지만, 자동으로 수혜자 심사를 수행하거나 전송을 승인하지 않습니다.

거래는 제출될 때 평가됩니다. 단일 제출 기록이 영원히 지속적으로 재평가된다고 설명하는 것은 정확하지 않습니다. Claude는 didit_transaction_get을 사용하여 모니터링된 거래와 해당 규칙 평가 결과를 검색할 수 있습니다.

결정 5: 비즈니스 콘솔에서 정책 작성 유지

비즈니스 콘솔의 거래 모니터링 규칙 빌더는 팀이 모니터링 규칙 및 정책 논리를 구성하는 곳입니다. 이것은 검증 워크플로우 편집기가 아닙니다. MCP 표면은 거래를 제출하고, 결과를 검색하고, 기록을 검색하며, 명시적인 케이스 작업을 지원합니다. 규칙 작성을 대체하지 않습니다.

케이스 작업 또한 제한적입니다. didit_case_manage는 assign, comment, escalate, reopen, resolve, update를 지원합니다. 의심스러운 활동 보고서(SAR) 워크플로우는 비즈니스 콘솔 작업으로 남아 있습니다. 이 경계는 거래소가 Claude를 증거 수집 및 운영자 지원에 사용할 수 있도록 하며, 에이전트를 자율적인 규정 준수 기관으로 묘사하지 않습니다.

운영자 코파일럿 연결

Didit의 호스팅된 MCP 엔드포인트는 Streamable HTTP를 통해 115개의 도구를 노출하며, PKCE(Proof Key for Code Exchange)와 함께 OAuth 2.1을 사용합니다. MCP 서버는 무료이며, 기본 검사는 공개된 가격을 따릅니다. 무료 티어는 월 500회의 무료 검증을 제공합니다.

호스팅된 Claude를 Didit 커넥터 딥 링크와 연결하십시오. MCP 개요, 인증 가이드, 도구 참조를 검토하십시오. 구현은 MIT 라이선스 GitHub 저장소에서 사용할 수 있으며, 제품 개요는 didit.me/developers/mcp에 있습니다.

지속 가능한 운영 패턴은 증거 우선, 정책 다음, 조치 마지막입니다. Claude는 KYC 결정, AML 결과, 지갑 결과 및 거래 평가를 수집합니다. 거래소는 어떤 응답이 어떤 결정을 유발했으며 어떤 별도의 조치가 뒤따랐는지에 대해 명확하게 유지합니다.