KYB/KYC Due Diligence With an AI Research API

Onboarding a business means answering questions that live in different places: is it registered and active, who stands behind it, has it raised money, and does its public record raise a flag. A KYC KYB data API for this job returns those answers from one request, with a citation on each claim. NeuralVerge does it with AI research over REST, plus registry lookups that agents can also call over MCP. What is KYB covers the concept.

The short version

• —What it is. A due-diligence workflow: a registry lookup for legal existence and status, and a cited research run for ownership, funding and reputation. Research runs over REST only; the registry sources, Search and AI extraction are available over REST and MCP.
• —What it is not. It does not screen sanctions or politically exposed persons lists, and it is not formal identity verification. Pair it with a dedicated provider for those. Nothing here is legal or compliance advice.
• —Who it is for. Developers and compliance teams who onboard vendors and business customers, review acquisition targets, or run an onboarding agent.
• —What it costs. A registry lookup is 5 points when the company resolves, a registry search is 1 point per returned record, and a research run is 20 to 400 points by depth tier. Plans start at $50 a month for 50,000 points.
• —Where to find exact fields. Each registry has its own page under data sources, such as the Finland company source, which is the reference for request shape and fields.

The check, step by step

A business check shares a shape with a person check: confirm the subject is real, understand who controls it, and surface risk before the relationship starts. For a business that breaks into four kinds of fact, each living in a different kind of source. The workflow below follows that order.

1. Find the entity and its identifier

Start from what you have. A registration number goes straight to the registry lookup. A name goes to the registry search first, which returns matches with the identifier, legal form and a link to the register. In the Finland search sample, a search for "nokia" reports 300 matches and returns the two you asked for, one of them a foreign entity registered in Finland, so look at legal form before you pick a match.

2. Confirm legal existence and status

This is the question a registry answers best, and it should come from the registry itself, not from a model reading a web page. NeuralVerge has dedicated sources for national company registries, listed in company registry by country and described in the corporate registries guide. Each returns the register's own record: name, status, legal form, registration date, address and, depending on the register, registrations, filings and tax or filing status.

3. Understand who controls it

What a register publishes about control differs by country, so check what your registers actually return. The UK Companies House source returns officers and persons with significant control, or the statement that a company is exempt from reporting them. The GLEIF source returns direct and ultimate parents and children for entities that hold a LEI; see the LEI lookup guide. The Finnish record in the sample below has no ownership fields at all. Where a register does not publish owners, the research run is the way to look for them in funding data and the open web, and its answer says where each claim came from.

4. Check funding and reputation

A funding history can explain the scale a counterparty claims, and a gap between the two is worth a question. Reputation signals come from review platforms and general web sources. Neither is authoritative the way a register is, and the citation tells you which kind of source stood behind each sentence.

5. Cross-check and keep the record

Disagreement between sources has to be visible. The cross-check step compares facts where more than one source touches the same claim. It then resolves the disagreement with a stated reason, prefers the more authoritative source, or reports the conflict in the answer. Deep research API walks through all five steps of the pipeline: plan, search, extract, cross-check and cite.

The person side of KYC

For the person behind an address or number, the email and phone enrichment sources add context: the person, employer and role behind an address, and line type, carrier and a litigator-risk flag for US numbers. That is useful context for a review, not identity verification.

Worked example: onboarding a vendor

Take Acme Oy (Finland), an illustrative vendor going through onboarding. The requirement is to confirm it is a legitimate, active entity with a plausible financial footing before a contract is signed.

1. —Plan splits the request into sub-questions: is Acme Oy registered and active, who controls it, has it raised funding, and does anything in its public reputation raise a flag.
2. —Search routes the registration question to Finland's YTJ register, the funding question to company-intelligence data, and the reputation question to review platforms and general web sources.
3. —Extract and cross-check pulls registration status and the registers entered, funding total and round history, and review themes, then compares them where they touch the same claim.
4. —Cite assembles a short structured answer with each claim linked to its source, so a reviewer checks it claim by claim instead of reading one unsourced paragraph.

A second case: screening a business customer

A payments company screens a new business customer before opening an account. Registration and ownership go to the national registry, reputation to review platforms and the web. The cross-check compares registered ownership with what the business has said publicly about its structure, and a mismatch is a signal a single-source check tends to miss. The structured answer attaches to the account record, with the session_id available to trace the run.

