How Vietnamese Fintechs Are Re-Wiring KYB Onboarding Around a Single Resolver Call

Why KYB Onboarding Breaks at the Form

A typical Vietnamese fintech KYB onboarding form asks the SME applicant to type the tax code, type the legal name, and type the registered address. Three points of failure, three points of drop-off. The KYB onboarding architecture that holds up under audit and under scale is one resolver call. Here is the pattern, and where it pays back.

The KYB Onboarding Data Picture

DataCore Company Services exposes the Vietnamese SME registry as a JSON API. The trial page lists 2,348,100 verified company records as of the most recent index (DataCore Company Services trial, 2026), accepting Tax Code, Company Name, or Phone Number as the resolution key. The response carries legal name, registered address, registered date, current status, and (where available) parent-subsidiary linkages.

Two underlying numbers shape the KYB onboarding design choice:

• Manual baseline. A back-of-envelope check of any VN credit team's queue shows manual lookups against the national tax portal absorb meaningful analyst time per record. Across a busy team, that is real headcount.
• Audit horizon. Decree 13/2023/NĐ-CP on personal data protection sets chain-of-custody expectations on processed data; Law 32/2024/QH15 on credit institutions adds vendor due-diligence reporting on top. The resolver response payload, persisted, is the audit artifact that satisfies both.

Three Architectural Choices for KYB Onboarding

1. Resolve at intake, not in batch. Call the API while the customer is still in the form. The user-typed value gets validated against the canonical record before the form submits, so the customer either sees a confirm screen or sees a "we could not find this company" prompt, not a rejection email three days later.
2. Store the canonical company ID, not the typed string. The user-typed name might be "Cong ty TNHH ABC" or "ABC Co., Ltd" or "ABC". The API resolves all three to the same ID. Persist the ID. De-dup downstream tables against ID, not text.
3. Persist the resolver payload as the audit artifact. Save the full JSON response, hashed, with a timestamp. When an examiner asks "what did this company look like on the day you onboarded them?", the answer is the persisted payload, not a re-fetch against today's state.

Five Steps to Ship This Quarter

1. Pick one KYB onboarding flow as the pilot, usually the SME credit application or the merchant-account application.
2. Wire the resolver call into the form's submit handler. Cache by tax code for 24 hours.
3. Add canonical_company_id and resolver_payload_id columns to the customer-master table.
4. Backfill historical records in batches of 1,000. Measure the dedup rate.
5. Wire the resolver into the credit-decisioning service so its rules can join on canonical_company_id.

VN Case Sketch (Illustrative)

A mid-sized VN fintech replaced a manual SME KYB onboarding form with a tax-code resolver call backed by the Company Services API. The first measured impact: drop-off at the form decreased meaningfully because the customer no longer re-typed the same fields three times. The second: the credit-risk team retired the "duplicate company under different name spellings" cleanup script that had run weekly for two years. (Pattern is illustrative; specifics anonymized.)

How DataCore Fits Into KYB Onboarding

DataCore Company Services is part of the broader DataCore Vietnam SME-registry dataset (DataCore datasets, 2026). The same canonical ID resolves into Cadastral Services for address geo-validation, Data & Datasets for fundamentals on listed parents, and Analytics for portfolio-level rollups. Pricing: Starter $19/mo, Dev $99, Pro $499, Enterprise custom, Academic VND 3M/mo for COR3, Scholars, and partner faculty (DataCore pricing page, 2026).

Getting Started With Resolver-Based KYB Onboarding

Pull the Company Services free trial, Tax Code / Name / Phone resolver, JSON response, 10 free queries per day. Pair with Cadastral Services for end-to-end address-plus-entity resolution. Implementation notes and weekly reads at DataCore News.

What KYB Onboarding Actually Requires

KYB onboarding, know-your-business, is the process of verifying that a company applicant is real, correctly identified, and safe to transact with. At minimum it confirms the legal entity exists, matches the name and tax code the applicant supplied, and is in good standing. Done well, KYB onboarding also captures the registered address, incorporation date, status, and beneficial-ownership or parent links, because those fields drive downstream credit and risk decisions.

The reason KYB onboarding is hard in Vietnam is fragmentation. The authoritative data lives in the national registry, but most teams reach it through manual portal lookups, copy-paste, and human re-keying. Every manual hop adds latency, error, and an audit gap. Collapsing those hops into one resolver call is what separates a KYB onboarding flow that scales from one that quietly breaks under volume.

