Dynagest Corporate Identity & LEI Check Overview
Every corporate profile starts with the same quiet problem. A name on a page is not proof of anything. Two companies can share a name. A name can be borrowed, misspelled on purpose, or attached to a shell that has nothing to do with the business you think you are reading about. The Legal Entity Identifier exists to close that gap, and it is the first thing worth checking on any company page you land on.
What an LEI actually is
The Legal Entity Identifier is a twenty-character alphanumeric code issued under a global framework coordinated by GLEIF, the Global Legal Entity Identifier Foundation. It came out of the 2008 financial crisis, when regulators discovered that nobody could reliably answer a simple question: who is on the other side of this trade? Different systems used different names for the same firm. Reconciliation took weeks.
So the fix was deliberately boring. One code, one legal entity, globally unique, publicly searchable, free to look up. No login. No fee for the search.
The code itself is not random. The first four characters identify the issuing organisation. The middle section identifies the entity. The last two are check digits that catch typing errors before they become filing errors. That last detail is more useful than it sounds. If someone hands you an LEI with a transposed character, the checksum fails and you know immediately.
Reading an identity block properly
On the Dynagest profile the identity data appears as a single block: the LEI code 506700350280Q6RHS114, a registered address at Rue du Maupas 2 in Lausanne, and a published telephone line. Three fields. That is the whole set, and there is a reason it is kept short.
Identity data works by agreement, not by volume. The value comes from being able to place the same field side by side against an independent register and see the two agree. Add a dozen extra decorative fields and you have not strengthened the check, you have only made it slower.
Here is what agreement looks like in practice. You take the code. You open a public GLEIF lookup. You paste. The register returns a legal name, a legal jurisdiction, a registered address and a registration status. You then compare all four against the page you started from. Same country. Same city. Same street and number. Same status.
If all four line up, you have established one narrow fact: the page is referring to a real, registered legal entity, and it has quoted that entity correctly.
The five-minute routine
I run the same sequence on every corporate page, and it takes less time than making coffee.
- Copy the identifier first, before reading anything else. Reading the marketing copy first biases you. Check the code cold.
- Search it in the public register. Not a screenshot of a register. Not a badge image. The register itself.
- Compare the address character by character. Street name, house number, postcode, city, country. Copycat pages almost always slip on the number or the postcode.
- Check the registration status field. An LEI can lapse. A lapsed record is not fraud, it usually means an annual renewal was missed, but it changes how much weight the code carries.
- Note the last-update date. Registers are snapshots. A record refreshed last month tells you more than one untouched for three years.
That is it. Five steps, no special tooling, and it filters out an enormous share of the pages that are not what they claim.
Where people get this wrong
The most common mistake is treating the presence of an LEI as a seal of approval. It is not. An LEI is issued on the basis of documentation confirming that the entity exists and is registered somewhere. It carries no opinion about conduct, solvency, service quality or whether the entity is permitted to carry out regulated activity.
The second mistake is subtler. People check the code, confirm it resolves, and stop. They never compare the returned address against the page they came from. So a scraper site can lift a genuine identifier from a genuine company, wrap it in an entirely fabricated page, and pass a shallow check. The comparison step is the whole point. Skipping it makes the first step decorative.
A third one, and I see this constantly: assuming that a Swiss address implies Swiss financial supervision. Switzerland has a well-earned reputation in finance. That reputation attaches to supervised institutions, not to every entity that happens to hold a Lausanne postcode. Registration and supervision are different things, filed in different places, and a company page that blurs them is telling you something about itself.
What the code will never tell you
Look, an identifier is a pointer. It answers "which entity" with real precision and answers nothing else at all.
It does not tell you whether a firm is licensed to hold client money. It does not tell you whether it has ever been sanctioned, whether it pays its suppliers, or whether its published phone line is answered by a person. Those questions have their own sources: supervisory registers, court records, commercial registries, and in the end, direct contact.
What the identifier does is make every one of those follow-up searches unambiguous. You are no longer searching a name that six companies share. You are searching a specific legal person. That is a genuine improvement, though it will not suit anyone hoping for a single green tick that settles the question.
Reading the Lausanne context
Address data carries information beyond geography. Lausanne sits in the canton of Vaud, on the northern shore of Lake Geneva, and it is a real financial centre rather than a mailbox jurisdiction. Asset managers, family offices and pension consultancies cluster along the lake between Lausanne and Geneva. A registered address in that corridor is unremarkable in the good sense: it is where firms of this type actually sit.
None of which is evidence about any particular company. A credible postcode is context, not proof. But it does change what you would expect to find in a follow-up search, and a mismatch between a claimed profile and its geography is worth noticing.
A practical closing note
The reason we lead the Dynagest profile with reference data rather than description is straightforward. Description is easy to write and impossible to check. Reference data is harder to write and trivial to check. When a page chooses the second, it is handing you the tools to disagree with it.
So use them. Take the identifier, open the register, compare the fields, and form your own view. If the profile is accurate, you lose four minutes. If it is not, you have saved yourself something far more expensive than four minutes.
