Everything ACH

Every once in a while, I get a question from someone about sending a transaction to <insert name of party here>.  Usually, Grandchild, college bound son/daughter, babysitter, anyone really.

Can they do it?  How do they do it?

The shorts answers are, yes, you can do it and contact your Bank or Credit Union.

Before I get to the fuller answer, let’s talk about options – you know I like doing that.  While this blog is all about ACH, I’m going to deviate for just a moment to make mention of ways you can transfer money easily and inexpensively between two individuals (not businesses)  that are not really (at least on the surface) ACH.

1)   Prepaid Cards – Visa, Mastercard, American Express, they all have them.  Like a gift card.  They are reloadable, usually online and sometimes at brick and mortar locations.  They generally have some kind of fee, monthly or per transaction, but are accepted at many, many locations.  Sometimes the transaction to fund the prepaid card is done by ACH in the background.

2)  PayPal – Eveyone knows who they are.  You can keep money in an account to buy things or just transfer money to others who also have a PayPal account.  Pretty basic.

3)  Obopay and other mobile-to-mobile payment providers like them.  I really like these guys – their process makes me seem hip.  I’m not hip, but it makes people think I am.  You use your cell phone to make payments from a previously set up account to someone else who has an account and then those funds can either be kept in that account for future use or accessed by a prepaid card.  They all do it a little differently, so check them out if you want details.  Sometimes this is done by ACH in the background.

Now, clearly via ACH.  The SEC Code – you remember those – Standard Entry Class Codes is CIE.  It stands for Customer Initiated Entry.  They can only be Credits and can only be P2P or Person to Person transactions.  And get this…no pesky authorization requirements.

See, the ACH Operating Rules specifically don’t require authorizations between “natural persons”.  Now this might mean that while you cannot send funds to either Edward or Jacob (mostly because I’m not sure a vampire or warewolf would considered a “natural person”, you could send money to your son at college, pay the kid who mows your yard or even pay your best girlfriend for your half of dinner last night.  Of course, you have to know the other person’s Routing Number and Account Number.

That being said, if you’re interested, talk to your Bank or Credit Union.  It’s an easy, inexpensive, frequently free (like bill payment) and quick.  I highly recommend it.

ACHGuy

Fighting back starts earlier than you think.

I’ve already told you about what can happen during those first 60 calendar days in But I Have the Authorization!.  How a customer can make a claim and return a transaction as Authorization Revoked (R07) or Unauthorized (R10) without notice to the Originator/Merchant.

Now let’s talk about after those 60 calendar days.  What happens and what can/should you do.  How you can fight back.

One of the many things I do around here is field requests for Proofs of Authorization.  These are generally requests made by an RDFI in relation to a query about, or a challenge to a transaction, by a Receiver.

These requests generally only come about when we are past that 60 calendar day timeframe.

Let me give you a bit of background; Regulation E says, essentially, that a consumer may challenge any debit transaction posting to their account for up to 60 calendar days from the date information relating to the transaction is made available to them.  Traditionally, we use the Statement Date. 

As you know, ACH Operating Rules say 60 calendar days from the Settlement Date.  This could potentially add as many as 30 calendar days to a dispute time frame.  Beyond the 60 calendar days, an RDFI cannot just return the transaction in question.  They do have a couple of options however;

1)  Take a hit.  Depending on the value of the transaction in question and the value of the customer as well as whether we’re talking about a single entry vs. a recurring transaction, many RDFIs will simply credit the customer/Receiver, write it off and be done with it.

2)  Initiate a Regulation E investigation.  This means that among other things, the RDFI may request a copy of the authorization from the ODFI, who makes the request to the Third Party Service Provider (if there is one) who in turn makes the request to the Originator.

That being said, it is important to know that Regulation E only exists between the Receiver and the RDFI.  It does not extend to the other parties of the ACH transaction.  However, per the ACH Operating Rules, the RDFI has the right to a copy of any authorization relating to any transaction posting to any account in their service.

You should also know, if the RDFI is challenging a recurring transaction, the legitimacy of all related transactions could be brought into question.

You, the Originator, are required by the ACH Operating Rules to respond to such requests for Proof of Authorization.  This is your chance to fight back…

Options:

1)  Provide a copy of the requested authorization by the deadline in the request

