Category Archives: Technology

April 6, 2015: Consolidated Sanctions List now in advanced format.

On April 6th, OFAC released the Consolidated Sanctions List (the 5 non-SDN lists – Palestinian Leadership Council List, Part 561 List, Iran Sanctions Act List, Foreign Sanctions Evaders List, Sectoral Sanctions Identification List) in the new advanced format that it previously had released the SDN List in. The new format, which had been developed by the Wolfsberg Group and the United Nations, “incorporates a variety of features that ensure maximum flexibility for sanctions list creators, while also limiting the need for future changes to the underlying data specification due to the standard’s adaptability.”

Links:

OFAC Notice

Advanced Format FAQ

 

Notice to Exporters 2015/14: Checker Tools now on SPIRE

From the UK's Export Control Organization (ECO):

1. The Checker Tools (OGEL Checker and Goods Checker) operated by the Export Control Organisation (ECO) have been redesigned and will now operate under the SPIRE online export licensing system, as well as being available directly via the internet.

2. The Checker Tools features will remain the same but the presentation has been updated. The main differences are:

    • Users can now access the Checker Tools without needing to log on using a password. The new landing page has guidance on using the tools and examples.
    • If you are a registered SPIRE user, you can access the Checker Tools from within SPIRE, once you have logged on.

What does this mean for me as an exporter?

3. When using the Goods Checker, you no longer need to add the dots to separate sub entries in a Control Entry. (For example, you don’t need to enter ‘3A001.a.7.a’ to find this entry; on the new Goods Checker you can enter ‘3A001a7a’. ) The OGEL Checker has always used this system and so the two tools are now aligned.

4. In the OGEL Checker, you can now display possible OGELs in alphabetical order or by ‘Activity’, which groups OGELs according to the way they are used.

5. Please note: The dedicated Helpline for the Checker Tools (help@ecochecker.co.uk) is no longer available. All queries relating to the Checker Tools should be emailed to: eco.help@bis.gsi.gov.uk

Link:

Notice to Exporters 2015/14

 

January 5, 2015: OFAC introduces new, improved sanctions list format for SDN List

OFAC, the United Nations and the Wolfsberg Group have been developing a standard, enhanced file format for sanctions data. The SDN List will now be available, as of Monday, in this format, which has the following features (according to the OFAC Notice):

• The advanced format provides a great deal of new metadata including specific labels for name parts that go beyond the standard, “Last name, First name” style of current sanctions lists. The advanced format now allows for unique name parts to be used, labeled and properly ordered based on the nomenclature rules of a specific culture, language, or region.

• The new format now supports language scripts beyond the standard Latin script used in many sanctions lists. It is now possible for sanctions targets to be provided to users in their original script (e.g., Arabic) and other non-Latin script translations. The Treasury Department will provide a Latin script translation for all listed, non-Latin script sanctions targets.

• The advanced list format provides a data dictionary of all valid look-up values in the header of the file. Including a data dictionary with the underlying data makes it easier for list users to construct databases that contain identifiers and other information that match the data in OFAC’s systems. When new look-up values are introduced to a sanctions list, this data dictionary is automatically updated.

• This new format introduces a flexible, “feature identifier” functionality that augments the normal identification look-up values that are currently available in the SDN List formats. Historically, the “remarks field” in the Treasury SDN list’s data format had been used for information that did not easily fit into existing fields and identifier categories. Using the advanced format, Treasury will now be able to provide easily-parsed, non-traditional identifier information.

Links:

OFAC Notice

OFAC Advanced Sanctions Data Model page

SDN XML Advanced Sanctions Data Schema

Explanatory Document for Advanced Sanctions Data Model

FAQ for Advanced Sanctions Data Model

 

October 10, 2014: OFAC introduces the Consolidated Sanctions List

On Friday, OFAC announced that it would now all 5 of its non-SDN lists in a data file format suitable for using in screening systems (similar to the files already available for the SDN List).

The 5 lists are:

  • Palestinian Council List (NS-PLC)
  • Iran Sanctions Act List (NS-ISA)
  • Part 561 (CISADA) List
  • Foreign Sanctions Evaders List (FSE)
  • Sectoral Sanctions Identification List (SSI)

Within 6 months, the current data files for the FSE, PLC and SSI Lists will be discontinued. The separate PDF and TXT files for each individual list will continue to be maintained, however.

