Worked example: KYB & data validation

spotit supplies registry facts with a filing reference attached. It is not a screening vendor — it gives your screening vendor clean keys to work from, which is the part that usually goes wrong.

The check, in one call and one read

1. Resolve the customer-supplied name and country. Require matched_on of register or vat for an automated pass; anything else goes to review.
2. Read the entity and assert on status, legal_form, registered_address and the identifier the customer gave you.
3. Read lineage and store the filing reference and publication date alongside your decision. That is your evidence, and it is free.

{
  "decision": "pass",
  "checked_at": "2026-09-05T11:04:22Z",
  "entity_id": "ent_01JR8K3F5T2QW9",
  "assertions": {
    "exists": true,
    "status": "active",
    "vat_matches": true,
    "legal_form": "GmbH"
  },
  "evidence": {
    "register": "HRB 148902",
    "authority": "Amtsgericht Hamburg",
    "document": "src_de_hrb_148902_2026_0118",
    "published": "2026-01-18"
  }
}

Where the median lands

2.1 seconds end to end for DE, CH and GB, almost all of it your own orchestration rather than our latency. Tier 2 markets are slower only because more cases fall to review.

What this is not

Not sanctions screening, not PEP, not adverse media, not a credit bureau, and not a consumer reporting agency under the FCRA. The Acceptable Use Policy is explicit about it because the failure mode is expensive.

The useful pattern is upstream: resolve first, hand your screening vendor a clean LEI, VAT or EUID, and their false-positive rate falls because they are no longer screening a misspelled string.

Re-checking without re-paying

Subscribe the entities you have onboarded to entity.status_changed and entity.insolvency_filed. A periodic review becomes an event stream, at 0.05 credits per delivered event rather than a full re-resolve of the book. See watch and webhooks.