2)  Offer to just credit the Receiver

3)  Contact the Receiver immediately and work it out before the deadline in the request

4)  Do nothing/don’t respond.  After the deadline, the transaction(s) will be returned

Obviously, option #1 is the best way to go.  You’re protecting your company and your company’s reputation by showing that you indeed have an authorization for any challenged transaction(s).  Options 2 and 3 are good, but you should be sure to respond to the request so the RDFI can be informed about what you’re going to do.  I don’t recommend #4.  The bottom line is this; I may be a graduate of the Dionne Warwick School of Mindreading, but my skills are rusty and I won’t necessarily know what you want to do unless you tell me.  And I don’t like accepting returns unless I have to.  Communication is a good thing.  And if you’re not sure what to do – Ask!

Finally!  Fighting Back.

Some of you might think that fighting back starts when you see a return or with the authorization itself.  I would argue that it starts before the authorization is even written.

Fighting back starts with ensuring that you have a workable revocation process and procedure in place and continues with ensuring that you have a process and procedure in place, to quickly and easily access those soon to be written authorizations.

Fighting back includes having a well written authorization that meets all the requirements of an authorization based on the type(s) of transactions you will be initiating (see my individual SEC Code posts or check out the ACH Operating Rules or talk to your local Regional Payments Association (click here to find one near you).  It is in your best interest to have your compliance person and/or your legal counsel either help you or at least review any authorization before you roll it out for general use.  There are lots of really good sample authorizations out there that will give you a good start, but there is nothing better than having someone in the know with your company’s best interests in mind write or review.

Further, fighting back includes ensuring that your authorization is clear and readily understandable – I mention that separate from the general authorization requirements because it’s that important.  Nothing causes problems faster than ambiguity or fine print.

Fighting back includes ensuring that when the transaction posts to your customers’ account it correctly reflects your company’s name as they know it.  If your company name is ABC Company, but the transaction shows your parent company’s name Brand X Company, there could be issues.  If the transaction shows an odd abbreviation or just your phone number, there could be issues.  Talk to your Third Party Processor or ODFI to ensure that what shows to the Receiver will be recognizable to the Receiver.

Fighting back includes making sure your Third Party Processor or ODFI have updated contact information.  You can take all the precautionary measures in the world, but if I have an old, invalid, unused or unchecked e-mail address  and/or phone number, my request will go unanswered and you’ve just defeated yourself.

Fighting back includes using the Company Entry Description field.  It’s 10 characters long and will appear on the Receiver’s monthly statement.  Use it to state the purpose of the transaction.

And last, but not least.  I cannot stress enough the power of communication.  I’m not suggesting that you have to notify your customers every time you’re getting ready to send them a debit, but a heads up reminder couldn’t hurt.  Communicate your revocation process in easy to understand terms.  Return customer phone calls in a timely manner.  Respond to e-mail queries in a timely manner.  Remember what your grandmother always told you about wearing clean underwear…I mean about catching more flies with honey.  A courteous, friendly, responsive, knowledgeable and empowered Customer Service person(s) will go a long way.

To me, fighting back is mostly about planning ahead.  What is it they say?; the best defense is a good offense?

And to make sure our legal folks don’t get upset with me:

Disclaimer:  The information provided does not constitute legal advice.  For any specific legal questions, you are advised to seek the counsel of an attorney.

- ACHGuy

Dealing with R07 and R10 Returns

Have a seat, this is a long post.

I think the one ‘Returns’ related conversation I have more than any other, relates to dealing with R07s and R10s.  I have this conversation so often that I decided to talk about it;

Generally it starts something like this; “the customer never told me they were sending it back” or “I got this transaction returned as Unauthorized or Authorization Revoked and I have the authorization right here, what do I do?”

I need to provide some basic and background info here first, so bear with me…

Let’s start with R07s.  R07 – Authorization Revoked – We talked about the definition in my post Return of the ACH Transaction – Part II.

We already know that any authorization for recurring transactions must include revocation language informing the Receiver of the manner by which they can revoke their authorization. 

If the Originator receives a proper and timely revocation, they must immediately stop and not process any further transactions based on the authorization.

If the Originator receives an R07 return whether they are aware of any revocation or not, they must immediately stop and not process any further transactions based on this authorization (even though the authorization may not have been properly revoked) until the situation can be investigated.

This is a great place to note the benefit of requiring that a revocation be in writing and sent by traceable mail. 

 This can go 2 ways:

Way #1)  the Receiver is willing to let the Originator continue to process transactions, or

Way #2)  the Receiver is not willing to let the Originator continue to process transactions

 We’ll come back to this.

 Now let’s talk about R10s.  R10 – Unauthorized – We talked about the definition in my post Return of the ACH Transaction – Part II.

 If the Originator receives an R10 return, they should immediately stop and not process any further transactions based on this authorization until the situation can be investigated.

 This can go the same 2 ways as above.

 Receipt of an R07 or R10 will only happen within 60 calendar days of the Settlement Date of the original transaction and the Receiver is not obligated to tell you or your ODFI or your Third Party Processor or anyone for that matter, except their financial institution – the RDFI.  So, if the Receiver returns a transaction within those 60 calendar days and you (the Originator) are sitting there holding an authorization, what can you do?  Technically, within the ACH Operating Rules; nothing.  Really.  Nothing.  However, you have options – outside of the rules.

 Option 1 – Investigate

Pick up the phone – open some line of communication with the Receiver and find out what’s going on – don’t assume and don’t assume the worst.  I have seen where;

1)  a transaction was returned in error, the RDFI inadvertently selected the wrong transaction

