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

 

Futures Shock (with apologies to Alvin Toffler)

Recently, a client of mine had told me that they didn't send out future-valued payments (e.g. via SWIFT) more than 2 days ahead, in order to minimize the chance that a person not on their watchlists on instruction date might be on value date, when they'd have to provide the actual funds.

It got me to thinking: what are the obligations regarding futures? Once you have a commitment to consummate a deal, are you done, or do you have to try to cancel things if the lists change? And what happens if you get stuck holding the bag because the banks down the chain have already debited your nostro account?

I know that when I was at UBS, we checked payments only on value date. We had a product where we advised beneficiary banks on instruction date, but provided cover on value date – because we wanted to ensure non-bank beneficiaries in Europe got paid on value date (typically, they get next day value). We didn't check the item on instruction date, only when we had to do the accounting (to the best of my memory – it has been almost a decade). What should we have done?

Well, it seems to me that there are a number of ways to go, all with pitfalls.First, you could screen on instruction date (in case you already have a guy on the list) so any messaging before value date doesn't occur. However, you'd also want to screen on value date so, if the lists changed, you'd be covered there, too.

Of course, the problem with that is what to do if the beneficiary bank already paid the customer and debited your nostro account? Would it be fruitful to chase your money – especially if you didn't provide cover? Or would it be a customer service nightmare?

This problem, of course, is worse if you only screen on value date, as the pre-value messaging has already gone out. If the payment references someone on the list when you receive the instruction, you can try to send a cancellation (e.g. SWIFT MTx92), but technically you shouldn't have sent out the message at all. Is this defensible to regulators? Probably – as long as the listed entity doesn't end up with the funds (after all, you didn't actually fund the cover).

A third option is to check only on instruction date. If your futures are not very far in the future, that's a calculated risk you might be willing to take – that someone doesn't crop up on the list between instruction and value. This is probably the cleanest in terms of process and procedure, but has a greater (athough not significantly so) potential for regulatory entanglements.

What do you think should be done (other than not offering such services)? And what have regulators said on the subject?

 

OFAC FAQ on Due Diligence for Non-Account Parties

116. On February 14, 2008, OFAC issued guidance stating that the property and interests in property of an entity are blocked if the entity is owned, directly or indirectly, 50% or more by a person whose property and interests in property are blocked pursuant to an Executive Order or regulations administered by OFAC. We act as an intermediary bank in wire transfers between other banks. Does OFAC expect banks that are acting as financial intermediaries to research non-account parties that do not appear on the SDN List, but are involved with or referenced in transactions that are processed on behalf of correspondents?

A wire transfer in which an entity has an interest is blocked property if the entity is 50% or more owned by a person whose property and interests in property are blocked. This is true even in instances where such a transaction is passing through a U.S. bank that (1) is operating solely as an intermediary, (2) does not have any direct relationship with the entity (e.g., the entity is a non-account party), and (3) does not know or have reason to know the entity’s ownership or other information demonstrating the blocked status of the entity’s property (e.g., that the entity is located in Cuba). In instances where all three conditions are met, notwithstanding the blocked status of the wire transfer, OFAC would not expect the bank to research the non-account parties listed in the wire transfer that do not appear on the SDN List and, accordingly, would not pursue an enforcement action against the bank for having processed such a transaction.

If a bank handling a wire transfer currently has information in its possession leading the bank to know or have reason to know that a particular individual or entity involved with or referenced in the wire transfer is subject to blocking, then the bank will be held responsible if it does not take appropriate steps to ensure that the wire transfer is blocked.

OFAC expects banks to conduct due diligence on their own direct customers (including, for example, their ownership structure) to confirm that those customers are not persons whose property and interests in property are blocked.

With regard to other types of transactions where a bank is acting solely as an intermediary and fails to block transactions involving a sanctions target, OFAC will consider the totality of the circumstances surrounding the bank’s processing of the transaction, including but not limited to the factors listed above, to determine what, if any, enforcement action to take against the bank. [02-24-09]

 

 

OFAC FAQ on Due Diligence for Non-Account Parties

116. On February 14, 2008, OFAC issued guidance stating that the property and interests in property of an entity are blocked if the entity is owned, directly or indirectly, 50% or more by a person whose property and interests in property are blocked pursuant to an Executive Order or regulations administered by OFAC. We act as an intermediary bank in wire transfers between other banks. Does OFAC expect banks that are acting as financial intermediaries to research non-account parties that do not appear on the SDN List, but are involved with or referenced in transactions that are processed on behalf of correspondents?

A wire transfer in which an entity has an interest is blocked property if the entity is 50% or more owned by a person whose property and interests in property are blocked. This is true even in instances where such a transaction is passing through a U.S. bank that (1) is operating solely as an intermediary, (2) does not have any direct relationship with the entity (e.g., the entity is a non-account party), and (3) does not know or have reason to know the entity’s ownership or other information demonstrating the blocked status of the entity’s property (e.g., that the entity is located in Cuba). In instances where all three conditions are met, notwithstanding the blocked status of the wire transfer, OFAC would not expect the bank to research the non-account parties listed in the wire transfer that do not appear on the SDN List and, accordingly, would not pursue an enforcement action against the bank for having processed such a transaction.

If a bank handling a wire transfer currently has information in its possession leading the bank to know or have reason to know that a particular individual or entity involved with or referenced in the wire transfer is subject to blocking, then the bank will be held responsible if it does not take appropriate steps to ensure that the wire transfer is blocked.

OFAC expects banks to conduct due diligence on their own direct customers (including, for example, their ownership structure) to confirm that those customers are not persons whose property and interests in property are blocked.

With regard to other types of transactions where a bank is acting solely as an intermediary and fails to block transactions involving a sanctions target, OFAC will consider the totality of the circumstances surrounding the bank’s processing of the transaction, including but not limited to the factors listed above, to determine what, if any, enforcement action to take against the bank. [02-24-09]

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]

