Take me through onboarding a company rather than a person. Where does beneficial ownership make it hard?

Three verifications, not one

Onboarding a person is one identity problem. Onboarding a company is three, and candidates who answer this well separate them from the first sentence, because they have different evidence, different failure modes and different owners inside a bank.

The first is that the entity exists and is what it says it is: incorporated, in the jurisdiction claimed, currently active rather than dissolved or struck off, with the name and registered number you were given and a registered address that is not obviously a mailbox shared with a thousand others. The second is who ultimately owns and controls it, which is the beneficial ownership question and the hard one. The third is who may act for it — the directors, the signatories, the people who will move money — and by what authority, evidenced by a board resolution or a mandate rather than by whoever completed the application. Getting the third one wrong is how a bank ends up executing instructions from a former employee.

Only the second is genuinely difficult, and it is difficult for reasons that have nothing to do with engineering throughput.

Following ownership upwards

The obligation is to identify the natural persons behind the entity, because a company cannot be a beneficial owner of itself. The commonly used trigger in Europe and the United Kingdom is a holding of more than 25 per cent of shares or voting rights, held directly or indirectly. The word doing the work is "indirectly": you cannot answer this by reading the shareholder register of the customer in front of you, because the shareholders are frequently other companies, and you have to keep going upwards until you reach human beings or run out of information.

Indirect holdings multiply down the chain, and that arithmetic is where an interviewer probes. A person holding a majority of a holding company that holds a majority of your customer may be well above the threshold in effect while appearing nowhere on your customer's own register.

flowchart TD
  P1[Individual A] --> H1[Holdco One]
  P2[Individual B] --> H1
  H1 --> C[Customer entity]
  P3[Individual C] --> H2[Holdco Two]
  H2 --> C
  P4[Individual D] --> C

What to look for is the difference between the register of the customer entity, which shows two corporate shareholders and one individual, and the set of people you must actually identify, which sits a layer higher and is not visible from the customer's own filing at all.

A percentage threshold is a floor, not a definition of who matters

The failure that separates a competent answer from a compliant-looking one is treating the threshold as the whole test. It is a trigger for mandatory identification, not a statement that anyone below it is irrelevant, and there are two reasons that matters.

The first is control by means other than shareholding. Someone may hold a right to appoint or remove a majority of the board, a veto over material decisions, a golden share, a dominant position through a shareholders' agreement, or influence exercised through debt covenants or a management contract. None of that appears in a percentage. It appears in the articles, the shareholders' agreement and the funding documents, which is why serious corporate onboarding reads documents rather than only ingesting register data. A structure engineered to keep every named holding just under a threshold while concentrating control in one person is not an accident, and noticing that pattern is exactly the judgement the question is testing.

The second is that the absence of anyone above the threshold does not end the process. Where no natural person is identifiable through ownership, the regime generally expects you to fall back to the senior managing official and to record why you got there, because "no beneficial owner found" as a terminal state is a defect rather than a finding. The recorded reasoning is what makes the file defensible.

Structures with no shareholders at all

Trusts, foundations, partnerships and similar arrangements break the shareholding model outright, and each has its own cast of parties: for a trust, the settlor who put the assets in, the trustees who control them, any protector, the named beneficiaries, and the class of persons in whose interest the arrangement operates where the beneficiaries are not individually named. All of those are relevant parties and none of them is a shareholder. The engineering consequence is that your data model cannot be a shareholding graph with percentages; it has to hold typed relationships between parties and entities, where the type carries the meaning. A schema that can only express "owns n per cent" cannot record a discretionary beneficiary, and what a schema cannot record, a bank does not know.

The same modelling pressure comes from nominee arrangements, where the registered holder holds for someone else, and from any jurisdiction whose instruments allow ownership to be held without being publicly attributed. The right response is not to refuse everything unusual but to hold the structure faithfully and to escalate opacity as a risk factor with a named consequence.

Registry data is a lead, not evidence

Public registers are indispensable and they are not proof. Much of what they contain is self-declared by the company, historically with limited verification of the individuals named, and some jurisdictions have only recently begun requiring identity verification of the people who file. Registers also lag: a share transfer or a director change may be months from appearing. So the design pattern is corroboration rather than lookup. You collect the structure the client declares, retrieve what the register says, and treat the disagreement between them as the interesting output — a queue item with a question for the client attached, not an exception to be cleared by whichever source loaded last.

That reframes what the system is for. It is not a pipeline that resolves an entity to a set of owners; it is a case file that holds a declared structure, the evidence gathered against each node in it, the date and source of each piece, and the unresolved discrepancies. Building it as a resolution pipeline is what produces the classic finding in a regulatory inspection: a technically complete record in which nobody actually examined the structure.

Keeping it true afterwards

Companies change hands quietly. Ownership review therefore cannot rely on the client volunteering a change, and periodic review on a fixed cycle will find things late by construction. The stronger design is event-driven: watch register filings for entities in your book, watch for changes in the parties you have already identified, watch the transactional behaviour for activity inconsistent with the business you were told about, and treat any of those as a trigger to re-open the structure. The cost of that is a review queue that can easily exceed what a team can work, so triggers need severity, and severity has to be justified by risk rather than by capacity.

Corporate onboarding is a structure problem wearing an identity problem's clothes: verify existence, ownership and authority separately, model relationships richly enough to record a trust or a nominee, and treat the gap between what the client declared and what the register says as the output rather than the noise.