2)  one co-signer authorized a transaction and the other co-signer, not knowing, challenges it without checking with the first co-signer.

3)  the company name was not recognized (strange abbreviation or dba name) or the Receiver forgot they set something up. 

 There are too many possibilities to assume this was done intentionally or maliciously.

 In order for a Receiver to return a transaction as R07 or R10, they must complete a Written Statement of Unauthorized Debit.  You have a right to a copy of the document (which must include the reason for the return).  As part of your investigation, you may request a copy of it.  Contact your ODFI or Third Party Service Provider to request a copy, understand there may be a fee involved.

 This is where the ‘ways’ come in:

Way #1)  the Receiver is willing to let the Originator continue to process transactions

Get it in writing, get it in writing, get it in writing…I cannot stress that enough.  Either get a new authorization (which would be preferable) or something in writing (dated) that explains the reason for the return and their agreement to allow you to continue to initiate transactions based on that original authorization.  It may be a bit of a pain in the backside for you or an annoyance to your customer, but it’s all about protecting you, the Originator.  You can continue to process transactions based on the original, updated/approved or new authorization at this point.

Way #2)  the Receiver is not willing to let the Originator continue to process transactions

Regardless of the reason, if the Receiver is not willing to let you continue to process transactions to their account based on that authorization, don’t.  If you do, you’ll be in violation of the ACH Operating Rules and nobody wants that and you cannot afford that.    This takes you to…

Option 2 – Legal Recourse  Always check with your legal counsel before seeking any legal recourse.

The authorization you have is, for all intents and purposes, a contract and you have hundreds of years of contract law to protect you.  You could;

1)  Send the item to collections

2)  If you have an attorney on staff or retainer, have them send a nasty-gram

3)  Seek redress in court (depending on the amount in question, small claims court)

All of this of course depends on you having a valid, proper authorization and takes place outside of the ACH Network, directly between you (the Originator) and your customer (the Receiver).

Before you go down this road, besides just consulting your legal counsel, I recommend that you ask yourself this question…Is the value of this transaction or authorization sufficient to warrant all of this additional time, energy and money? 

 If the transaction is for $4.95, the answer is most assuredly ‘No’.  However, if the transaction was for, say $495.00, the answer might be ‘Yes’ or if it was for $1,400.00, I would assume the answer would be a big ‘Yes’.  You need to know where your line in the sand is…how much are you willing to let go vs. how much is too much.  Or for that matter, is any amount too much?  Every Originator will give me a different answer – As an Originator, you must decide for yourself.

An Option to Your Options:

Sometimes I get an Originator who wants to just call the RDFI and assumes they can just send them a copy of the authorization and all will be good.  More power to you. 

However, keep in mind, that unless you happen to bank at the same bank as your customer, chances are pretty good that the RDFI will do nothing for you.  Chances are they won’t even be able to confirm whether Mr. or Ms. Customer has an account with them.  They don’t know who you are, they owe you nothing and they are bound by privacy regulations such Gramm, Leach, Bliley which restrict the release of private information.