In addition, the OFAC Notice notes that the current online search tool has been upgraded to also search the Consolidated Sanctions List.

Links:

OFAC Notice

Consolidated Sanctions List information

Consolidated Sanctions List data files download page

Consolidated Sanctions List specifications

 

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]

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.

OFAC Updates for February 5, 2013

A three-parter from OFAC today: updates to the Kingpin Act (narcotics trafficking) and anti-terrorism sanctions, and release of a beta version of a fuzzy search tool.

First, there are a sizable number of new designations under the narcotics trafficking sanctions:

​GARCIA AYALA, Filemon, C Constitucion # 32, Col Rio Grande, Rio Grande, Zacatecas 98400, Mexico; Matamoros, Tamaulipas, Mexico; Rio Grande, Zacatecas, Mexico; DOB 28 Oct 1948; alt. DOB 26 Oct 1948; alt. DOB 27 Oct 1948; POB Loreto, Zacatecas, Mexico; Passport 160010455 (Mexico) issued 03 May 2002 expires 03 May 2012; C.U.R.P. GAAF481027HZSRYL07 (Mexico); alt. C.U.R.P. GAAF481026HTSRYL08 (Mexico) (individual) [SDNTK].

INTERNACIONAL & NACIONAL EXCHANGE SERVICES, INC., Pharr, TX; Business Registration Document # 801199276 (Texas); Tax ID No. 32040757414 [SDNTK].

PRODIRA CASA DE CAMBIO, ACTIVIDAD AUXILIAR DEL CREDITO S.A. DE C.V., Blvd La Florida 3-A, Colonia La Florida, Guadalupe, Zacatecas 98618, Mexico; RFC PCC031010989 (Mexico) issued 18 Dec 2003 [SDNTK].

PRODIRA S.A. DE C.V., CASA DE CAMBIO, ACTIVIDAD DEL CREDITO (a.k.a. PRODIRA CASA DE CAMBIO INCORPORATED), Pharr, TX; Business Registration Document # 801041970 (Texas); Tax ID No. 32038179357 [SDNTK].

PRODIRA, INC., Aurora, CO; Phoenix, AZ; Des Moines, IA; Pharr, TX; Business Registration Document # F-853615-0 (Arizona); alt. Business Registration Document # 20011210699 (Colorado); alt. Business Registration Document # 335187 (Iowa); alt. Business Registration Document # 148693800 (Texas); Tax ID No. 17428803666 [SDNTK].

TRASTREVA S.A. DE C.V., Av. La Florida 3, La Florida, Guadalupe, Zacatecas 98610, Mexico; Cedula No. DLC/P/152/2011 (Mexico); R.F.C. TRA0010109E4 (Mexico) [SDNTK].

Second, a large number of deletions were made under the anti-terror sanctions:

ATWAH, Muhsin Musa Matwalli (a.k.a. ABDEL RAHMAN; a.k.a. ABDUL RAHMAN; a.k.a. AL-MUHAJIR, Abdul Rahman; a.k.a. AL-NAMER, Mohammed K.A.), Afghanistan; DOB 19 Jun 1964; POB Egypt; citizen Egypt (individual) [SDGT].

ABDEL RAHMAN (a.k.a. ABDUL RAHMAN; a.k.a. AL-MUHAJIR, Abdul Rahman; a.k.a. AL-NAMER, Mohammed K.A.; a.k.a. ATWAH, Muhsin Musa Matwalli), Afghanistan; DOB 19 Jun 1964; POB Egypt; citizen Egypt (individual) [SDGT].

ABDUL RAHMAN (a.k.a. ABDEL RAHMAN; a.k.a. AL-MUHAJIR, Abdul Rahman; a.k.a. AL-NAMER, Mohammed K.A.; a.k.a. ATWAH, Muhsin Musa Matwalli), Afghanistan; DOB 19 Jun 1964; POB Egypt; citizen Egypt (individual) [SDGT].

AL-MUHAJIR, Abdul Rahman (a.k.a. ABDEL RAHMAN; a.k.a. ABDUL RAHMAN; a.k.a. AL-NAMER, Mohammed K.A.; a.k.a. ATWAH, Muhsin Musa Matwalli), Afghanistan; DOB 19 Jun 1964; POB Egypt; citizen Egypt (individual) [SDGT].

