What Is KYB? Know Your Business Checks Explained for Developers

What is KYB? KYB, short for know your business, is the process of confirming that a company is a real, legally registered entity, finding out who stands behind it, and checking for risk signals before you onboard it as a customer, vendor, partner or borrower. It is the company-level counterpart to KYC. This guide explains what a check involves, where each fact comes from and what a real registry lookup returns, reachable over REST or MCP. It is a technical explainer, not legal or compliance advice.

The short version

• —The answer. KYB asks whether a company exists, what its status and legal form are, where it is, and who runs and owns it. Existence, status, legal form and address come from an official company register, so the first half of a KYB pipeline is a data-retrieval problem. The second half, how much evidence is enough and what counts as a red flag, is a policy decision.
• —Who it is for. Developers building fintech, marketplace, procurement or onboarding software who are asked to verify business customers, sellers or suppliers, and agents that need a registry record at the moment they need it.
• —What it costs. The real lookup shown below, the Finnish YTJ company source, is 5 points per resolved company, which its source page lists as $5 per 1,000, and a lookup that finds nothing is not billed. Plans start at $50 a month for 50,000 points. Other registry sources have their own point costs on their pages.
• —How you reach it. Every registry source is available over REST and as an MCP tool for agents. The source page is the reference for exact fields, request shape and prices.
• —The boundary. Which checks you must run, on whom, and how long you keep the records depends on your jurisdiction, industry and regulator, and rules change. Ask your compliance team or counsel what applies to you.

What KYB is

Strip away the acronym and a KYB check asks a handful of plain questions about a company:

• —Does it exist? Is there an entity on an official register with this name and registration number?
• —What is its status? Active, dissolved, in liquidation, struck off, or something else.
• —What kind of entity is it? A public limited company, a private limited company, a partnership, a sole trader. The legal form tells you who is liable for what.
• —Where is it? The registered address and, where published, other establishments.
• —Who runs it? Directors, managing officers and other people with authority to act for the company.
• —Who owns or controls it? Shareholders and, in many countries, the natural persons who ultimately own or control the company, often called beneficial owners.
• —Does anything look wrong? Adverse entries, unusual history, or details that differ from what the applicant told you.

Most of these are questions of public record. The judgment on top of them belongs to your risk policy, not your code.

KYB vs KYC

KYC (know your customer) is about an individual: is this person who they say they are, and is the identity document genuine? KYB is about a legal entity, but a company cannot be verified without looking at the people behind it, so a KYB process usually ends up running KYC-style checks on directors and beneficial owners. The post on KYB and KYC due diligence with an AI research API covers how the two combine in a research workflow; this one stays on the company side.

KYB vs AML and sanctions screening

Anti-money-laundering programs are the broader frame KYB often sits inside. In many regimes, verifying a business customer is one component of a wider obligation that also includes transaction monitoring and sanctions and politically-exposed-person screening. Screening lists are a separate data product from dedicated providers, and a company registry does not replace them.

KYB vs credit checks and enrichment

A credit report asks whether the business will pay. Enrichment adds attributes such as headcount to a record you already trust. KYB asks whether the record should be trusted at all. If an enrichment source and the official register disagree on a legal name or status, the register is normally the one a reviewer wants cited.

Why developers end up owning it

KYB used to be an operations team's spreadsheet. Volume moved it into code, because a self-serve signup cannot wait for someone to open a government website. A structured record with a source and a timestamp is easier to defend to an auditor than a screenshot, and re-checking on a schedule is trivial for code.

The hard part is that no global company register exists. Each country runs its own, with its own identifier format, language, fields and access rules. The post on corporate registries as an API compares the ways to reach that data; this article assumes the structured route and shows what it looks like.

How a KYB check works

Implementations differ, but most KYB flows follow the same sequence.

1. Collect what the applicant gives you

You start with applicant-supplied claims: legal name, country of incorporation, registration number, address, and often a list of directors and owners. Treat all of this as unverified. The most useful input is the registration number, because it identifies exactly one entity on a register while a name can match several. If you only have a name, resolve it to a number first with a name search.

