Know your business (KYB)

KYB, short for know your business, is the set of checks a company runs on a business it is about to work with. The question it answers is whether the counterparty is a real legal entity, whether it is active, and whether the details on file match the official register. Banks, payment providers, marketplaces, lenders and procurement teams all run some version of it before they open an account, release a payout or issue a purchase order.

The letters come from KYC, know your customer, which is the same idea applied to people. KYB is the business half of that work.

A register-data KYB check is a short list of questions, each with a source:

1. Does the entity exist? The name or number resolves to a record in an official register.
2. Is it active? The register reports active, dissolved or in liquidation.
3. Does it match? The legal name, address and identifiers you hold agree with the register.
4. Who runs it? The officers or directors the register publishes, with roles and appointment dates.
5. Can you trace it? Each fact carries the source it came from and when it was retrieved.

Questions 1 to 3 come from the register and are what Corpo API returns. Question 4 comes from the register's own officer records. Question 5 is provenance, and it is what makes the result usable in an audit file.

The two are complements. A KYB flow confirms the entity. A KYC flow confirms the people behind it. Most onboarding programs run both, and the register step is the one with a public, authoritative source behind every answer.

You can run a KYB check with a company name alone, but the result is stronger with more:

• The legal name, spelled as the register spells it
• The registration number, which turns a fuzzy name match into an exact lookup
• The registered address or postcode
• The VAT number, for a European counterparty
• The names of the officers you were given

A company number makes the check exact. A name alone usually finds the company, but two businesses can share a name in different registers, so it pays to resolve the number first and check against the number after.

The entity step is the /v1/verify endpoint. You send what you know. It resolves the company in the register and returns a verdict plus the result of each check.

curl -X POST https://api.corpoapi.com/v1/verify \
  -H "Authorization: Bearer ck_live_..." \
  -d '{"jurisdiction": "se", "company_number": "5560129206", "expected": {"legal_name": "Ahlsell Sverige AB", "status": "active"}}'

The response has three parts: the verdict (verified, partial or mismatch), a list of the checks that ran with what each found, and the company record the match resolved to. A company number resolves exactly. Names are compared on a normalised form, with trigram similarity for near matches. When a check cannot run, for example a VAT number the register does not store, the verdict is partial rather than a false mismatch.

Billing follows the answer. A 200 that returns a company is one verified company. A not-found or ambiguous result is free, so a call that finds nothing costs nothing.

The register record below is the one our own API returns for Swedish organisation number 5560129206. It is a real, active company from the Swedish company register, retrieved through the company endpoint and used in our own end-to-end checks.

{
  "jurisdiction": "se",
  "company_number": "5560129206",
  "legal_name": "Ahlsell Sverige AB",
  "status": "active",
  "company_number_scheme": "SE-ORGNR",
  "legal_form": { "code": "AB-ORGFO", "name_en": "Limited company" },
  "identifiers": ["SE-ORGNR", "EU-VAT"]
}

The same register holds dissolved entities, which is why a status check earns its place:

{
  "jurisdiction": "se",
  "company_number": "7720001457",
  "legal_name": "Nordic Build Supply AB",
  "status": "dissolved"
}

A check that only confirms the name exists passes both of these. A check that also reads status tells them apart.

Merchant onboarding uses the same entity step. A merchant signs up with a trading name, and the flow has to tie that name to a real registered company before payments are switched on. That is verify, run inside the signup rather than in a manual review queue. Self-serve merchants need the answer inside the signup request, which is why bulk registers return in under a second and live registers are read on request.

The entity step is the entity half of due diligence. Sanctions and politically exposed person screening, identity verification of directors, and document checks run alongside it in your existing stack. Corpo API is the register-data layer underneath them: official company facts, officer records and provenance, without a per-country connector to build.