Your Product Onboards Businesses. Now What?

Your platform signs up companies. Maybe it's merchants. Maybe it's suppliers, partners, or corporate clients. At some point, someone from legal or compliance walks over and asks:

And suddenly you're Googling acronyms, reading regulation summaries written for bank examiners, and wondering how this affects your sprint backlog.

This guide is not for compliance officers. They already know what KYB is. This guide is for the developer or product manager who needs to understand KYB well enough to spec a feature, evaluate an API, or push back on a vendor who's overcharging for basic registry lookups.

We'll cover what KYB actually requires you to build, what data you get from government registries (and where the gaps are), and how to decide whether to roll your own verification or plug into an API.

No sales pitch. No regulatory wall of text. Just the parts you need to ship.

KYC vs KYB: The 60-Second Version

KYC (Know Your Customer) verifies individuals. KYB (Know Your Business) verifies companies.

That's the textbook answer. Here's the one that matters for your architecture:

That's why KYB is harder to build — and why most teams underestimate it.

The 5 Components of KYB (What You Actually Need to Build)

Every KYB implementation, whether homegrown or API-driven, has five components. Skip any of them and your compliance team will send it back.

What Registry Data Actually Looks Like Across Jurisdictions

This is where most "KYB explained" articles stop. They tell you what KYB is but not what the data looks like when it comes back from a real registry. Here's what you'll actually encounter:

KYB Workflow Architecture

Here's how a production KYB flow typically works. This is the diagram your engineering team needs.

Sample API Flow

# Step 1: Search for company
POST https://api.zephira.ai/v2/companies/search
Body: { "name": "Acme Holdings", "country": "GB" }
→ Returns: company_id, registration_number, status, legal_form

# Step 2: Get full company profile
GET https://api.zephira.ai/v2/companies/{company_id}
→ Returns: registered address, directors, shareholders, financials

# Step 3: Get ownership structure
GET https://api.zephira.ai/v2/companies/{company_id}/ownership
→ Returns: shareholder tree with parent entities and UBO candidates

# Step 4: Start monitoring for changes
POST https://api.zephira.ai/v2/companies/{company_id}/watch/start
→ Triggers alerts on status changes, director updates, ownership transfers

Build vs Buy: When to Roll Your Own KYB

This is the decision your team is actually making. Here's a framework:

The honest answer: If you operate in one country (say, UK only), connecting directly to Companies House is free and straightforward. The moment you add a second jurisdiction — Germany, the US, Singapore — the normalization burden grows exponentially.

Most teams that start by building in-house end up buying within 12 months. The registry maintenance cost alone justifies the switch.

Edge Cases That Break KYB at Scale

Your happy path works. Here's what breaks it:

Dormant companies. A company can be legally registered but operationally inactive. Some registries mark this; most don't. You need business activity signals (web presence, financial filings, employee count) to distinguish real businesses from paper entities.

Nominee directors. In some jurisdictions, the listed director isn't the real decision-maker. They're a professional nominee — a placeholder. Your UBO logic needs to account for this, especially in offshore jurisdictions like BVI, Cayman, and Cyprus.

Jurisdictions with no digital registry. Not every country has an API or even a searchable database. Parts of Africa, the Middle East, and Central Asia still require manual document requests. Your workflow needs a fallback for these.

Name mismatches. "Société Générale S.A." in the French registry vs. "Societe Generale" in your CRM. Transliterations, abbreviations, accent marks, and legal form suffixes all create matching problems. Fuzzy matching helps, but registration numbers are the only reliable identifier.

Circular ownership. Company A owns 60% of Company B. Company B owns 40% of Company A. Your UBO traversal logic needs a cycle detection mechanism or it will loop forever.

Recently dissolved entities. A company that was active last week might be dissolved today. Point-in-time checks miss this. You need monitoring — or at minimum, re-verification at key transaction moments.

Frequently Asked Questions