Everything ACH

A TEL entry is a transaction for which the authorization is received, orally, over the telephone.  TEL should only be used for Business to Consumer transactions and can only be debits.  Single, one-time debits to be specific.

Authentication:  Unlike most ACH entries, TEL transactions require that the identification of the consumer be verified before the authorization piece takes place.*

 Authorization:  The authorization requirements are very specific for TEL transactions and yet the ACH Operating Rules also give you a workable option.  Here’s the deal:

 TEL authorizations require the following 6 pieces of information:

 Date of the authorization

Date on or after which the transaction will post

The consumer’s name

The amount

A telephone number that is available and answered during normal business hours

A statement by the Originator that the authorization will be used to originate an ACH Debit

And here’s the option.  The Originator gets to decide whether to record the conversation that includes the exchange of those 6 pieces of information, OR provide* a notice to the consumer detailing those 6 pieces of information. 

In addition to all of that, the Originator must state clearly during the telephone conversation that the consumer is authorizing an ACH debit entry to their account, express the terms of the authorization in a clear manner and the Receiver (Customer) must unambiguously express consent.  Silence is not express consent.

Before you can use TEL, there is one last thing you should understand.  A TEL entry can only be transmitted when 1) there is an existing relationship between the Originator and the consumer or 2) if there is not an existing relationship between the Originator and the consumer, then it is the consumer who initiated the telephone call to the Originator.

* Notes: 

The Originator must use a commercially reasonable procedure to verify the consumer’s Routing Number.

Provide does not mean that the notice must be received by the Receiver only that it must be sent.  Usually the postmark or time/date stamp of an e-mail is sufficient proof that notice was sent before the transaction posted to the consumer’s account.

Formatting requirement:  Originators must ensure that the name of the Receiver is included within each TEL entry.

Because TEL transactions are one-time debits, they cannot be returned as R07 – Authorization Revoked.

There is so much more I could probably tell you about TEL transactions, but that’s all the big stuff and some of the little stuff too.  All of that being said, stay tuned for POP next.

CCD – Corporate Credit or Debit

CCD should only be used for any Business to Business transactions* and can be either Debits or Credits. CCD can be used for either a single one-time transaction or recurring transactions and may be accompanied by one addenda record.

Authorization: The authorization requirements are much more lax for CCD transactions* than PPD transactions which we discussed in the last post. However, I like to use the PPD authorization requirements as a guide for a really good authorization.

Here’s what the ACH Operating Rules say though: “The Receiver has authorized the Originator to initiate the entry to the Receiver’s account. In the case of CBR, CCD, and CTX entries, the Receiver has an agreement with the Originator under which the Receiver has agreed to be bound by these rules as in effect from time to time.” Essentially, to me, this means that there must be an agreement. That’s it, there must be an agreement.

The reasoning is that we all assume that when there is an ACH Authorization between two businesses that 1) it will be part of a larger agreement and 2) lawyers (with the best interest of the Receiver) will be involved. The difference of course is the assumption that the typical consumer would not have that luxury and therefore requires additional protections.

Please note that I strongly advocate the incorporation of all or as many as possible PPD authorization requirements be used in any Business to Business authorization.

 * Notes:

I know that I said that CCD should only be used for Business to Business transactions; there is of course, one exception. In the event a company is reimbursing an employee for expenses, that transaction to their personal/consumer account should be labeled a CCD.

Just because the requirements for CCD transactions are less onerous than PPD does not mean you should start using CCD for all of your transactions hoping to reduce your requirements. It does not work that way. Sending a CCD transaction to a consumer account, inappropriately, is a violation of the ACH Operating Rules.

And as before, when you have designed the authorization to suit your needs, please, please, please, be sure to pass it by your compliance person or preferably, your legal counsel before you roll it out for general use and after any future changes.

Stay tuned next week for TEL. Ring, ring.

A lot.  Really.  Standard Entry Class or SEC Codes are a cornerstone to the everyday ACH transaction and work hand in hand with authorization requirements.

Remember in Originators Originate that we talked about how Originators are required to ensure that all information contained in a transaction is accurate?  That includes the SEC Code.  The SEC Code tells us how the transaction was authorized and what type of account the Receiver has – Consumer or Business.

When it comes to using SEC Codes, I cannot stress the importance of using the proper code – every time.

Here is a brief list of some of the more popular SEC Codes;

PPD

CCD

WEB

TEL

BOC

ARC

RCK

There are a bunch of other SEC Codes, and if you want to see a full list, you can always visit pages OR 103 through OR 106 of the 2009 ACH Operating Rules book or just stay tuned here and we’ll talk about them in upcoming posts.

I figure the easiest thing to do would be to review them one at a time.  We’ll talk about what they mean, what the authorization requirements are, how to properly use them and anything else that comes to mind.

