Everything ACH

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.

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.

I love that quote on so many levels.  What’s funny to me is that for the most part I don’t think we normally pay much attention to the man behind the curtain.  As an example, think about a live concert or movie or performance of some kind.  We just want to enjoy the event.  We don’t have any idea what has to happen on the backside to make it happen.  As far as we know, it just happens.

So how does that translate to ACH?  Do you know what has to happen in the background to make sure your transactions are processed on time?  Most people don’t, they just know it happens.

There are many parties behind the scenes making it happen though.  Today, we are tugging aside the curtain to take a peek at the ODFI …

The ODFI is the gateway into the ACH Network.  The long and short of it is, through their doors pass essentially all ACH transactions…with few exceptions.  And the ODFI is responsible for every last one of them.

We have already learned a bit about the ODFI in previous posts, but did you know the ODFI warrants that their Originators obtain and maintain an authorization for every ACH transaction?  Did you know the ODFI warrants that all information contained in every ACH transaction is accurate?  Did you know that the ODFI is responsible for everything their Originators do?

With such huge responsibilities, it should come as no surprise that ODFIs maintain the longest list of warranties of all parties to an ACH transaction. So, what are some of their other responsibilities?

Among other things, ODFIs warrant that they will:

          Bind their Originator to the ACH Rules

          Ensure their Originators follow the ACH Rules

          Process transactions (and returns) in a timely manner

          Notify their Originators of Returns and NOCs

          Retain records for 6 years

          Perform an Annual ACH Audit

          Indemnify all the other parties should something go wrong

Those are just the biggies.  The list goes on.

No matter what happens, remember, there will always be ODFIs behind the curtain, pulling levers and spinning wheels and taking care of business.  That’s it, the peek is over.  The next time a transaction is processed in a timely manner; remember it’s not magic.  Some ODFI was just doing their job…behind the curtain.

While essentially true, saying that an Originator originates, is like saying a cook cooks or a coach coaches.  If only it were that simple.

In the greater scheme of things, an Originator is so much more, does so much more and is responsible for more yet.  We know already where they fall into the ACH model, but now let’s learn who they are and what they do; besides originate.

In simple terms, an Originator is a party that gives permission to an ODFI or Third Party Service Provider to initiate ACH transactions into the ACH Network on their behalf.   Sounds easy, let’s keep going.

Who is an Originator?  A good example of an Originator is an employer.  We all know how much I enjoy getting paid and because my employer pays me via Direct Deposit, that makes them an Originator.  Other good examples of Originators are my gym, my insurance company, my mortgage holder, my cable company and the list goes on.  What about me?  Can I be an Originator?

Yup, I sure can.  Just like my employer originates Credits (payroll) to my account and my gym, etc. originates Debits to pay my bills, I can originate a credit to give money to someone I know.

How does a company become an Originator?  This is a little more difficult, not much, but a little.  You cannot just mount your company flag to a pole, stick it in the ground and declare yourself an Originator.  There is a process.  The process includes finding a financial institution (Bank, Credit Union or Savings & Loan Association) or a 3^rd Party Service Provider who is willing to take your transactions…remember, you have to give someone permission to initiate those transactions on your behalf and they are going to want it in writing.

It’s called an ODFI–Originator or a TPSP–Originator Agreement.  Among other things, this agreement binds the Originator to the ACH Rules and Regulations and lays out general and party specific responsibilities, such as:

Credit Exposure Limits

Deadlines/Time frames – how late are transactions processed

File formats – NACHA format please

Security Requirements – secure that computer, protect that information

What types of transactions will you process

Authorization/Authentication requirements

How Returns and Rejects are handled and more…

Before you get to this point though you have to go through an underwriting process of some sort, the FI or TPSP have to determine that you are not just some kind of a fly-by-night operation and that you are legitimate and you have to have someone or someones to whom you can originate transactions.  That means you have to have their permission (authorization) to credit and/or debit their account.  An authorization in some form or fashion is required for every ACH transaction – no exceptions.  That’s another post….the list grows.

Once you have all this in place, you are good to go – you are an Originator.  You are now part of the process.  It’s almost like being a member of a lodge without the secret handshake.  And when people ask you what you do; tell them you originate.

I had been thinking of what to write for my next post, where to direct you and had been debating about bringing “The Lifecycle of an ACH Transaction” into the mix.  I remember, from years of answering the same question over and over again, having something akin to a recording in my head.  When someone asked the question, I could press ‘play’ and run through the spiel explaining the lifecycle all the while surfing the Internet, checking and responding to e-mails or simply working on something else – as long as the recording was going, I was good to go.  When the recording stopped, so did my multi-tasking. 

The decision was cemented when I was trying to think about where I had put the graphic I created for this very purpose and lo and behold at that very moment, on the radio, was Elton John singing Circle of Life from The Lion King soundtrack.  It was a sign; as the song talks about the cycle of life, I am supposed to be talking about a Lifecycle, The Lifecycle of an ACH Transaction that is.  By the way, if you have not seen the original movie, The Lion King, I very highly recommend it. 

That being said, let’s get started.  You already know who the main players are in every ACH transaction.  The purpose of this post is simply to show the direction of the transaction at different stages and should be easy enough to follow.  I don’t get into details such as timeframes or what’s required to effect a return, we’ll get into that soon enough – in future posts.

Original Presentment:  This is the first presentment of an ACH Transaction.  These travel from the ODFI to the RDFI.  Credits, like Direct Deposit, rarely, if ever get past this point: afterall who’s going to refuse a credit? 