When the automated check surfaces something inconsistent, that is the trigger for manual review. The pipeline gives every applicant the same baseline check; it does not replace an analyst's judgment on an edge case.

REST and MCP

Both parts of the workflow are real requests. The research run is REST, and it is asynchronous: you start it, get a session_id back, and poll for the answer.

# Start the research run, which returns a session_id immediately
curl https://api.neuralverge.ai/functions/v1/run-research \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "instructions": "Is Acme Oy (Finland) a registered, active company, who controls it, has it raised funding, and does its public reputation raise any flags?",
    "settings": { "country_code": "fi", "search_enabled": true, "deepsearch_model": "core" }
  }'

# Poll for the result
curl "https://api.neuralverge.ai/functions/v1/get-session-status?session_id=<SESSION_ID>" \
  -H "Authorization: Bearer <API_KEY>"

The response has the same envelope as the example on the AI research page, shortened here, with a placeholder session id:

{
  "session_id": "11111111-1111-1111-1111-111111111111",
  "status": "complete",
  "results": {
    "kind": "deepsearch",
    "human": "# Acme Oy\n\nAcme Oy is a private limited company registered with YTJ...",
    "machine": { "summary": "Acme Oy is a private limited company registered with YTJ..." }
  }
}

results.human is the readable answer and results.machine a structured version for code. Poll until status is complete. The Core tier costs 100 points.

The registry lookup is a single synchronous call. This is the Finland source with a Business ID, over REST:

curl https://api.neuralverge.ai/functions/v1/run-fi-companies \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{ "company": "0112038-9" }'

This is the captured response for the source page's sample company, Nokia Oyj, trimmed to the fields a KYB check reads. The full record also carries names, addresses and the register history:

{
  "kind": "fi_company",
  "machine": {
    "company": {
      "registration_number": "0112038-9",
      "name": "Nokia Oyj",
      "status": "Active",
      "company_type": "Public limited company",
      "incorporation_date": "1896-12-19",
      "termination_date": null,
      "registrations": [
        { "register": "Trade register", "status": "Registered", "start_date": "1896-12-19" },
        { "register": "Tax Administration", "status": "Registered", "start_date": "1978-03-15" }
      ],
      "tax_debt": {
        "taxes_owed": "No record of tax debts.",
        "filing_negligence": "No register entries that would indicate non-filing of the Return for Self-Assessed Taxes.",
        "last_update": null
      },
      "business_id_history": [
        { "date": "1999-08-25", "event": "Fusion", "description": "Business 0732607-0 merged into 0112038-9 .", "related_business_id": "0732607-0" }
      ]
    }
  },
  "total_points": 5
}

Status, legal form and registrations answer the existence question. The tax debt text and the merger event in the Business ID history are the kind of detail a reviewer would otherwise dig out of the register by hand. A lookup costs 5 points and is charged only when the company resolves.

Over MCP

AI research is the one piece that is not an MCP tool: a research run is asynchronous and an MCP tool has to return inside the call. Everything around it is. NeuralVerge hosts the server at https://mcp.neuralverge.ai/mcp, so there is nothing to build or host. Add the URL to Claude, ChatGPT, Cursor, VS Code, Gemini CLI or another MCP client, sign in in the browser and click Allow. The client setup guides cover each one, and MCP server for Claude walks through a connection.

Tool names use underscores where REST paths use hyphens. The registry search above is run_fi_companies_search, the lookup is run_fi_companies, Companies House is run_uk_companies and LEI records are run_gleif_companies. A search call looks like this:

{
  "tool": "run_fi_companies_search",
  "arguments": {
    "keyword": "nokia",
    "max_items": 2
  }
}

Each tool returns the same response shape as its REST endpoint at the same price. The server docs list everything exposed.

A workable split for an onboarding agent: let it use the registry tools for questions it can settle itself, such as whether an entity exists, its legal form and its identifier. When the case needs planning and cross-checking across registries, funding and reputation sources, your own code, or a tool you wrap, calls run-research over REST and attaches the cited answer to the case. Pick REST when the check is a fixed step in a pipeline, such as right after a counterparty record is created. Pick MCP when an agent decides mid-case which lookup it needs next.

