Patent Application
20080147522
This invention is concerned with methods for preventing check fraud, and is more particularly concerned with methods in which an issuer of checks provides data concerning the checks to a drawee bank.
Check fraud is a significant problem for banks and issuers of checks; systematic efforts to combat check fraud are well known. So-called “positive pay” systems are one accepted anti-fraud technique. In positive pay systems, an issuer of checks sends data to the drawee bank to inform the drawee bank in advance about the attributes of checks from the issuer that the drawee bank should expect to have presented to it for payment. If the drawee bank receives a check drawn on the issuer's account which does not match the previously received “positive pay” data, then the bank is alerted to undertake inquiries before paying the check.
According to conventional practices, the positive pay data file includes, for each check, data which conveys attributes of the check such as, for example, the date of the check, the serial number of the check, the number of the account upon which the check is drawn, the dollar amount for which the check is drawn, and the name of the payee. In some cases a subset or a superset of this data, or another combination of check attributes, is included in the positive pay data file.
At 104 in
At 108 in
In due course, the payees (not shown) present the checks for deposit and/or collection to their banks, which use the check clearing system (indicated at 112) to present the checks for payment by the drawee bank. At 114 in
One difficulty with the positive pay system as implemented in the manner described above is that banks tend to have varying requirements as to the check attribute data to be submitted by the check issuers. In addition, there are variations in the format in which the check attribute data is to be submitted. As a result, it may be expensive, or even impractical, to provide and/or modify the accounting application software such that it can assemble the “positive pay” file in a manner that is acceptable to the drawee bank.
In another proposed manner of operating a positive pay system, the accounting application does not assemble the positive pay file. Instead, after the check printing operation a stand-alone application software package assembles a positive pay file by accessing a database of check data maintained by the check issuer's computer. However, in addition to the need to meet the drawee bank's requirements for check attribute content and format, the application which assembles the positive pay file also must operate in a manner that reflects the database schema employed for the check data. Again, this may tend to produce a greater variety of requirements than the application can readily cope with.
According to an aspect of the invention, a method includes using an intermediary program to parse print data being sent from an application program, which may be, for example, an accounting program, to a print driver. The print data is suitable for causing the print driver program to print one or more checks utilizing a printer. The parsing of the print data identifies data fields in the print data. The data fields are indicative of attributes of the checks. The method also includes storing data from the identified data fields. The stored data is check attribute data. In addition, the method can include printing the checks. Still further, the method includes transmitting the stored check attribute data to a bank upon which the checks are drawn.
The parsing of the print data may include detecting, for at least some blocks of text within the print data, what check attributes the blocks of text correspond to. The detecting of what check attributes the blocks of text correspond to may include reading contents of the blocks of text and/or determining at what position in the check one of the blocks of text is to be printed.
The stored check attribute data may include any combination of one or more of (a) the date of the checks, (b) dollar amounts of the checks, (c) serial numbers of the checks, (d) names of payees of the checks, (e) the account number which corresponds to the account on which the checks are drawn, (f) a check routing number, and (g) the signature on the checks.
The check attribute data may be stored in the form of an XML (Extensible Markup Language) file. The transmitting of the check attribute data to the bank may include translating the XML file with an XSLT (Extensible Stylesheet Language Transformations) transformation to produce the output file. The output file may be in a format prescribed by the bank and may be transmitted to the bank.
The method may further include allowing a user to select a printer from among a plurality of printers, receiving an indication from the user as to selection of the printer, and selecting the print driver program from among a plurality of print driver programs. The selecting of the print driver program may be based at least in part on the indication from the user as to selection of the printer.
In another aspect of the invention, an apparatus is provided which includes a processor and a memory in communication with the processor. The processor stores program instructions. The processor is operative with the program instructions to perform the method steps described in the preceding paragraphs.
In still another aspect of the invention, a method of protecting against check fraud is provided. The method includes using an accounting application program to generate check printing data for one or more checks. Each check includes a plurality of text blocks. The method further includes invoking a print function of the accounting application program with respect to the check printing data. The method also includes parsing of the check printing data by an intermediary program. The parsing includes reading at least some of the text blocks to detect a type of data included in each of the text blocks. The detecting of the type of data includes determining with respect to at least some of the text blocks where in the check the text blocks are to be printed. The method also includes extracting data from the text blocks and storing the extracted text data as check attribute data which corresponds to the detected types of data. Still further, the method can include driving a printer to print checks corresponding to the check printing data. In addition, the method includes translating the check attribute data to a format prescribed by the bank on which the checks are drawn, and transmitting the translated check attribute data to the bank.
The method may further include scanning the checks at the bank on which the checks are drawn to extract check attribute data from the scanned checks, and comparing the check attribute data extracted from the scanned checks with the check attribute data transmitted to the bank.
Therefore, it should now be apparent that the invention substantially achieves all the above aspects and advantages. Additional aspects and advantages of the invention will be set forth in the description that follows, and in part will be obvious from the description, or may be learned by practice of the invention. Various features and embodiments are further described in the following figures, description and claims.
The accompanying drawings illustrate presently preferred embodiments of the invention, and together with the general description given above and the detailed description given below, serve to explain the principles of the invention. As shown throughout the drawings, like reference numerals designate like or corresponding parts.
The present invention, in certain of its aspects, provides an improved technique for generating a file of check attribute data to be transmitted to a drawee bank by a check issuer as part of a positive pay system.
At 202 in
Regardless of whether the intermediary program receives the check printing data by having it passed directly to it from the application software package or by monitoring and reading the check printing data, at 206 in
At 210 in
To summarize an aspect of the present invention, an intermediary program receives check printing data by being inserted between a conventional application package, e.g., accounting, and a conventional print driver to serve as a conduit for the check printing data between the accounting application and the print driver, or by monitoring and reading the check printing data being sent from the conventional application package to the conventional print driver. In addition to relaying the check printing data to the print driver (if sent to the intermediary program), the intermediary program derives positive pay data from the check printing data. With such an intermediary program, there is no requirement for the accounting application to be adapted to the needs of the positive pay system, nor is it required to collect the positive pay data after the fact from a check database. Any program customization that may be required is limited to the intermediary program or, preferably, to a utility program which is discussed below. The utility program may operate in association with the intermediary program and may perform any format translation, etc., needed to place the check attribute data gathered by the intermediary program into a suitable condition for transmission to the drawee bank.
The computer system 300 includes a processor 302, which in practice may be constituted by one or more conventional microprocessors. The computer system 300 also includes one or more memory/storage devices (represented by block 304) which are in communication with the processor 302. For example, the memory/storage device(s) 304 may include read only memory (ROM), random access memory (RAM), flash memory, one or more hard disk drives, drives for one or more removable disk-shaped storage media, etc., none of which is shown separately from block 304. The memory/storage device(s) may function as both program and working memory and may store various software programs 306 as described in more detail below. The software program includes program instructions which cause the processor 302 to operate so as to perform functions described herein.
The memory/storage device(s) 304 may also store one or more databases 308. The databases 308 may store data required to generate check printing data, and data that reflects checks that were previously printed.
Further, the computer system 300 includes a printer 310 which is in communication with the processor 302. The printer 310 may be a conventional printer of a type used to print checks and may also be employed to print documents other than checks. For example, the printer 310 may be a laser printer.
In addition, the computer system 300 may include other customary input/output devices, which may be in communication with the processor 302 and which are represented by block 312 in the drawing. For example, the other input/output devices may include a keyboard, a mouse, and a display device, none of which is separately shown in the drawing.
Still further, the computer system 300 includes a communication device 314 which is also in communication with the processor 302. The communication device 314 may be a network interface card, a modem and/or another device or devices that allow the computer system 300 to exchange data communications with external devices such as the computer (not explicitly shown) of the drawee bank.
The software 402 includes the above mentioned application program (block 404) which may be a conventional accounting program or other application, operational to generate check printing data suitable for passing to a print driver. The software 402 also includes a conventional print driver 406.
The software 402 further includes the above-mentioned intermediary program (block 408), provided in accordance with aspects of the invention and functionally inserted between the application 404 and the print driver 406 or adapted to monitor data being sent from the application 404 and print driver 406. Further details concerning the functions of the intermediary program 408 are provided below in conjunction with
As indicated by dashed line block 410, the application 404, print driver 406 and intermediary program 408 may all run under a conventional operating system, such as an operating system from the family of “Windows” operating systems distributed by Microsoft Corporation. The print driver 406 drives the printer 310 in a conventional manner. Aspects of the printer 310 were described above in connection with
At 510 it is determined, in response (e.g.) to the user's interaction with the second printer dialog box, whether the user has selected a new printer for printing of the batch of checks. If not, then the printer previously employed for the last batch of checks is selected to print the current batch of checks, as indicated at 512. However, alternatively, the user may have selected a new printer, as indicated at 514.
When selection of the printer has been accomplished, the intermediary program 408 commences to receive the check printing data from the application 404, as indicated at 516 in
At 520, the intermediary program 408 parses the page of check printing data to extract check attribute data from the check printing data. More particularly, the intermediary program may parse (e.g., read and/or detect the format of) blocks of text data included in the page of check printing data.
The purpose for parsing the page of check printing data is to gather check attribute data regarding the check to be printed using the page of check printing data. The check attribute data may be of the types referred to above, such as one or more of: check serial number, check amount (courtesy and/or legal amount), date of the check, name of payee, account number, routing number, or signature. Typically, for at least some types of check attribute data, the format of the text information in each text block in the page is adequate to allow the intermediary program to identify which type of desired check attribute data, if any, is contained in the text block. For example, a text block that contains a dollar sign (“$”) followed by one or more numerals, followed by a decimal point (“.”, which may also be identified as a period), followed by two more numerals, can be reliably detected as the (courtesy) dollar amount of the check, and the text data in that block may be interpreted accordingly to extract the (courtesy) dollar amount.
As another example, a text block that contains a string of letters, followed by a space, followed by one or two numerals, followed by a comma, followed by a space, followed by four numerals (of which the first two are “20”), can be reliably detected as the date of the check, and the check attribute corresponding to the date of the check may be extracted accordingly from the text block.
As still another example, a text block that contains only letters except for possibly also including one or more spaces or periods may be interpreted as the payee's name. A text block that contains only letters forming words representing numbers, e.g., one hundred thirty three, can be reliably detected as the legal amount of the check. To disambiguate between the possibilities for the check attribute data, the position of the text block in the check (and/or in the page of check printing data) may be taken into account. Position in the check or page of check printing data may be judged based in terms of either or both of: (a) absolute or relative coordinates at which the text is to be printed on the check blank, or (b) the order in which the text block appears in the page of check printing data relative to other check blocks. (Either or both of these may be considered to indicate the position of the text block in the check, or where in the check the text block is to be printed.) For example, if a text block having the format described in the first sentence of this paragraph is placed ahead of the courtesy dollar amount in the page of check data, then it may be concluded that the text block represents the name of the payee.
Similar conclusions may be drawn from the content and/or format of the information in other text blocks in the page of check data and/or from the position of the text blocks in the check or page of check data. (For present purposes, and for the appended claims, each text block may be considered to be a “data field”.)
Optionally, at 522, the intermediary program 408 can generate a barcode that includes at least a portion of the check attribute data gathered at 520. The barcode can be, for example, a machine readable 2-Dimensional barcode which can be read to provide additional authentication properties for each check. Thus, if the attributes of the check have been changed on the actual physical check, the attributes as recorded in the barcode will not match (unless the original barcode on the check has been replaced with a new barcode generated based on the altered check attributes). Preferably, the barcode is encrypted or signed with a digital signature, thereby providing additional security measures against the unauthorized generation of such barcodes.
At 524 in
Following steps 520-526, the intermediary program 408 determines at 528 whether a “close file” indication has been provided from the application 404. If not, the process loops back to 516, and the intermediary program 408 obtains the next page of check printing data from the application 404. However, if at 528 the intermediary program 408 determines that there has been a “close file” indication, then the process advances from 528 to 530. At 530, the intermediary program 408 passes the “close file” indication on to the print driver. The process then concludes (532).
When selection of the printer has been accomplished, the intermediary program 408 commences to receive the check printing data from the application 404, as indicated at 612 in
At 620, the intermediary program 408 determines whether the check printing data being sent from the application program 404 has ended. If not, the process loops back to 612, and the intermediary program 408 obtains the next page of check printing data from the application 404. However, if at 620 the intermediary program 408 determines that there is no more data being sent, the process then concludes (622).
In some embodiments, the check attribute data gathered at 520 and 616 may be stored in the form of an XML file. Thereafter, (e.g., in batch, and/or after close of file), a utility program (not separately indicated), or the intermediary program itself, may apply an XSLT transformation to the XML file to translate the check attribute data into a format prescribed by the drawee bank. If a utility program is employed for this purpose, it may be possible to use a standard version of the intermediary file in all installations.
The above description, and the flow charts herein, are not meant to imply a fixed order of the enumerated process steps. Rather, the process steps may be performed in any order that is practicable.
A number of embodiments of the present invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. Other variations relating to implementation of the functions described herein can also be implemented. Accordingly, other embodiments are within the scope of the following claims.
