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 SPL lists 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!
Kevin Riddell
Kevin Riddell
No comments:
Post a Comment