I will try to do one a week and we’ll start with PPD.

Ooh, something to look forward to.

As promised, here is the final installment of the Return of the ACH Transaction trilogy:  Operator Returns.

 Most returns are processed by the RDFI, Operator Returns (also called Rejects) never make it to the RDFI.  They are returned or rejected by the ACH Operator – the RDFI never even sees these transactions.  However, as with all other returns, there are limited reasons for which an ACH Operator may return transactions.  

 The most common of these Return Reason Codes is R13 – Invalid ACH Routing Number (formerly DFI Not Qualified to Participate).  This simply means (in most cases) that the RDFI Routing Number in the File Header Record is incorrect. 

There are of course several other codes such as;

R18 – Improper Effective Entry Date

R19 – Amount Field Error

R27 – Trace Number Error

 Those, I think are the most commonly used codes among the bunch.  If you want to check out the entire list, see page OR 120 of the 2009 ACH Rules Book.

 And that’s returns.  It’s a lot of information, and I could probably tell you a lot more, but hopefully, the picture is starting to come together. 

 I can’t guarantee there won’t be a part IV, but I just don’t think I’m up for it.  Not today anyway.

 Stay tuned for a great post from our new (ish) Marketing Manager.  He’s a great guy by the name of Jay Alsup, who is just like you, he’s learning the ACH ropes too and he shares a bit of his experiences and observations. 

Finally, Part II.  I know you have been waiting – very patiently, I might add.

 So, on to Extended Returns:

Remember in Part I, I mentioned the 24 hour Rule of Thumb?, well, Extended Returns have a much longer return time frame, ergo the ‘Extended’ part.

The RDFI has 60 calendar days from the Settlement Date to return a transaction using one of the Extended Return Reason Codes.  Note that this does not mean that an RDFI can just use these Return Codes willy-nilly.  That is a no-no.

The proper use of Return Reason Codes (all return codes) is one of the many warranties the RDFI maintains; meaning they should only use these codes when it is appropriate to do so.  To do otherwise, could be considered a violation of the ACH Rules – and nobody wants that.

There are only a few of these codes, so let’s review;

R05 – Unauthorized Debit to Consumer Account Using Corporate SEC Code

          This means that the Originator has processed a CCD, CTX or CBR (until IAT becomes active) to a consumer/personal account.

R07 – Authorization Revoked by Customer

           This is when there was an authorization in place, but the consumer (not business) revoked this authorization per the requirements of the authorization.  Remember that most authorizations require verbiage informing the consumer how to revoke it.

R10 – Customer Advises Not Authorized, Notice Not Provided, Improper Source Document, or Amount of Entry Not Accurately Obtained from Source Document

          Customer Advises Not Authorized – the consumer never authorized this transaction, could be they did not authorize a debit from this company, did   not authorize a debit for this amount, or the debit was to post on or after the 15^th of the month and today is the 10^th.  This part covers several possibilities.

           Notice Not Provided – this refers specifically to ARC and BOC transactions    and as we know, ARC and BOC transactions require a notice as part of the authorization process.  The notice must be posted in a clear and conspicuous place.  If it is not, the consumer can claim that Notice was Not Provided.

           Improper Source Document – For all of the check conversion SEC Codes,    there are certain types of checks that are not allowed to be converted.  This Return Reason Code can be used when one of those forbidden types of checks is converted and processed.

           Amount of Entry Not Accurately Obtained from Source Document – I think   you can figure out what this one means.

  R33 – Return of XCK Entry

           XCK Entries are Destroyed Check Entries wherein the check from which the transaction was created has been destroyed or is otherwise unavailable.    These are not very common.

R37 – Source Document Presented for Payment

           This refers specifically to ARC, BOC and POP transactions.  This would be used in the event the Originator processes both the Source Document   (Check) and the electronic transaction.

R38 – Stop Payment on Source Document

           This refers specifically to ARC or BOC transactions.  This would be used in the event a Stop Pay request has been placed on the physical item (Source Document/Check), but the electronic item was presented for payment.

R51 – Item is Ineligible, Notice Not Provided, Signature Not Genuine, Item Altered, or Amount of Entry Not Accurately Obtained from Item

           This refers specifically to RCK transactions.

           Item is Ineligible – The item that was converted to an RCK was not eligible to be converted (see list on page OG 212 of the 2009 ACH Rules Book).

           Notice Not Provided – Same as above – See R10

           Signature Not Genuine – This indicates the signature on the Source Document may be a forgery.

           Item Altered – The Source Document and the electronic transaction do not    match up in some way – amount, account number, routing number, Receiver, etc.

           Amount of Entry Not Accurately Obtained from Item – Same as above  – See R10

R52 – Stop Payment on Item

           This refers specifically to RCK transactions and is used when there is a stop pay order on the physical item (Check/Source Document).

