This blog is dedicated to understanding Automated Clearing House (ACH) transactions.
If you look out there, everything you’ll find about ACH is talking about banks and credit unions and using words and acronyms we don’t understand.
Everything ACH is about breaking it all down, explaining it and describing it in terms we can all understand. Real people language, not the typical legalese. I think this will be an interesting journey and I welcome you to come aboard…
Subscribe to my blog!
Where can we email questions?
You can either post your question here or send me an e-mail at jeff.gonzales@achdirect.com.
Please forgive my ignorance on this subject as I am a teller researching for a project and haven’t the first clue where to begin.
I work at a small community bank that uses a correspondence bank for our EFTs. We only offer savings accounts, CDs and loans. When our customers set up direct deposit their money goes into our checking account at our correspondence bank. Then we must discern what EFT belongs to who and take from our checking account and transfer into that person’s savings account or apply it to their loan.
We are interested in simplifying these direct deposits and electronic transfers and “cutting out the middle man (bank)”. What do we need to know? Where do we begin?
Thank you for whatever help you can provide!
Hey Laura,
I’m probably not the best source of information for this, but let me take a stab at it and make a couple of recommenations. I have a couple of suggestions for resources too.
First things first, you want to find out what you’re in for – from a workload stand point. Talk to your ACH Operator (likely the Federal Reserve Bank or Fed) and your industry peers to find out what your responsibilities will be. Not just from a processing piont of view, but from daily tasks, audits, things of that nature. You may also want to talk with your local Regional Payments Association. I don’t know where you are, but if you are not a member of your local association, I highly recommend it. I belive there is a publication or two that might be of value when it comes to operating as an RDFI. I am not intimately familiar with many of today’s publications, but your RPA will be and should be able to make suggestions. If you need, you can find a list of RPAs at http://www.nacha.org/Memberships/RPA/rpa.htm.
While your talking with your peers, pick their brains on software. Depending on what all services your correspondent bank is providing, you may need to purchase your own software. There is no better recommendation than that from a trusted source. There are many, many, many providers out there. You will need to do your due diligence to determine which is best for you.
Once you get to this point and your software is selected, installed and your staff trained, you will need to change your agreement with your ACH Operator. Currently, it would show your correspondent bank as your Receiving Point and that’s what you will want to change.
Suggestions for resources: Industry peers tops my list and then your Regional Payments Association. Of course, if you have an AAP on staff that’s good too.
That’s all I have I think Laura. If I think of anything new, I will update my post here and send you an e-mail too.
I wish you luck,
ACHGuy
Can you refer me to the regulations for the posting of payments? Example: A customer pays their loan through an EFT payment – what requirements/regulations are there that require us to post that payment within X hours. Can we back date a payment? If they pay on the 3rd of the month what prevents us from posting it as a payment of the 31st?
This one really made me stop and think. Depending on whether you are the RDFI or the Originator, the ACH Rules may not address this.
Let me explain. If you are the RDFI and you need to know when you are required to post a payment, say to a loan account or any transaction in general. Transactions must be posted on Settlement Date. You can find this on page OR 23. 4.4.1 for Credits and 4.4.2 for Debits.
For credits, if the information were made available to the RDFI by 5:00 PM the day before Settlement Date, then the Credit must be posted by 9:00 AM or opening of business, whichever is later. If the information was not made available to the RDFI by 5:00 PM the day before the Settlement Date, then the Credit must simply be posted on Settlement Date.
For Debits, they cannot posted to an account earlier than Settlement Date.
If you’re talking about posting to an account at the Originator, which I think is your question, the ACH Operating Rules do not address this. I would say that the common practice is that you would post the payment on the date you initiate the debit to your customer’s account.
As far as back-dating a payment….could you? Sure, I guess. Once again, however the ACH Operating Rules do not address this. You may have to answer to your Accountant or perhaps an auditor, but that is an entirely different issue.
I guess that’s not much of an answer, but it’s all I got.
I hope that helps,
ACHGuy
Hi,
I have two quries related to the way ACH operates,
1) If the physical check is converted into an electronic transactions how does the drawee bank / paying bank verfies/ authenticates the signature.
2) How does teh ACH cycle operates ie what are the ACH batch processing cycle times.
Thanking you
LMK
Hey LMK,
Welcome to Everything ACH.
In answser to your questions:
1) When you refer to verifying or authenticating the signature, you are referring to a standard check law convention. As check law does not apply to these types of transactions (ARC, POP, BOC), there is no requirement for the Receiving Bank (equivalent to the Drawee/Paying Bank) to verify the signature. However, that being said, I don’t mean to imply this to be any easy avenue for shady business.
The Originator should still follow their standard procedures when accepting a check prior to conversion to ACH. A process which typically includes verifying ID/Driver’s License, running the check against a negative and/or positive check database or other check verification services.
Should there ever be a question, the RDFI maintains the right to request a copy of the ‘source document’ (check) from the Originator and the Originator must provide it. They have to keep a copy for 2 years from the Settlement Date (for ARC and BOC). For POP a copy of the signed receipt/authorization must be kept for 2 years from the Settlement Date and it is becoming more common for the check scanner (MICR Reader) to capture an image of the check too.
2) The ACH Operator – specifically the Fed (though I assume EPN as well) processes 6 times a day – the final processing time is 2:00 AM ET. If you follow that backwards to the typical ODFI or 3rd Party Service Provider, they probably only process a couple of times a day. Contractually, they have a cut off time with the ACH Operator. They in turn offer a scaled back cut off time to their Originators to allow for any processing errors/issues. This cut off time will vary from ODFI to ODFI and even within an ODFI, it may vary from Originator to Originator.
I hope this helps, but if you have any further questions, just let me know,
ACHGuy
Dear ACH Guy , Thank you for your prompt response.
We know that the ACH is an ideal platform for the repeated pull type transactions ie Insurance premia, loan installments etc where the money needs to be pulled by the Insurance co( ODFI) . and lending institution regularly , I am sure there must be a one time mandate/ authorization provided by the payee authorizing the ODFI to debit their accounts periodically , I am sure these mandates would be requiered by the RDFI to authenticate such transactions whenever thet are presented , Can u help me in understanding how is this process handled at the RDFI’s end
Regards
LMK
Good afternoon LMK,
This may be an easier conversation than an e-mail, but let me take another stab at this…
I think you are referring to an authorization for recurring transactions and trying to determine at what point the RDFI authenticates/verifies the signature on that authorization. Is that right?
With that, if I’m understanding you correctly, there is no standard opportunity for the RDFI to see the authorization. The RDFI maintains the right to request a copy of any authorization relating to any transaction they receive for an account holder, but unless there is an issue, they have no incentive to make that request. There are warranties in place requiring the Originator to verify the identity of the Receiver.
As I don’t know your level of ACH knowledge, please don’t be offended by this simplified comparison, but I think it might make things a little easier as you seem to have some check knowledge and I should be able to equate the parties to make it easier all around….
In a typical debit transaction process (let’s say insurance company debiting my checking account), the parties (there are a minimum of 5 parties to every ACH transaction) are as follows:
Originator = Insurance Company = Payee
ODFI = Insurance Company’s Bank = Bank of First Deposit or Payee Bank
ACH Operator = Federal Reserve Bank = Clearing House
RDFI = ACHGuy’s Bank = Payor Bank
Receiver = ACHGuy = Payor/Check Writer
When I (Receiver) sign an debit authorization with the Insurance Company (Originator), they are required to provide a copy to me (in most cases). So, who has a right to a copy of the authorization?, almost everyone really. The Origintor, ODFI, RDFI and Receiver.
The Originator must maintain a copy of the authorization for 2 years from the Settlement Date of the transaction.
The ODFI who processes the transaction on behalf of the Originator maintains the right to request a copy at any time, they generally will only do so in the event an issue arises relating to the transaction.
The RDFI who receives the transaction on behalf of the Receiver maintains the right to request a copy for their own use or on behalf of the Receiver. They too will generally only do so in the event an issue arises relating to the transaction.
The Receiver. They should already have a copy, but they also have the right to request a copy at any time.
Does that make sense?
ACHGuy
Dear ACHGuy,
Your website is great and I have a few questions for you regarding WEB debits.
The company I work for provides e-commerce (B2B Business 2 Business) and payment processing solutions to our customers. Usually we only do credit card applications but our customers seem to be really interested in ACH. I have done some research on the internet and read your blog and so far this is what I think we need to implement in order to comply with the NACHA rules. Please correct me if I am wrong or if I am missing something.
Once a customer is online trying to pay his/her bill we need to display a text agreement similar to this:
I authorize {company name} to debit the bank account indicated in this web form, for noted amount on today’s date. I understand that because this is an electronic transaction, these funds may be withdrawn from my account as soon as the above noted transaction date. I acknowledge that the origination of ACH transactions to my account must comply with the provisions of U.S. law. I will not dispute merchant debiting my checking/savings account, so long as the amount corresponds to the terms indicated in this web form.
(I got this example from the PayPal website)
The website should then prompt the customer to print this authorization and then provide them with a button “I Agree” or a “Cancel” button.
If they click on “I Agree” then the application will save the details of this order as well as the authorization text in a secure database. This way a receipt can be re-generated at any time.
Of course I understand that the internet connection has to be secure and that the company needs to conduct an annual security audit.
Is there anything else that is needed legally? I keep reading about digital signatures and pins and passwords and I’m not sure where this all fits in.
If it’s too much to discuss online I would love for my manager and I to give you a call. Let me know. Your help is much appreciated.
Thank You,
RMB
Dear ACH Guy,
How do I know when I should use PPD vs WEB? Can an e-commerce B2C transaction be a PPD entry? If the authorization is displayed in writing on the website and digitally signed by clicking on an I Agree button, how do I know what to classify it under?
Thank You,
RMB
Hey RMB,
Thanks for your question. Here’s the deal on PPD vs. WEB – it’s actually pretty short and sweet…
It’s PPD IF you have a written, signed (or similarly authenticated) authorization and the transaction is B2C. The authorization for a PPD transaction will always be something in writing, something you can hold, typically with a wet signature.
It’s WEB IF the authorization is actually displayed and authenticated (signed) on the Internet and it’s B2C. The authorization for a WEB transaction will always be something that was displayed (and printed) and authenticated over the Internet.
It’s all dependends on how you receive the authorization.
Does that help?
ACHGuy
I found your site a couple of days ago…I’m so EXCITED! I’m studying for the AAP exam in October and the way you disscuss these topics using “Human language” makes it much easier to understand. Thank you for the time and energy you put in.
I’m so glad to hear that my work is appreciated. Good luck on the AAP exam!
Dear ACH Guy,
I need a little help! With the new regulation changes going into effect tomorrow, I have a question concerning stop payments on ACH tranactions. Can a person ask that a stop payment be placed on an ACH debit if it has has not taken place yet? How do the new changes come into play?
Hey Desiree,
Stop Payments can only be placed on an account before the transaction (to which it relates) has posted to their account. The account holder is seeking to stop a future payment.
If the payment has already posted to their account, then they need to look at other options for returning it, such as Authorization Revoked or Unauthorized. That type of claim can only be made after the transaction posts to their account.
As far as the new changes relating to Stop Payments, check out my recent post titled “The Good ‘Ol Days”, it’s about the new Stop Pay Rules. Also, it’s important to note that the new changes go into effect on Friday, March 19.
I hope this helps,
ACH Guy
great stuff thx
awesome work thanks
This is my first time I have visited here. I found a lot of interesting information in your blog. From the tons of comments on your posts, I guess I am not the only one! keep up the impressive work.
My friend mentioned to me your blog, so I thought I’d come have a read. Very interesting reading, will be back for more!
Hello Warner,
Of course you may share any information contained on this blog. I do ask however, that if done in writing, you provide my blog as the reference.
Thanks,
ACHGuy
Good morning Bryon,
To subscribe to my blog, click on the “Subscribe to my blog” link on the right hand side under the “sponsored by ACH Direct” grahic and in the box at the top, you can click subscribe.
I hope that helps,
ACH Guy
Readers are always welcome to share my posts on their blog. All I ask is that you reference back to Everything ACH.
– ACHGuy
Do you do all your own writing? Or do you outsource some of it? I’m looking for some similar content for my blog! These are great posts!
Thanks for the compliment. Yes, I do all my own writing. I enjoy it – it’s a good time.
-ACHGuy
This was really a great post, and this blog is really boosting my knowledge in the financial industry which is a great help as I run several bad credit websites, making it very important to get all the up to date finance info I can
Dear ACHGuy,
In our previous interactions you had explained me the inportance of the ‘Debit Authorization’ which teh ODFI has to hold record, I have following queries in this regard,
1)Is there any standard format of the debit authorization / mandate that the ODFI has to sent to the RDFI
2)Are the details of the authorization tagged in the ACH system centrally
3)Is the RDFI supposed to store the authorisaton info in his systems
4) What is the recourse avaialble if the ODFI has fraudulently initiated the transaction.
Welcome back.
To answer your questions in order:
1) While there are many great sample authorizations out there, because every situation is different, every authorization is different. That being said, keep in mind that there certain requirements for authorizations that supersede any differences. For example, all TEL authorizations must include 6 specific pieces of information, all authorizations for recurring transactions must provide revocation language and the language in every authorization must be clear and readily understandable – to name a few.
2) No. The specifics of the authorization are known only to the parties to that authorization – the Originator and the Receiver.
3) The RDFI is not required nor expected to maintain copies of authorizations to which they are not a party. However, it is important to note that the RDFI maintains a right to a copy of any authorization relating to transactions posting to accounts at their institution.
4) That’s a bit of a loaded question, ordinarily, an ODFI would only initiate transactions into the ACH Network when acting on behalf of an Originator. However, whether Originator or ODFI, any fraudulent transactions would be subject to returns up to 7 years beyond the Settlement Date of the transaction – depending on the state (the number of years varies from state to state and currently ranges from 2 to 7 years). Beyond that, an Originator or ODFI could be fined.
I would think that knowingly initiating fraudulent transactions into the ACH Network would be considered Willful Disregard of the ACH Operating Rules and would likely invite the harshest of fines in the amount of $500,000.00 per month until the situation is rectified. This ordinarily would relate if the activity were specific to an Originator. The Originator could also be subject to Suspension; meaning they would be barred from access to the ACH Network through that or any ODFI.
If it were the ODFI perpetrating the fraud, I would assume the treatment would be just as harsh though more so.
Not to mention as every ACH Network participant; Originator and ODFI included, is contractually bound to the ACH Operating Rules, they could be found to be in breach of warranty (every participant warrants that they will initiate only lawful ACH transactions) – reason enough for any ODFI to close an Originator account and I would think severe enough for an ACH Operator to reconsider their contract with any ODFI.
I hope that helps,
ACHGuy