A client completes your onboarding form. She types her name as Katie Brennan, because that is what her colleagues call her, what her email signature says and what she has answered to since school. Her passport reads Kathleen Mary Brennan.
The identity check comes back with a partial match on the name. What should happen next?
In a surprising number of firms the answer is that the file stops, the client is asked to explain herself, and somebody senior is drawn into a conversation about whether this is a red flag. It is not. It is Tuesday.
Why the names differ
Start with how ordinary this is, because a control calibrated for the exception will fire on the rule.
A shortened or familiar form. Kathleen becomes Katie, Margaret becomes Peggy, Robert becomes Bob. None of these is derivable from the other by rule, and none of them appears on a passport.
A middle name used as the first. Common across these islands and much of the British Isles. A man christened John Peter Le Prevost may have been Peter to everyone, including his employer and his bank, for sixty years.
Anglicisation. A client born Katarzyna may have introduced herself as Kate on her first day in a London office and never gone back. The passport did not change.
Diacritics that do not survive the journey. A passport's machine-readable zone cannot carry an acute, a cedilla or a caron. Müller becomes MUELLER or MULLER depending on the issuing state's convention. Nguyễn becomes NGUYEN. Your form, meanwhile, may have accepted the accented form the client actually uses. The two are the same name and will not match as strings.
Name order. In much of East Asia the family name comes first, and a person who writes it that way on your form has written it correctly. Transposed against a document that lists it the other way round, an automated comparison sees two different names.
Patronymics and multiple family names. Many Spanish-speaking clients carry two surnames and use one socially. Icelandic and several Slavic naming systems build the second name from a parent's. Arabic names may run to four or five elements, of which the client habitually uses two.
Marriage, and the long tail after it. A client may have married, taken a new name on some documents and not on others, and be mid-way through changing the rest. This is the case most likely to look suspicious and least likely to be.
None of these is unusual. Taken together they cover a substantial share of any book of clients that is not exclusively British-born and unmarried.
What the check actually told you
Here is the part worth being precise about, because the language invites a misreading.
An electronic identity check compares what the client typed with what it read from the document, field by field. When it reports a partial name match it is making a narrow, mechanical statement: these two strings are not identical. It is not saying the person is not who they claim to be. It has no view on that at all.
And the check will usually have been far more confident about everything else. The document was tested for authenticity. The person proved they were live. Their face was matched against the portrait. Those are the findings that speak to whether this is the passport's holder, and they may all have passed comfortably while the name field disagreed over an accent.
Reading a name mismatch as a decline therefore inverts the evidence. It sets aside three strong signals in favour of one weak one, and the weak one is weak for reasons that have nothing to do with fraud.
Why a decline is the wrong response
The Handbook's customer due diligence measures, at Chapters 4 to 7, require you to identify the customer and to verify that identity from a reliable, independent source. They require a judgement, made by your firm, applied to the circumstances of the file, and recorded. They do not require the string in your form to match the string on the document.
Refusing at that point fails on three counts. It is wrong about the risk, because the population it rejects is overwhelmingly honest clients with ordinary names. It substitutes a machine's output for the judgement the regime asks your firm to make. And it produces no evidence: a refused application leaves nothing on file except an absence, where a reviewed one leaves a question, an answer and a name against it.
There is a fourth cost, harder to measure. The client experiences it as being accused of something on the strength of her own passport. That is a poor first conversation, and it is avoidable.
What the reviewer should actually check
Treat the mismatch as a prompt to look at the rest of the file, in roughly this order.
The date of birth. If the typed date and the document agree exactly, you are almost certainly looking at one person using two forms of one name. A discrepancy here is a different and more serious matter.
The document number. It should be the document the client presented and the one the check read. Agreement closes off the possibility that two records have been confused.
Whatever else the file holds. A proof of address, a bank statement, an employer's letter, a previous engagement. Look for the known-as name appearing in the client's ordinary life. A utility bill in the name of Katie Brennan, alongside a passport for Kathleen Mary Brennan and a matching date of birth, is a coherent picture rather than a contradiction.
The client's own explanation. Ask, plainly and without implying anything. "Your passport reads Kathleen, you have given us Katie. Can you confirm both are you?" The answer takes a sentence, and it is worth more on the file than any inference you would otherwise have drawn.
Where the explanation is a formal change rather than a habit, a deed poll or marriage certificate, the file should hold it. Where it is simply what the client is called, the record should say so.
Recording it so it holds up
The reviewed file needs four things: what the check reported, what the reviewer checked against it, what the client said, and the conclusion with a name and a time against it. Store the passport name as the verified legal name and the known-as name as exactly that, rather than overwriting one with the other. Both are true and both are useful; the legal name is what you screen and evidence against, and the known-as name is what stops a colleague opening a second file for the same person next year.
Done that way, an inspector asking about a partial match finds a firm that noticed, asked and decided. Done as a decline, they find nothing at all.
What Flarion does about it
Flarion compares what the client typed against what the document says, field by field, and shows any difference on the verification record as its own line: the typed value, the document value, and the fact that they differ. A name that does not match is a cross-check to review, and it is the only thing that happens. Nothing is declined by a machine.
The reviewer records a decision against that line with a reason in their own words, and it carries their name and the time. Later decisions supersede rather than overwrite, so the reasoning stays readable. The record keeps the legal name and the known-as name as separate fields, and screening runs against the name on the document.
When an inspector asks how the firm handles a client whose passport reads one thing and whose life reads another, the answer is a file showing exactly that being asked and answered.