Category Archives: Matching Technologies

03.20.14
by

OFAC’s FAQ on Weak Aliases

122. What are weak aliases (AKAs)?

A “weak AKA” is a term for a relatively broad or generic alias that may generate a large volume of false hits. Weak AKAs include nicknames, noms-de-guerre, and unusually common acronyms. OFAC includes these AKAs because, based on information available to it, the sanctions targets refer to themselves, or are referred to, by these names. As a result, these AKAs may be useful for identification purposes, particularly in confirming a possible “hit” or “match” triggered by other identifier information. Realizing, however, the large number of false hits that these names may generate, OFAC qualitatively distinguishes them from other AKAs by designating them as weak. OFAC has instituted procedures that attempt to make this qualitative review of aliases as objective as possible. Before issuing this updated guidance, OFAC conducted a review of all aliases on the SDN list. Each SDN alias was run through a computer program that evaluated the potential of an alias to produce false positives in an automated screening environment. Names were evaluated using the following criteria:

  1. Character length (shorter strings were assumed to be less effective in a screening environment than longer strings);
  2. The presence of numbers in an alias (digits 0-9);
  3. The presence of common words that are generally considered to constitute a nickname (example: Ahmed the Tall);
  4. References in the alias to geographic locations (example: Ahmed the Sudanese);
  5. The presence of very common prefixes in a name where the prefix was one of only two strings in a name (example: Mr. Smith).

Aliases that met one or more of the above criteria were flagged for human review. OFAC subject matter experts then reviewed each of the automated recommendations and made final decisions on the flagging of each alias.

OFAC intends to use these procedures to evaluate all new aliases introduced to the SDN list. [01-18-11]

123. Where can I find weak aliases (AKAs)?

Weak AKAs appear differently depending on which file format of the SDN List is utilized.

In the TXT and PDF versions of the SDN List, weak AKAs are encapsulated in double-quotes within the AKA listing:

ALLANE, Hacene (a.k.a. ABDELHAY, al-Sheikh; a.k.a. AHCENE, Cheib; a.k.a. “ABU AL-FOUTOUH”; a.k.a. “BOULAHIA”; a.k.a. “HASSAN THE OLD”); DOB 17 Jan 1941; POB El Menea, Algeria (individual) [SDGT]

This convention also is followed in the alphabetical listing published in Appendix A to Chapter V of Title 31 of the Code of Federal Regulations.

In the DEL, FF, PIP, and CSV file formats, weak AKAs are listed in the
Remarks field (found at the end of the record) of the SDN file. In
these formats, weak AKAs are bracketed by quotation marks. Please see the data specification for these files for more information:

http://www.treasury.gov/resource-center/sanctions/SDN-List/Documents/dat_spec.txt

8219 @”ALLANE, Hacene”@”individual”@”SDGT”@-0- @-0- @-0- @-0- @-0- @-0-
@-0- @”DOB 17 Jan 1941; POB El Menea, Algeria; a.k.a. 'ABU
AL-FOUTOUH'; a.k.a. 'BOULAHIA'; a.k.a. 'HASSAN THE OLD'.”

