Registry lookup
Didit connects to company registries in supported countries to retrieve official data. The lookup is triggered automatically when the company name, registration number, and country are provided.Search types
Registry searches support two modes:| Mode | Description |
|---|---|
| Exact | Matches the company name or registration number precisely |
| Contains | Matches companies whose name contains the search term — useful when the exact legal name is unknown |
Search workflow
The registry lookup follows an asynchronous workflow:Search
Didit queries the registry with the provided company name, country, and optional registration number. The search runs asynchronously.
Poll results
Poll the search status until results are resolved. Large registries may take a few seconds to return results.
Select company
Review the returned companies and select the correct match. Didit links the selected company to the KYB check and populates all available data.
Retrieved data
| Field | Description |
|---|---|
company_name | Legal name as registered with the authority |
registration_number | Official company registration or incorporation number |
country_code | Country of incorporation (ISO 3166-1 alpha-3) |
company_type | Legal entity type (Ltd, LLC, PLC, SA, GmbH, SL, etc.) |
registry_status | Current company status from the registry (active, dissolved, struck_off, etc.) |
incorporation_date | Date the company was originally registered |
registered_address | Official registered office address |
tax_number | Tax identification number where available |
alternative_names[] | Trade names, dbas, former legal names |
legal_entity_identifier | LEI — for financial institutions and listed entities |
nature_of_business | Short description of the business (in the registry’s language) |
registered_capital | Authorized / issued capital as an {amount, currency} object |
location_of_registration | City / subdivision of the registry of record |
control_scheme | Control / governance scheme where the registry exposes it |
website, email, phone | Contact details on file with the registry |
addresses[] | Additional registered or trading addresses |
industries[] | Industry classification codes (SIC, NACE, or local equivalents) |
accounts | Filing dates — due_by_date, last filed, and next filing date |
financial_summary | Summary financial data where the registry publishes it (revenue, employees, filing status) |
confirmed_by_user_at | Timestamp when the end user confirmed or edited the registry data |
last_console_edit_at | Timestamp of the last console-side edit by an analyst |
is_editable | true while registry-sourced data can still be edited by the end user in the hosted flow |
is_from_registry | true for registry-sourced companies, false for manual entry |
fetch_status | pending, resolved, or failed — registry lookup state |
verification_status | verified, failed, or unknown |
Company statuses
| Status | Description |
|---|---|
| Active | Company is currently active and in good standing |
| Dissolved | Company has been formally dissolved |
| Struck off | Removed from the register (e.g., for non-compliance) |
| In liquidation | Company is in the process of being wound up |
| Dormant | Registered but not currently trading |
Data source indicator
Each company record includes anis_from_registry flag:
true— data was retrieved from an official company registryfalse— data was manually submitted because the company was not found in the registry
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:| Field | Description |
|---|---|
registry_data | Raw payload returned by the registry. Immutable — kept as an audit record of exactly what the registry said, unchanged. |
user_provided_data | What the end user confirmed or edited during the registry-confirmation step in the hosted flow. |
Top-level canonical fields (company_name, registration_number, country_code, incorporation_date, etc.) | The merged truth — user-confirmed data when present, registry data as fallback. Downstream features (document OCR cross-check, AML screening, risk assessment) run against the canonical view. |
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.
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
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 nameslegal_entity_identifier(LEI) — for financial institutions and listed entitieswebsite,email,phone— contact information on file with the registrynature_of_business— short description (in the language of the registry)registered_capital— authorized / issued capital as an{amount, currency}object
business block of the KYB decision.
Confidence and verification status
Each registry response carries averification_status:
| Value | Meaning |
|---|---|
VERIFIED | Registry returned a match and data was retrieved. |
FAILED | Registry returned a match but data retrieval failed (e.g. partial response). |
UNKNOWN | Company could not be located in any registry. |
is_from_registry to drive your own downstream logic:
is_from_registry | verification_status | Meaning |
|---|---|---|
| true | VERIFIED | Fully verified against official registry |
| true | FAILED | Partial — some fields may be stale or missing |
| false | UNKNOWN | User-provided data only; no registry match |
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.
Risk assessment
The company’s overall risk level is calculated based on:| Factor | Impact |
|---|---|
| Company status | Non-active companies increase risk |
| Country risk | Incorporation in high-risk jurisdictions increases risk |
| Age | Recently incorporated companies may receive additional scrutiny |
| AML results | Company-level AML screening results |
| Ownership complexity | Multi-layered or opaque ownership structures |
Supported countries
Coverage varies by country — see supported countries for the per-region tier breakdown.Next steps
Ownership
UBO identification and ownership chains.
Response schema
Where each field appears in the payload.
Supported countries
Coverage by region.