AL-NAMER, Mohammed K.A. (a.k.a. ABDEL RAHMAN; a.k.a. ABDUL RAHMAN; a.k.a. AL-MUHAJIR, Abdul Rahman; a.k.a. ATWAH, Muhsin Musa Matwalli), Afghanistan; DOB 19 Jun 1964; POB Egypt; citizen Egypt (individual) [SDGT].

MSALAM, Fahid Mohammed Ally (a.k.a. AL-KINI, Usama; a.k.a. ALLY, Fahid Mohammed; a.k.a. MSALAM, Fahad Ally; a.k.a. MSALAM, Fahid Mohammed Ali; a.k.a. MSALAM, Mohammed Ally; a.k.a. MUSALAAM, Fahid Mohammed Ali; a.k.a. SALEM, Fahid Muhamad Ali); DOB 19 Feb 1976; POB Mombasa, Kenya; citizen Kenya (individual) [SDGT].

ALLY, Fahid Mohammed (a.k.a. AL-KINI, Usama; a.k.a. MSALAM, Fahad Ally; a.k.a. MSALAM, Fahid Mohammed Ali; a.k.a. MSALAM, Fahid Mohammed Ally; a.k.a. MSALAM, Mohammed Ally; a.k.a. MUSALAAM, Fahid Mohammed Ali; a.k.a. SALEM, Fahid Muhamad Ali); DOB 19 Feb 1976; POB Mombasa, Kenya; citizen Kenya (individual) [SDGT].

MUSALAAM, Fahid Mohammed Ali (a.k.a. AL-KINI, Usama; a.k.a. ALLY, Fahid Mohammed; a.k.a. MSALAM, Fahad Ally; a.k.a. MSALAM, Fahid Mohammed Ali; a.k.a. MSALAM, Fahid Mohammed Ally; a.k.a. MSALAM, Mohammed Ally; a.k.a. SALEM, Fahid Muhamad Ali); DOB 19 Feb 1976; POB Mombasa, Kenya; citizen Kenya (individual) [SDGT].

MSALAM, Fahid Mohammed Ali (a.k.a. AL-KINI, Usama; a.k.a. ALLY, Fahid Mohammed; a.k.a. MSALAM, Fahad Ally; a.k.a. MSALAM, Fahid Mohammed Ally; a.k.a. MSALAM, Mohammed Ally; a.k.a. MUSALAAM, Fahid Mohammed Ali; a.k.a. SALEM, Fahid Muhamad Ali); DOB 19 Feb 1976; POB Mombasa, Kenya; citizen Kenya (individual) [SDGT].

SALEM, Fahid Muhamad Ali (a.k.a. AL-KINI, Usama; a.k.a. ALLY, Fahid Mohammed; a.k.a. MSALAM, Fahad Ally; a.k.a. MSALAM, Fahid Mohammed Ali; a.k.a. MSALAM, Fahid Mohammed Ally; a.k.a. MSALAM, Mohammed Ally; a.k.a. MUSALAAM, Fahid Mohammed Ali); DOB 19 Feb 1976; POB Mombasa, Kenya; citizen Kenya (individual) [SDGT].

MSALAM, Mohammed Ally (a.k.a. AL-KINI, Usama; a.k.a. ALLY, Fahid Mohammed; a.k.a. MSALAM, Fahad Ally; a.k.a. MSALAM, Fahid Mohammed Ali; a.k.a. MSALAM, Fahid Mohammed Ally; a.k.a. MUSALAAM, Fahid Mohammed Ali; a.k.a. SALEM, Fahid Muhamad Ali); DOB 19 Feb 1976; POB Mombasa, Kenya; citizen Kenya (individual) [SDGT].

AL-KINI, Usama (a.k.a. ALLY, Fahid Mohammed; a.k.a. MSALAM, Fahad Ally; a.k.a. MSALAM, Fahid Mohammed Ali; a.k.a. MSALAM, Fahid Mohammed Ally; a.k.a. MSALAM, Mohammed Ally; a.k.a. MUSALAAM, Fahid Mohammed Ali; a.k.a. SALEM, Fahid Muhamad Ali); DOB 19 Feb 1976; POB Mombasa, Kenya; citizen Kenya (individual) [SDGT].

MSALAM, Fahad Ally (a.k.a. AL-KINI, Usama; a.k.a. ALLY, Fahid Mohammed; a.k.a. MSALAM, Fahid Mohammed Ali; a.k.a. MSALAM, Fahid Mohammed Ally; a.k.a. MSALAM, Mohammed Ally; a.k.a. MUSALAAM, Fahid Mohammed Ali; a.k.a. SALEM, Fahid Muhamad Ali); DOB 19 Feb 1976; POB Mombasa, Kenya; citizen Kenya (individual) [SDGT].

