Introduction
Sanctions and watchlist screening is often described as one of the more mature financial crime controls. The lists are published, the screening systems are well established, and most institutions can demonstrate that every customer and payment is screened. However, the effectiveness of screening depends on a step that receives far less attention: whether the system correctly understands the name it is screening.
Most screening systems, customer databases and payment formats were designed around a familiar Western structure, with a first name, perhaps a middle name, and a family name that appears last and is passed from one generation to the next. A large part of the world does not name people in this way. Names may begin with the family name, consist of initials followed by a single given name, use a father’s name in place of a surname, or exist originally in a script that can be romanised in several different ways.
My interest in this subject comes from two directions. I grew up with Sri Lankan naming conventions, in which long ancestral or family names are often reduced to initials, so that the same person may appear in full on one document and as initials followed by a given name and surname on another. Later, while working with a UAT team on new banking systems, testing them against trade requirements and migrating trade data on behalf of the trade team, I came to appreciate how much depends on the way a name is captured, split into fields and carried from one system to another. This article brings those two perspectives together and considers why names that do not fit Western formats present a particular challenge for screening, and what institutions can do about it.
Regulatory context
In the UK, financial sanctions are imposed under the Sanctions and Anti-Money Laundering Act 2018 and administered by the Office of Financial Sanctions Implementation (OFSI). Since June 2022, OFSI has been able to impose civil monetary penalties on a strict liability basis, which means that a firm may be penalised for a breach even where it did not know, and had no reasonable cause to suspect, that it was dealing with a designated person (Economic Crime (Transparency and Enforcement) Act 2022). A screening system that fails to recognise a designated person because of the way that person’s name is structured therefore exposes the institution to real enforcement risk.
The FCA’s Financial Crime Guide sets out its expectations for screening. It describes as good practice an automated screening tool that can make “fuzzy matches”, identifying similar or variant spellings of names, name reversal, digit rotation and character manipulation. It also expects a firm to understand how its screening tool is calibrated and to be able to demonstrate that the calibration is appropriate to its risk exposure, and it identifies as poor practice calibration that is not adequately tailored, leaving the system either too sensitive or not sensitive enough (FCA, 2023). The Wolfsberg Group’s guidance on sanctions screening similarly emphasises that institutions should understand the matching logic of their systems and test and tune them on a regular basis (Wolfsberg Group, 2019).
The sanctions lists themselves have reflected the same underlying structure. For many years, the main reference for UK financial sanctions screening was OFSI’s Consolidated List, which recorded individual names across six fields, with “Name 6” defined as the last name of the individual and the list sorted alphabetically by that field, alongside fields for name variations, aliases and names in non-Latin script (HM Treasury, 2022). These features are helpful, but they also show that the list, like most of the systems that screen against it, was organised around the idea of a single surname appearing at the end. On 28 January 2026 the Consolidated List closed, and the UK Sanctions List maintained by the Foreign, Commonwealth and Development Office became the only official UK list of sanctions designations (FCDO, 2026). For many institutions, this meant changing the list source that their screening systems rely on, which is precisely the kind of change that can alter how names are matched.
Where Western assumptions break down
Name order
In many naming traditions, the family name comes first. Chinese, Korean, Japanese, Hungarian and Vietnamese names commonly place the family name before the given name, and a customer may present the name in either order depending on the document or the context. Where a system assumes that the last word is the surname, or where a core banking system stores names in separate first name and surname fields, the same person can be recorded in different ways across the institution. Name reversal is one of the variations that the FCA expects screening tools to handle, but the effectiveness of that capability depends on the system recognising which part of the name is which.
Initials and abbreviated names
In Sri Lanka and parts of South India, it is common for a person’s name to include several ancestral or family names that are routinely reduced to initials. A name recorded in full on a birth certificate may appear on a passport, a bank account and a payment message in quite different forms, for example with the full ancestral name on one document, a series of initials on another and only the given name and final name on a third. Each form is correct, and each may be the form the customer uses most often.
Screening systems are generally better at handling spelling variations than at relating initials to the names they stand for. Where a designated person’s name is recorded on the list in full, and the same person appears in a payment using initials, the similarity score between the two may be too low to generate an alert.
Patronymic names and names without a surname
In Tamil naming practice, a person often has no family surname in the Western sense. Instead, the father’s given name is used alongside the person’s own name, frequently as an initial placed before it. Arabic names may include patronymic elements such as “bin” or “ibn”, Icelandic names use patronymics that differ between father and child, and in Myanmar many people have no family name at all. In each case, the part of the name that a Western system treats as the surname may not be stable across generations, may change between documents, or may not exist.
When such names are forced into first name and surname fields, the choice of which element becomes the surname is often made by the person entering the data. Two members of staff may make different choices for the same customer, and the screening system will then compare different elements of the name against the list.
Transliteration
Many names originate in scripts other than Latin, such as Sinhala, Tamil, Arabic, Cyrillic or Chinese characters. There is often no single accepted romanisation, and the same name may be spelt in several ways depending on the conventions of the issuing authority, the individual’s own preference or the language through which the name was transliterated. Fuzzy matching handles some of this variation well, particularly where differences involve single characters. It is less effective where transliteration produces structural differences, such as different vowel patterns, merged or separated name elements, or prefixes that are sometimes joined to the name and sometimes written separately.
An illustrative case
Consider a hypothetical designated individual listed as Rajan Kumaraswamy, where Kumaraswamy is in fact his father’s given name rather than a family surname. The name is invented for illustration, and the same difficulty can arise with any naming convention that does not use an inherited surname. Under the list structure, Kumaraswamy is recorded in the surname field.
A payment is received for the benefit of “K. Rajan”, which is the form in which this individual commonly writes his name, following the Tamil convention of placing the father’s initial before his own given name. The bank’s screening system compares the surname elements of the two names, finds that “Rajan” and “Kumaraswamy” are entirely different, and gives the possible match a low score. Because the initial “K” is not linked to the name it represents, no alert is generated and the payment is processed.
At the same time, the system generates large numbers of alerts for customers with common South Asian names, such as Perera, Fernando or Kumar, where a single shared element produces a high score against unrelated list entries that happen to contain the same name. Analysts spend considerable time clearing these alerts, while the genuine match described above is never presented to them.
The case illustrates that the problem has two sides. A system that is poorly calibrated for a particular naming convention may miss genuine matches and, at the same time, generate excessive false positives for the same communities. Both outcomes weaken the control, and the second also places an unfair burden on legitimate customers whose payments are delayed or questioned because of the structure of their names.
Why these issues are often missed
From what I have observed, these weaknesses are rarely visible in the metrics that institutions use to monitor screening. A system can screen every customer and every payment, clear alerts within service standards and still perform poorly for particular naming conventions.
Screening systems are often implemented with vendor default settings that have been tuned on data that may not reflect the institution’s own customer base. For a bank with a significant number of customers from South Asia, the Middle East or East Asia, those defaults may be unsuitable, but this only becomes apparent if the system is tested against names that reflect those customers.
Testing practice also plays a part. In my experience of UAT, test cases tend to be built around the scenarios the business expects to see, and the test data used for screening frequently consists of names in Western formats with simple spelling variations. A system can pass such tests comfortably while performing poorly on initials, patronymics or transliterated names, simply because those patterns were never included in the test pack.
Data capture and migration introduce further risk. When customer data is moved from one system to another, a name held in a single field may need to be split into first name and surname fields, and the rules used to do so usually assume that the final word is the surname. Once the data has been migrated, the resulting errors are rarely revisited, and every subsequent screening result depends on them.
Finally, alert reviewers may not be familiar with the naming conventions involved. An analyst who does not know that “K. Rajan” and “Rajan Kumaraswamy” can refer to the same person will not recognise the connection, even where the system presents both names together.
Practical measures
Improving screening for names that do not follow Western formats does not necessarily require a new system. It requires institutions to understand how their existing system treats different naming conventions and to test it accordingly. In practical terms, institutions should consider the following measures:
- Build test packs that reflect the customer base. Screening test data should include names with family-name-first order, initials, patronymics, multiple surnames, prefixes and alternative transliterations, drawn from the naming conventions most common among the institution’s customers and counterparties.
- Capture names as they are given. Alongside structured name fields, institutions should retain the full name exactly as it appears on the customer’s identity document and, where available, the name in its original script. This allows screening against more than one representation of the same person.
- Review name-splitting rules in data migration. Where names are moved between systems or split into fields, the rules used should be reviewed by people who understand the relevant naming conventions, and a sample of migrated records should be checked before go-live.
- Tune the system for specific conventions. Matching rules for initials, name order and common name elements should be assessed separately, so that the system neither ignores relevant matches nor generates excessive alerts on common names. This analysis should be based on name structure rather than on assumptions about a customer’s ethnicity or nationality, and should respect data protection requirements.
- Provide naming convention guidance to analysts. A short reference explaining the main naming conventions encountered by the institution, with examples, helps reviewers recognise when two different-looking names may refer to the same person.
- Repeat testing after changes. Vendor upgrades, threshold changes and significant list updates can change how names are matched. Regression testing with the same diverse test pack should be part of every such change. The move from the Consolidated List to the UK Sanctions List is a recent example, and institutions that have not yet tested how their system maps the new list’s name fields should do so.
Conclusion
Screening is often treated as a solved problem, because its coverage can be demonstrated so easily. Coverage, however, says little about whether the system recognises the names it is screening. For the many customers and counterparties whose names do not follow a first name and surname structure, the effectiveness of screening depends on assumptions that are rarely tested.
The consequences fall on both sides of the control. Genuine matches may be missed, which under a strict liability regime exposes the institution to enforcement action, and legitimate customers may face repeated delays because their names generate false alerts. Institutions that test their systems against the naming conventions of their own customer base, capture names as they are actually given and equip their analysts to recognise those conventions will be better placed to address both risks.
Having grown up with a naming tradition that rarely fits neatly into a first name and surname field, and having later seen how names are tested and moved between systems, I have come to view name structure as one of the less visible but more important factors in screening effectiveness. It deserves the same attention that institutions already give to list coverage and alert volumes.
References
Economic Crime (Transparency and Enforcement) Act 2022. London: The Stationery Office.
Financial Conduct Authority (FCA) (2023) Financial Crime Guide: A Firm’s Guide to Countering Financial Crime Risks, FCG 7: Sanctions and Asset Freezes. London: FCA.
Foreign, Commonwealth and Development Office (FCDO) (2026) The UK Sanctions List. London: FCDO.
HM Treasury (2022) Consolidated List and the List of Persons Named in Relation to Financial and Investment Restrictions: Format Guide. London: Office of Financial Sanctions Implementation.
Sanctions and Anti-Money Laundering Act 2018. London: The Stationery Office.
Wolfsberg Group (2019) Wolfsberg Guidance on Sanctions Screening. Wolfsberg Group.
Leave a comment