Company Data

When a business verification session starts, Didit queries official company registries to retrieve and validate company information. This automated lookup provides the foundation for the entire business verification process.

​

Registry lookup

Didit connects to company registries in supported countries to retrieve official data. In the hosted flow the user selects the country of incorporation and fills in the company name, the registration number, or both — at least one is required. Registration numbers are normalized where registries require it (for example, UK company numbers are zero-padded to eight digits), and when both identifiers are provided the registry lookup combines them.

​

Pre-filling the search with expected_details

If you already know the company, pass expected_details (company_name, registry_country, registration_number) when creating the session. The hosted flow pre-selects and locks the country (and the state for state-level registries like US-CA), pre-fills the matching search fields, and runs the asserted search automatically — the user lands directly on their company’s result. Both fields stay editable so the user can correct a wrong assertion. Prefill only: selecting a different company than asserted does not produce a warning.

​

Search types

Registry searches support two modes:

​

Search workflow

The registry lookup follows an asynchronous workflow:

​

Retrieved data

​

Company statuses

​

Data source indicator

Each company record includes an is_from_registry flag:

• true — data was retrieved from an official company registry
• false — data was manually submitted because the company was not found in the registry

The fetch_status field tracks whether the registry lookup has completed, failed, or is still in progress.

​

Registry data vs user-provided data

Didit keeps registry-returned data and user-confirmed data as separate audit records, with a merged canonical view used by downstream checks. Every company carries three related blocks: The confirmed_by_user_at timestamp marks when the end user confirmed or edited the registry data. While that timestamp is still null and is_editable is true, the end user can continue to modify fields inside the hosted flow. For manual-entry companies (is_from_registry: false), user_provided_data is the only source and is_editable becomes false after the user submits. Analysts can see the two sources side-by-side in the Business Console session review and diff what the registry said vs what the user confirmed.

​

Configurable registry form fields

You control which company-data fields the hosted verification flow asks for during the registry-confirmation step. Configure them in the Business Console: open the workflow editor, select the KYB Registry check node, and switch to the Fields tab. Each field has one of three states: Three fields are always shown and always required — they identify the company and cannot be configured: company_name, country_code, and region (state/region, where the registry is regional). The 16 configurable fields: registration_number, incorporation_date, legal_address, vat_number, alternative_names, tax_number, company_type, legal_entity_identifier, location_of_registration, nature_of_business, registered_capital_amount, registered_capital_currency, website, email, phone, control_scheme By default — and for all existing workflows — only incorporation_date is Required; every other configurable field is Optional, so the form behaves exactly as it did before this setting existed. Requiredness is enforced server-side: submitting the registry form with a required field empty returns 400 with per-field error messages, and the hosted UI renders only the enabled fields. In the workflow API, the setting is the kyb_registry_fields_config object on the KYB Registry node — see feature configs for the shape.

​

VAT validation (VIES)

When the end user (or the registry) provides a vat_number for a company incorporated in the EU, Didit validates it against the European Commission’s VIES service when the registry step is submitted.

• Coverage — the 27 EU member states plus Northern Ireland (XI). Greek VAT numbers are checked under the EL prefix automatically. Companies from any other country skip validation entirely and get vat_validation_status: "not_applicable".
• Prefix handling — the number is normalized before the check, so it can be submitted with or without the country prefix (DE123456789 and 123456789 are equivalent for a German company).

The result is stored on the company and exposed in the KYB decision payload: Name cross-check. When the number is valid and VIES discloses the registered trader name, Didit fuzzy-compares it against the submitted company name. A meaningful divergence raises the KYB_COMPANY_VAT_NAME_MISMATCH warning (with vies_name and submitted_name in additional_data) without changing the session status — it is a soft signal for reviewers. Some member states do not disclose the name or address; the fields come back empty and no comparison runs. Configurable actions. Two settings on the KYB Registry check node control what an unsuccessful check does to the session (values REVIEW, DECLINE, NO_ACTION): Each outcome also raises the matching warning (KYB_COMPANY_VAT_INVALID, KYB_COMPANY_VAT_COULD_NOT_VALIDATE) on the registry check — see Business Verification warnings.

​

Data cross-referencing

Didit automatically compares the user-provided / canonical data with what the registry returned, and with OCR data extracted from uploaded documents:

• Company name — fuzzy matching to account for abbreviations and formatting differences
• Registration number — exact match validation
• Country — consistency check between provided and registry country
• Address — geocoding and normalization for comparison

Any inconsistencies are flagged as warnings in the session and visible to analysts in the console.

​

Financial summary

Where available, Didit retrieves summary financial data from the registry:

• Revenue or turnover
• Number of employees
• SIC/NACE industry codes
• Filing dates and compliance status

​

Additional registry fields

Depending on jurisdiction coverage, the registry response may also include:

• alternative_names[] — trade names, dbas, former legal names
• legal_entity_identifier (LEI) — for financial institutions and listed entities
• website, email, phone — contact information on file with the registry
• nature_of_business — short description (in the language of the registry)
• registered_capital — authorized / issued capital as an {amount, currency} object

All fields land in the business block of the KYB decision.

​

Confidence and verification status

Each registry response carries a verification_status: Combine with is_from_registry to drive your own downstream logic:

​

Cross-referencing outputs

Each cross-reference runs per field and returns one of:

• MATCH — provided data agrees with registry.
• MISMATCH — meaningful divergence. Flagged as a warning.
• NO_DATA — one side was empty; no comparison possible.

Mismatches are visible per-field in the console session review.

​

Risk assessment

The company’s overall risk level is calculated based on: See risk assessment for the full computation.

​

Supported countries

Coverage varies by country — see supported countries for the per-region tier breakdown.

​

Next steps