TL;DR: KYB (Know Your Business) is the corporate counterpart to individual KYC, extending anti-money laundering laws to business entities. It rests on four pillars: company verification, UBO identification, sanctions screening, and ongoing monitoring. Most implementations break at the UBO layer. This post walks through why, and how to architect around it.
Most fintech teams discover KYB compliance the hard way: when their first enterprise client's complex ownership structure breaks their onboarding flow, or when a regulatory audit reveals gaps in their business verification process. The cost is not just operational friction. It is regulatory penalties and reputational damage that compound as you scale.
I have watched this play out dozens of times. A team builds a slick consumer KYC flow, ships it, then gets their first request to onboard a corporate client with three layers of holding companies across two jurisdictions. Their system falls over. Not because the engineering is bad, but because nobody architected for the reality of business verification.
Let me walk you through what KYB actually involves from an implementation perspective, where the complexity hides, and how to avoid the mistakes we see most often.
KYB is not just KYC for companies
It is tempting to treat KYB as "run the same checks, but on a company instead of a person." That mental model will cost you months of rework.
KYB verification is mandatory for banks, fintechs, NBFCs, marketplaces, payment aggregators, and B2B platforms that onboard business entities. The core requirements include CIP (Customer Identification Programme) for business entities, CDD (Customer Due Diligence) risk assessment, and sanctions screening against OFAC, UN, and EU watchlists. Payment providers must also comply with PSD2 and EMD requirements alongside cross-border payment regulations.
The critical use cases where KYB applies: corporate account opening, commercial lending applications, merchant payment processing requests, vendor onboarding, and B2B SaaS platform registration. If your platform onboards businesses in any of these contexts, KYB is not optional.
The four-pillar framework
KYB rests on four foundational elements. Most teams get the first one right and underestimate the remaining three.
1. Company verification
Confirm the entity legally exists. This means validating certificates of incorporation, business registration numbers, and licences against authoritative registries. In the UK, Companies House now mandates identity verification at incorporation and for new directors as of November 2025, which improves registry data quality, but independent checks are still required.
From an API perspective, this is the straightforward part. You call a registry API, match the returned data against what the applicant submitted, flag discrepancies.
interface CompanyVerificationResult {
registryMatch: boolean;
companyName: string;
registrationNumber: string;
jurisdiction: string;
incorporationDate: string;
status: 'active' | 'dissolved' | 'suspended' | 'unknown';
discrepancies: string[];
}
async function verifyCompany(
registrationNumber: string,
jurisdiction: string
): Promise<CompanyVerificationResult> {
const registryData = await registryClient.lookup(
registrationNumber,
jurisdiction
);
const discrepancies: string[] = [];
if (registryData.status !== 'active') {
discrepancies.push(
`Company status is ${registryData.status}, not active`
);
}
return {
registryMatch: discrepancies.length === 0,
companyName: registryData.name,
registrationNumber,
jurisdiction,
incorporationDate: registryData.incorporatedOn,
status: registryData.status,
discrepancies,
};
}
Straightforward. The problems start at pillar two.
2. UBO identification
This is where most implementations fail. Ultimate Beneficial Owner identification means mapping ownership structures down to the controlling individuals, typically anyone holding 25% or more ownership (the standard threshold globally, including under the UK's Money Laundering Regulations 2017). You then run layered KYC on those individuals.
The difficulty is not the threshold. It is the nesting.
A company is owned 40% by another company, which is owned 60% by a trust, which has three beneficiaries across two countries. Your system needs to recursively resolve that structure, identify the natural persons at the bottom, and run identity checks on each of them.
interface OwnershipNode {
entityId: string;
entityType: 'company' | 'individual' | 'trust' | 'fund';
name: string;
jurisdiction: string;
ownershipPercentage: number;
children: OwnershipNode[];
}
interface UBOResult {
individual: string;
effectiveOwnership: number;
jurisdictions: string[];
requiresKYC: boolean;
}
function resolveUBOs(
node: OwnershipNode,
parentOwnership: number = 100,
threshold: number = 25
): UBOResult[] {
const effectiveOwnership =
(node.ownershipPercentage / 100) * parentOwnership;
if (node.entityType === 'individual') {
return [
{
individual: node.name,
effectiveOwnership,
jurisdictions: [node.jurisdiction],
requiresKYC: effectiveOwnership >= threshold,
},
];
}
return node.children.flatMap((child) =>
resolveUBOs(child, effectiveOwnership, threshold)
);
}
In practice, this gets messier. Circular ownership structures exist. Some jurisdictions do not disclose beneficial ownership data. Some entities deliberately obscure their structure. This is exactly why KYB is critical for detecting shell companies and fraudulent entities: systematic UBO resolution surfaces what manual processes miss.
A Head of Engineering at a European payments company told us: "We spent four months building our own UBO resolution logic. It handled maybe 70% of cases. The remaining 30%, the multi-jurisdictional nested structures, took another six months and we still had edge cases."
3. Sanctions screening
Every entity, director, and resolved UBO must be screened against global watchlists: OFAC, UN, EU sanctions lists, plus PEP databases and adverse media sources. This combines business verification with AML checks to maintain secure payment ecosystems.
The technical challenge here is not the initial screen. It is the false positive rate. Name matching across transliterations, common names, and partial matches generates noise. AI-driven screening is increasingly used to reduce false positives, but tuning the sensitivity is an ongoing engineering problem, not a one-time configuration.
4. Ongoing monitoring
KYB extends beyond initial verification to continuous tracking of corporate structure changes, director replacements, and ownership shifts. This is the pillar most teams defer and most auditors flag.
From an architecture perspective, you need webhook-driven monitoring that triggers re-verification when material changes occur:
interface CorporateChangeEvent {
entityId: string;
changeType:
| 'director_added'
| 'director_removed'
| 'ownership_change'
| 'status_change'
| 'address_change';
previousValue: string;
newValue: string;
detectedAt: string;
source: string;
}
interface MonitoringAction {
entityId: string;
action: 'rescreen' | 'flag_review' | 'suspend' | 'no_action';
reason: string;
priority: 'high' | 'medium' | 'low';
}
function evaluateChange(
event: CorporateChangeEvent
): MonitoringAction {
const highPriorityChanges: CorporateChangeEvent['changeType'][] = [
'ownership_change',
'status_change',
];
if (highPriorityChanges.includes(event.changeType)) {
return {
entityId: event.entityId,
action: 'rescreen',
reason: `Material change detected: ${event.changeType}`,
priority: 'high',
};
}
return {
entityId: event.entityId,
action: 'flag_review',
reason: `Non-critical change: ${event.changeType}`,
priority: 'medium',
};
}
Where this gets hard at scale
Fintech platforms use KYB for merchant onboarding, PSP validation, and business partner verification. The challenge is balancing fast onboarding requirements with comprehensive AML screening and risk scoring, particularly for cross-border payment compliance.
When you are onboarding ten merchants a month, you can handle edge cases manually. When you are onboarding hundreds, every unhandled ownership structure, every false positive in sanctions screening, every missed director change becomes a scaling bottleneck.
Managing KYB across multiple data sources and regulatory frameworks requires orchestration platforms that can coordinate company verification, UBO mapping, and sanctions screening in a unified workflow. This is what we built Zenoo to solve: the orchestration layer that sits between your onboarding flow and the dozen data providers you need to call, so your engineering team is not rebuilding compliance infrastructure from scratch.
What actually matters
If you are building KYB into your platform, here is what I would focus on:
Architect for UBO depth from day one. Do not treat it as a v2 feature. Your data model needs to support recursive ownership structures, and your UI needs to present them clearly to compliance reviewers.
Separate your screening logic from your verification logic. They change at different rates. Sanctions lists update daily. Your company verification flow might not change for months. Decoupling them saves you from redeploying your entire onboarding pipeline every time OFAC publishes an update.
Build ongoing monitoring as a first-class concern, not a cron job. Event-driven architecture handles corporate changes far better than periodic batch rescreening.
Expect false positives in sanctions screening. Budget engineering time for tuning, not just implementation. The compliance team will thank you.
KYB is infrastructure. Treat it with the same seriousness you would give your database or payment processor. The teams that get this right early scale without hitting regulatory walls. The ones that bolt it on later spend months unpicking technical debt under audit pressure.
If you are building compliance flows and want to see how orchestrated KYB works in practice, check out zenoo.com.
Stuart Watkins is CEO of Zenoo, the compliance orchestration platform for fintechs and financial institutions.
