Going It Alone…

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 – Beyond 60 days

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

But I Have The Authorization!

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

2 of 8 – FREE Webinar – Authorization Requirements

Tomorrow – April 21, 2010 – is the 2nd in our series of FREE ACH educational webinars.

As I mentioned before, ACH Direct has partnered with UMACHA (Upper Midwest ACH Association) to bring you the best darned beginner level ACH Education for Free.  And I’m pretty sure that I mentioned that it’s FREE.  Oh, and it starts at 1:00 PM CT and should last about 90 minutes.

This fantastic series runs for 8 months covering topics ranging from a basic introduction to Returns and Unauthorized transactions to an entire session on ARC, POP and BOC.  Then to wrap up the year, we’ll tackle a couple of Check related sessions.

We always have a great mix of participants (from across the network), we encourage participation and we always leave room for Q&A. 

This month’s presentation is:  Authorization Requirements

Authorizations can be verbal, written or similiarly authenticated, or by notice – but there needs to be one in place for an ACH entry to be inititated.  This session will provide details on ACH Authorizations including, “Who is responsible for the authorization?”

We do ask that you register in advance. 

If you’re interested and I know you are, go to http://www.achdirect.com/news/events-teleseminars.asp.   

Click on the date/title of tomorrow’s presentation and you’ll be presented with the registration page. 

After you register, you’ll receive an e-mail with the log in and dial in details.

If you would like to register for multiple sessions, you will have to register separately for each one.  A bit of an annoyance I know, but what do you expect for free?  I mentioned it was FREE right?

If you would like a hard copy of the presentation, you can click on the link below the description and download a .pdf copy.

Should be a great time and I hope to hear you there.

Who Are You?

You have me at a disadvantage…you know who I am, but I don’t know who you are.

 I told you that I was going to put together a survey to find out who my readers are, and here it is.

 It won’t take you long and you don’t even have to tell me your name, just a few questions about who you are and what you think about my little blog.  And, I would be most grateful.

Here is the link:  http://www.zoomerang.com/Survey/WEB22AHPLRLUQX

Thank you for participating in the first ever survey of the readers of the ‘Everything ACH’ blog. 

As an additional thank you, I am planning a drawing for some great ACH Direct goodies.  I think 2 winners will do nicely.  Up for grabs is a very cool and stylish padfolio, a tres cool light up pen, an ACH Direct mug and leather coaster.  You’ll each get a package containing all 4 items.

 IF you would like to participate in the drawing, you will of course have to provide some additional information – see question #11.  The drawing will take place on May 19.  The winners will be notified by e-mail.

Thanks for sharing.

ACHGuy

Who Am I?

Do you know who I am?

I’m not talking about the D-List celebrity or self-important person who yells this at the bouncer who won’t let them into a club or at the person behind the counter who is trying to serve the customer who was in line first.  I’m talking about the person on the other end of the internet session or telephone line who wants to buy something from you.

Yup, I’m talking about WEB and TEL.  If you are processing WEB or TEL transactions, that question is one that needs to be addressed.  Now I know that you know that the ACH Operating rules require that you authenticate the identity of the Receiver for each transaction – before the authorization takes place.  But they don’t tell you how to authenticate that person.  Do you know how?  Are you doing it?  Please say ‘yes’.

From a practical standpoint or real-life perspective, I don’t.  I mean, I know the basics, but I don’t live this process – it’s a very back-end kind of thing to me.  So, I turned to our very own Leslie Hendrix, Vice President of Sales and Marketing and asked about it.

I didn’t really interview her, cause I’m not very good at that kinda stuff, but I asked her questions and she talked.  I even took notes.  OK, I interviewed her….

ACHGuy:  Ms. Hendrix, when you think of authentication for WEB and TEL transactions, what comes to mind?

Ms. Hendrix:  My, so formal.  I’m sure you know that the ACH Operating Rules require merchants that use ACH for WEB and TEL transactions to authenticate the identity of the Receiver using commercially reasonable measures. 

ACHGuy:  OK. Leslie.  Without sounding like you’re delivering a sales pitch for ACH Direct services, how is a merchant supposed to do that?

Note:  Merchant = Originator, but you already knew that. – ACHGuy

Leslie Hendrix:  There are many different services available in the marketplace to help merchants comply with the NACHA requirements. When I think authentication, I think Account Verification and Identity Authentication.

ACHGuy:  Can you give me an example or tell me a little about they work?

Leslie Hendrix:  Identity Verification services can be used to validate that someone is who they say they are.  Most identity verification services use a combination of publically available data in conjunction with private information.  Most services can optionally generate out-of-wallet questions for further identification, if necessary.

ACHGuy:  What about Account Verification?

Leslie Hendrix:  As far as Account Verification is concerned, there are many companies out there that offer a variety of services ranging from a simple Routing & Transit Number verification to Negative and Positive databases and even Funds Verification services. 

