Онбординг криптобиржи с Claude: Последовательность решений оператора

Основные выводы

• Claude может координировать решения криптобиржи по онбордингу, но клиент завершает сбор данных «Знай своего клиента» (KYC) в размещенном пользовательском интерфейсе Didit для верификации, а не внутри чата.
• Для 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 координировать эти шаги через единый аутентифицированный интерфейс инструмента. Он не сводит клиентский опыт к беседе и не превращает реакцию на риск в автоматическую систему контроля средств. Полезный шаблон — это помощник оператора с явными передачами и явными действиями.

Эта статья посвящена именно этой операционной последовательности. Механизмы уже имеют специальные руководства для KYC через MCP, проверки кошельков через 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. Изображения удостоверения личности и селфи отправляются туда. Они не остаются в чате Claude.

После того, как клиент завершит, Claude вызывает didit_session_get_decision с session_id. Инструмент возвращает полное решение о верификации и извлеченные данные для настроенного рабочего процесса. Затем оператор может применить политику рассмотрения биржи к фактическому ответу. Это цикл передачи и извлечения, а не утверждение, что Approved решает каждый последующий вопрос соответствия.

Решение 2: отделить доказательства личности от риска имени

Верификация личности и проверка на предмет отмывания денег (AML) отвечают на разные вопросы. После прочтения верифицированных данных личности Claude может вызвать didit_verify_aml с полным именем человека. Необязательные входные данные, такие как дата рождения и национальность, могут улучшить точность совпадения. AML-скрининг стоит 0,20 доллара США за проверку по более чем 1300 спискам.

Решение оператора — это не просто «совпадение или нет». Результат может потребовать сравнения с верифицированными данными клиента, документирования обоснования или ручного рассмотрения в соответствии с политикой биржи. Если оператор решает, что нужен кейс, didit_case_create — это отдельный явный вызов инструмента. Ничто в сессии KYC не создает этот кейс автоматически.

Такое разделение делает аудиторский след читаемым:

• Доказательства KYC: что вернул размещенный рабочий процесс верификации.
• Доказательства AML: что вернул ответ на проверку имени.
• Решение оператора: как политика биржи сопоставила эти ответы для одобрения, рассмотрения или отклонения.

Решение 3: проверить кошелек, затем решить, что делать

didit_transaction_screen_wallet принимает wallet_address, blockchain и необязательное direction. Перечисление blockchain является смешанным идентификатором актива или цепочки: оно включает идентификаторы цепочек, такие как BTC, ETH, SOL и TRX, а также идентификаторы активов, такие как USDT и USDC. USDT и USDC являются активами, а не блокчейнами.

Ниже приведен запускаемый запрос Claude с точной формой полезной нагрузки MCP. Замените пример адреса адресом кошелька клиента:

Вызвать didit_transaction_screen_wallet с точно такой полезной нагрузкой:
{
  "wallet_address": "0x0000000000000000000000000000000000000000",
  "blockchain": "ETH",
  "direction": "deposit"
}

Вернуть поля ответа risk_score, severity, sanctions_hit и сообщенные
источник и назначение средств. Не удерживать средства, не создавать кейс и никого не уведомлять.
Запросить явную инструкцию по дальнейшим действиям после подведения итогов проверки.

Форма ответа — это результат проверки: risk_score, severity, sanctions_hit, а также информация об источнике/назначении средств. Инструмент может вернуть ответ 409, если конфигурация проверки мониторинга транзакций недоступна.

Проверка кошельков, также называемая «знай свою транзакцию» (KYT) в каталоге продуктов, стоит 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": "<уникальный-идентификатор-транзакции-биржи>",
  "transaction_category": "finance",
  "transaction_details": { "<поля-категории-финансы>": "<значения>" },
  "subject": { "<поля-инициирующей-стороны>": "<значения>" },
  "counterparty": { "<поля-другой-стороны>": "<значения>" },
  "transaction_at": "<ISO-временная-метка>"
}

Заполнители преднамеренны. Схема MCP утверждает, что transaction_details и subject зависят от transaction_category; она не публикует одну универсальную вложенную полезную нагрузку. Оператор должен использовать поля, определенные для настроенной категории, а не копировать придуманную криптосхему.

Для travel_rule применяется тот же контракт верхнего уровня, с данными передачи, специфичными для категории, в transaction_details, инициирующей стороной в subject, другой стороной в counterparty и данными Travel Rule в travel_rule_details. В этом инструменте нет поля metadata. Выбор travel_rule идентифицирует полезную нагрузку, специфичную для категории; он не выполняет автоматически проверку бенефициара или очистку перевода.

Транзакция оценивается при ее отправке. Неточно описывать одну отправленную запись как постоянно переоцениваемую навсегда. Claude может получить отслеживаемую транзакцию и ее результат оценки правил с помощью didit_transaction_get.

Решение 5: сохранять создание политики в бизнес-консоли

Конструктор правил мониторинга транзакций в бизнес-консоли — это место, где команды настраивают правила мониторинга и логику политики. Это не редактор рабочего процесса верификации. Интерфейс MCP отправляет транзакции, извлекает результаты, ищет записи и поддерживает явные операции с кейсами; он не заменяет создание правил.

Действия по кейсам также ограничены. didit_case_manage поддерживает assign, comment, escalate, reopen, resolve и update. Рабочие процессы отчетов о подозрительной деятельности (SAR) остаются операциями бизнес-консоли. Эта граница позволяет бирже использовать Claude для сбора доказательств и помощи оператору, не описывая агента как автономный орган по соблюдению требований.

Подключите помощника оператора

Размещенная конечная точка MCP Didit предоставляет 115 инструментов через Streamable HTTP и использует OAuth 2.1 с ключом подтверждения для обмена кодами (PKCE). Сервер MCP бесплатен; базовые проверки следуют своим опубликованным ценам. Бесплатный уровень — 500 бесплатных проверок в месяц.

Подключите размещенный Claude с помощью прямой ссылки на коннектор Didit. Ознакомьтесь с обзором MCP, руководством по аутентификации и справочником по инструментам. Реализация доступна в репозитории GitHub с лицензией MIT, а обзор продукта находится по адресу didit.me/developers/mcp.

Устойчивый операционный шаблон — это сначала доказательства, затем политика, затем действие. Claude собирает решение KYC, результат AML, результат проверки кошелька и оценку транзакции. Биржа остается явной в отношении того, какой ответ вызвал какое решение и какое отдельное действие последовало.