Verifying a Business with Claude: KYB and Beneficial Owners Through the Didit MCP

Key takeaways

• In Claude, an operator creates one parent Know Your Business (KYB) session with a configured KYB workflow. Didit’s hosted flow—not Claude—automatically spawns child Know Your Customer (KYC) sessions according to the workflow’s Key People settings.
• KYC is not mandatory for every Ultimate Beneficial Owner (UBO). Ownership thresholds, required roles, and skip rules are configurable, and the applicable legal threshold depends on the jurisdiction and policy.
• didit_verify_kyb_search returns registry candidates. It does not traverse corporate relationships. A selected candidate can be resolved with didit_verify_kyb_select.
• Claude is useful as the conversational control surface: you ask it to create the parent session, explain returned states, summarize party progress, and assemble evidence. A human still selects the correct company and makes policy decisions.
• Didit Business Verification starts from $2.00 per business. Didit covers 220+ countries and territories, and each feature includes 500 free verifications per month.

A business-verification conversation with Claude should feel simple without pretending the underlying compliance work is simple. The operator names the company and the approved workflow. Claude calls the relevant Didit tools. The business representative completes the hosted flow. Didit resolves registry and Key People requirements. Claude then turns the resulting records into a readable case summary.

This article focuses on that conversation: what you type, what Claude should return, and what a human still decides. For the product mechanics, ownership data, and the broader Business Verification lifecycle, read KYB with the Didit MCP server. For Claude setup, use the connector installation guide.

Before the conversation: configure the policy

Claude should not invent your KYB policy. Configure a KYB workflow in Didit first. Its Key People settings determine which people connected to a business must complete child KYC sessions. Those settings can use ownership thresholds, require verification for specific roles such as directors or representatives, and skip KYC where your approved policy allows it.

A 25% ownership threshold is common in some regulatory contexts, but it is not universal. Jurisdiction, customer type, risk level, control rights, and your organization’s obligations can change which people must be identified or verified. The workflow configuration expresses that policy; Claude executes against it.

Connect through the Didit custom connector for Claude. The hosted endpoint uses OAuth (Open Authorization) 2.1 with PKCE (Proof Key for Code Exchange), so Claude acts with the signed-in user’s existing organization role.

Conversation 1: confirm context and workflow

Start by asking Claude to identify where it will operate. This matters when an analyst can access several organizations or applications:

Call didit_context_get. State the selected Didit organization and application. Do not create or update anything.

Then ask for the configured workflows:

List my workflows and show only those configured for business verification. Return each name and workflow_id. For the workflow I choose, summarize its Key People requirements without changing them.

Claude can use didit_workflow_list to show the available definitions. Read the summary carefully. If the workflow requires directors, representatives, or owners above a configured threshold, those are workflow rules—not recommendations generated by Claude. If the summary is ambiguous, stop and inspect the workflow in the Business Console before starting the business session.

Conversation 2: optionally check the registry candidate

For a pre-check, you can ask Claude to search an official registry:

Search the United Kingdom registry for “Acme Trading Limited” using country_code GB. Return the candidate registered names, registration numbers, statuses, and kyb_response_id values. Do not select a candidate.

Claude calls didit_verify_kyb_search. The response is a candidate list, not a verified ownership graph; the search tool does not traverse subsidiary or parent-company relationships. Similar names, former names, and reused trading names can produce several plausible candidates.

The operator chooses the matching legal entity using evidence such as registration number, jurisdiction, and registered address. Then ask Claude to resolve that candidate:

Select kyb_response_id KYB_CANDIDATE_ID and return the full registry record. Separate registry facts from any interpretation. Flag missing fields and do not infer owners that are absent.

didit_verify_kyb_select resolves the chosen candidate. Claude can format the record and point out inconsistencies, but the human owns candidate selection. A fluent summary is not proof that the correct “Acme” was selected.

Conversation 3: create one parent KYB session

