or as long as I can remember, merchants, banks, merchant acquirers, ISOs, independent contractors and collection agencies have seemed mesmerized by the notion that the bigger the negative file, the better the risk prevention. Dueling negative files would seem to be a good tune, but there are those who have actually lived in the business who proclaim to know better.

Having grown up in this industry, I can only assert that if you run the math the result is that:

1. If complex risk management methodologies are employed, a check service processor does not need a negative file of any size to earn a reasonable profit at competitive pricing.

2. The addition of a negative file, however, does in fact aid in further loss reduction.

3. The value of negative file data has a relatively short shelf life and, as such, diminishes dramatically and quickly over time, so you might as well take anything older than one year (roughly 80% of the size of the file) and chuck it into the can as it relates to its "age valuation."

4. The size of the negative file of New York bad check writers is somewhat immaterial to the lone merchant in Los Angeles given that most losses are concentrated within dense geographic pockets that don't require nationwide coverage. In fact, our own studies prove that half of a merchant's losses generally could be prevented by a given merchant's OWN proprietary data and velocity algorithms.

In tests of negative file sanctity (and sanity as well!) that I've commissioned, it is clear that:

1. Some third-party files are better than others.

2. Bigger is not better. And when I say "better," I really mean "more valuable."

As proof of these axioms, we tested our guarantee claim data against two large third-party negative file sources. During one week we gave one vendor real-time transactions for that week and asked which ones it would decline based on its negative file.

We separated the files into ID types such as driver's license transactions, MICR transactions and the combination of the two given we have merchants that meet the conditions of these differing ID requirements.

We subsequently waited for four to six weeks to analyze how many of our customers' checks actually bounced (because they were guaranteed by us and hence were mailed to us for reimbursement).

The results were abysmal at best! More than 95% of the transactions the one vendor said should be declined (anywhere from 0.50% to 1.50%) based on its own negative file data (but were really accepted by us) actually cleared the bank!

Suffice it to say that we didn't go in that vendor's direction. While the company is nationally known and recognized for its systems capabilities, I would not use its file if it were free. Could the results have been a quirk? Perhaps, but the tests were based on large data samples, so I leave it to your imagination.

The other vendor produced results more consistent with what I had seen while I was President of Telecredit/Equifax Check Services. So, while we are indeed using a national third-party negative file to augment our own guarantee negative claim data, what is the definition of the word "consistent" that I use above?

Well, at this stage I think you need to take a deep breath and take a step back; even the best third-party file is not "squeaky clean" given that tests show more than 50% of the negative file hits would have cleared when presented despite the negative file flag on the system.

The good news? We've done an analysis that demonstrates that the "inaccurate" declines could be mitigated by drilling down into the demographic detail of the original bad check, including but not limited to the age of the bad check when the next transaction is conducted, the amount of the bad check, the amount of the current check, the check number, the age of the check writer, the reason the check was returned, etc. We've been able to improve on those percentages but not to any significant degree.

Moreover, we can only perform that analysis and subsequent benefit enrichment to the merchants on data that is available to us - namely, our own bad check data and not that of a third-party negative file where detail of the bad checks on file or negative file "hits" is not released to users of those negative files.

Shouldn't merchants be keenly interested in knowing that 50% of all negative file declines are inaccurate lost sales margin?

A bad check might be outstanding, but there are factors to consider:

1. It might be in the stage of "reclearing limbo."

2. It might have already cleared after being represented yet is still negative on the system.

3. It might be negative only because the service charge has yet to be paid.

4. The money order/cashier check payment is in the mail and is yet to be posted.

5. A personal check was mailed, and the processor waits two to three weeks before removing data from the negative file to ensure adequate bank-clearing time. Naturally, these waiting periods are testimony to our banking system, where we only know when items don't clear and not when they do clear!

It has been my experience that third-party check guarantee companies generally have "cleaner" negative files in that the data is representative of their own losses - unlike collection companies or other third parties that accept data from "others" who are at the mercy of data contributors as it relates to how promptly (if at all) payments are reported so as to keep the file "current." And if data is stale, then consumers are being declined though payments already have been made, cleared and posted!

So where do we go from here?

First, data contributors must report data promptly! Some collection companies report payments only once per month, generally at the same time they pay their clients.

Second, honest stop-payment disputes (where there is clear two-way dispute resolution dialogue occurring between the check writer and the service provider) should not hold an innocent consumer hostage on any negative file.

Third, check companies should pressure third-party negative file providers to include extra pieces of detail information so that the check companies can "override" a third-party negative file hit based on analytics using additional information from the original dishonored check.

Fourth, extra care and due diligence should be used in transmitting check conversion data to originating depository financial institutions (ODFI's) lest the wrong consumer be debited (such as might occur in a manual entry, non-POP environment such as Internet-based home shopping).

What happens? An R10 (not authorized) return is created, and the wrong consumer is made negative and will stay negative until collection resolution determines that errors have been made.

The bottom line? Don't take it too personally when someone, even a competitor, says to you, "My negative file is bigger than your negative file." Simply look them in the eye and tell them, "Bigger is not better, better is better."

Everything is relative to the value generated and the analytics behind it. Many companies have started without negative data and prospered! Sure, negative file data helps, but it is certainly NOT the panacea you think it is. Innovative risk-management methodologies create 10 times as much impact in preventing loss as a negative file of ANY size.

Every second, bad check writers simply open new accounts using new or fraudulent identification that negative files are powerless to stop, even with advanced credit screening and profiling techniques.

Don't select a company if its officials tout the size of their file, select them because they talk about the value proposition important to your customer (the merchant). Simply stated, that should be the mathematical intersection of maximizing sales and minimizing risk.

Lin Fellerman is founder, President & CEO of San Diego based Secure Payment Systems, a national provider of Electronic Check and Gift Card processing services. Prior to founding SPS in 1996 Lin was formerly a 20 year employee and 10 year President of Telecredit/Equifax Check Services (now Certegy Check Services). To learn more about SPS look them up at www.securepaymentsystems.com or you can send email to Lin at lfellerman@securepaymentsystems.com