P2P, A2A Payments: Perils to Protection. WACHA Conference 2016 Kimberly W. Rector, AAP

Transcription

1 P2P, A2A Payments: Perils to Protection WACHA Conference 2016 Kimberly W. Rector, AAP

2 You Know the Drill The views and opinions expressed in this presentation are those of the presenter (and it is likely not even the views of the presenter) and do not necessarily represent the views of WACHA, MACHA, or NACHA (or any other ACHA ). The content of this presentation should not be construed as regulatory or legal guidance. As my Dad would say it is what it is 2

3 I Want You to Think (just a bit) Using the Same Language ACH Rules Risks = Perils Control = Some Protection Scary Stuff Questions 3

4 You Choose No Front Brakes because of Cost 10 Specific Features Safety beat Cost 4

5 Shaking My Head $151,000 A2A transaction 5

6 Language Our discussion is focused on Consumers, natural persons, individuals, however you want to phrase but that is important Account to Account = A2A Both accounts are owned by the same Consumer Kimberly Rector to Kimberly Rector Person to Person = P2P Both accounts are not owned by the same Consumer Kimberly Rector to Mary Smith 6

7 What It Is A2A or P2P Checking Account to Checking Account Two options Sending a credit to myself or someone else financial institution will debit my account and send an ACH credit to another financial institution Pulling a debit from myself not so much from someone else financial institution will credit my account and send an ACH debit to another financial institution Additional thought The account offset most likely be an ACH formatted entry Lot s of talk about split transactions in the ACH That s not really how the ACH works Very important to understand 7

8 What It s Not A2A or P2P is not Paying billers on bill pay Biller is a corporate It is not having the financial institution generate an entry for Loan payments Interest disbursement Online account opening All of these are services offered by the financial institution You are the Originator and are offering to do something to the Receiver The account holder owes you or you owe them In A2A or P2P the Consumer is considered the Originator 8

9 Where The ACH Used to Be The previous ACH Rules were silent The only comment Section Credit entries if both the Originator and the Receiver are natural Persons, no authorization by the Receiver is required, and no warranty with respect to any such authorization is made by the ODFI. This means me paying me or me paying you does not require authorization in a format we typically associate with the ACH When the Rules were developed this type of payment was not on the radar! 9

10 Where The ACH is Today WEB Credit entry Pushed Person to Person Payments via ACH credit entry initiated by or on behalf of a holder of a Consumer Account that is intended for a Consumer Account of a Receiver Authorization is not required for credits between natural persons WEB Credit entry Regardless of form of request including paper authorization 10

11 Where The ACH is Today Person to Person Payments Receipt of WEB entry that is a Credit Company Name in Company Batch Header Provider of the P2P service (ODFI or Third Party) ODFIs Consumer (originator) statement requirement Name of the person receiving the entry Should be in the Individual Name field of WEB RDFIs Statement requirement for Receiver Sender of entry Consumer Individual Identification Number field of Entry Record Must print this on the statement Not the Company Name from the Batch Header 11

12 Where The ACH is Today Debits = a Pull from Another Account (another institution) Authorization How did you obtain In writing - PPD Phone TEL Online WEB All the current ACH Rules for authorization apply Remember you warrant the authorization for the debit that hits the account at the RDFI 12

13 Think About This Can One Consumer authorize another Consumer to debit their account? 13

14 How Do You Offer Using your online banking/online bill pay Using another service offered by a vendor Doing it yourself (HIGHLY DISCOURAGE) No matter what you must Remember All of these transactions are covered by Regulation E Both the offset entry to the account at your institution and the transaction that is sent into the ACH network In many/most all cases you are considered the ODFI of the entry That means you provide the warranty to the transaction As the financial institution representing the account holder making the request Regulation E applies 14

15 How Do You Offer Do You Understand your System and the Reports How do the transactions appear Those that were sent out Those that offset to the account at your institution Those that are returned from RDFIs 15

16 What Do You Offer You Decide A2A Originator & Receiver are the same person Credit Push Do you operate on good funds model Debit Pull How long are you holding credit offset However long you want so long as you disclose Determining how you know that I own both accounts Micro Deposits??? 16

17 What Do You Offer You Decide P2P Originator and Receiver are not the same person Credit Push Do you operate on good funds model Debit Pull Really thinking not so much How is Authorization obtained Rules do not recognize one consumer allowing another consumer to debit account 17

18 Who Gets To Use You Tell Me Things you should consider Account relationship Tenure of relationship Definitely should not be a new account holder History of account activity Account balances NSFs Regulation E Claims Recurring Deposits Relationship to type of service you offer A2A or P2P Credits Push Debit Pulls 18

19 Who Gets To Use After you decide who gets to use You must have considered these issues Dollar limits Frequency limits Daily, weekly, monthly Combined exposures Remember some activity may be better suited to other payment methods!!!! 19

