When FINMA, a self-regulatory organisation or your audit firm reviews client onboarding, nobody asks whether you take financial-crime prevention seriously. They ask for files. A sample of client relationships is pulled, and each file has to tell a complete, coherent story on its own — without the relationship manager in the room to explain what everyone knew at the time.
That is the shift many institutions underestimate. Compliance culture, training, good intentions: all invisible in a file review. What the reviewer sees is what was documented, when it was documented, and whether the documents agree with each other. Onboarding documentation is not the paperwork around the control. It is the control.
Identification: the file speaks for you
The Swiss anti-money-laundering framework asks two foundational things of every relationship: identify the contracting party, and establish who ultimately stands behind it. On paper, both are simple. Files fail on evidence, not on concept.
The classic failures are mundane. An identity document that had expired before the account was opened. A form dated after the first transaction. A corporate client identified through a registry extract that was already stale on day one. None of these means the institution did not know its client — but the file cannot prove that it did, at the moment it mattered. In a file review, what you cannot show, you did not do.
Beneficial ownership must match the rest of the story
The beneficial-ownership declaration is rarely wrong in isolation. It fails by contradiction. The declaration names one person; the corporate chart in the same file suggests another. The KYC profile describes a modest family business; the declared owner is a foundation in a third jurisdiction that appears nowhere else in the file. The relationship manager's notes mention a "partner" who has power of attorney but no documented role.
Reviewers are trained to read across documents, not down them. Before a file is closed as complete, someone — or something — should do the same: does every document in this file describe the same client, the same structure, the same source of the relationship? Contradictions found at onboarding cost an email. Contradictions found by a regulator cost considerably more.
A risk classification you can defend
The risk-based approach means you must sort relationships by risk and treat higher-risk ones with more care. That only works if the classification is defensible. Three questions expose weak ones. First, was it derived from stated criteria — domicile, activity, structure, product — or assigned by feel? Second, when the criteria pointed one way and the rating went another, was the override reasoned and approved, or silent? Third, does the rating actually change anything?
The last question is the one that stings. A "high risk" label that triggers no additional enquiry, no senior approval and no closer monitoring is decoration, and a reviewer will say so. The classification is not a field in the system. It is a commitment to a level of diligence, and the file has to show that the commitment was kept.
Monitoring only exists if it leaves traces
Onboarding ends; the obligation does not. Ongoing monitoring means the relationship is periodically re-examined and transactions are checked against what the file says the client would plausibly do. Both must leave traces. A periodic review that produced no note is, for review purposes, a review that never happened. An alert closed with a bare "OK" is worse than the alert itself, because it documents that a question was raised and visibly not answered.
The expected-activity profile written at onboarding is what makes monitoring meaningful. If the file never says what normal looks like for this client, no later transaction can be abnormal — and the reviewer will conclude that monitoring could not have worked.
One client, one story across products
Institutions grow sideways: a new product line, an acquired portfolio, a second booking system. The same client then exists twice — with, not rarely, two risk ratings, two beneficial-ownership declarations and two expected-activity profiles that were never reconciled. Each file may look adequate alone. Side by side, they prove the institution does not have a single view of its client, which is precisely what the framework assumes.
Whether a specific file is adequate always depends on the relationship's facts, and no checklist replaces that judgment. But completeness and internal consistency can be checked systematically, across every file rather than a sample — structured reading that systems do tirelessly, with a lawyer judging the cases that need judgment. If you would like to know how your files would read to a visitor, we are happy to look before anyone else does.