SWEDAN, Sheikh Ahmed Salim (a.k.a. ALLY, Ahmed; a.k.a. SUWEIDAN, Sheikh Ahmad Salem; a.k.a. SWEDAN, Sheikh; a.k.a. SWEDAN, Sheikh Ahmed Salem; a.k.a. “AHMED THE TALL”; a.k.a. “BAHAMAD”; a.k.a. “BAHAMAD, Sheik”; a.k.a. “BAHAMADI, Sheikh”); DOB 09 Apr 1969; alt. DOB 09 Apr 1960; POB Mombasa, Kenya; citizen Kenya (individual) [SDGT].

SUWEIDAN, Sheikh Ahmad Salem (a.k.a. ALLY, Ahmed; a.k.a. SWEDAN, Sheikh; a.k.a. SWEDAN, Sheikh Ahmed Salem; a.k.a. SWEDAN, Sheikh Ahmed Salim; a.k.a. “AHMED THE TALL”; a.k.a. “BAHAMAD”; a.k.a. “BAHAMAD, Sheik”; a.k.a. “BAHAMADI, Sheikh”); DOB 09 Apr 1969; alt. DOB 09 Apr 1960; POB Mombasa, Kenya; citizen Kenya (individual) [SDGT].

SWEDAN, Sheikh Ahmed Salem (a.k.a. ALLY, Ahmed; a.k.a. SUWEIDAN, Sheikh Ahmad Salem; a.k.a. SWEDAN, Sheikh; a.k.a. SWEDAN, Sheikh Ahmed Salim; a.k.a. “AHMED THE TALL”; a.k.a. “BAHAMAD”; a.k.a. “BAHAMAD, Sheik”; a.k.a. “BAHAMADI, Sheikh”); DOB 09 Apr 1969; alt. DOB 09 Apr 1960; POB Mombasa, Kenya; citizen Kenya (individual) [SDGT].

SWEDAN, Sheikh (a.k.a. ALLY, Ahmed; a.k.a. SUWEIDAN, Sheikh Ahmad Salem; a.k.a. SWEDAN, Sheikh Ahmed Salem; a.k.a. SWEDAN, Sheikh Ahmed Salim; a.k.a. “AHMED THE TALL”; a.k.a. “BAHAMAD”; a.k.a. “BAHAMAD, Sheik”; a.k.a. “BAHAMADI, Sheikh”); DOB 09 Apr 1969; alt. DOB 09 Apr 1960; POB Mombasa, Kenya; citizen Kenya (individual) [SDGT].

“BAHAMADI, Sheikh” (a.k.a. ALLY, Ahmed; a.k.a. SUWEIDAN, Sheikh Ahmad Salem; a.k.a. SWEDAN, Sheikh; a.k.a. SWEDAN, Sheikh Ahmed Salem; a.k.a. SWEDAN, Sheikh Ahmed Salim; a.k.a. “AHMED THE TALL”; a.k.a. “BAHAMAD”; a.k.a. “BAHAMAD, Sheik”); DOB 09 Apr 1969; alt. DOB 09 Apr 1960; POB Mombasa, Kenya; citizen Kenya (individual) [SDGT].

ALLY, Ahmed (a.k.a. SUWEIDAN, Sheikh Ahmad Salem; a.k.a. SWEDAN, Sheikh; a.k.a. SWEDAN, Sheikh Ahmed Salem; a.k.a. SWEDAN, Sheikh Ahmed Salim; a.k.a. “AHMED THE TALL”; a.k.a. “BAHAMAD”; a.k.a. “BAHAMAD, Sheik”; a.k.a. “BAHAMADI, Sheikh”); DOB 09 Apr 1969; alt. DOB 09 Apr 1960; POB Mombasa, Kenya; citizen Kenya (individual) [SDGT].

“BAHAMAD” (a.k.a. ALLY, Ahmed; a.k.a. SUWEIDAN, Sheikh Ahmad Salem; a.k.a. SWEDAN, Sheikh; a.k.a. SWEDAN, Sheikh Ahmed Salem; a.k.a. SWEDAN, Sheikh Ahmed Salim; a.k.a. “AHMED THE TALL”; a.k.a. “BAHAMAD, Sheik”; a.k.a. “BAHAMADI, Sheikh”); DOB 09 Apr 1969; alt. DOB 09 Apr 1960; POB Mombasa, Kenya; citizen Kenya (individual) [SDGT].