2. Resolve the entity on the right register

Work out which register to ask. Usually that is the country of incorporation, though a company may operate elsewhere and a group may have a holding company in a third country.

3. Fetch the registry record

Read the official record: name, status, legal form, registration date, address, and whatever else that register publishes. Store the retrieval date next to it, since the record is only as current as the register.

4. Compare claims with the record

Check that the name matches (registers can list several names for one entity), that the status is one you accept, that the legal form is what the applicant said, and that the address is plausible. Mismatches are often just a stale form field or a trading name, but each one is a reason to look, and the comparison is easy to automate.

5. Establish ownership and control

Where the register publishes officers, shareholders or beneficial owners, read them. Where it does not, you generally have to ask the applicant for the structure and request supporting documents. Ownership transparency varies widely between countries.

6. Screen and look for risk signals

Run the entity, and the people you identified, against whatever screening and adverse-information sources your program calls for.

7. Decide, record and monitor

Apply your policy: approve, reject, or send to manual review. Store the inputs, the retrieved records with their source and date, and the decision. Then schedule a re-check, because the record you retrieved today describes the company as of today.

Which source answers which question

A registry is the foundation, not the whole check. This table shows where each question is usually answered; the fields a register publishes differ by country.

A real registry request and response

To make steps 3 and 4 concrete, here is one real call to a NeuralVerge corporate registry source: the Finnish YTJ company lookup, which reads the company record from the joint register of Finland's Patent and Registration Office and Tax Administration. You send a Business ID (the Finnish Y-tunnus) or the link to the record on the register and get structured JSON back. Registry sources for other countries share the same request pattern; only the endpoint and identifier change.

The request:

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

And the response. This is the sample response from the source page, a real captured response for a publicly listed Finnish company (Nokia Oyj), not an illustrative one. The session_id is a placeholder.

{
  "session_id": "11111111-1111-1111-1111-111111111111",
  "kind": "fi_company",
  "company": "0112038-9",
  "company_id": "0112038-9",
  "human": "# Finland — PRH / YTJ — company\n\n- **Number:** 0112038-9\n- **Pages opened:** 1\n- **Proxy traffic:** 51.3 KB\n- **Name:** Nokia Oyj\n- **Status:** Active\n- **Type:** Public limited company\n- **Registered:** 1896-12-19\n- **Address:** Karakaari 7 02610 ESPOO",
  "machine": {
    "company": {
      "registration_number": "0112038-9",
      "name": "Nokia Oyj",
      "status": "Active",
      "address": "Karakaari 7 02610 ESPOO",
      "url": "https://tietopalvelu.ytj.fi/en/yritys/0112038-9",
      "company_type": "Public limited company",
      "incorporation_date": "1896-12-19",
      "activity": "Activities of head offices",
      "activity_code": "70100",
      "business_id_date": "1978-03-15",
      "termination_date": null,
      "street_address": "Karakaari 7 02610 ESPOO",
      "postal_address": "P.O. Box 226 00045 NOKIA GROUP",
      "home_municipality": "HELSINKI",
      "language": "Finnish",
      "website": "www.nokia.com",
      "eu_id": "FIFPRO.0112038-9",
      "company_name_start_date": "1997-09-01",
      "previous_names": [
        {
          "value": "Oy Nokia Ab",
          "start_date": "1966-06-10",
          "end_date": "1997-08-31"
        }
      ],
      "parallel_names": [
        {
          "name": "Nokia Abp",
          "start_date": "1997-09-01"
        },
        {
          "name": "Nokia Corporation",
          "start_date": "1997-09-01"
        }
      ],
      "auxiliary_names": [
        {
          "name": "Vertu",
          "start_date": "2006-03-08"
        },
        {
          "name": "TCC Nokia",
          "start_date": "2004-11-12"
        }
      ],
      "phone": null,
      "phone_registered": true,
      "registrations": [
        {
          "register": "Trade register",
          "status": "Registered",
          "start_date": "1896-12-19"
        },
        {
          "register": "Tax Administration",
          "status": "Registered",
          "start_date": "1978-03-15"
        }
      ],
      "register_history": [],
      "prepayment_register_check_dates": "1 March, 1 June, 1 September and 1 December",
      "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": "1978-03-15",
          "event": "ID given",
          "description": null,
          "related_business_id": null
        },
        {
          "date": "1999-08-25",
          "event": "Fusion",
          "description": "Business 0732607-0 merged into 0112038-9 .",
          "related_business_id": "0732607-0"
        }
      ],
      "details": [
        {
          "label": "Business ID",
          "values": [
            {
              "value": "0112038-9",
              "start_date": "1978-03-15",
              "source": "Business Information System"
            }
          ],
          "previous": []
        },
        {
          "label": "Company name",
          "values": [
            {
              "value": "Nokia Oyj",
              "start_date": "1997-09-01",
              "source": "Finnish Patent and Registration Office"
            }
          ],
          "previous": [
            {
              "value": "Oy Nokia Ab",
              "start_date": "1966-06-10",
              "end_date": "1997-08-31"
            }
          ]
        }
      ],
      "requested_id": "0112038-9"
    },
    "blocked": false,
    "pages_opened": 1,
    "proxy_traffic_bytes": 52535
  },
  "total_points": 5
}

