Everything ACH

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. 

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.