R53 – Item and ACH Entry Presented for Payment

           This refers specifically to RCK transactions and is used when the physical item (Check/Source Document) and the electronic transaction are both presented for payment.

 Whew, there are more than I thought, but still only 9 codes and you will notice, they all have fairly specific uses.

A note:  R05, R07, R10, R37 and R53 all require the Receiver to fill out a Written Statement Under Penalty of Perjury.

 Wow, this post has really been all business.  I won’t let that happen again.

 Anyway, that’s all I have for now.  I know you’re waiting with baited breath for Part III and it will come…soon.

It sounds like the title to a really lame 50′s horror flick.  OK, maybe it doesn’t sound quite that good.

As we have already discovered the wonders of processing ACH transactions and we learned what most of the participants do, I wanted to talk about what happens when things don’t go so smoothly.

Like your college-bound teenage kid, many ACH transactions eventually come home to roost, sometimes just for a short time (maybe the Summer) and sometimes when they move in, they really move in.

To my mind, there are really two kinds of Returns – Regular Returns and Extended Returns.  OK, there are three kinds of Returns – Regular Returns, Extended Returns and Operator Returns.  OK, there are four…just kidding, only three.  Today, I want to talk about Regular Returns.  When I say Regular Returns, I am referring to the common everyday kinda return that just sort of happens.

For instance, NSF, Account Closed, Stop Payments, stuff like that.  Of course the full list is a lot longer than that.  For a full list of all Returns, check out pages OR 113 to OR 120 in your 2009 ACH Rules book, you know that pretty pea green book that so-and-so gave you that you have never opened?, that’s the one.  If you really don’t have one, check with your Regional Payments Association or visit pubs.nacha.org and get your copy today.

You may be asking, what makes a regular return a Regular Return. Well, there is one truly defining requirement of all Regular Returns that bind them to this category and that is their return time-frame.  Check it out:

The Technical:

This applies to all RDFIs:  “Except as otherwise provided…, each return entry must be received by the RDFI’s ACH Operator by its deposit deadline for the return entry to be made available to the ODFI no later than the opening of business on the second banking day following the Settlement Date of the original entry….”.  This is quoted from page OR 26 of the 2009 ACH Rules book.  The “…” represents the really boring parts.

Human Language:

This applies to all RDFIs:  The rule of thumb – all returns must be processed within 24 hours, unless otherwise noted.

Note:  This is on banking days only, if received on a Friday, the 24 hours is up on the next banking day – Monday, possibly Tuesday.

A Practical Example:

As the RDFI, chances are that you download your files from the ACH Operator or Third Party Receiver every banking day morning at oh-my-goodness AM.  Let’s say that one of those transactions is a debit transaction that is destined to post on Tuesday, June 16 and there are not sufficient funds in the account to accommodate it, and you choose to return it (excepting of course, any overdraft protection, courtesy posting and the like). 

That return item must be made available to the ODFI by opening of business on Thursday, June 18.  How are you going to get it to them?  You know that your last file of each banking day is processed at 4:00 PM to your ACH Operator or Third Party Sender. 

You could process the return as soon as you realize that it cannot post on Tuesday or you can wait and process the return at any time, as long as it is processed by your 4:00 PM deadline on Wednesday.  As long as you make that 4:00 PM deadline, it will process overnight and be made available to the ODFI by opening of business on Thursday morning…the 2^nd banking day following the Settlement Date of the Original Entry.

My 24 hour rule of thumb says you would process it by Wednesday morning….accomplishes the same goal and is easier to remember.

As a subset to Regular Returns, there are Dishonored Returns and Contested Dishonored Returns.  Notes: 1) you will find specifics on those returns after the details of the Regular Returns on the pages mentioned above and 2) As a refresher on Dishonored and Contested Dishonored Returns, I encourage you to go back and read my earlier post titled Circle of Life.

Stay tuned for Part II.

Check out the origin of “Rule of Thumb“.

Receive! Receive!

This is a bit of a no- brainer to me.

Of course we all know how much I love to receive ACH transactions.  Especially credits.  Being on the receiving end of an ACH transaction (debit or credit) automatically makes me a Receiver and makes me subject to a number of responsibilities. 

Being a Receiver is not as easy as it seems (we should add that to the list); we do not get to just sit back and let transactions post to our accounts willy-nilly.  Let’s talk about the responsibilities;

Authorizing transactions – the authorization between the Originator and the Receiver is the beginning of every ACH transaction.  No transaction should ever take place without some form of authorization

Review monthly bank statements – the Receiver is required to review their monthly statement for errors

Notifying RDFI of errors – the Receiver is required to notify the RDFI of any errors within proper timeframes

