Whether you are checking that a person owns a bank account or that a document belongs to the person signing up for your service, Youtrust compares the name you declared with the name it extracted. This page describes that comparison once, for every service.

The three levels

A comparison always resolves to one of three outcomes.

Value	Meaning
`exact`	The two names are the same, once normalised
`close`	The two names differ only by a spelling mistake, an inversion, or a missing middle name
`no_match`	The two names are too far apart to be the same person

Where each service exposes it

Only Document Trust returns the levels as a field. The other services carry the same three outcomes through their status codes, because their responses have no per-field check object.

Service	How the outcome reaches you
Document Trust	`checks.<field>.match_level`, alongside `expected` and `extracted`
Bank Account IBAN Verification	`BALV_1330` for a close match, `BALV_1103` for no match. On a close match the bank sometimes discloses the real holder in `data.account_holder`
Bank Account Document Check	`BAV_1611` first name, `BAV_1612` last name, `BAV_1613` first name initials, `BAV_1614` legal entity name
Image Identity, Video Identity, Proof of Address, Company Registry	a dedicated status code per field, listed on each product's status page

A Document Trust response looks like this:

{
  "checks": {
    "full_name": {
      "expected": "John Doe",
      "extracted": "Jane Doe",
      "match_level": "no_match"
    }
  }
}

How the comparison works

Before comparing, both names are normalised: converted to a single case, stripped of accents, and stripped of separators such as - and spaces. Normalisation follows the ICAO transliteration rules, so a name written Müller on a German passport and MUELLER in the machine readable zone compares equal.

A comparison is exact when the normalised strings are equal. When a name has several tokens, every token must be present on both sides: "Jean Paul" against "Jean Paul" is exact, "Jean Paul" against "Jean" is not.

A comparison is close when the strings differ only by small errors, detected by a scoring function rather than by strict equality. A close match is also returned when every token you declared appears in the extracted name but the document carries more: declaring "Jean Dupont" against a document reading "Jean Baptiste Dupont" is a close match, not a failure, because a person with several given names often provides only some of them.

Declared	Extracted	Level	Why
Nicolas Dupont	Nicolas Dupont	`exact`	The strings are equal
Jean-Baptiste Dupont	Jean Baptiste Dupont	`exact`	The hyphen is a separator, dropped by normalisation
Nicloas Dupont	Nicolas Dupont	`close`	Two letters inverted in the declared name
Jean Dupont	Jean Baptiste Dupont	`close`	Every declared token appears in the extracted name
Paul Dupond	Jean Dupont	`no_match`	Too far apart

Deciding what to do with a no match

Check these in order.

Is the declared name simply wrong? Ask the person to re-enter it and start a new verification. Names typed from memory into a form are the usual cause.
Did you declare a name the document does not carry? A married name, a shortened given name, or a name in a different script will not be found on the document. Declare the name as it appears on the document.
Are you comparing across several verifications? The same person's name can legitimately differ between an identity document and a bank statement. Compare each verification against what its own document should say, not against one canonical value.