Claudeと連携した暗号通貨取引所のオンボーディングにおけるオペレーターの意思決定フロー
自動化やペイロードフィールドを独自に作成することなく、ClaudeからKYC、AML、ウォレットスクリーニング、取引送信、明示的なケースアクションを調整します。.
主なポイント
- 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 Model Context Protocol (MCP) サーバーを使用すると、Claudeは認証された単一のツールインターフェースを通じてこれらのステップを調整できます。これは、顧客体験を会話に集約したり、リスク対応を自動的な資金管理システムに変えたりするものではありません。有用なパターンは、明示的なハンドオフと明示的なアクションを伴うオペレーターのコパイロットです。
この記事では、その運用シーケンスに焦点を当てます。メカニズムについては、MCPを介したKYC、MCPを介したウォレットスクリーニング、MCPを介したトランザクションモニタリングに関する専用ガイドがすでにあります。
決定0：顧客に触れる前に範囲を確立する
オペレーターはdidit_context_getから開始します。このツールは、認証されたユーザーが利用できる組織とアプリケーションを一覧表示するため、Claudeは顧客や環境を混同することなく、意図した運用コンテキストを確認できます。
取引所には、既存の検証ワークフローも必要です。ワークフローの設計は、顧客への引き渡し前に行われ、どのチェックを実行するかを決定します。一般的な暗号通貨オンボーディングフローでは、ID検証、パッシブライブネス、顔照合、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を呼び出します。このツールは、設定されたワークフローの完全な検証決定と抽出されたデータを返します。オペレーターは、実際の応答に取引所のレビューポリシーを適用できます。これは、承認済みがすべての下流のコンプライアンス問題を解決すると主張するものではなく、ハンドオフと取得のループです。
決定2：身元証明と名前のリスクを分離する
本人確認とアンチマネーロンダリング（AML）スクリーニングは、異なる質問に答えます。検証された身元データを読み取った後、Claudeは人物のフルネームでdidit_verify_amlを呼び出すことができます。生年月日や国籍などのオプションの入力は、照合の精度を向上させることができます。AMLスクリーニングは、1,300以上のリストに対して1チェックあたり$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）とも呼ばれるウォレットスクリーニングは、1チェックあたり$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カテゴリフィールド>": "<値>" },
"subject": { "<開始当事者フィールド>": "<値>" },
"counterparty": { "<相手方フィールド>": "<値>" },
"transaction_at": "<ISOタイムスタンプ>"
}プレースホルダーは意図的なものです。MCPスキーマは、transaction_detailsとsubjectがtransaction_categoryに依存すると述べており、単一の普遍的なネストされたペイロードを公開していません。オペレーターは、作成された暗号通貨スキーマをコピーするのではなく、設定されたカテゴリに定義されているフィールドを使用する必要があります。
travel_ruleの場合、同じトップレベル契約が適用され、transaction_detailsにカテゴリ固有の転送データ、subjectに開始当事者、counterpartyに相手方、travel_rule_detailsにトラベルルールデータが含まれます。このツールには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のツールを公開し、Proof Key for Code Exchange (PKCE) を使用するOAuth 2.1を使用します。MCPサーバーは無料です。基盤となるチェックは、公開されている価格に従います。無料枠は月あたり500回の無料検証です。
ホストされたClaudeをDiditコネクタのディープリンクで接続します。MCPの概要、認証ガイド、ツールリファレンスを確認してください。実装はMITライセンスのGitHubリポジトリで入手でき、製品の概要はdidit.me/developers/mcpにあります。
永続的な運用パターンは、まず証拠、次にポリシー、最後にアクションです。ClaudeはKYC決定、AML結果、ウォレット結果、トランザクション評価を収集します。取引所は、どの応答がどの決定を引き起こし、どの個別のアクションが続いたかについて明示的であり続けます。