In the XML version of the SDN List, there is a Type element for each
AKA. The Type can either be 'weak' or 'strong' (see the XML SDN
Schema (XSD file) at:
http://www.treasury.gov/resource-center/sanctions/SDN-List/Documents/sdn.xsd for more information). [01-18-11]

124. Am I required to screen for weak aliases (AKAs)?

OFAC’s regulations do not explicitly require any specific screening regime. Financial institutions and others must make screening choices based on their circumstances and compliance approach. As a general matter, though, OFAC does not expect that persons will screen for weak AKAs, but expects that such AKAs may be used to help determine whether a “hit” arising from other information is accurate. [01-18-11]

125. Will I be penalized for processing an unauthorized transaction involving a weak alias (AKA)?

A person who processes an unauthorized transaction involving an SDN has violated U.S. law and may be subject to an enforcement action. Generally speaking, however, if (i) the only sanctions reference in the transaction is a weak AKA, (ii) the person involved in the processing had no other reason to know that the transaction involved an SDN or was otherwise in violation of U.S. law, and (iii) the person maintains a rigorous risk-based compliance program, OFAC will not issue a civil penalty against an individual or entity for processing such a transaction. [01-18-11]

08.23.13
by

OFAC’s got some ‘splaining to do…

From OFAC's FAQ on how to determine if you have a match against the SDN list, we have:

Step 3. How much of the SDN’s name is matching against the name of your account holder? Is just one of two or more names matching (i.e., just the last name)?

If yes, you do not have a valid match.*

If no, please continue to 4 below.

Really? Is that really the standard? How about:

  • The data matches the first and middle names but not the last: does every Mary Ann and Jose Maria require additional review?
  • The data matches a first name and the maternal last name of a Hispanic (or Portuguese-speaking) individual, but not the paternal last name – do those require additional research and review?
  • The data matches the 2 last names of a Hispanic (or Portuguese-speaking) individual, but none of the first or middle names – do those require review?

And what should be reviewed for matches to the multiple name components of Muslim names? Are they all created equal other than the given name?

It's very easy for OFAC to say “we can't give any more guidance – otherwise, the terrorists will win.” And it's also not very fair, especially since each of these cases involves significant additional operational overhead – or much smarter systems – to handle the increase in matches.

OFAC needs to issue more precise guidance… period.

To be clear, Mr. Watchlist believes that none of the cases in the list above requires additional review, and that a workable model for Muslim names would require matches to the given name, or initial, and the nisbah, which is the tribal, clan or geographic name. A case could potentially be made to substitute the laqab, which is an attribution name, like al-Rashid, for the nisbah, but it's my understanding that the nisbah is the closest to a family or last name in Muslim name structures.

01.02.13
by

Making Smaller Haystacks

There are always more matches than we want – and experience teaches us that the ratio is not close (1000 to 1, according to BNP Paribas’ NY branch, using an exact matching methodology). We’re searching through an awful lot of hay to find needles that may or may not be hidden in there. All that reviewing our haystacks of data is awfully costly.

So, we need a way to reduce the number of matches we review. Operations staff will tell you that it’s patently obvious, in the overwhelming majority of cases, that the data matched is not the same as the listed data. These patterns of false positive matches tend to repeat regularly, the frequency determined by the nature of the business and data.

For example, wholesale businesses tend to have a more concentrated set of matches, since there are a smaller set of counterparties (some of which are used by multiple businesses due to the generic nature of the goods and services they provide) than for retail businesses. Similarly, transactional data tends to have more repetitive name data, while static data may have more recurring matches to cities and countries. A wholesale payments business will have more concentrated data than check disbursements, due to the relative frequency of the transactions. Etc., Etc.

So, we have a number of basic strategies, which we’ll discuss over a series of posts. These are:

  1. Finding patterns in our data that we trust
  2. Accepting limited amounts of additional risk in specialized circumstances
  3. Using secondary criteria to further assess the likelihood of a match

Some of these have a number of flavors to them so we may cover a topic over multiple posts, for brevity’s sake.

12.31.12
by

Set phasers (not) to stun!

A lot of this seems daunting, doesn’t it? So many possible lists, system settings to consider… and so much work to process Day 1. Seems a little nuts to me…

Well, even if you’re facing down the loaded end of a C&D (cease and desist), one doesn’t have to implement a whole raft of changes in the blink of an eye. You can phase in your changes.

What auditors and regulators want to see is, of course, an acceptable program – eventually. What matters more is the plan to get there. These folks aren’t ogres (at least, not the ones I’ve met).

Imagine the following paths to “full” compliance:

  1. In January, you screen all accounts with an average daily balance of $1MM US against your PEP list. In March, you lower that threshold to $750,000. In May, you lower the threshold to $500,000. In August, it goes down to $250,000 and finally, in January of the next year, you drop it to $100,000…
  2. In the beginning of January, you start screening your accounts against sanctions lists using exact matching. In mid-January, you start using fuzzy screening at 93%. In mid-February, the fuzzy threshold drops to 91% – in mid-March, to 90%, in mid-April, to 88%, in mid-May, to 87%…
  3. In January, you begin screening against OFAC, the HMT (Her Majesty’s Treasury) list, the UN list and the EU list, because they’re your highest-volume currencies. In February, you add the second tier – the Canadian lists (OSFI, plus the DFAIT economic sanctions countries and cities, which include some city names that are very common in the US), the Japanese Ministry of Finance, the Monetary Authority of Singapore list and the Hong Kong Monetary Authority list. In March…
  4. In January, you start screening account information against national and international-level foreign PEPs that are still in office. In February, you include officials who have left office within the last 3 years. In March, you include national and international-level domestic PEPs who are still in office. In April, you include domestic officials who have left office within the last 3 years. In April, you include provincial/state-level domestic PEPs. In May, you include local-level domestic PEPs.
  5. In January, you start out with what you consider the bare minimum list of sanctions lists, including OFAC. Over the next few months, you add transaction-specific lists, such as BIS (Bureau of Industry and Security), BISN (Bureau of International Security and Nonproliferation), DTC (Directorate of Defense Trade Controls) and the World Bank Debarred List. In the second half of the year, you add a screen to your client onboarding process against law enforcement lists, including US Marshal Service, FBI, and Interpol.

Making some of these changes may increase the overall number of matches over time (e.g. changing the fuzzy logic level), while others may just increase the number of matching entity listings (which increases the time to clear each item).

Why phase in changes, instead of a “big bang” that gets your program up to snuff immediately? First, there’s the cost – a large increase in matches will either mean overtime, a large increase in staff or temporary help and/or less time devoted to making a decision on each match. Second, there’s the likelihood that a massive set of changes will overwhelm your staff, making them less, rather than more, productive (which adds to costs and errors). Third, making significant changes requires that compliance processes still keep their focus on the proper set of priorities – like, economic sanctions items are most important, followed by PEP screening, followed by other due diligence efforts (that’s an example – your priorities might be different). Priorities can easily get lost amidst the rush to get the decks cleared on a daily basis.

So, plan getting from here (where you are today) to there (where you want to end up) in an orderly fashion, like they tell you to do in movie theaters for if there’s an emergency, like a fire – instead of in the mad rush that usually happens. There will be fewer bruises all around if you do.

12.27.12
by

It takes two to tango

So, companies match their static and transactional data… to what? What specific pieces of the watchlist listing should be matched?

Well, what is there to match on? Well, there’s the name… what else?

Listings often have addresses but you don’t really want to match on those alone. After all, street addresses are not unique and, in fact, may generate false positive matches (there is a street named after Robert Mugabe in Harare, Zimbabwe, for example). And listed individuals may be located in non-sanctioned countries. I know of one OFAC-listed firm (Travel Services, Inc.) located in Florida in the US, for example.

For similar reasons, date of birth is not a good single element to match on. And don’t get me started about OFAC, who lists some dates of birth as “approximate”, in which case they want you to pick up the phone and call them regardless of how far off the dates are.

But, on a frequent basis, there are other ways to identify the listed entity besides their name. For example, national IDs like the Cedula in Colombia or the SSN in the US are included in sanctions listings. Same thing goes for passports for people, DUNS or VAT IDs for companies, IMO (International Maritime Organization) numbers and call signs for cargo vessels, and SWIFT ids and other routing codes for banks (and some corporates).

Now, I have mentioned matching on a single element. Why not multiple pieces of information?

Certainly, you can rely on multiple pieces of information in static data screening – if you have it, if the data quality is good, and if you consider keying errors and use of default values. Raise your hand if you’ve ever seen a system that defaulted date fields to 1/1/1970 (Windows) or November 11, 1858 (DEC VAX – remember those?). Of course, the chances of you getting multiple criteria if you’re screening transactional data are slim to none.

Don’t forget that dates come in multiple formats – US format (month/day/year), European format (day/month/year) and the format used in Asia (year/month/day). It’s important to know how the dates are formatted by the data provider before trying to use date of birth as a matching criteria – at least past using the year.

Now, I should preface the rest of this by noting that how data actually gets matched – whether the matching criteria are in software or in the watchlist databases – varies. So, both the software and data providers need to be able to explain how the data elements that generate matches are being derived.

As you can see, I’ve avoided the elephant in the room – the entity name. What should we match on? Let’s assume that things other than people and groups (i.e. countries, cities, cargo vessels) are pretty simple – match the whole thing. But, what about those pesky people, companies, and other organizations?

At one end of the spectrum, you could match on the entire name as listed – but you’d miss a lot of potential matches. People often don’t use their full names when opening accounts, much less doing business, and the little niceties of corporate names (e.g. The, A, Of, Inc, Corp, etc.) often get omitted in the name of brevity and speed.

On the other hand, you could cast a very wide net. Imagine matching on a person’s last name only, or matching on any individual token in a corporate name – oh, the horror! Clearly there is a middle ground.

Let’s deal with corporate names first. It seems a reasonable middle ground to eliminate articles, prepositions and corporate suffixes (Co, Corp, Inc, Ltd) and match on what’s left. Additionally, if the group or company is identified by an acronym, it would be reasonable to match that, too (although I have a beef about that which I’ll get into in a future post).

How about individuals? Again, you’re not going to get all the names, fully spelled. So, it boils down to a question of what subsets of the possible names you should match on. In general, Mr. Watchlist believes that any matching system must match multiple name components, one of which is the last name.

Now, let’s now enumerate all the little details that one (or, at least, one’s software) needs to take into account:

  1. One must consider what abbreviations or contractions, alternate spellings or transliterations and foreign translations, of the selected tokens might also occur – and account for them. “Bank” should match “Bk” and “Banca,” while “Mohammed” must also match “Muhd” and “Muhamad” (among many others).
  2. One must consider what is considered a person’s last name.
    • For Hispanic names, the first last name is the father’s, which will always be used. For Portuguese names, it’s the second last name. If you wish to also search for the “optional” names, realize that, at best, you will generate multiple matches when you could have generated one (e.g. “Maria Elda Rodriguez Pulido” will match “Rodriguez Pulido” as well as “Maria Rodriguez”) and may also generate matches to obvious false positives (“Rodriguez Pulido” will also match “Jose Rodriguez Pulido”, for example).
    • For Arabic names, there are multiple name components that are neither considered “last” or “midde”. The one that, according to an acquaintance of Mr. Watchlist’s from a bank in the UAE, is the closest to a “last” name is the nisbah, which is a tribal or geographic name (e.g. “Al-Tikriti” or “of Tikirit”, was Saddam Hussein’s nisbah). And the kicker is that the only “required” name component is the first name – so you may not even get a nisbah.
  3. One must consider how to handle name components that consist of multiple tokens. For “Juan M. de la Cruz”, does the software drop “de” and “la” (meaning “of” and “the”) and match only on “Cruz”, or does it require all three? Similarly, “Abdul” in non-Americanized Arabic names, is always followed by one of the 99 adjectives for Allah. Does the software treat the pair of tokens as a single name component? As an aside, the “Abdul Rahman” on the SDN list is really the equivalent of listing someone purely as “Barney.”

Of course, the elephant in the room remains to be named: unless you are willing to endure great expense, you will not catch everything. Normally a listing for “The Ford Motor Company” would match on something like “Ford Motor”, and possibly abbreviations like “FoMoCo” and “FMC”. But you could get a reference like “Ford” – do you really want to stop all references to that? In a more tangible sense, there were Burmese companies called “New York” and “Hong Kong” – someone, somewhere (either you or your data provider) had to make an assumption or shortcut to prevent the deluge of matches.

So, that really is the last issue to be considered: how does a data provider deal with terms that are too generic to be a sole matching criteria? There are entity names, aliases or acronyms of “So”, “Maria”, “SRA”, “BOTH”, “Am”, and “55”, not to mention the examples above. Does the data provider drop these, combine these with another criteria (e.g. “Hong Kong Yangon” because the company is located in Yangon) or leave them as-is? And how can you modify the handling of these should you wish to?

Ultimately, you may not get a perfectly-tuned set of data. However, if you at least understand the reasoning behind what it provides, you can better strategize your matching and operational strategies going forward.

Reference:

Arabic nomenclature: A summary guide for beginners

12.18.12
by

Beyond Vanilla – Flavors of Matching

It’s one thing to want to match against watchlists, and it’s another to figure out all the ways your technology can miss something you want to catch (or catch something you don’t want).

So, consider the following things that some screening engines do, and consider the implications for the results you get:

    All Matching Technologies

  • Name Variations
    • Does the matching engine provide alternate spellings of names, like the multiple ways that Mohamed can be spelled? How about common abbreviations like Mohd or Muhd?
    • Does the matching engine provide abbreviations of common words, like Co., Inc., or Ltd.?
    • Does the matching engine provide foreign translations, such as Bank, Banco, Banca, and Banque?
  • Matching Functionality
    • How does the matching engine treat tokens that are out of order? Are Kim Young and Young Kim identical, or (at least a partial) mismatch?
    • How does the matching engine treat additional tokens between the target tokens? Is there a matching window such that all tokens must be within a certain distance of each other? Is that window fixed or tunable?
    • How does the matching engine handle embedded characters? Will it find “Ira n”, or even “I r a n”?
    • How does the matching engine handle run-on text? Will it match Muhammad Ibrahim to MuhammadIbrahim?

    Fuzzy Matching

    • Is the match threshold for the entire phrase being matched, or for each individual token?
    • If the match threshold is for the entire phrase, is there a minimum match percentage for each individual token? In other words, will XX International match UI International if the threshold is high enough?
    • How is are transpositions (flipped letters) scored? Are they one edit error, or two?
    • Are transpositions only of adjacent characters, or can any two positions be flipped and scored as a transposition (instead of two substitutions)? So, is Nalcof considered a single transposition for Falcon?
    • Are inserted letters that are duplicates of adjacent letters scored differently than other insertions? In other words, is Cubba scored differently for Cuba than Cuxba?
    • Is keyboard layout considered when scoring insertions and substitutions? In other words, is Myhammad a better score for Muhammad, because the Y is next to the U on the keyboard? And which keyboard layouts are considered?
    • If a token is a legitimate word or name, is fuzzy matching still invoked? In other words, will Fernandez still match Hernandez, all other things being equal, even though Fernandez is a legitimate name?
    • Do use of alternate spellings, abbreviations or foreign translations affect the match score? How?
    • Does token order affect the match score? How?
    • Do intervening tokens between the target tokens affect the match score? How?

    Phonetic Matching

    • Do use of alternate spellings, abbreviations or foreign translations affect the match score?If so, how? If not, why not?

This is a good starter list. If you have others that would be useful to ask a prospective vendor, please comment below.

12.18.12
by

A is for Algorithm

So, how do we actually match our data to the watchlist data? There are two components to this, really: the mechanism by which we match, and what we actually match against. The matching mechanism is, ultimately, boiled down to some flavor of text search and matching technology.

In broad strokes, there are three kinds of matching algorithms: exact matching, fuzzy matching and phonetic matching. They each have their pros and cons.

Exact matching is just what it sounds like: match the tokens (like words, but includes strings of numbers and mixed items like passport numbers or SWIFT addresses that are alphanumeric) in the data being screened to the tokens derived from the regulatory list. A prominent exact matching methodology is known colloquially as the Clearing House Algorithm, which was developed by the Clearing House, which runs the CHIPS wholesale funds transfer network and the EPN automated clearinghouse (ACH), back in the 80s.

The good news about exact matching is two-fold: it’s fast and it has the lowest rate of false positives (matches to data that isn’t actually the listed person or entity) of the various technologies. The bad news is that it has limited ability to catch common typographical errors.

Fuzzy matching (or fuzzy search) is similar to exact matching, but will also match data that is “close” to the regulatory data. The quality threshold, which determines how good a match is required for an item to need review, is usually tunable. The result of the fuzzy matching algorithm is often called a “score”, which we’ll use here for convenience. Although it’s not a precise way of looking at it, the threshold is roughly the percentage that is properly matched. Generally, fuzzy matching relies on a concept called “edit distance”, which is a way of counting how many changes would have to be made to one token in order to be identical to another. Popular edit distance algorithms include those by Levenshtein and Hamming. So, JONES and JANE might have an edit distance of 2, for the substitution between the O and the A, and the extra (or missing, depending on your perspective) S. So, using a possible calculation, the resulting match generates a score of roughly 5 (the length of JONES) – 2 (the edit distance) / 5 = 60%.

The big advantage of fuzzy search is that it permits firms with higher risk profiles to cast wider nets, and find matches with a certain level of typos. The disadvantages are equally significant: fuzzy search is slower, and can generate a significantly larger number of matches (part of why it’s slower).

In fact, fuzzy matching generates what’s known as “hockey stick data.” At high matching thresholds, the number of additional matches (compared to exact matching) is small and doesn’t change much for small changes to the threshold, like the blade of a hockey stick. Imagine, for example, a threshold of 98% – it’s hard to get a score that high without trying to match a very long phrase (around 50 characters long).

On the other hand, at some point, the curve inflects and starts rising rapidly, like the shaft of a hockey stick. When does that happen? When the average length of what you’re matching against gets more common, the number of matches rises commensurately. So, a 91% threshold will, generally, let you find errors in 12 character data, and 90% will include 10 and 11-character data. Since you typically match multiple words (like first and last names of individual terrorists or drug traffickers), that’s not totally unreasonable; consider common Hispanic last names of HERNANDEZ (9 characters long), GONZALEZ (8 characters long) and RODRIGUEZ (9 characters long), coupled with common first names like MARIA or JOSE can generate fuzzy matches at 91% and, in some cases, higher percentages.

Phonetic matching algorithms match words that sound alike. There are quite a few phonetic algorithms in use, the most popular being Soundex, Metaphone and Double Metaphone. These algorithms are useful when the assumption is that the information is being heard, not seen. There are a number of downsides, These algorithms are not designed to catch typos, and, as they are based on pronunciation of the words, are language and accent-specific. For example, Diatch-Mokotoff Soundex is best for names of Slavic or Germanic heritage, while Caverphone is optimized for New Zealand accents.

This is only part of the story, of course – there are many options that make these algorithms more or less effective. But that’s the subject of another post – this one’s long enough as is.