The call cost 5 points, shown in total_points. The source page lists that as $5 per 1,000 lookups, charged only when the company resolves; a Business ID that finds nothing is not billed.

Reading the response as a KYB reviewer would

• —Existence and state: registration_number, name, status ("Active") and termination_date (null here). The url links back to the record on the register, which is what you attach to a case file.
• —Entity type and place: company_type and incorporation_date, plus address and postal_address. The postal address differs from the street address, a reminder that a mismatch is not automatically a red flag.
• —Names: previous_names, parallel_names and auxiliary_names. A name comparison needs more than an exact string match, since an applicant calling itself "Nokia Corporation" appears on the register as Nokia Oyj with that as a parallel name.
• —Registrations: the trade register and the Tax Administration, each with a status and start date.
• —Adverse text: tax_debt returns the register's own wording about taxes owed and filing negligence. The source page says these are text, not figures, so display them rather than parse them.
• —History: business_id_history records events such as a merger, with the related Business ID.

What the record does not contain matters as much: no shareholders, directors or beneficial owners. The source page notes that some fields can be null depending on what the register holds, and that the record covers one company per request. For a Finnish counterparty, ownership evidence has to come from elsewhere, such as other filings, applicant documents or your own review. A KYB build that assumes every register returns the same fields will have holes in the countries you looked at last.

The illustrative version for Acme Oy

Suppose Acme Oy, a fictional Finnish company, applies to sell on your marketplace. Your pipeline calls the lookup with the Business ID from the form and compares the result with what was typed. A non-active status, a different company_type, or no name resembling the submitted one sends the application to review. A clean match gets stored with the url and retrieval date, and moves on to your ownership and screening steps. This is an illustration of the flow, not a claim about a real company.

Where the other countries fit

The same call pattern works for other registers. In the catalog, the corporate registry category holds 93 sources across Europe, the Americas and Asia-Pacific, plus global LEI lookups. That is not 93 countries: most countries have a company lookup by identifier and a name search, and some add a source for filings or documents. What differs is what each register publishes, so read the source page for your country before assuming a field exists.

Name search sources exist because applicants do not always give you a number: a search takes a company name and returns candidates with identifiers you can pass to the company lookup. Searches are billed per returned record, and the data source catalog lists every registry source with its point cost.

REST and MCP