“BAHAMAD, Sheik” (a.k.a. ALLY, Ahmed; a.k.a. SUWEIDAN, Sheikh Ahmad Salem; a.k.a. SWEDAN, Sheikh; a.k.a. SWEDAN, Sheikh Ahmed Salem; a.k.a. SWEDAN, Sheikh Ahmed Salim; a.k.a. “AHMED THE TALL”; a.k.a. “BAHAMAD”; a.k.a. “BAHAMADI, Sheikh”); DOB 09 Apr 1969; alt. DOB 09 Apr 1960; POB Mombasa, Kenya; citizen Kenya (individual) [SDGT].

“AHMED THE TALL” (a.k.a. ALLY, Ahmed; a.k.a. SUWEIDAN, Sheikh Ahmad Salem; a.k.a. SWEDAN, Sheikh; a.k.a. SWEDAN, Sheikh Ahmed Salem; a.k.a. SWEDAN, Sheikh Ahmed Salim; a.k.a. “BAHAMAD”; a.k.a. “BAHAMAD, Sheik”; a.k.a. “BAHAMADI, Sheikh”); DOB 09 Apr 1969; alt. DOB 09 Apr 1960; POB Mombasa, Kenya; citizen Kenya (individual) [SDGT].

ALI, Abbas Abdi, Mogadishu, Somalia (individual) [SDGT].

DARWISH, Sulayman Khalid (a.k.a. “ABU AL-GHADIYA”), Syria; DOB 1976; alt. DOB circa 1974; POB Outside Damascus, Syria; nationality Syria; Passport 3936712 (Syria); alt. Passport 11012 (Syria) (individual) [SDGT].

“ABU AL-GHADIYA” (a.k.a. DARWISH, Sulayman Khalid), Syria; DOB 1976; alt. DOB circa 1974; POB Outside Damascus, Syria; nationality Syria; Passport 3936712 (Syria); alt. Passport 11012 (Syria) (individual) [SDGT].

Lastly, OFAC has updated its SDN Search Tool to include fuzzy logic. You can adjust the sensitivity of the search to be more or less permissive. Here’s the FAQ from the information page:

1) How does SDN Search work?

In addition to returning results that are exact matches (when the match threshold slider bar is set to 100%), SDN Search can also provide a broader set of results using fuzzy logic. This logic uses character and string matching as well as phonetic matching. Only the name field of SDN Search invokes fuzzy logic when the tool is run. The other fields on the tool use character matching logic. Please click here for more information on what a true SDN match is.

2) What does the SDN Search Score mean?

The score field indicates the similarity between the name entered and resulting matches on the SDN List. It is calculated using two matching logic algorithms: one based upon phonetics, and a second based upon the similarity of the characters in the two strings. A score of 100 indicates an exact match, while lower scores indicate potential matches.

3) How do I use the Minimum Name Score field and score slider bar?

The minimum name score field limits the number of names returned by the search. A value of 100 will return only names that exactly match the characters entered into the name field. A value of 50 will return all names that are deemed to be 50% similar based upon the matching logic of the search tool. By lowering the match threshold the system will return a broader result set.

4) How is the Score calculated?

SDN search uses two matching logic algorithms, and two matching logic techniques to calculate the score. The two algorithms are Jaro-Winkler, a string difference algorithm, and Soundex, a phonetic algorithm. The first technique involves using the Jaro-Winkler algorithm to compare the entire name string entered against full name strings of SDN entries. The second technique involves splitting the name string entered into multiple name parts (for example, John Doe would be split into two name parts). Each name part is then compared to name parts on the SDN list using the Jaro-Winkler and Soundex algorithms. The search calculates a score for each name part entered, and a composite score for all name parts entered. SDN Search uses both techniques each time the search is run, and returns the higher of the two scores in the Score column.

5) Does OFAC recommend a specific match threshold score?

OFAC cannot make such a recommendation because each search has its own unique set of facts surrounding it. Users of SDN Search must make their own match threshold determinations based upon their own internal risk assessments and established compliance practices.

6) What fields influence the score?

Only the name field influences the score.

7) What fields use fuzzy logic?

Only the name field uses the fuzzy searching logic.

