Strong name, wrong person: identifiers decide

Normalization

• Debtor name (Dbtr/Nm): “Tobias Kellner” → “TOBIAS KELLNER” (Uppercase; no punctuation or legal-form tokens to remove.)
• List entry primary name: “KELLNER, Tobias” → “TOBIAS KELLNER” (Resolve the surname-first inversion so both names are compared in the same token order.)

Candidates

• le-kellner-orion: matched on Identical name after inversion normalization — Both tokens of the debtor name equal both tokens of the inverted list name; the entry is pulled in at the highest candidate priority.

Scores

• le-kellner-orion: total 0.94 vs threshold 0.84 (Name similarity 60%×100%; Phonetic similarity 20%×95%; Country corroboration 10%×100%; Identifier corroboration 10%×50%)

Disposition

Alert generated. An identical name in a matching country scores 0.94 against a 0.84 threshold. On an instant rail there is no time to investigate in-flight, so the instruction is rejected within the scheme window and the alert is investigated out of band — a common pattern, though institutions configure it differently.

Investigation

1. Does the customer's date of birth match the list entry? Evidence: Customer KYC file: date of birth 1990-11-08; List entry date of birth: 1975-03-30. Finding: The dates of birth differ by more than fifteen years; the entry's strongest secondary identifier rules the customer out.
2. Does the customer's passport match the identifier on the list entry? Evidence: Customer passport on file: fictional passport L2209581; List entry passport: fictional passport C8113374. Finding: Different document numbers from different issue series; no identifier overlap.
3. Is there residual risk that the KYC file itself is wrong or stale? Evidence: The customer's identity documents were verified at onboarding and re-verified at the last periodic review; No adverse media or internal-list hits connect the customer to Fictional Programme ORION. Finding: The KYC identifiers are reliable enough to rest the disposition on.

Final: False positive — release. Close the alert as a false positive, documenting the date-of-birth and passport mismatches as the discounting evidence. Register the customer-to-entry pairing so the customer's resubmitted payment passes without a repeat manual review, and tell the channel the customer can safely retry. The pairing must be re-reviewed if the list entry ever gains new identifiers.