Complete and sign an Affidavit or Written Statement Under Penalty of Perjury –

                Unauthorized – If a transaction is received for an amount different than authorized or posts on a date different than agreed to or if the Receiver does not recognize the Originator, they maintain the right to request the transaction in question be returned.

                Authorization Revoked – in the event a Receiver wishes to withdraw or revoke their authorization relating to a specific transaction, they are required to notify the Originator first.  With few exceptions, every ACH authorization is required to contain language informing the Receiver how they may revoke it.

It’s a very short list, but a very important list.  The bottom line here is that as Receivers, we are responsible for all transactions that post to our account.

There I was in a pair of shorts, a t-shirt and my fuzzy slippers, arms crossed, cursing the ice, smiling inside.  Why was I smiling inside when the outside was pretty cold and dreary?  Well, I had just seen where our local school district was closed for the day due to ice and that means the office is closed too.  Woohoo…a free day.

Well, sort of.  I have a contingency plan.  I am one of the lucky few who has the ability to work from home…I can access almost everything I need.  How convenient. 

Most ACH Network participants are required by the ACH Rules to have some kind of contingency or back-up plan in the event something happens, like say, an ice storm.

And I knew that across the country, Originators would be wondering if their transactions were processed.

Let me offer a bit of background…There are three kind of ‘days’ addressed in the ACH Rules; Calendar Days, Business Days and Banking Days. 

Calendar Days are any day on a calendar….Sunday through Saturday. 

Business Days are Monday through Friday – no weekends. 

Banking Days are Monday through Friday, minus any Federal Holidays (there are 10 of them – see http://www.frbservices.org/holidayschedules/index.html). The ACH Network will process transactions on every Banking Day with a few exceptions….I’ll talk about those next.

So, how does this relate to an inclement weather day?  It wasn’t a Federal Holiday, it wasn’t a weekend day, it was just another ordinary Banking Day.  Except we had a lot of ice on the roads.  So onto the bigger question; Were transactions processed?  Yes, yes they were.

One of the many warranties that ODFIs, RDFIs and ACH Operators have is that they are willing and able to process transactions in a timely manner.  This includes, on all Banking Days.  They also warrant they have workable contingency plans, such as working from alternative locations during extreme conditions, like inclement weather days, power outages, fire, etc.

On to the exceptions.  There is a clause in the ACH Rules called “Excused Delay”.  This allows for a delay in processing by a participant for a variety of reasons such as:  natural disasters, war or some other kind of catastrophe outside of the of the participant’s control.

Some examples;  major power outage in the northeast a few years ago – exception, recent tornados in Kentucky – exception, entire ACH staff out with the flu – not an exception, local power outage – not an exception, Good Friday, Day after Thanksgiving, Day before Christmas, etc. – not an exception.  Not sure?, contact your local RPA for direction.

Oh, and just for the record, I don’t really own a pair of fuzzy slippers.

This time of year, this simple phrase has special meaning to us all with the holidays and the special times we spend with our families. This phrase usually refers to family or blood ties, of course. However, I think it can relate into the ACH Network too.

In our case, the ties are contracts. These are the contracts that allow the ACH Network to operate and provide roles and responsibilities to us all. We have already talked Originator and ODFI, now it’s time to talk Operator. ACH Operator.

Once upon a time, there were 5 ACH Operators. Over the years, the number of ACH Operators has dropped for various reasons leaving us with 2. The Federal Reserve Bank and Electronic Payments Network (EPN).

If you are a FI in the U.S. and you want to participate in the ACH Network, you must have an agreement/contract with at least one of these two Operators. This is where it all starts for the ODFIs and RDFIs.

So what does the ACH Operator do? What are they responsible for?

Here’s a short, but potent list;

Process and Deliver ACH Files – they receive files from the ODFIs, separate out the

individual transactions by RDFI (process) and deliver those individual

transactions to the appropriate RDFI within proper time frames

Facilitates Settlement – provides settlement services for the DFIs using their Fed

Accounts

Record Retention – just like the DFIs, the ACH Operator is required to maintain

copies of all transactions that pass through their hands from 1 year from

Settlement Date

Monitor Network – the Operators are set with the task of monitoring the ACH

Network as a whole to ensure there aren’t any major issues that would

interfere with the appropriate and timely processing of all ACH transactions

Systemic Risk Manager – while this actually falls under the category of Monitoring

the Network, it is important enough to warrant its own special mention.

Systemic Risk is frequently referred to as the domino effect.

This is where one FI fails or is unable or unwilling to settle their ACH

transactions. In turn, this causes other FIs to not be able to settle their ACH

transactions and so on and so forth…the domino effect. Get it? The ACH

Operators specifically monitor the network looking for any tell-tell signs of this

phenomenon and if they see any signs, they must immediately investigate

and act if necessary.

That is actually a pretty short list. But I think I hit the biggies. Just think of the ACH Operator as just another member of the ACH Family…maybe the responsible Uncle or the crazy Aunt. Either way, family is family.