That being said, sometimes you’ll luck out.  I’ve heard stories of Originators calling the RDFI and the RDFI gladly helping out.  I’m not suggesting that RDFIs aren’t over-run with helpful people, I am however suggesting that that event was the exception, not the rule.

So, I won’t tell you not to contact the RDFI directly, but I am telling you that you probably won’t get anywhere, so don’t be disappointed if they turn you away and buy an extra lotto ticket if they offer full disclosure.

 Speaking of disclosure:

Our legal folks would be very upset with me if I published a post like this without some kind of legal stuff talking about how I’m not an attorney, anything I say should not be construed as legal advice, etc., etc., so here it is:

 Disclaimer:  The information provided does not constitute legal advice.  For any specific legal questions, you are advised to seek the counsel of an attorney.

ACHGuy

An ARC entry is a transaction for which the authorization is received in the mail or at a dropbox (can be received via US Mail, Fed Ex, UPS or any other traceable mail)  in the form of a check.  However, before it can be considered for conversion to an ARC entry, the Originator must ensure the check writer was provided with a proper notice of their intent to convert.

In the ARC world, Notice  = Authorization.  The ACH Operating Rules provide specific authorization language for the notice as follows:

“When you provide a check as payment, you authorize us either to use information from your check to make one-time electronic fund transfer from your account or to process the payment as a check transaction.”

OR

“When you provide a check as payment, you authorize us to use information from your check to make a one-time electronic fund transfer from your account.  In certain circumstances, such as for technical or processing reasons, we may process your payment as a check transaction.”

In addition to the above language, until January 1, 2010, the notice must include the following (or substantially similar) language:

“When we use information from your check to make an electronic fund transfer, funds may be withdrawn from your account as soon as the same day you make your payment, and you will not receive your check back from your financial institution.”

The ideal location for such notice is the monthly statement or invoice.  Keep in mind that the authorization notice must be provided in a clear and conspicuous manner, meaning in part that it should not be lost in the fine print.

 Notes:

The Originator must provide an Opt Out method for their customers.  In the event a customer wishes to opt out of the ARC conversion process, the Originator is not allowed to convert any check received from that customer going forward.

The Originator must use a MICR Reading device to capture the MICR information from the check.

To be eligible for conversion to an ARC Entry, besides being received at a lock-box, the check must:

            Contain a pre-printed serial number

            Not contain an auxiliary on-us field

            Be in an amount of $25,000.00 or less

            Be completed and signed by the Receiver

The amount of the ARC transaction must match the face value of the check.

ARC is actually pretty good for any Originator that receives a number of checks in the mail.  If that sounds like you, check it out.

In the meantime, we have one last Standard Entry Class Code that I want to cover, BOC.  I hope to knock it out soon.  Then we can move on to some fun stuff.

A WEB entry is a transaction for which the authorization is received via the Internet.  WEB should only be used for Business to Consumer transactions and can only be debits; Single or Recurring.

Authentication:  Just like TEL transactions, WEB transactions require that the identification of the consumer be verified before the authorization piece takes place.*

Authorization:  While there is no specific authorization language, the WEB authorization must follow these 4 basic rules:

          1) be in a writing that is signed or similarly authenticated*        

          2) be readily identifiable as an ACH Debit authorization

          3) clearly and conspicuously state its terms, and

          4) must (for recurring payments only) provide the Receiver with a method to revoke                     their authorization by notifying the Originator in the manner prescribed.

 It’s a good idea from a Proof of Authorization standpoint to capture the IP address and time/date stamp for each transaction authorized.

 * Notes: 

WEB entries may be either Single one-time entries or Recurring entries designated by the use of an S – for Single or R – for Recurring in the Payment Type Code Field of the Entry Detail Record. 

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

Authorization #1 – This means that the authorization is displayable for the consumer to read on a computer screen and the consumer should be prompted to print and retain a copy of the authorization.  The consumer must then be able to demonstrate their assent to the terms and conditions of the authorization by clicking an “I Agree”, or “OK”, or some such button before moving on to complete their transaction.

The Originator must ensure that the exchange of account information is only accomplished during a secure Internet session using at a minimum 128 bit RC4 Encryption and is considered Commercially Reasonable.