Private Lives

Watchlists are not just the stuff of regulation; they can also be how the firm institutes its own set of restrictions. The question is: can you incorporate your own internal lists into your other watchlist screening efforts, and what flexibility do you have in that regard?

Questions to consider:

  • Can you define multiple functional lists? Can they be separated out physically, as separate lists? If not, is the process for differentiating between entries of different types (e.g. through a type code or other identifier) easy to leverage in your screening applications?
  • What control do you have over the data elements? Can you create custom fields? Can you control which fields are used for creating matching phrases?
  • What control do you have over matching phrase creation? Can you generate a default set of phrases for a given entry? Can you do that in bulk (i.e. enter all the data, then press a button to fill in all the blanks)? Can you add, change and/or delete matching phrases, whether they were manually created or automatically generated?
  • Can you import an existing list you have in some other format (like, from Excel)? What are the options available with that? Can you specify default values if a required element is not in your current list file? If you import multiple times, does it append to the current list, replace the entire current list, or does it replace newer versions of the same record, and create new records when it can’t find an existing one?
  • Can you wipe out all existing records in bulk if you needed to (e.g. like a 314(a) list)?
  • If the vendor supplies a private list maintenance application (Accuity, my employer, has a nice one), as opposed to importing your data directly into the screening application, do the export capabilities make integration into other applications reasonably easy? In other words, if you have two screening solutions that both need your private lists, can one list maintenance application provide exported files that could be imported into both screening applications – or do you have to maintain the list in multiple places?

It’s a matter of trust – or is it?

Yes, this is a follow-on to my “Who does what” post – because there was an element I wanted to treat separately.

A lot of the matches that an Operations or Compliance staff review are pretty straightforward. There are often name elements that just don’t match, so it’s easy to say that the listed entity doesn’t match the data.

Can you, at a minimum, trust lower-level staff to do that sort of triage? Getting rid of the bulk of potential matches by using someone other than the Chief Compliance Officer or Legal Counsel may be a good, simple, easily defensible trade-off of operational cost vs, regulatory risk.

Does that staff have to be Compliance/Legal staff, or could it be parceled out to the appropriate business unit? Money Transfer Operations staff might be more knowledgable about their payments, after all, and Human Resources is probably, from a legal standpoint, the better place to review employee screening results.

Beyond the patently obvious false positives, can you trust others with some of the day to day review work? Might Documentary Credit know about transaction-specific licenses that are relevant to their clients’ businesses, sparing Compliance/Legal from that spadework?

And let’s say you don’t inherently trust other departments or lower-level Compliance staff with certain final decisions. Could they do the research for you? That way, when it hit the Compliance Officer’s work basket, the bulk of the work would have been done, and only the decision-making would be left. And, in fact, had some data not been gathered, the item could be referred back so the other staff members could go out and retrieve it.

Mr. Watchlist is a fan of getting things done in the most cost-effective way, as long as it’s actually effective. If other, closer to the business and/or more inexpensive, staff can perform the same function as a highly paid Compliance or Legal officer, it would seem to make good economic sense to utilize them in that way.

An added bonus: involving less-knowledgable staff in the day to day review work builds their knowledge base and your firm’s compliance “bench” – some of those folks might want to work in Compliance or Legal one day, and involving them on an ongoing basis will enable them to have that career option, and make your firm’s Compliance capabilities more broadly based.

An added “D’oh” – this is not just a maxim for watchlist screening, or even just for Compliance activities. Spreading the wealth, especially across functional and/or business lines, adds to organizational strength – as Martha Stewart would say, “it’s a good thing.”