20 Risks to Consider Pushing Credits Either A2A or P2P Good Funds Model Incorrect Account but a valid account at the other financial institution Online access Your account holder s credentials are compromised Imposter generates transactions Regulation E issue Will Talk about this a little more in just a minute 20

21 Risks to Consider Pulling Debits Most likely A2A (but maybe P2P) Returns NSF, account closed, incorrect account number Can you recover Debited valid account but wrong account Automatic 60 day right of return ODFI has a warranty issue for much longer timeframe Your account holder s credentials are compromised Imposter generates transactions If you offer both Credit push, debit pulls They debit an account another institution (not theirs) Then push that money to their account at another institution That s why your decisions on Frequency are so important 21

22 When Things Go Wrong Returns Okay remember you are the ODFI You are going to get entries returned You need to know how to recognize the Returns for what they are Credits not so much a problem Right credit your account holder Debits whole new story Reason for returns NSF, Account Closed/Invalid Account Can you recover from your account holder 60 day right of return unauthorized You have no recourse with the other financial institution regardless of what type of authorization exists You must accept the return if it is timely!!!!!! 22

23 When Things Go Wrong Okay all of these transactions are governed by Regulation E both sides Consider this: RDFI contacts you because a debit has been posted to the wrong account (number was a valid number) Let s assume it is past 60 calendar days There is no valid authorization However, as the ODFI you stand behind the transaction as valid and correct They are most likely going to press you to accept the return 23

24 When Things Go Wrong Another scenario (just an FYI) all these are real examples directly from calls that I have received Credit Push a credit was sent to another institution The account number is valid but it is not the correct account Does the RDFI have to return it to you No not even if you ask nicely and the money is still in the account There is no guarantee of recovery once that entry is sent!!! 24

25 When Things Go Wrong With this scenario nothing is good Your account holder s access credentials are compromised by a bad guy Let s say you only push out credits only okay so they send out credits Most likely you cannot recover those credits Your account holder is claiming that the debit to their account for the credit you sent is authorized This is a Regulation E claim Unless you can prove otherwise you are probably paying Proving is the hard part Your account holder s access was used looks like them 25

26 When Things Go Wrong With this scenario nothing is good Your account holder s access credentials are compromised by a bad guy Let s say you offer both debits and credits Bad guy sends debits to someone else s account, then sends the credits to their account The debits are returned (the credits are gone) But your account holder is claiming that their access was compromised Regulation E claim So you end up losing out on the debits unless you can prove that your account holder did the transactions Remember when the debits are returned by the RDFI you cannot refuse them if they are timely 26

27 Hard Truth In most cases The ODFI is going to be on the hook when the music stops Are you prepared for potential losses associated with your dollar limits Know in advance your exposure 27

28 Your Whiteboard Decide What to Offer Recognize and Understand the Risks Including Management Actions to Manage Risks Reaction to real Issues 28

29 Awesome Resource Your Local Regional Payment Association WACHA The Premier Payments Resource Thank you for your time!!

30 My Sample Letter of Indemnity Date Name Organization Address City State Zip Dear ODFI Name is the originating financial institution of an ACH entry that was sent to RDFI Name in error. We are requesting that RDFI Name return the erroneous ACH entry under the NACHA Operating Rules section (2015 NACHA Operating Rules). ODFI Name requests that the incorrect ACH entry be returned through the ACH using ACH Return Reason Code R06. Detail information about the incorrect entry as it appears in the ACH transaction: Settlement Date: Originator Name: ODFI Routing Number: Receiver Name: RDFI Routing Number: Receiver Account Number: Dollar Amount: Trace Number: Transaction Code: ODFI Name agrees to indemnify RDFI Name from and against any and all claims, demands, losses, liabilities and expenses, including attorneys fees and costs, resulting directly or indirectly from compliance with this request. If you have additional questions about this request, please contact me at: Contact Information Sincerely,

31 My Sample Letter Request for Authorization Date Name Organization Address City State Zip ACH Coordinator: RDFI Name is the receiving financial institution of the ACH entry referenced below. We are investigating an error claim submitted to us by our account holder, the receiver of the ACH entry in question. Per the NACHA Operating Rules Subsection we are requesting accurate proof of valid authorization for the following ACH transaction in which ODFI name is listed as the originating financial institution. We request that this information be provided to RDFI Name within ten banking days of receipt of this request. If ODFI Name is unable to provide an accurate record of the authorization for the ACH entry, RDFI Name is requesting the right to return the ACH entry as unauthorized. Detail information about the ACH transaction: Settlement Date: Originator Name: ODFI Routing Number: Standard Entry Class Code (SEC): RDFI Routing Number: Receiver Name: Receiver Account Number: Dollar Amount: Transaction Code: Trace Number: Please remit the request proof of authorization to: Address, fax, , etc for RDFI If you have additional questions about this request, please contact me at: Contact Information Sincerely,