Originators of WEB entries are required by the ACH Operating Rules to conduct an Annual Security Audit of their security practices and procedures that include at a minimum, adequate levels of;

           1) physical security to protect against theft, tampering, or damage

          2) personnel and access controls to protect against unauthorized access and use, and

          3) network security to ensure secure capture, storage and distribution of financial                          information

You should understand that because of the anonymous nature of WEB transactions, they are considered a high risk type of ACH transaction.  That doesn’t mean that they are difficult to implement or cumbersome for your customers, it’s just the nature of the beast.  Stay tuned for ARC next.

POP – Point of Purchase a.k.a. the Walmart experience

I like to call POP the Walmart experience as I believe Walmart has been the single largest adopter of POP to date.  If you want to experience POP for yourself, go to your local Walmart store and write a check.  Here’s what will happen…the cashier will gladly accept your check for your purchases.  They will then run the check through a MICR reader and print out a receipt (it looks a lot like a Credit Card receipt) and ask you to sign it.  After you sign the receipt, they hand you a copy and your check (which has been voided) and you go on your merry way, purchases in tow. 

 So, how does it work?

 Let’s start at the beginning.  POP should only be used for Business to Consumer, debit transactions and they will always be a single one-time transaction.  It is important to note that the whole process will always start with acceptance of a check/source document.

 Authorization:  The authorization requirements for POP are pretty specific.  They’re based on a written authorization (source document/check) and proper notice provided to the Receiver – posted in a prominent and conspicuous manner.

 The posted notice should read:  “When you provide a check as payment, you authorize us either to use information from your check to make a one-time electronic fund transfer from your account or to process the payment as a check transaction.”

 OR

 ”When you provide a check as payment, you authorize us to use information from your check to make a one-time electronic fund transfer from your account.  In certain circumstances, such as for technical or processing reasons, we may process your payment as a check transaction.”

 In addition to the above notice, until January 1, 2010, your notice should also include the following text:  “When we use information from your check to make an electronic fund transfer, funds may be withdrawn from your account as soon as the same day you make your payment.” 

 As I mentioned, the copy of the authorization and receipt look much like a Credit Card receipt and can satisfy the requirements that the authorization must be in writing and then signed or similarly authenticated^*.  As with all authorizations, it must be readily identifiable as an ACH authorization and clearly and conspicuously state its terms. 

 I mentioned using a MICR reader in my opening paragraph and so I figured I better tell you what it is.  A MICR reader is simply a device designed to read the numbers across the bottom of your check.  POP requires that you use a MICR reader when processing POP transactions.  Of course, if it misreads or rejects, you can manually key enter the information, but otherwise you have to use the reader. 

 Not all checks are created equal: 

 Not all checks or sharedrafts are elegible to be converted during the POP process.  A check or sharedraft can be used as a source document if it;

           Has not been previously negotiated

          Has not been previously voided

          Contains a pre-printed serial number

          Is drawn on a consumer account

 Receipt Requirements:

Originators must, at the point-of-purchase, provide Receivers with a receipt that contains the following minimum amount of information:

           Originator name (merchant)

          Company (merchant)/third-party service provider telephone number;

          Date of transaction

          Transaction amount

          Source document check serial number

          Merchant number (or other unique number that identifies the location of the                                 transaction)

          Terminal City and State

 Record Retention:  Merchants/Originators are required to maintain copies of the authorization for CCD transactions for 2 years beyond Settlement Date of the transaction.

  * Notes:

 Amount:  POP transactions must be in the amount of $25,000.00 or less.

 Formatting requirements: 

           Originators must ensure that the name of the Receiver or ID number or code which

          identifies the transaction or customer is included within each POP entry.

           Originators should ensure that the check serial number from the Receiver’s source     document is placed within the Check Serial Number Field of the POP entry.  Further,          the word “check,” abbreviations such as “ck” or “chk,” or other merchant codes must      not be included within the field. Here are some examples of incorrect and correct   applications:

           INCORRECT             0001234

                                      000000000001234

                                      CK# 001234

                                      CK1234

                                      1234 6532986002

                                      CK1234 48832817

           CORRECT                1234

 That’s a lot of information for such a simple process, but I wanted to make sure you had all the important stuff.

 WEB is next, stay tuned.

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.