Localized Onboarding with Conduit

No two countries have the same KYB requirements. 

That’s not criticism or a complaint, it’s a reality. When onboarding customers from around the world, the disparities become obvious quickly.

The US wants an EIN in a specific format. Brazil wants a different tax ID and a different registry document. Ownership-declaration thresholds differ. The documents that prove a company is real and who controls it differ. The people you have to name, and how you have to verify them, differ. On and on. 

Unfortunately, when onboarding a customer you are almost certainly faced with a giant list of KYB fields, document requirements and persona checks that fulfill the requirements of every market, regardless of what the requirements in your customer’s market really are. 

We set out to change that with localized onboarding, with a per-jurisdiction rulebook maintained by us and exposed through a discovery endpoint. 

What is localized onboarding

Conduit’s per-jurisdiction rulebook keeps a record of what every country requires for KYB. This means that one call –

GET /v2/onboarding/requirements?country=BR

– returns exactly what that country requires, and nothing else. 

• fields — the data to collect, as machine-readable specs: each field's name, human label, type, whether it's required, and its validation constraints with examples. For the US that's an EIN with its exact XX-XXXXXXX pattern; other countries return their own tax-ID formats, legal-structure options, and address rules.
• documents — the KYB document checklist for that jurisdiction: articles of incorporation in one country, a commercial registry extract in another. Canonical types, titles, minimum counts.
• individualRequirements — the people rules: which roles must be declared, how many, at what ownership threshold (for example, owners above 25%), and which identity documents each of them needs.

Your integration renders its onboarding form directly from that response – you never hardcode the requirements. 

As requirements vary by country and change over time, your onboarding form continues to request only what is needed to get your customer into your product, quickly and compliantly. 

Why it matters

Localized onboarding has a few powerful benefits:

Market expansion without an engineering project. Whether you start onboarding businesses from Mexico or Brazil, you don’t need to build anything new. It’s the same endpoint with a different country code – the form renders itself. The localization burden sits with Conduit, permanently. This means launching in a new market is a parameter change, not a roadmap item.

Requirements evolve without breaking your flow. Regulations shift. When they do, the endpoint’s response changes, so your integration can pick it up automatically. Your contract is the discovery endpoint, not a PDF of requirements that could be stale a few weeks after you read it.

The form is always right. Because the field-level patterns, examples and enums come from the API, your UI validates the same way Conduit will. That means fewer rejected applications and much less back-and-forth with the businesses you’re trying to onboard.

Handled by Conduit

Collecting the right data is only half the story. The other half is what happens after, on the Conduit side. 

Onboarding is application-based and built to submit-and-listen. You don't manage a customer through a sequence of intermediate states. You submit one application – the fields, the uploaded document IDs, the ownership roster – and wait for a webhook. 

Conduit runs business verification, screening, and identity verification on every control person. On approval, a customer record is created automatically and delivered on the webhook. On rejection, a human-readable reason comes back. Nothing to poll.

A few details that make this a great experience to build on:

• Verification can take seconds or days depending on review, but your integration doesn't change — it's the same webhook either way.
• A rejection isn't a dead end. Fix the data and resubmit under the same client reference, and every attempt stays correlated.
• Duplicate protection is built in: a submission matching an active application's tax ID or control person is rejected up front, so you can't accidentally double-onboard the same business.

One API, from the ground up

Localization here isn't a feature bolted onto onboarding –  it's how the API is built. Orders expose their own requirements endpoint so you can confirm a conversion route and learn the required recipient fields before you create it. Virtual Accounts are added per-currency, each with its own document requirements. Payout purposes and supporting documents vary by corridor and amount, enforced with specific, actionable errors rather than silent failures. Travel Rule is a first-class step in the transfer lifecycle, worldwide.

Same idea every time: ask the API what's required, render it, submit, and listen. The complexity of operating across jurisdictions stays where it belongs – with us.

Get started in the sandbox

Get your sandbox API keys today and start building with us.