In a recent audit, it was brought up that our core processor does not scan the Remittance Information Addenda Record for OFAC. This guidance appears in the NACHA rules so it's not just something they came up with on their own.

Is this field not akin to the memo line of a check? My understanding is that it is not a formatted name field and could contain numbers, special characters, and free form text.

Running free form text against a formatted database such as OFAC is a very frustrating endeavor to say the least, so I can understand a core processors reluctance to take this on. It was suggested that we run the checks on this field manually; however, by the time we have access to the information - the transaction would have already posted to the account.

Even if we did get a "Hit" on something contained in the addenda record field what would we be obligated to do? If the sender, receiver, and other bank involved in the transaction all pass OFAC but the addenda record potentially contains the name of an SDN should the transaction be blocked? For example, a customer purchases a statue of Fidel Castro from Canada on e-bay for $15 and when the IAT comes through it has "Fidel Castro" in the addenda record all of the sudden we have a blocked transaction?

Just wondering if others have addressed this and how they are managing it.

Sorry man, our core provides us with a daily report.

It was my understanding that there were (up to) seven additional specific addenda records required for IAT's. Our core processor is able to scrub the data in those records against the SDN list and produce a daily report of potential matches.

The seven mandatory addenda records do contain the required 'travel rule' information on the sender, sender's bank, receiver's bank and receiver. These are formatted records and generally used for the OFAC scans. I'm not sure which, if any vendors use the optional remittance information addenda records, which are not formatted, for OFAC matching.

The optional field is the one they are wanting us to scan and our core does not - nor do they plan to anytime soon. We do scan the seven mandatory fields through the core.

It seems our core processor has updated its capabilities of scanning the addenda records and we are getting swamped with false hits that require clearing.

Just thinking aloud:

I think this is going to boil down, as all things do, to the level of risk you think you're incurring.

The originating DFI has a definite responsibility to check any remittance information in the Payment Related Information contained in the optional Remittance Information addenda record. So if you are largely originating such transactions, I'd suggest working with your vendor to get this scan on their 'to do' list.

If you are largely the receiving DFI, then you have to determine the volume of such IATs you receive and whether there is an elevated risk of receiving an IAT in which that informatin relates to an individual or entity on the SDN.

I have inquired from our Core Processor whether or not they check the remittance information addenda records. Even if they don't we receive very few IATs and all of them have been PAYPAL transactions. From my perspective, they would be low risk and I wouldn't be overly concerned if the remittance information was not being scanned.

Just my thoughts.

My thought is what bearing the optional addenda record has on the transaction as far as OFAC is concerned? If there is a name in that field, they are neither the sender, receiver, or financial institution involved in the transaction.

It would be somewhat like freezing or blocking a check based on the fact that there is a name on the memo line that is a match. Ooops, I hope I did not just give regulators an idea here.....

I think any system that tries to match the free form data in that optional field to formatted name data is going to produce a boat load of false hits.