Everything ACH

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 or CTX 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.