"Verification" is used as though it were a single step. It is at least three, they establish different things, and they fail in different ways.
Conflating them is how you end up with a process that feels thorough and proves less than you think.
Identity verification: is this person who they claim to be?
The narrowest of the three, and the best understood. It normally combines:
- Document authenticity — is this a genuine passport or ID, or a manipulated image?
- Document validity — is it in date, and does it parse correctly?
- Biometric match — does the person presenting it match the photograph?
- Liveness — is there a real person present, rather than a photograph of one?
Where it fails: document coverage. Providers support the document types they have invested in, which correlates with the markets they sell into. A founder holding a passport from outside that set hits a check that cannot process their document — and the response is usually a generic failure rather than "we do not support this document", which leaves them with nothing to act on.
Company verification: does this entity exist as described?
This asks whether the legal entity is real and whether the details given about it match the official record.
The check is straightforward in jurisdictions with an open register. For a UK company you can confirm the number, the name, the status, the incorporation date, the registered office and the current officers directly against Companies House. Estonia's e-Business Register offers something similar.
Where it fails: staleness and jurisdictional variation.
A register extract is a snapshot. A company that was active when the document was produced may not be now. Directors change. Addresses change. The right question is not "does this document say the company is active" but "is the company active today", and answering it means going back to the source rather than trusting the artefact.
Variation is the bigger problem. Not every jurisdiction has a public register, and among those that do, the level of detail, the update frequency and the access model vary enormously. A verification process that assumes UK-quality data will produce confident results in some countries and silent gaps in others.
Beneficial-owner verification: who actually controls this?
The hardest of the three, and the one that matters most.
Identity verification tells you a person is real. Company verification tells you an entity is real. Neither tells you who ultimately controls the entity — which is the question anti-money-laundering regimes actually care about.
In the UK this is framed as Persons with Significant Control. Broadly, someone who holds more than 25% of shares or voting rights, who can appoint or remove a majority of the board, or who otherwise exercises significant influence.
Why it is hard:
Ownership can be layered. A UK company owned by a holding company owned by a foreign entity requires you to walk the chain until you reach natural persons. Each hop may cross a jurisdiction with different disclosure rules.
Registers are often self-declared. The PSC register records what the company told the registrar. It is a filing obligation, not an independent verification. Treating it as verified fact is a common and consequential mistake.
Control is not only shareholding. Someone with a small stake can hold control through agreements that appear in no register at all.
The chain has no natural end. You need a stopping rule, and it needs to be written down: how many layers you follow, what you do when you hit an opaque jurisdiction, and what happens when the chain cannot be resolved.
The three together
Run in sequence, each check constrains the next:
- Identity establishes that the individuals are real.
- Company verification establishes that the entity is real and current.
- Beneficial-owner verification connects them — which of these real people control this real entity.
The gap that matters is between steps 2 and 3. It is entirely possible to verify a company against an official register, verify every individual who signs up, and still not know who controls it, because control sits one layer up in an entity nobody looked at.
Why human review remains part of this
Each check produces evidence, not a verdict. The verdict is a judgement about whether the evidence is sufficient, and that judgement carries consequences.
The cases that need a person are predictable:
- The extracted data is internally inconsistent.
- The ownership chain cannot be fully resolved.
- The register data conflicts with the documents supplied.
- Something is technically valid but implausible.
A system that resolves these automatically is not more advanced. It is making a decision it does not have the information to make, and recording it as though it did.
Practical notes
A few things we have found worth doing:
- Record what you checked, against what, and when. "Verified" as a boolean is not defensible six months later. The evidence and its date are.
- Re-verify on a schedule. Ownership and officers change. A check from two years ago describes a company that may no longer exist in that form.
- Distinguish "could not verify" from "failed verification". They mean different things and warrant different responses. Collapsing them into one status loses the distinction exactly where it matters.
- Keep the source. When a decision is questioned later, you want the document and the page, not a field in a database.
Where this sits at Dorsko
Verification workflows are part of the infrastructure Dorsko is building, including under DorskoVerify, which is in development and not available to customers.
The design principle throughout is the one this article argues for: automate the reading, keep the deciding with a person, and record enough that either can be checked afterwards.