Can someone please summarize for me who (ODFI, RDFI) is responsible for OFAC compliance and who (sender, receiver) needs to be verified against the OFAC list, for each type of ACH transaction:

domestic ACH credit
domestic ACH debit
foreign ACH credit
foreign ACH debit

I've read throug the NACHA handbook and other resources and find this to be very confusing!

Thank You!

As the RDFI, you are responsible for:

• Domestic ACH credit: Determining whether any of your account holders is identified as a blocked party on the current SDN list. Freezing incoming credits to such a person's account.
• Domestic ACH debits: Know whether any of your account holders is a blocked party on the SDN list. Ensure the account is frozen, return the debit R16 (with an advice it was an OFAC blocked entry) and notify OFAC.
• IAT credits: If the receiver is a blocked party, post the credit entry, ensure the account remains frozen, and report to OFAC. If the originator is an OFAC blocked party, do not post the transaction. Suspend the entry (hold onto it) and report to OFAC, which will give you instructions.
• IAT debits: If the entry is unlawful under OFAC sanctions, contact OFAC for guidance (to be handled on case-by-case basis).

As you can see, for international entries (IATs) you need to scan the entire transaction record, including the addenda records, to do a complete OFAC check on all parties.

Thank You John! That's what I was looking for.

One more if I may: For IAT's - do we need to OFAC the bank it came from/is going to, or just the originator and receiver?

Every field in the whole record. There are blocked banks outside the U.S.

What does the OFAC screening indicator offer? I understand the RDFI is ultimately responsible, but is the ODFI or the gateway responsible for making sure the indicator is marked accordingly?

The screening indicator is really something for the Gateway Operator. If the field is empty, it's supposed to mean that it has not been checked. On inbound IATs, a value of "0" means the GO found no OFAC hits. A value of "1" means the GO identified an OFAC suspect. The GO is responsible for populating the field.

We get a few Paypal IATs that are suspect hits that do not seem to have the indicator marked. Is Paypal or the processing bank at fault for not populating the field? Again, I realize we are ultimately responsible as the RDFI.

BTW thank you for your response, John.

We are the ODFI for an originator that meets the definition of a 3rd party sender under NACHA rules. We have a client that works with several third parties (payday lenders) to process the third party billings. The originator (our customer) creates a batch ACH file which includes lots of receivers (all US banks, no IAT's).

We have done our due diligence with our customer (as a deposit customer, a 3rd party sender, done due diligence on the parties our customer is processing for including an OFAC check).

My question is this - Do we have responsibility as the ODFI to check each of the receiver names included in the batch file?

I don't think we do as that's the responsibility of the RDFI. Our responsibility with these files would be if any of them are returned (R16), then we'd need to check against OFAC.

I understand that nothing needs to be checked against the OFAC list - it's dictated by the bank's risk assessment. We are not in a high risk area but the mere fact that our customer is acting as a 3rd party sender for payday lenders around the country and the receivers are also all around the country makes me a little nervous. I firmly believe we've done good due diligence on our customer and the 3rd parties, just not the receivers.

However, if it's the responsibility of the RDFI to run the receiver names against OFAC, I'd sure feel a whole lot better. Our OFAC possible hit list has grown quite long recently with false positives since our customer started being a 3rd party processor. Our report shows both incoming and outgoing ACH items.

http://www.ffiec.gov/bsa_aml_infobase/pages_manual/olm_059.htm

Scroll down to "OFAC Screening". It will answer all of your questions.

Thanks RL! That is EXACTLY what I was looking for but couldn't find!