Name Matching and Fuzzy Logic

Exact name matching would be useless for sanctions screening, because real payment data is messy. Names are transliterated from Arabic, Cyrillic or Chinese scripts in different ways, spelling varies, middle names are dropped, and companies trade under short forms. A person called Mohammed on a list might appear as Mohamed, Muhammad or Mohd on a payment, and all of those must be caught. Screening engines therefore use fuzzy matching algorithms that score how similar two names are, looking at phonetics, character swaps, missing words and word order. A score above a threshold creates an alert, and the threshold is a tuning decision that balances catching real matches against flooding analysts with noise. Good matching goes beyond the name itself. The engine also compares dates of birth, nationalities, addresses, passport numbers and other identifiers when they are available, and it uses that extra data to raise or lower the score. A name match combined with a matching date of birth is far more serious than a name match alone. Some engines also use transliteration tables and nickname dictionaries, so that a common shortened form still matches the full legal name. The quality of the underlying list data matters enormously, because a list entry with no date of birth and no address will generate far more false alerts than a well populated entry, and banks cannot fix list data themselves. Tuning the matching engine is a continuous operational job, not a one off configuration. If the threshold is too loose, analysts face thousands of alerts a day and real hits hide in the pile. If it is too strict, a genuine sanctioned party slips through because of a single spelling difference. Banks review their alert volumes, measure how many alerts turn into true hits, and adjust rules for specific lists, countries and payment types. A BA involved in this work should ask for the false positive rate, the true hit rate and the average handling time per alert, because those three numbers tell you whether the screening setup is actually working or just generating busywork. Name matching uses an algorithm, not a simple comparison, because names are spelled differently across languages and systems. A fuzzy matching algorithm compares the payment name to the list entry and produces a score, usually from 0 to 100, where 100 is an exact match. The algorithm considers transliteration, so that a Russian name written in Cyrillic and the same name written in Latin are recognised as the same name. It considers nicknames and abbreviations, so that Mohammed, Mohamed, Muhammad and Mo are recognised as variants. And it considers word order, so that a name written family name first is matched to the same name written given name first. The scoring threshold is the most important configuration decision in name matching. A threshold of 90 will generate very few alerts, but will miss true hits where the name is spelled differently. A threshold of 70 will generate many alerts, most of them false positives, and the operations team will be overwhelmed. The threshold is usually set between 80 and 85, and is tuned by testing it against a set of known true hits and known false positives. The tuning must be documented, and the threshold must be reviewed when the false positive rate changes, because a rising false positive rate means the threshold is too low. The tuning process is a test, not a guess. The team takes a sample of past payments, including known true hits and known false positives, runs them through the screening engine at different thresholds, and measures the true positive rate and the false positive rate at each threshold. The threshold that gives the best balance is chosen, and the results are documented. The test must be repeated when a new list is added, when the matching algorithm is updated, or when the payment volumes change significantly. A threshold that was correct a year ago may be wrong today. Take the name Mohammed Al-Rashid on a sanctions list, and a payment to a customer called Mohamed Al Rashid, with no hyphen, a different spelling of the first name, and no date of birth on the payment. A fuzzy matching engine scores the two names by phonetics, by character swaps, and by word order, and produces a score of 88 out of 100, which is above the threshold of 80, so it creates an alert. The analyst checks the customer's passport, finds a different date of birth and a different nationality, and clears the alert as a false positive. The same name with a matching date of birth would score 97 and would be escalated as a likely true hit. The point is that the score is a starting point, not a decision, and the analyst's judgement, using the extra data, is what makes the decision. Threshold tuning is where screening succeeds or fails in practice. Suppose a bank sets its threshold at 95 to reduce alert volumes, and a genuine sanctioned party whose name differs by two characters scores 93 and passes. The bank has missed a true hit because it tuned for convenience. Suppose instead the bank sets the threshold at 70, and analysts face 5,000 alerts a day, of which 99 percent are false positives. The analysts start clearing alerts quickly without proper checks, and a true hit hides in the pile. The right threshold is found by measuring the false positive rate, the true hit rate, and the average handling time, and by tuning separately for each list, each country and each payment type, because one threshold for everything is wrong for almost everything. A BA involved in matching engine work should ask for three numbers: the false positive rate, the true hit rate, and the average handling time per alert. Those three numbers tell you whether the screening setup is actually working or just generating busywork. The BA should also specify the test pack: names with transliteration differences, names with missing middle names, names with different word orders, and names that are common in the bank's customer base. The test pack must include the tricky cases, because an engine that passes only easy tests will fail on the real data. And the BA should specify who can change a threshold, who approves the change, and how the change is tested, because a threshold changed without governance is a control changed without approval.