The Finnish lookup above is one call that can be made two ways. Over REST the endpoint is run-fi-companies, called with the request shown. As a tool on the hosted MCP server (https://mcp.neuralverge.ai/mcp) the name uses underscores, run_fi_companies, and takes the same argument, company. The response envelope is the same in both cases, and so is the point cost. Setup for Claude and other clients is covered in the MCP server for Claude guide; parameters are in the documentation.

REST fits a pipeline that knows where a registry check belongs, such as onboarding or a fixed monitoring schedule. MCP fits a task where the next step depends on the last result: an agent that reads a record, notices a parent company in another country and asks that country's register next.

Cost and limits

Registry sources are priced in points, shown on each source page. The Finnish lookup above is 5 points, charged only when the company resolves. Points come out of your monthly plan allowance, which starts at 50,000 points for $50 a month on the Base plan, so adding a country does not mean a new contract. Search and filing sources are charged per returned record, so their cost scales with how many results you pull. The pricing page has the current plans.

The limits:

• —Registers are only as current as their filings. A record is read at request time, but a recent change may not be filed yet.
• —Coverage is not uniform. Ownership and beneficial-owner data in particular is published in some places and restricted in others.
• —A registry is not a screening list. Sanctions and politically-exposed-person screening are separate products.
• —A registry is not identity verification. It tells you about the entity, not whether the person on your signup form is who they claim to be.
• —Treat a failed or empty lookup as an outcome your workflow handles, not an exception that crashes onboarding.

The largest cost in most KYB builds is the review queue, the audit trail and the exception handling for thin registers. A consistent data layer shrinks only part of that. What you must collect, retain and decide is a question for your compliance team or counsel.

How to decide

Check these against the countries you will actually see, and note where KYB data tends to be used:

1. —Which registers do you need, and are they covered? List where your applicants come from, not where you hope to expand.
2. —What fields does each register publish? Note where officers, shareholders or beneficial owners are absent.
3. —Does every response carry the source link? A reviewer should be able to open the register page the fact came from.
4. —How does the source handle a miss? A company that does not resolve should come back as a clear empty result, ideally not charged.
5. —Can you resolve a name to an identifier? If applicants give names, you need a search source per country.
6. —Is the cost predictable at your volume? Price a realistic month, including searches and re-checks.
7. —Can you re-run checks on a schedule and diff the results? Ongoing monitoring catches a status change, a name change or a merger; the Finnish record's business_id_history is an example of the kind of event that matters.
8. —Where do ownership and screening come from if the register does not supply them?
9. —Have you asked your compliance team or counsel what is required? What you must collect, retain and decide is a legal question for your jurisdiction and industry.

The same checks apply to fintech onboarding, marketplace seller verification, vendor due diligence and agent-driven workflows. Running ten counterparties you already know through a candidate source beats reading a feature list.

Frequently asked questions

What does KYB stand for?

KYB stands for know your business. It is the process of confirming that a company is a real, legally registered entity, understanding who stands behind it, and noting anything that looks like a risk before you start working with it.

What is the difference between KYB and KYC?

KYC (know your customer) verifies an individual: who they are and whether the identity they present is genuine. KYB verifies a legal entity: whether it exists, what its status is, and which people own or control it. A KYB process usually ends up including KYC-style checks on those people.

Is a company registry lookup enough to complete KYB?

Usually not on its own. A registry confirms legal existence, status and often officers, which is the foundation. Most programs also look at ownership, screening lists and other signals, and the exact requirements depend on your jurisdiction, your industry and your own risk policy. Ask your compliance team or counsel what applies to you.

Do all countries publish the same company data?

No. Each national register publishes different fields. Some include officers, some include filed accounts, a few include shareholders or beneficial owners, and many keep ownership data restricted. A KYB workflow has to expect that the same question gets a fuller answer in one country than in another.

Can KYB checks be automated?

The data-gathering part can be, because registry lookups are ordinary requests that return structured data. The decision part, such as whether a case needs manual review, depends on your policy and often needs a human. A common pattern is to automate fact collection and route anything unusual to a person.

Can an AI agent run a registry lookup for KYB over MCP?

Yes. The Finnish lookup in this article is the tool run_fi_companies on the hosted MCP server, with the same arguments as the REST call, and every other registry source is a tool in the same way. An agent can read a record and decide which register to ask next. Which results need a human review is still a decision for your compliance team and your policy.

What does a registry lookup cost on NeuralVerge?

The Finnish YTJ lookup shown in this article costs 5 points per resolved company, which the source page lists as 5 dollars per 1,000, and a lookup that finds nothing is not billed. Other registry sources have their own point costs listed on their source pages.