The Impact of Person-to-Person (P2P) ACH Payments for RDFIs and ODFIs [VIDEO]

The Impact of Person-to-Person (P2P) ACH Payments for RDFIs and ODFIs [VIDEO]

ACH P2P payment policy updates - sheshunoff

NACHA's P2P rules, approved March 7 of last year, went into effect 3/21/2014 and addresses necessary changes to handle the Individual ID field, as well as the proper use of the WEB credit by Originators.

In a recent Sheshunoff Webinar, I presented a comprehensive overview of ACH rule amendments effective in 2014, including the P2P rule amendment highlighted in the video below.

Highlights of P2P ACH Rule Amendment Video:

To Sum Up:

  • WEB will be used for person-to-person payments and requires unique credit format specifications
  • ODFIs must provide transaction info to the originator on periodic statement
  • RDFIs may need to make programming changes to provide Originator name in the Individual ID field on periodic statement
  • You need to add the verification of providing NOCs to third party service providers, to your 2014 audit requirements.
  • Reversal issues to consider: ODFI or 3rd party service might want to initiate reversal
  • Beware any personal data being carried in the individual ID field
  • Use of WEB credit by Originators for P2P is required no later than March 20, 2015.

As I mentioned in the webinar, here's the NACHA Rules reference point for P2P: Appendix 8, under part 8.4, letter E

Stay Up-To-Date on all ACH Amendments

While important, P2P is only one of several rules effective in 2014. Guard your institution against unwelcome surprises (and earn CPE credit) by attending my next ACH compliance webinar on April 22nd. You can see all upcoming sessions in our event calendar and follow the Sheshunoff team on Twitter, LinkedIn, and Google+ for exclusive deals. 

For an even more complete training, consider registering for an upcoming ACH certification class to become an AAP (Accredited ACH Professional).

Full Video Transcript:

So the impact to your financial institution on this thoroughly significant rule amendment. You might have to make changes, or your third party service provider, if you're using one for the receipt of your ACH, may need to be making changes to be able to accept these web credits because they could only be web debits before.

You might have to make programming changes in order to look at that originator name in the individual ID field because you need to grab that to put on your periodic statements. Then also because of the personal data that might be carried in that individual ID field, another consideration that you make is providing that information only on web credit entry.

The individual identification field in other types of transactions -- it's not a requirement for that field in anything other than a web credit entry for that to be provided.There may be personal information. For example, in a typical PBD transaction used for a payroll deposit, an individual ID number might be used to identify the employee. The employer might be using that employee's social security number. In that case you sure don't want to put that individual ID on a statement that's going to be going through the U.S. mail, and potentially have information on there that someone can get a hold of that you wouldn't want them to.

When the changes are being made, or if you have your statements prepared by a third party and they are relying on pulling from you system, give consideration to only including the individual ID field of information on web credit entries. Don't make that a universal change and say we'll just do that for all transactions because that could have some residual problems there if you do that.

On the ODFI side, you may have to make programming or system changes so that you can originate these web credits, and also to accommodate that plain text addenda that I explained. It doesn't have to be in a particular format.

You might have to make some changes to provide the transaction information to the originator on your periodic statement. I'm pretty certain here you will because typically you're only looking to received transactions to provide statement information, not originated transactions. If you're going to originate these, you need to make sure you're prepared to do that.

You need to add the verification of providing NOCs to third party service providers, to your 2014 audit requirements. Again, this is actually specifically in the rules and added as a new requirement. Let me give you that reference point. In Appendix 8, under part 8.4, which is the part that applies the audit to the ODFI, look at letter E, as in Edward, and there you'll find the new audit requirement step that you need to take to make sure that if you have NOCs received for web credit entries that they are being either handled by you as the ODFI or are being passed along to third party service providers for the corrections.


Marge SimmonsAbout the Author: Marge Simmons is President of Electronic Payments Advisory Services. Her 30+ years of experience in the area of electronic payments includes development of ACH software, management of Michigan’s ACH association, and 12 years in Treasury Management. Marge is a frequent Sheshunoff Webinar speaker and author of several banking publications. Consulting services offered by her company include training and ACH audits.