Company KYB API: Resolve LEI and SEC CIK, Then Check EU VAT

Know Your Business (KYB) checks typically mean three separate lookups across three different registries: GLEIF for the LEI, VIES for EU VAT status, and SEC EDGAR for US-listed entities. The Company KYB Resolver does the two identity lookups, GLEIF and EDGAR, in one call for a whole batch of names, and flags which entities are headquartered in the EU. The VAT check runs as a second call to the EU VAT Validator, so the full three-registry check is two runs rather than three integrations.

The three-registry problem

When onboarding a business counterparty, compliance teams typically need to cross-reference:

1. GLEIF: to get the Legal Entity Identifier and confirm the entity is registered and active under a recognised LEI issuer
2. VIES: for EU entities, to confirm VAT registration is valid in their claimed member state
3. SEC EDGAR: for US-registered or US-listed entities, to get the CIK number and access their filings

Each registry has its own API, its own schema, and its own quirks. A company may appear in one, two or all three, depending on where it is registered and whether it is regulated in the US.

Registry	What it verifies	Coverage
GLEIF (LEI)	Legal entity existence, status and jurisdiction	Over 2.5 million entities worldwide
EU VIES (VAT)	Active EU VAT registration	All 27 EU member states
SEC EDGAR (CIK)	US registered issuer	US-listed companies and other SEC filers

What the actor returns

One row per company you submit:

{
  "query_name": "Apple Inc",
  "lei": "HWUPKR0MPOU8FGXBT394",
  "lei_status": "ISSUED",
  "legal_name": "APPLE INC.",
  "country": "US",
  "entity_status": "ACTIVE",
  "is_eu_registered": false,
  "edgar_cik": "0000320193",
  "edgar_name": "Apple Inc. (AAPL)",
  "resolved": true,
  "scraped_at": "2026-08-01T23:00:00.000Z"
}

query_name is the name you sent, so rows join straight back to your input. resolved is true when either registry produced an identifier, which means a name that matched nothing still shows up as a row instead of quietly going missing.

edgar_cik is null for a private company, and that is deliberate. EDGAR full-text search returns filings that mention a name, and the filer is often a different company (a private firm can show up inside a public investor’s 10-K). The resolver only accepts a hit whose filer name matches the company you asked about. It returns nothing rather than the wrong CIK.

is_eu_registered comes from the GLEIF headquarters country checked against the 27 member states. It is a jurisdiction flag, not a VAT check. Use it to decide which rows need the VIES step.

Input options

Company names: pass a list in companies. GLEIF matches on the registered legal name, so the full legal form (“ASML Holding N.V.” rather than “ASML”) matches more reliably.

Country hint: set countryCode (for example ES) to restrict the GLEIF search to entities headquartered in that country. This is how you separate a parent from same-name national subsidiaries.

EDGAR on or off: set includeEDGAR to false for a European book where the SEC lookup adds time and no information.

If you already hold LEIs, go straight to the GLEIF LEI Lookup. If you already hold VAT numbers, go straight to the EU VAT Validator.

Python example

No SDK needed. This starts a run over the Apify REST API, polls until it finishes, and reads the dataset:

import os
import time
import requests

API = "https://api.apify.com/v2"
HEADERS = {"Authorization": f"Bearer {os.environ['APIFY_TOKEN']}"}


def run_actor(actor_id: str, run_input: dict) -> list[dict]:
    run = requests.post(f"{API}/acts/{actor_id}/runs",
                        headers=HEADERS, json=run_input).json()["data"]
    while run["status"] in ("READY", "RUNNING", "TIMING-OUT", "ABORTING"):
        time.sleep(5)
        run = requests.get(f"{API}/actor-runs/{run['id']}", headers=HEADERS).json()["data"]
    if run["status"] != "SUCCEEDED":
        raise RuntimeError(f"Run ended with status {run['status']}")
    items = requests.get(f"{API}/actor-runs/{run['id']}/dataset/items", headers=HEADERS).json()
    return [i for i in items if i.get("_type") != "summary"]  # drop the run summary row


entities = run_actor("themineworks~company-identity-resolver", {
    "companies": ["Apple Inc", "ASML Holding N.V.", "SAP SE"],
})

for e in entities:
    print(e["query_name"], "resolved" if e["resolved"] else "no match")
    print(f"  LEI: {e['lei'] or 'not found'} ({e['lei_status'] or 'n/a'})")
    print(f"  EU HQ: {e['is_eu_registered']}")
    print(f"  CIK: {e['edgar_cik'] or 'not found'}")

Enrich a counterparty list

Resolve a whole CSV, flag the names no registry recognises, then run VIES only for the EU-headquartered rows that have a VAT number on file:

import pandas as pd

df = pd.read_csv("counterparties.csv")  # needs company_name, and vat_id where you have one
names = df["company_name"].dropna().unique().tolist()

resolved = pd.DataFrame(run_actor("themineworks~company-identity-resolver", {"companies": names}))
merged = df.merge(resolved, left_on="company_name", right_on="query_name", how="left")

unmatched = merged[merged["resolved"] != True]
print(f"{len(unmatched)} counterparties returned no registry match")

# Second step: VAT validity for EU entities
eu = merged[(merged["is_eu_registered"] == True) & merged["vat_id"].notna()]
vat = pd.DataFrame(run_actor("themineworks~eu-vat-vies-validator",
                             {"vatIds": eu["vat_id"].tolist()}))
print(vat[["vat_id", "valid", "status", "name"]])

Send VAT IDs with their two-letter country prefix (DE811569869). A status of unavailable or service_error means that member state’s VIES service was down, not that the number is invalid, so re-check those later.

Use cases

Counterparty onboarding: one call confirms legal name, LEI status and SEC presence before you execute any contract. Add the VIES step for EU counterparties.

Supplier master data: enrich your ERP supplier records with LEI and CIK, plus VAT validity for EU suppliers, so every payment and purchase order references a verified legal identity. Suppliers with no registry presence at all are worth a closer look.

Accounts payable fraud prevention: check that a new vendor registration matches a real registered entity before it is approved for payment.

Fintech account opening: put entity resolution in the business onboarding flow as the automated first layer of KYB, ahead of manual review.

Trade finance: confirm counterparty identity before issuing letters of credit or financing a shipment. Banks increasingly ask for an LEI on the parties to a transaction.

Investment due diligence: for target companies, get the LEI (for transaction reporting) and CIK (SEC filings access) in one step before you pull their 10-K or 20-F, and VAT status if they operate in the EU.

AML/CFT screening pipelines: use the LEI as a stable identifier to deduplicate entities across watchlist screening results, since trading names and legal names often differ.

AI agent tooling: expose the actor as an MCP tool so AI agents can answer questions like “what is the SEC filing CIK for this counterparty?” or “is this company headquartered in the EU?” from the registries instead of from memory. Ask a model for a CIK without that and it will often invent one.

How it relates to the component actors

The Company KYB Resolver covers identity across GLEIF and EDGAR. For the full LEI record, use the GLEIF LEI Lookup. For live VAT validity with the registered name and address, use the EU VAT Validator. For a company’s actual filing history, use SEC EDGAR Filings. Use the resolver when you want identity for a list of names in one run, and the individual actors when you only need one registry.

Pricing

Pay per company looked up, see pricing. No API keys required. GLEIF, VIES and SEC EDGAR are all publicly accessible.

---

Run Company KYB Resolver on Apify →