People

A person is resolved and deduplicated across an account by identifier, so the same individual on six merchants is one record — which is what makes portfolio linkage possible.

The person workspace

Reached from any party card. Shows:

• Checks on this person — what every check says, and where it says nothing, why. First on the page, because it is the question you came to answer
• Identity — what the file holds beside what the government record returned, side by side
• Where this person appears — every entity in the account, with relationship and current review
• Screening findings — classifications a provider asserted, such as PEP
• Registered address — the addresses the national register returned
• Check history — folded away: every run attempted, including the failures

Recording a date of birth

Elm's identity and address checks need a date of birth, and only a provider response can normally supply one. When none is on file, an operator with entity.update can record one.

It is stored as declared, not verified, and labelled that way everywhere it appears. This is legitimate KYB input — the date of birth is the claim the government record is tested against, not evidence in itself — and an operator cannot fake a pass without already knowing the true value.

A later authoritative answer overwrites a declared value. Every other identity field is fill-if-blank; this one is the exception, because otherwise a typo would be permanent.

The form asks for a specific calendar

Saudi citizens are matched on a Hijri date; Iqama holders on a Gregorian one. The field states which, derived from the identifier type, and the two are stored in different columns. A Gregorian date entered for a citizen is a claim that can never match. See Dates of birth and calendars.

Identity assurance and risk

The identity_assurance risk factor reads the weakest party on an entity, not the best. One verified owner among four does not make the merchant verified — it makes it partially verified, and scores accordingly.