Why the Single Resolver Call Wins

A resolver-based KYB onboarding design accepts one key, a tax code, company name, or phone number, and returns the full verified record in a single round trip. The applicant types one field instead of three, so there are fewer points of drop-off and fewer chances to introduce a typo that later forces a manual review.

The architectural payoff compounds. Because the resolver returns a canonical company identifier, every downstream system, credit scoring, address validation, portfolio rollups, joins on the same stable key. Teams that adopt this pattern routinely retire the fuzzy-matching scripts that previously tried to reconcile the same company under five different name spellings. KYB onboarding stops being a data-cleaning problem and becomes a single, auditable lookup.

Common KYB Onboarding Failure Modes

The failure modes are predictable once you look for them. Free-text entry produces name variants that never match cleanly. Manual portal checks introduce hours of latency and no audit trail. Storing only a pass or fail flag, rather than the full resolver payload, leaves nothing to show a regulator. And treating KYB onboarding as a one-time gate, rather than a record that can be refreshed, means stale data quietly accumulates in the book.

Each of these is solved by persisting the structured resolver response. The payload itself, captured with a timestamp, becomes the artifact that proves what was verified and when, which is exactly what an auditor or partner asks for.

KYB Onboarding and Vietnam's Regulatory Expectations

Two instruments shape KYB onboarding obligations. Decree 13/2023/NĐ-CP on personal data protection sets chain-of-custody expectations for processed data, and Law 32/2024/QH15 on credit institutions layers vendor due-diligence reporting on top. Neither is satisfied by an informal portal check. Both are satisfied by a persisted, timestamped resolver payload that shows exactly which authoritative record informed each decision.

The practical lesson is to design KYB onboarding so that compliance is a by-product of the architecture rather than a separate reporting chore. If every verification automatically writes an immutable, dated record, the audit answers itself.

Measuring KYB Onboarding Performance

Three metrics tell you whether a KYB onboarding flow is healthy. Form drop-off measures how many applicants abandon during entry, and it falls sharply when re-typing is removed. Time-to-decision measures how long verification takes, and a resolver call compresses it from minutes of manual work to a single request. False-match rate measures how often the wrong entity is accepted, and it drops when matching runs against a canonical identifier rather than free text.

Track these before and after adopting the resolver pattern and the business case for KYB onboarding modernisation usually makes itself. The analyst hours saved, alone, often justify the change within a quarter.

Building KYB Onboarding That Scales With the Business

The first version of a KYB onboarding flow only has to work for a handful of applications a day. The version that matters is the one still working when volume is ten times higher and a regulator is reviewing the book. Designing for that future from the start costs almost nothing extra if the resolver pattern is in place, because the same single call serves one application or ten thousand.

Scale also changes what good looks like. At low volume, a manual fallback is tolerable; at high volume it becomes the bottleneck that defines your capacity. Teams that treat KYB onboarding as core infrastructure, rather than a form to be bolted on, find that the architecture absorbs growth instead of fighting it. The canonical identifier returned by each resolver call keeps the data layer coherent no matter how many products eventually read from it.

Finally, a scalable KYB onboarding design is one that other teams can build on without asking how it works. Clear payloads, stable identifiers, and persisted audit records mean the credit team, the risk team, and the compliance team all draw from the same verified source. That shared foundation is the quiet, compounding return on getting KYB onboarding right early.

Frequently Asked Questions About KYB Onboarding

What is the difference between KYB onboarding and eKYC?

eKYC verifies an individual; KYB onboarding verifies a business and the people behind it. They are complementary: a complete flow confirms both the company and its authorised representatives.

How long should KYB onboarding take?

With a resolver-based design, the core verification is effectively instant, a single API round trip, so the applicant experience is measured in seconds rather than the minutes or hours manual lookups require.

What data should a KYB onboarding flow store for audit?

Persist the full structured resolver response with a timestamp and the canonical company identifier. That payload is the artifact that satisfies both data-protection and vendor due-diligence requirements.

Sources

• DataCore Company Services trial page, 2026: https://datacore.vn/en/services/company-trial
• DataCore Services overview, 2026: https://datacore.vn/en/services
• Decree 13/2023/NĐ-CP, Personal Data Protection, 2023
• Law 32/2024/QH15, Law on Credit Institutions (revised), 2024
• Decree 94/2025/NĐ-CP, fintech sandbox, 2025

DataCore. Data Leads Future.