The hosted KYB flow begins with one session created from the selected KYB workflow:

Create one business verification session using workflow_id 11111111-2222-3333-4444-555555555555. Set vendor_data to merchant-2048. Return the parent session_id and url only.

Claude calls didit_session_create. The required argument is workflow_id; the workflow defines that this is a KYB session. The response includes the parent session_id and hosted url. Send that URL to the authorized business representative through your approved channel.

Claude must not call didit_session_create once per owner and claim those ad hoc sessions are linked to the business. That is not the KYB orchestration model. As the representative completes the hosted business flow, Didit automatically spawns the required child KYC sessions according to the parent workflow’s Key People settings. The configured rules determine which parties must verify; skip settings and per-role requirements remain effective.

The end user sees the hosted business flow: requests for company information or documents required by the workflow, registry-resolution steps where applicable, and invitations or handoffs for the Key People who must complete KYC. The exact experience depends on configuration and available registry data. It is not a universal “verify every UBO” sequence.

Conversation 4: read the parent state correctly

Ask Claude to retrieve the actual parent decision rather than estimate completion time:

Retrieve the decision for parent KYB session 66666666-7777-8888-9999-000000000000. Report the parent status, business findings, required Key People, and the completion state of each linked child KYC party. Do not infer missing parties or mark the business approved.

Claude calls didit_session_get_decision and summarizes what Didit returned. The Awaiting User state has a specific KYB meaning: the parent business session is waiting while required child KYC parties finish. It is not a generic label for any missing business information.

Do not attach the sub-2-second p99 inference figure to the overall KYB response time. A business flow can include human document collection, registry availability, and multiple people completing hosted child sessions. Claude should report current states, not promise a completion window.

A useful follow-up prompt is:

Turn this KYB decision into an analyst checklist with four sections: verified registry facts, completed Key People checks, unresolved or conflicting evidence, and decisions that require a human. Include record identifiers beside every finding.

Conversation 5: screen and review without overclaiming

If the workflow or policy calls for Anti-Money Laundering (AML) screening, ask Claude first whether a current result already exists. Avoid paying for a duplicate check merely because a new conversation started:

Check the existing KYB decision for entity and Key People AML results. If a required current result is absent, show the exact subject data you would submit to didit_verify_aml and wait for approval before running a new screening.

didit_verify_aml screens against 1,300+ sanctions, Politically Exposed Person (PEP), and adverse-media lists. Returned matches are candidates for analysis, not automatic proof that the business or person is prohibited. A human reviewer must resolve identity similarity, jurisdiction, dates, source reliability, and the organization’s escalation policy.

What Claude returns, and what the human decides

• Claude can return: registry candidates, a selected registry record, the parent session link, current parent status, linked-party progress, screening results, and a source-labeled evidence summary.
• The human selects: the correct legal entity when candidates are ambiguous and the approved workflow before the session starts.
• The configured workflow determines: ownership thresholds, required roles, and allowed KYC skips for Key People.
• The human reviews: ownership or control ambiguity, registry gaps, potential AML matches, exceptions, and the final risk decision.
• The Business Console remains useful: when an analyst needs a visual ownership view, policy configuration, or a controlled review surface beyond the chat summary.

Business Verification starts from $2.00 per business. A linked full KYC bundle, when required by the configured Key People rules, is $0.33 and includes ID verification, passive liveness, face match, and IP analysis. Each feature includes 500 free verifications per month. The MCP server itself is free.

Resources

• Didit MCP GitHub repository — public source under the MIT license
• MCP overview — endpoint, transport, and connector model
• MCP tools documentation — canonical inputs and outputs
• Didit MCP developer page — product overview
• Didit MCP tools reference — conversational tool catalog

The practical value is not an imaginary autonomous ownership investigation. It is a controlled conversation around a real KYB workflow: one parent session, automatically managed child KYC requirements, evidence returned from Didit, and a human decision at the points where law and risk policy require judgment.