Cost and limits

Points are from the pricing page and the source pages at the time of writing, and billing follows each source page: a registry lookup is charged only when the company resolves, and a research run is billed by its tier. The pricing page lists the plans and the cost of every action.

Depth is a setting per request (deepsearch_model), so a pipeline does not have to run exhaustive research on every routine counterparty to have it available for the few that warrant it. The five tiers run from about 30 to 90 seconds at Lite up to 5 to 12 minutes at Ultima, so research suits background jobs and queues, not a synchronous page load. Lighter tiers run fewer cross-checks, which suits a narrow question and is a worse choice for a broad one.

Limits worth stating plainly:

• —No sanctions or PEP list. Use a dedicated provider for that check.
• —Not identity verification. Enrichment adds context about a person; it does not confirm that someone is who they say they are.
• —Registers differ. Fields, update frequency and what is published about owners vary by country, so read the source page for each register you rely on.
• —Open-web claims are weaker than register claims. A review or a news item is a signal to follow up, not a finding.
• —Read-time freshness. The answer reflects what is public when you ask, and a register is only as current as its own last update.

Pitfalls

Picking the wrong match

A name search can return foreign entities, branches and similarly named companies. Confirm legal form and identifier before treating a record as the counterparty.

Checking once

A counterparty that was in good standing at onboarding is not guaranteed to be later. A dissolution, a change of control or a reputation shift only shows up if you look again, so schedule a lighter re-check for existing relationships.

How to decide

Ask these before building the workflow:

• —Does the program require sanctions or PEP screening? If yes, this is only part of it. Add a dedicated provider.
• —Which countries do your counterparties come from? Check the registry list for each one, and read what that register publishes about owners.
• —Is the depth matched to the stakes? A routine vendor and an acquisition target do not need the same cross-checking. See the table above.
• —Can a reviewer check each claim? Per-claim citations are what make an answer auditable. A single combined source list is not.
• —Does it re-check live relationships? Re-running on a schedule catches a status change after onboarding.
• —Where does it plug in? Vendor and supplier onboarding, business customer onboarding, first-pass diligence on a deal target, ongoing monitoring and onboarding agents each fit REST, MCP or both, as described above. For deal work specifically, see the M&A due diligence guide.
• —Does the output fit your case file? A structured, cited answer should attach to a record without reformatting.

Running a counterparty you already know the right answer for is a faster way to judge fit than reading a features page.

Frequently asked questions

Does this replace a dedicated sanctions or PEP screening tool?

No. AI research draws on corporate registries, funding and company-intelligence sources, and general web and reputation sources. It does not maintain a sanctions or politically exposed persons list, so a program that needs that check still needs a dedicated provider alongside this.

Are the facts in the answer sourced from official registers?

Where a sub-question routes to a corporate registry, yes: the citation points to the register the fact came from. Where it routes to the open web or a review platform, the citation points to that source instead, and the answer should be read with that difference in mind.

How current is a KYB check run this way?

Each source is read at request time, so the answer reflects what is publicly available when you ask. A registry record is as current as the register's own last update, and the open-web layer reflects whatever is publicly indexed at that moment.

Can this run automatically as part of an onboarding flow?

Yes. It is an ordinary REST call, so backend code can start it when a counterparty record is created, or an onboarding agent can call it through a tool you wrap around it. A common pattern is a light automatic check on every new counterparty, with flagged cases sent to manual review.

Can I run KYB checks over MCP, or only through the API?

Partly. AI research runs over REST only. The hosted MCP server at mcp.neuralverge.ai exposes Search, AI extraction and every data source, including the corporate registry sources, as tools an agent can call around a research job. Add the URL to an MCP client, sign in and click Allow. Calls cost the same as over REST.

What happens when sources disagree on a fact?

The cross-check step is built for this. It resolves the disagreement with a stated reason, prefers the more authoritative source, or reports the disagreement in the answer instead of silently picking one side.

Can this be used for ongoing monitoring, not just onboarding?

Yes. Running the same question against an existing counterparty on a schedule and comparing the results over time is a normal way to catch a status change or a reputation shift after onboarding, instead of treating the check as a one-time gate.