Note:  I included definitions of each of those below – ACHGuy

ACHGuy:  If a new Originator approached you, what would you recommend?

Leslie Hendrix:  I recommend that like most merchants, they should use a combination of identity and account verification services.  In the end, it’s all about protecting the merchant.  I also tell them that the most powerful verification services combine everything I’ve mentioned into one service to provide actionable, definitive responses on 100% of the checking accounts in the US. 

ACHGuy:  This is your ‘Buy my product’ moment.  Tell us what service, specifically, that you recommend and then sell it to me.  But keep it short, say 50 words or less?

Leslie Hendrix:  Thanks!  Specifically, I recommend a combination of IDVerify and ATMVerify.  This ensures that the merchant is in compliance with the NACHA rules and provides the merchant with reasonable assurance that the person is who they say they are and that the account information the consumer has provided to the merchant has a high probability of successful payment.  Interested merchants can find additional information about the services at www.atmverify.com and www.idverify.com.

Thank you to Leslie Hendrix, VP Sales and Marketing at ACH Direct for helping me out today.  And just for the record, if anyone is interested in ACH Direct’s verification services, they can contact our Payment Specialists at sales@achdirect.com or 866 378 0001.

I don’t generally care to ‘sell’ anything via my blog.  After all, it’s about education, not sales, but I needed some help and have zero budget.  With that in mind I hope you’ll forgive the shameless plug and more importantly, I hope you learned something today.  I know I did.

 ACHGuy

As mentioned above, here are the definitions promised.

Routing and transit verification – a service that will verify the validity of the routing and transit number

Negative database – a service that will determine whether there are any known unpaid items on an account

Account history database – also known as a positive database, these databases contain information about the history of items that have been presented on the account and whether or not the items paid successfully

Account current status verification – a service that will verify the current status of an account

Funds verification – a service that will verify that adequate funds are available in the account at the time of inquiry

A Document by Any Other Name…

A few years ago there was a document titled “Affidavit of Unauthorized/Improper ACH Debit Activity”.  Sound familiar?  Maybe not.  And then it was discovered that there was some state law (I think it might have been an M state) that said something to the effect that to be a valid Affidavit, it must be notarized.

That presented a bit of a problem to the industry at large, afterall, rules need to be consistent across the board.  Not every RDFI had an easily accessible Notary.  Not to mention, it could simply be inconvenient.   So, what do you do?

You change the name.

The title of the document was changed to “Written Statement Under Penalty of Perjury”, more affectionately referred to as a WSUPP form.  That, I’m sure you recognize.  It is the exact same document, except for the title.  Personally, I really liked this title.  I think it made some Receivers stop and think before signing.  It was serious. 

We’ve been moving along really well for a number of years now and for some reason, there’s another name change on the horizon.  March 19, 2010 to be exact.  I’m not really sure why this time.

There is quite a bit of information here (and these are just the highlights), so bear with me.  Beginning on March 19, 2010 the following changes to the Written Statement go into effect;

1)    The title of the document is being changed to “Written Statement of Unauthorized Debit”.  To be affectionately referred to as a WSUD.  Not nearly as sexy as a WSUPP, but they didn’t ask my opinion.

2)   Along with the name change, the Written Statement is no longer required to be signed ‘Under Penalty of Perjury’

3)   The requirement stating that an authorization must clearly and conspicuously state its terms has been changed to ‘the authorization must be clear and readily understandable’

4)   The Written Statement will now require very specific pieces of information including;

1. Receiver’s printed name and signature
2. Receiver’s account number
3. Name of the Originator
4. Posting date of the entry
5. Dollar amount
6. Reason for the return
7. Date of the signature
8. Receiver’s assertion that the Written Statement is true and correct and
9. Receiver’s assertion that they are an authorized signer or has authority to act on the account

5)   The Written Statement must be signed and dated on or after the Settlement Date of the entry(ies) to which it relates

6)   Multiple claims may be made on the same Written Statement

7)   Requests for copies of the Written Statement must be fulfilled within 10 banking days

8)   The RDFI must retain a copy of the Written Statement for 1 year

9)   A Written Statement is no longer required when returning an ARC, BOC or POP entry using R39 (Improper Source Document)

As I said, those are the highlights.  For details, I strongly encourage you to check out the Revisions section of the 2010 ACH Operating Rules book.  If you don’t have one, reach out to your local Regional Payments Association or visit https://www.nacha.org/member-apps/index.cfm?action=store.category&ProductCategoryID=28.

There are some rules changes coming relating to Stop Payments as well, so keep an eye out here for another post soon.

ARC – Accounts Receivable Truncated Check Entries

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.

Standard Entry Class (SEC) Codes: WEB

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.

Standard entry Class (SEC) Codes: POP

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.