What's everyone done to prepare for the NACHA IAT rules?

We are upgrading our subscription to an OFAC checking solution. (We already had a product, but we are going to the fancier model.) That allows us to scan batch ACH files and split out the IATS so that we up the escalate the ones that have a potential OFAC hit.

We are also in the process of not giving such early credit on ACH direct deposits so that we have more time to scan these files. (We until recently paid on early direct deposit advices. In effect paying them a day early,which was a nightmare on other operational aspects of the bank.)

This second step has been a pain for the last week, training tellers what to tell customers about why their direct deposit isn't available or here yet. But it will solve a settlement issue, and once they (customers) get used to it, it will be fine.

What about policy changes?? What has everyone done as far as changes to ACH and OFAC Policies?

Our core software system will unbatch the ACH and pull out the IATs. These will be OFACd, and suspects will be sent to our Bank to be 'cleared'.

Our current ACH Policy and customer agreement already addressed international ACH's transactions, so no changes there. I do however, need to make changes to the OFAC policy just to reference we will OFAC IAT's.

Fortuneatly, our bank dose not provide the ability to orginate international ACH.

Lori

Lori,

Who is your core processor???

We have reporting from our core processor which will show our OFAC hits and suspects for clearing. We have also updated our BSA, OFAC, ACH and ACH Risk policies for the new rule.

We originate entries for a small number of companies and did not think we needed to do much because we only originate PPD and CCD entries. But I attended an ACH seminar yesterday, and discovered that some current ACH PPD and CCD entries may actual qualify as IATs as well. Given the nature of our Originators, I would be surprised if any do, but we have decided to do a mailing to our Originators notifying them of the new IAT rules and are asking them to contact us if they think it applies to any of their transactions.

I found some good material on the NACHA website on preparing for IAT: http://www.nacha.org/IAT_Industry_Information/

Our core processor is _ Metavante.

We use ITI/Fiserv. They have sent an upgrade and we ran a test thru the Fed. We are going to add some procedures onto our existing ACH procedures and BSA policy/procedures and then wait to see how many we actually recieve. We are a small RDFI and anticipating very few. Our op's processor is going to actually run manual OFAC checks at first and then we'll see what we need to adjust.

It makes sense to make the solution fit the size of the problem. A fly swatter is a lot more effective at what it's used for than a sledge hammer would be.

Lori,

I sent you a PM but haven't heard back from you. Thanks!!

See your PM

Sorry, Lori, but there's nothing there. You were sending me something but I didn't get it.

IAT's = Rg CC and Reg E, what's your take on this?

I don't see IAT having any reg cc issues...

I think there were some comments about being able to delay availablilty on an IAT transaction, but I don't remember where they came from.

There was a question posted in the the tool kit on the NACHA website:Questions have also been raised about the RDFI’s obligation to clear a transaction for purposes of OFAC compliance versus its obligations to comply with Regulation E and
Regulation CC. In these cases, which law or regulation – OFAC or Regulation E or
Regulation CC – takes precedence?

Just curious - for those who will not allow IAT - did you amend your ACH origination agreement? Our ACH agreement does not address international transactions and we don't allow them. So, I don't really want to amend the agreement. Maybe just give cash management customers a notice regarding IAT? What have others out there done?

Our Origination agreement only details which SEC codes they may originate. However, since certain PPDs could qualify as IATs,we decided to send our Originator's a letter notifying them on the new IAT rules and transaction definitions with instructions to notify us if they think they originate transactions that could qualify as IATs.

We are adding a section on IATs to our agreement addendum even though we will not originate them.

How can you deny IAT transactions as a Receiver? Those are the ones of more concern to us. We do not allow international transactions input by Originators but we can't control where we receive transactions from

You cannot deny inbound IATs. You must accept them if received. You do, however, have a wider return window, because all IATs will be covered by the 60+1 rule for return, based on the fact that they can post to both commercial and consumer accounts.