November 23, 2015: Technical OFAC Announcement

Technical Announcement Regarding the Download of OFAC’s SDN and Consolidated List Files
​In response to a necessary security upgrade, users of OFAC's SDN and Consolidated List may need to update previously automated file download procedures. Please see the following technical announcement for more details.

Links:

OFAC Notice

Technical Announcement

 

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.