Return:  This happens for any number of reasons, such as NSF (Non-Sufficient Funds) or Account Closed or No Account or Unable to Locate.  Returns travel from the RDFI to the ODFI.

Dishonored Return:  There are a limited number of reasons for which you can initiate a Dishonored Return – 5 reasons to be exact.  Dishonored Returns travel from the ODFI to the RDFI.

Contested Dishonored Return:  There are a limited number of reasons for which you can initiate a Contested Dishonored Return too – 6 reasons to be exact.  Contested Dishonored Returns travel from the RDFI to the ODFI.

R.I.P.:  At this point, once received as a Contested Dishonored Return, the ACH Transaction is effectively dead and cannot be sent through the ACH Network again.  However, that does not mean an RDFI can just return every transaction using one of the Contested Dishonored Return Reason Codes claiming it’s dead.    Every ACH transaction must be allowed to move through its lifecycle naturally and in the specific order mentioned…no skipping around.

I know it sounds like a lot, but know that there are very few ACH transactions that actually make it to the end of their life cycle.  The lion’s share of ACH transactions post without any problems, a few are returned and only those few remaining transactions (generally less than 1%) are lucky enough to have an opportunity to see the end.  Whether they hear  Elton John singing to them or not is another issue.

Party, Party, Party.

We just talked about the 5 main parties (Originator, ODFI, ACH Operator, RDFI and Receiver), now let’s talk about the 3^rd party.

The Third Parties, to be exact.  There are three of them and they each have a very different and distinct function.

Third Party Sender

Third Party Receiver

Third Party Service Provider

First:  The Third Party Sender (TPS) exists between the ODFI and the ACH Operator .  Their primary function is to simply take transactions from the ODFI and send them on to the ACH Operator.  An example of a TPS is ADP.  This is not a shameless plug.

Second:  The Third Party Receiver (TPR) exists between the ACH Operator and the RDFI.  Their primary function is to simply take transactions from the ACH Operator and send them to the RDFI.  The TPR also generally provides additional support as well, such as posting transactions to the RDFI’s accounts, handling returns (which we’ll talk about in another post), etc.  Their responsibilities will vary depending on the needs of the RDFI.  An example of a TPR is The Independent Banker’s Bank or FiServ.  This is not a shameless plug.

Third:  The Third Party Service Provider (TPSP) exists between the Originator and the ODFI.  Their primary function is to collect transactions from an (or multiple) Originator(s) and forward to the ACH Operator.  Just like the TPR, the TPSP can provide a number of additional services.  THIS is a shameless plug.   Check out www.achdirect.com for all your ACH (and Credit Card and Debit Card) processing needs.

Now that’s a party.  Hope you had fun.  Tell your friends.

Hands up if you remember Abbott & Costello.

There certainly are a bunch of us.  I am a huge fan myself.  And nothing illustrates my next point like the classic Who’s On First? skit… here’s a little snippet.

Costello: Well then who’s on first?

Abbott: Yes.

Costello: I mean the fellow’s name.

Abbott: Who.

Costello: The guy on first.

Abbott: Who.

Costello: The first baseman.

Abbott: Who.

Costello: The guy playing…

Abbott: Who is on first!

Costello: I’m asking YOU who’s on first.

Abbott: That’s the man’s name.

Costello: That’s who’s name?

Abbott: Yes.

Costello: Well go ahead and tell me.

Abbott: That’s it.

Costello: That’s who?

Abbott: Yes.

It goes on and on…a classic, repeated over a 1,000 times on the radio and numerous times on TV.

It’s clear to those of us ‘in the know’ that Who is in fact on first base, but poor Lou, he was lost from the get-go. 

It can be just as confusing trying to figure out who’s-who in an ACH transaction.  I don’t know enough about baseball to make the analogy, but I can at least break it down for you and show you, well, Who’s on first.

There are 5 main parties to every ACH transaction; Originator, Originating Depository Financial Institution (ODFI), ACH Operator, Receiving Depository Financial Institution (RDFI) and Receiver.

To best illustrate what I’m talking about here, check this out.

I am going to use Direct Deposit for my example, mostly because I just really enjoy getting paid, but also because I think we are all familiar with it.

The Employee/Receiver signs an authorization (agreement), providing their banking information to their Employer.  The Employer/Originator uses this information to create an ACH transaction to pay the Employee/Receiver.

The Originator/Employer sends the transaction to their Financial Institution (Bank, Credit Union or Savings & Loan Association) a.k.a. the Originating Depository Financial Institution (ODFI) who in turn sends it to the ACH Operator.

There are 2 ACH Operators in the U.S.; The Federal Reserve Bank and Electronic Payments Network (EPN).  The ACH Operator forwards the transaction to the Receiver’s Financial Institution a.k.a. the Receiving Depository Financial Institution (RDFI) who in turn, posts the transaction to the Receiver’s account.

In this Credit example, the parties are as follows:

Originator = Employer

ODFI = Employer’s Financial Institution

ACH Operator = The Federal Reserve Bank or EPN

RDFI = Employee’s Financial Institution

Receiver = Employee

If this were a debit transaction, for instance a consumer paying their mortgage, the parties would be the same, but the money would flow in reverse.

Originator = Mortgage Company

ODFI = Mortgage Company’s Financial Institution

ACH Operator = The Federal Reserve Bank or EPN

RDFI = Homeowner’s Financial Institution

Receiver = Homeowner

Those are the biggies.  There are a few other optional parties, which we’ll talk about next time in Party, Party, Party. 

Only because I know there are some fans out there like me, here is a link to the entire Who’s on First script.

http://www.baseball-almanac.com/humor4.shtml

And if you want to watch it…