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!
April 23, 2009 at 4:25 pm |
Where can we email questions?
April 24, 2009 at 10:07 am |
You can either post your question here or send me an e-mail at jeff.gonzales@achdirect.com.
November 18, 2009 at 12:13 pm |
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!
November 18, 2009 at 2:04 pm |
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
January 14, 2010 at 4:38 pm |
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?
January 15, 2010 at 4:25 pm |
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
January 20, 2010 at 10:11 pm |
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
January 21, 2010 at 10:15 am |
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
January 21, 2010 at 10:36 pm |
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
January 22, 2010 at 5:21 pm |
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
January 28, 2010 at 10:50 am |
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
February 25, 2010 at 10:01 am |
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
March 1, 2010 at 11:41 am |
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
March 10, 2010 at 7:51 am |
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.
March 10, 2010 at 9:24 am |
I’m so glad to hear that my work is appreciated. Good luck on the AAP exam!
March 17, 2010 at 11:30 am |
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?
March 17, 2010 at 12:22 pm |
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