Crypto Exchange Onboarding with Claude: An Operator Decision Sequence

Key takeaways

• Claude can coordinate a crypto exchange's onboarding decisions, but the customer completes Know Your Customer (KYC) capture in Didit's hosted verification UI, not inside the chat.
• didit_session_create requires an existing workflow_id. It returns a URL that the exchange gives to the customer.
• didit_transaction_screen_wallet returns screening results only. It does not hold funds, create a case, or notify a compliance team.
• didit_transaction_create requires transaction_id, transaction_category, transaction_details, and subject at the top level. Transaction fields vary by category.
• The operator's value is the decision sequence: collect the right evidence, interpret it under exchange policy, record each decision, and explicitly trigger any follow-up action.

A crypto exchange does not have one onboarding decision. It has a chain of decisions: can this person start identity verification, did the hosted check complete, does a name-screening result require review, what does a wallet result mean under policy, and should a submitted transaction be accepted for monitoring?

The Didit Model Context Protocol (MCP) server lets Claude coordinate those steps through one authenticated tool surface. It does not collapse the customer experience into the conversation, and it does not turn a risk response into an automatic funds-control system. The useful pattern is an operator copilot with explicit handoffs and explicit actions.

This article focuses on that operating sequence. The mechanics already have dedicated guides for KYC over MCP, wallet screening over MCP, and transaction monitoring over MCP.

Decision 0: establish scope before touching a customer

An operator begins with didit_context_get. The tool lists the organisations and applications available to the authenticated user, so Claude can confirm the intended operating context instead of mixing customers or environments.

The exchange also needs an existing verification workflow. Workflow design happens before the customer handoff and determines which checks run. For a common crypto onboarding flow, that might include ID Verification, Passive Liveness, Face Match, and IP Analysis. The published full KYC bundle price for those checks is $0.33.

The MCP call does not receive a “workflow configuration.” didit_session_create receives a workflow_id that already exists. That distinction makes the operator's first question concrete: which approved workflow applies to this customer and market?

Decision 1: send the customer to the hosted KYC flow

Claude creates the session with the selected workflow and a stable customer reference. The response contains session_id, url, and session_token.

Create a verification session with didit_session_create:
{
  "workflow_id": "<existing-crypto-onboarding-workflow-uuid>",
  "vendor_data": "customer_18427",
  "callback": "https://exchange.example/onboarding/complete",
  "language": "en"
}

Return the url to the customer and retain the session_id for the decision lookup.

The customer opens that URL and completes the required capture in Didit's hosted UI. Identity-document images and the selfie are submitted there. They do not remain inside the Claude chat.

After the customer finishes, Claude calls didit_session_get_decision with session_id. The tool returns the full verification decision and extracted data for the configured workflow. The operator can then apply the exchange's review policy to the actual response. This is a handoff and retrieval loop, not a claim that Approved resolves every downstream compliance question.

Decision 2: separate identity evidence from name risk

Identity verification and Anti-Money Laundering (AML) screening answer different questions. After reading the verified identity data, Claude can call didit_verify_aml with the person's full name. Optional inputs such as date of birth and nationality can improve match accuracy. AML Screening is $0.20 per check across 1,300+ lists.

The operator's decision is not simply “hit or no hit.” A result can need comparison with the verified customer data, documentation of the reasoning, or manual review under the exchange's policy. If the operator decides a case is needed, didit_case_create is a separate explicit tool call. Nothing about the KYC session silently creates that case.

This separation keeps the audit trail readable:

• KYC evidence: what the hosted verification workflow returned.
• AML evidence: what the name-screening response returned.
• Operator decision: how the exchange's policy mapped those responses to approve, review, or decline.

Decision 3: screen the wallet, then decide what to do

didit_transaction_screen_wallet accepts wallet_address, blockchain, and an optional direction. The blockchain enum is a mixed asset-or-chain identifier: it includes chain identifiers such as BTC, ETH, SOL, and TRX, and asset identifiers such as USDT and USDC. USDT and USDC are assets, not blockchains.

