Newsgroups: comp.risks
X-issue: 6.75
Date: Mon, 2 May 88 13:24:37 PDT
From: brian@ucsd.edu (Brian Kantor)
Subject: Re: bad checks

In the middle 70s I was responsible for designing a simple on-line
inquiry system for automating bad-check lookup for one of those
firms that guarantee checks for retail merchants.

The way this works is that for a monthly fee (based on average
purchase amount and volume), the guaranteee firm would automatically
guarantee any check up to some limit, and provide a guarantee for
any higher amount check that was verified with them.

Initially this consisted of having the guarantee firm's telephone
operators page through a thick paper listing of bad checks and
returning a code 1, 2, 3, or 4 (1=accept:guaranteed, 2=accept:follow
ID procedures and we'll guarantee it, 3=do not accept:no guarantee,
4=do not accept:detain customer, police notified). For example,
checks listed as "stolen" would return a code 4 (yes, they stored
the range of check numbers so that they wouldn't flag unstolen checks
on the same account).  The default (we don't know that check) was
code 2 [i.e., what the store should have done without the guarantee
service].  Merchants would be paid by the guarantee service for a
guaranteed check that didn't clear, and the guarantee service would
then assume the responsibility of collecting on the bad check.
Each inquiry was recorded for amount, the assigned approval number
and code, check customer number (a reference to the name used to
verify/guarantee the check), and the merchant number.  This
was printed in a ledger and cleared from the system each night.

A new entry for someone was given code 2 until they'd been inquired
about several times over some period of time (I seem to recall more
than twice in 30 days), at which time they'd be advanced to code
1 on the assumption that they hadn't bounced any checks yet.  Since
the merchant's best interest was served by reporting bad checks
ASAP, this seemed to work.  Downgrade to code 2, 3 and 4 was manual
and done by accounting types at the guarantee firm from bad check
collections referred by the customer merchant.  Perhaps they also
used other data; I don't know.

The whole premise was that each guarantee office usually served
repeat check customers: it could build a payment history database.
I think the assumption was that people who wrote several checks
without bouncing them would probably continue to do so.

We built the database for online inquiry by storing the last name
Soundex-indexed (as a sort of hashing technique, if you will), and
listing other information such as SSN, driver's license number,
account number on the check, etc in a cross-reference.  If more
than one "hit" occured when an operator keyed in a last name, he
was prompted for more information to resolve the hits, or he could
page through a summary of the records on line to see if one fit
the profile of the check being submitted.

Clearly the RISK here is misidentification: the more information
they stored and the more the merchant's clerk collected for check
verification, the better they could do at eliminating false denials.
The system was clearly biased towards generating accepts to avoid
pissing off honest customers, but to contain the losses of the
guarantees.  Last I heard they were still using revisions of that
software and making a chunk of money.

Note that most of the actual data used to determine check acceptance RISK was
not stored online.  Probably it is now, but at that time (about 15 years ago)
the disk storage was too dear and the retrieval time simply wasn't important:
paper files in file drawers was quite good enough.  Since the review was manual
anyway, it seemed reasonable to have the relevant documents in human-readable
form.  One of them - the returned check - was always on paper anyway.  This all
ran on a Microdata REALITY system with 64K of main memory (the max) and one 10
Meg hard drive.  Nowadays you'd do it on an ATKlone.
                                                     Brian Kantor, UC San Diego