The heading of this blog posting seems to state a question with an obvious answer: yes, the United States Department of the Treasury’s Office of Foreign Assets Control (OFAC) obviously doesn’t want to deal with frivolous licenses applications. But the real question is are they fed up with them? The reason I raise this question is because of certain language OFAC has included in recent a cover letters to a license I received. Late last year I filed a fairly lengthy license application on behalf of a client requesting numerous authorizations for the client’s proposed transactions involving Iran. Included in those authorizations was a request for OFAC to confirm that the use of money exchangers was OK in remitting funds to Iran for an authorized purpose. The reason for the question, is because I had previously informed the client and their bank that the remittance was authorized, pursuant to 31 CFR 560.550, due its non-commercial, personal nature. Regardless of the legality of the transfer, the U.S. bank would not remit the payment to a third country money service business for ultimate transfer to a private Iranian bank designated solely under E.O. 13599. As such, I included, in a longer license application on behalf of the client for other purposes, a request for OFAC to provide guidance on the issue in writing so that we could prove to the bank its legality. This is generally standard practice when something is generally licensed, or at least appears to be, but a financial institution wants some proof of that general authorization’s applicability to the proposed transaction.

Ultimately, we received the guidance and the license authorization from OFAC, however, there was some language in the cover letter to the license application that I had not seen included before and that was interesting to me. OFAC stated in the cover letter, “Please note that funds transfers to Iran through third-country money service businesses may be effected according to the terms of the authorization of section 560.516 of the ITSR, and thus no further authorization from OFAC is necessary. Indeed, it is the policy of OFAC not to grant applications for specific licenses authorizing transactions to which the provisions of an outstanding general license are applicable. 31 C.F.R. 501.801”

The reason I find this interesting is because I have heard from several sources that OFAC may soon stop responding to license applications which request authorizations for transactions which are clearly permissible by exemption or general license. This new language I refer to above, would clearly indicate that OFAC is beginning to shift in that direction. While of course it makes sense for OFAC to do this at a time of increased sanctions with no increase in resources, the danger is that it leads to one of two outcomes. One, it could cause people to be more cavalier in their interpretations of what OFAC general licenses permit. This would be incredibly dangerous given that OFAC violations are enforced on a strict liability basis. Ont the other hand, and probably more likely, it could lead to transactions for which authorization exists not being effectuated because the parties involved are too scared to act without some positive confirmation from OFAC.

In short, if this will really become OFAC’s policy, it could either be a roadblock to those wanting clarity on whether or not their activity falls under a general license, or it could be a boon for lawyers working in the OFAC area whose guidance on such issues would become ever more valuable. While I’m typically an optimistic person, I think the former scenario is more likely. Most people are uncomfortable operating merely on the text of a regulation and blind faith alone. Moreover, even for the more adventurous types out there, getting a U.S. bank to process a transaction merely based on a general license and your word may prove to be difficult.

The author of this blog is Erich Ferrari, an attorney specializing in OFAC matters. If you have any questions please contact him at 202-280-6370 or ferrari@ferrariassociatespc.com.