The following is a runnable Claude prompt with the exact MCP payload shape. Replace the example address with the customer's wallet:

Call didit_transaction_screen_wallet with exactly this payload:
{
  "wallet_address": "0x0000000000000000000000000000000000000000",
  "blockchain": "ETH",
  "direction": "deposit"
}

Return the response fields risk_score, severity, sanctions_hit, and the reported
source and destination of funds. Do not hold funds, create a case, or notify anyone.
Ask for an explicit follow-up instruction after summarising the screening result.

The response shape is a screening result: risk_score, severity, sanctions_hit, and source/destination-of-funds information. The tool can return a 409 response when transaction monitoring's screening configuration is unavailable.

Wallet Screening, also called know your transaction (KYT) in the product catalogue, costs $0.15 per check. The result does not itself move money. A hold, release, case, escalation, or notification belongs to the exchange's own policy and requires a separate system or tool action. For example, Claude can call didit_case_create only after the operator or an authorised policy layer explicitly chooses that action.

Decision 4: submit a transaction with the real schema

didit_transaction_create submits a transaction for monitoring and rule evaluation. Its required top-level fields are:

• transaction_id: the exchange's unique transaction identifier.
• transaction_category: one of the documented category values, including finance, kyc, travel_rule, and user_event.
• transaction_details: the category-specific transaction payload.
• subject: the party initiating the transaction.

Optional top-level objects include counterparty, travel_rule_details, network_snapshot, and custom_properties. The tool does not define transaction hash, source address, destination address, asset, or amount as universal top-level fields. If those values are part of a category's data, they belong inside the relevant category-specific object.

The top-level contract for didit_transaction_create is:
{
  "transaction_id": "<exchange-unique-transaction-id>",
  "transaction_category": "finance",
  "transaction_details": { "<finance-category fields>": "<values>" },
  "subject": { "<initiating-party fields>": "<values>" },
  "counterparty": { "<other-party fields>": "<values>" },
  "transaction_at": "<ISO timestamp>"
}

The placeholders are deliberate. The MCP schema states that transaction_details and subject depend on transaction_category; it does not publish one universal nested payload. An operator should use the fields defined for the configured category rather than copying an invented crypto schema.

For travel_rule, the same top-level contract applies, with category-specific transfer data in transaction_details, the initiating party in subject, the other party in counterparty, and Travel Rule data in travel_rule_details. There is no metadata field on this tool. Selecting travel_rule identifies the category-specific payload; it does not automatically perform beneficiary vetting or clear the transfer.

The transaction is evaluated when it is submitted. It is inaccurate to describe a single submitted record as being continually re-evaluated forever. Claude can retrieve the monitored transaction and its rule-evaluation result with didit_transaction_get.

Decision 5: keep policy authoring in the Business Console

The Business Console's Transaction Monitoring rule builder is where teams configure monitoring rules and policy logic. It is not the verification workflow editor. The MCP surface submits transactions, retrieves results, searches records, and supports explicit case operations; it does not replace rule authoring.

Case actions are also bounded. didit_case_manage supports assign, comment, escalate, reopen, resolve, and update. Suspicious Activity Report (SAR) workflows remain Business Console operations. That boundary lets an exchange use Claude for evidence gathering and operator assistance without describing the agent as an autonomous compliance authority.

Connect the operator copilot

Didit's hosted MCP endpoint exposes 115 tools over Streamable HTTP and uses OAuth 2.1 with Proof Key for Code Exchange (PKCE). The MCP server is free; underlying checks follow their published prices. The free tier is 500 free verifications per month.

Connect hosted Claude with the Didit connector deep link. Review the MCP overview, authentication guide, and tool reference. The implementation is available in the MIT-licensed GitHub repository, and the product overview lives at didit.me/developers/mcp.

The durable operating pattern is evidence first, policy second, action third. Claude gathers the KYC decision, AML result, wallet result, and transaction evaluation. The exchange remains explicit about which response caused which decision and which separate action followed.