A recent OFAC press release, and guidance document, offers some good advice, but also risks misleading readers. A careful read of the case and guidance will reveal a hidden lesson to be learned. At first glance, the guidance simply reminds companies to ensure their Sanctioned Party Lists (SPL) are updated and reviewed, and most readers will come away satisfied that they are compliant. A primary message in the guidance refers to what they call “false hit lists”, and reminds readers to ensure entities on that list are reviewed as regulations change. Upon a deeper look, however, this Finding of Violation contains another lesson, one that may surprise readers and give them reason to review their compliance program. Before we explain that statement, let’s take a good look at the finding, and the guidance.
The bank responsible for the violation, as far as can be ascertained from the public notice, was guilty of the following: making 6 funds transfers in violation of 31 cfr 560.204. Without getting into too much detail, the primary offending act was the purchase in the USA of Iranian (Persian) carpets. The buyer of the carpets (the bank’s customer) had been doing so legally when there was a general license offered for Persian carpets, but then continued to do so after the license was revoked in 2010. The bank’s violation occurred when they made the money transfers for their customer after 2010. It’s a little unclear if the transfer was directly to Iran, or to an Iranian individual in the USA, for the benefit of the Iranian vendor. That difference is irrelevant, as 560.204 would still apply as interpreted in 560.410. The important point is that a business practice became illegal after 2010, due to a regulatory change, and the bank did not adapt.
OFAC makes an interesting statement at this point, that the bank “did not remove the company from the “false hit list”. Later we learn that as a result of this, OFAC is offering guidance to industry regarding the use of “false hit” lists – lists of parties that are deemed screened and no longer requiring screening. The focus is on the particular customer of the bank – apparently the customer had been flagged by their SPL screening software, due to the word “Persian”, but the bank had placed them on a “false hit” list to ensure no business interruptions – it appears this means they were placed on a “do not screen list” and removed from the SPL screening process.
OFAC then issued guidance, and emphasises the review and re-screening of any party placed on a “false hit” list.
OFAC gives (rightfully) caution regarding this practice, and warns companies to be very careful before removing an entity from their screening program. The reason for this, is that changes to regulations could mean that party is prohibited at some time in the future. As a SAP GTS user, to put this in perspective, OFAC is warning against the use of “Positive Lists” – lists of parties that will no longer be screened. This is sound advice – placing a customer on a “do not screen” list means you will miss it, if they get listed at some point in the future. A better solution is to ensure parties are screened against all changed or new SPL list data (commonly called “delta screenings”), but you don’t need to re-screen them against the same SPL data again. This is standard configuration for SAP GTS, and likely most SPL screening systems.
Everything sounds nice and neat – as long as you ensure all parties are rescreened against changed or new SPL list data, you’ll be fine, right? Unfortunately – no. A deeper look at the notice reveals a more complicated side to the story. The public notice even admits that the company was screening against SDN lists, and that they updated that data – “(the company’s) OFAC compliance program failed to include procedures for updating its internal sanctions list following changes to the sanctions programs administered by OFAC (other than updates to the SDN List).” So what gives? What’s all this “false hit list” business if they were in fact screening against updated SPL lists? Who else does Treasury expect us to screen against?
Well, let’s go back to 560.204 and have a good look. 204 is not a prohibition against dealing with listed SDN entities. It is rather a prohibition against extending services to an entity in Iran, or to someone in the US where the benefit of the services is presumed to be received in Iran, as clarified in 560.410. Here is a quote from section 410: “Example. A United States person is engaged in a prohibited exportation of services to Iran when it extends credit to a third-country firm specifically to enable that firm to manufacture goods for sale to Iran or for an entity of the Government of Iran”
In other words – you can violate 560.204 even though your US customer is not listed on any SPL list. This can happen if the service you provide them is ultimately helping an entity in Iran. And SPL screening may not help you here – let’s be clear on this. In the example given, SPL screening was returning a hit caused by the word “Persian” in the entity’s name, but there is no reason to believe 560.204 violations will always be so easy. If the customer was called John Smith Inc., the violation still exists if all other facts remain the same, and no amount of SPL screening will help you here.
How then, are we to comply? Well, first of all let me restate – the OFAC guidance on what they term “false hit lists” (and I call “Positive” lists, or “do not screen” lists) is sound advice – I am not questioning that. I’m just stating it may not be enough. The only way to catch my John Smith Inc. example is through training, retraining and education. Ensure your sales, customer service and logistics staff know the rules, and take them seriously. If they catch one whiff of “Iran” (or any other forbidden country/entity) in the transaction, they need to come running to legal or compliance for help.
That said – automation is still essential. Most SPL software allow you to build your own lists, to augment the government published ones. Anytime you discover an entity that puts you in 560.204 risk, place them on your internal “sanction” list and leave them there. That protection will go a long way to ensuring you never accidentally violate the OFAC rules.
Another layer of protection can be added through import/export license automation. While a bank may find this more difficult, an import/export company can flag the product in question (in this example Persian Rugs) as requiring a license. They can then take advantage of general licenses when they exist, and prevent accidental transactions when the general license is revoked – the system is focussing on the product, not the entity.
When you combine training, communication and a sound automation solution, you have the makings of a strong compliance program. Lacking any part of this complete package, like a weak link in a chain, can lead to your company’s name in the news – exactly what compliance managers are working to avoid!
Guest Blogger: Kevin Riddell, CCLP
Co-author of Practical Guide to SAP GTS