8) When conducting a search using the ID field, does SDN Search account for variations in non-alphanumeric characters?

At present, SDN Search’s ID field uses exact character matching to provide users with a result. In order to receive the broadest number of results, users should conduct ID field searches both with and without any non-alphanumeric characters. An upcoming update to SDN Search will allow for searching of the ID field regardless of whether or not non-alphanumeric characters are included.

Links:

OFAC Press release
SDN Fuzzy Logic Search Tool page

Matching Multiple Factors

If your main focus is screening business transactions, you can skip to the next blog item you wanted to read – nothing to see here for you.

On the other hand, if you screen static data, like customer records or insurance policies, one way to cut down the number of matches is to attempt additional matches beyond the basic matching phrase. The results of these additional matches can then be used to better assess the quality of that match and potentially skip over the matches which do poorly on the additional comparisons.

It’s reasonable to assume that the additional matching is between elements of your data and elements in (or associated with) the watchlist listing. Typically, both of these records may have the following in common:

  • The address, city and country of residence or domicile
  • Date of birth
  • Identification number, like passport number, national id (like SSN or Cedula), corporate id (like TIN, DUNS id, or VAT id), SWIFT address, IMO number or call sign

In addition, a comparison of the full name from your data could be made to the full listed name.

There are pitfalls to many of these additional checks:

  • A company that has many locations may not be listed on the sanctions lists under all of them, so an address or even city comparison may fail when it’s valid
  • Multiple lists may list dates of birth in different formats, so comparisons of dates beyond year may be inaccurate unless the other components are known to be reliable
  • Some listed persons’ dates of birth are listed as approximate and should not be used in comparisons
  • Name comparisons will yield inaccurate results if the name field can contain multiple parties (e.g. joint account ownership)
  • Name comparisons, of course, must account for name variations (Bill vs. William), use of initials

So, how are these results used? Depends on your technology, of course. Basically, though, each comparison that is performed generates some sort of score. These scores can either be evaluated singly or can be combined into an overall weighted score. Systems can either display these values for informational and evaluational purposes, or may provide rules-based processing to ignore matches with low score values.

What’s the frequency, Kenneth?

In a recent post, I suggested that workflow design be dictated, to some extent, by volumes. If you have lots of states or work folders that are lightly used, you might be better off with rethinking how you segment your data and design your workflow.

Well, the same is true for false positive reduction (FPR) configuration. Making a system change to save a single match that may or may not recur is not a good use of operations or IT resources; it may take less time to clear an individual item than it does to figure out the change you want to make, get it approved, test the change thoroughly and implement it.

In general, rules-based processing (as opposed to whitelisting) should be modified for recurring, higher-volume matches. Where that lower bound is for a particular firm, within limits, depends on where they want to spend their money – on staff or consultants to modify the system or on operational staff to clear the matches.

Some examples:

  1. My first client was an investment bank. They had 1100 FPR rules, some of which were unclear to me as to intent. So, we scanned 6 months’ of traffic to determine what got ignored due to those rules Guess what? 500 of the rules were unused. Apparently, operational staff had written a rule each time they got a match.
  2. An investment bank was performing watchlist screening for a check disbursement product. None of the matches were high-volume, but they were clock-like in their regularity – each biweekly or monthly. And they had a lot of them. For them, anything that was regular was fair game, because that was the nature of the business.
  3. When I was at UBS, we processed German war reparations payments once a quarter. On that single day, 4 times a year, our matches doubled because of how the bank formatted SWIFT field 72. If you averaged those matches over the entire quarter, they fell below the threshold used to change the application configuration. However, since the impact on those 4 dates was so significant, we addressed those matches with system changes.
  4. A recent client had a fair amount of high-frequency matches, but also a decent number of lower-frequency ones. While the high-frequency matches constituted maybe 50-60% of the total, the client wanted to derive as much value from our time, and minimize their internal operations costs, so we included the lower-frequency items and reduced matches by over 90%.

The “how” of finding out what changes to make is another post for another day – it’s boring Excel and/or Access stuff.

For those not as old as I am, or from outside the US, let me explain the title (beyond its relevance to the subject matter). On October 4, 1986, longtime CBS anchorman Dan Rather was mugged by two men who kept asking him “Kenneth, what is the frequency?”. In 1994, the band R.E.M. included the song “What’s the frequency, Kenneth?”, referring to that incident, on their Monster album. So, now you know…