CA2165246A1 - Automating production and processing of financial documents - Google Patents

Abstract

A financial instrument such as check contains a transaction record in human-readable form which is digitally signed, error checking characters corresponding to the characters of the transaction record, and error recovery characters corresponding to both the record characters and the error checking characters. An image of the financial instrument is delivered by facsimile transmission to a service center for depositing, certification, authentication or registration. The image is subjected to optical character recognition, and an error calculation is performed using the error checking characters to detect recognition errors. In response to a recognition error, the error recovery characters are used to reconstruct the instrument data. The various characters in the instrument are arranged in error-handling coding blocks whose members are distributed to accommodate common problems associated with facsimile transmission and poor paper handling practices. Authentication involves verification of the digital signature to verify the source of the instrument and absence of alterations. To allow detection of digital impersonation, all financial instruments from a particular source contain transaction codes that reflect the issuing sequence of the instruments and contain random elements that cannot be predicted.

Description

2~6524 ~

AUTOMATING PRODUCTION AND PROCESSING OF
FINANCIAL DOCUMENTS
FIELD OF THE INVENTION
The invention relates generally to financial transactions involving the transfer of assets, particularly funds, and more specifically, to methods for automating the production, delivery, authentication and processing of documents such as the financial instruments that authorize such transactions.
DESCRIPTION OF THE PRIOR ART
Paper checks remain the principal instrument for transferring funds between deposit accounts m:~intAined by financial institutions. Checks require repeated physical delivery and processing. A check must be physically delivered to the payee, then to the financial institution where the payee m~in~ins a deposit account, then to a clearing center operated by the financial institution of the payee, and eventually to the financial institution that supports the check.
Checks must be processed at various stages by individuals, which is costly and introduces errors. As well, checks are not particularly secure documents. They are easily mislaid or misapl)lopliated, and can also be forged. Authentication depends largely on recognition of handwli~Lell signatures and personal knowledge of the depositor and his practices, which is unreliable.
Error rates associated with optical character recognition are a major impediment to automating check processing. Although optical character recognition is a well-developed art, an error rate greater than 1% is not uncommon even under optimum circumstances. The accuracy of conversion depends very much on the quality of the image being processed. Facsimile transmission of images over telephone lines, for example, degrades the general quality of an image, and can introduce gross distortions that cannot be accommodated by convention conversion techniques. Authenticating the source of a tr:~nsmittcd check and avoiding electronic forgeries are additional 216a24 i) impediments to electronic delivery and processing of checks.
BRIEF SUMMARY OF THE INVENTION
In general terms, the invention provides a financial instrument in both human and machine-readable form and methods of processing such an 5 instrument. The instrument can be delivered by conventional facsimile transmission, with other forms of digitized image transmission, on a co~ uler disk, or as a paper document. The instrument may be formatted and coded to provide security against forgery, to accommodate shortcomings characteristic of facsimile transmission which is a preferred mode of delivery, and to facilitate 10 image conversion, authentication, and data processing by a digital computing machine. Individuals and institutions h~nclling the instrument can arrange for transactions to be entirely electronic, largely paper-based, or a mix of electronic and manual processing. This allows some parties to the transaction to automate their financial transactions and record keeping while allowing others to follow 15 more conventional practices, ultimately pe"llilling a smoother transition to fully automated transactions.
In one aspect, the invention permits a document, such as a financial instrument, that contains text in human-readable image form to be converted withhigh reliability into text in digital form. An image of the document may typically be 20 composed with a digital computing machine. The composition involves generating error checking characters that correspond to characters of the text, and generating error recovery characters that correspond to both the text characters and the error checking characters. The characters may be inserted into the image such that the text characters are presented in distinct fields and 25 such that the characters are arranged in error-h~ntlling blocks positioned according to a predetermined distribution algorithm The distribution of image characters may be selected to accommodate image distortion characteristic of image sc~nning and tr~n~mi~ion. The composed document may then be stored in electronic form, as on a magnetic disk, or in printed form. When tr~n~mi~tecl 21 6~2 ~ 6 electronically or otherwise delivered, the document may be subjected to image-to-text conversion. The conversion involves performing optical character recognition on the image to converted the image characters into digital form. The text characters and error checking characters may then be S reconstructed using the error recovery characters. An error calculation may then be performed to confirm whether the text has been reconstructed error-free. In practice, a preliminary error calculation is preferably performed immediately after conversion of the text characters and the error checking characters into digital form, to identify whether a recognition error has occurred. If no 10 recognition error is identified, then the conversion of the error recovery characters and the reconstruction using the error recovery characters can be avoided, potentially reducing processing time. The process achieves "high reliability" as the converted text is known either to be error-free with reasonable certainty or definitely subject to error. A sound decision can then be made 15 whether to rely on the converted text.
In another aspect, the invention provides a method of delivering a financial instrument that authorizes the transfer of an asset over telephone lines and of authenticating the delivered financial instrument. The method involves forming an electronic image of the financial instrument that contains a transaction record.
20 The transaction record includes human-intelligible characters (alphanumeric characters and common symbols) specifying the transaction, optionally various data fields cont~ining additional transaction information such as sequencing numbers and what is referred to herein as a "transaction fingerprint", and digital signature characters produced by combining a digital key code, such as a private25 or secret code of the transferor, with other characters of the transaction record.
The image also contains error checking characters that correspond to the characters of the transaction record, and error correcting characters corresponding to both the transaction record characters and the error checking characters. The image is tr~n~mitt~l over telephone lines to a desired 21~2~ ~

destination, which may be a service center adapted to process and authenticate the financial instrument. Image-to-text conversion, as described above, is used to extract the characters of the transaction record. The authenticity of the financial instrument is then tested, the authenticity testing comprising combining a digital key code corresponding to the transferor' s digital key code with the characters of the transaction record.
A principal application of the invention is to transferring of funds with a check. The check may be composed, as described above, on a digital computing machine using appropriate software. The payor may then deliver the check to the payee by facsimile transmission. The payee may in turn deliver the received check together with a service request document providing deposit instructions to a service center by facsimile tr~n~mi~ion. The service center performs the necessary image conversion, authenticates the check, records details of the transaction, and instructs any required transfer of funds betweenfinancial institutions.
Several aspects of the invention have been identified above to give a general indication of the nature of the invention. Various aspects of the invention will be apparent from a description below of preferred embodiments and will be more specifically defined in the appended claims.
DESCRIPTION OF THE DRAWINGS
The invention will be better understood with reference to drawings in which:
fig. 1 diagrammatically illustrates one method of transferring funds that involves a specially composed check;
fig. 2 schematically illustrates overall operating procedures of a service center adapted to process the check;
fig. 3 is a diagrammatic representation of the check;
fig. 4 is a table indicating how the elements of an error-handling 216~24 ,~

logic block are positioned in the check;
fig. 5is a flow chart of steps for extracting processing vectors from documents tr~n~mitt( d to the service center;
fig. 6 is a flow chart of steps for performing image-to-text conversion on documents after extraction of their processing vectors;
fig. 7 is a flow chart indicating how the service center handles a request to deposit a check; and, fig. 8 is a flow chart indicating how the service center authenticates a check.

Methods for producing a check 10 in both human and machine-readable form, for extracting and authenticating data from the check 10, and for processing data contained in the check 10 will be described in detail below.
However, a brief overview will first be provided with reference to fig. 1 of how a transfer of funds can be effected using the check 10 and a similarly configured deposit request form 12, to make the purpose for various formatting, coding, and processing steps more apparent.
The issuer 14 of the check 10 m~in~in~ an issuing station 16 comprising a personal computer 18 with fax modem and software required to produce and transmit an image of the check 10. Access to the software may be controlled with a personal authorization device ("PAD") 20 such as a software diskette, an electronic key, a smart card, or a card reader and a personal magnetically-encoded card. As well, the issuer 14 may be required to enter a personal identication code ("PIC") to authorize issuance of a check. The issuer 14 may enter all information commonly required to complete a conventional check, such as the name of the payee 22, the amount of the check, and also the check number and date if the software does not otherwise provide such information by default. The software then composes an electronic image of the check 10, which includes the entered information and transaction control data 216~24&

required to process the check 10. The software may also insert into the image a pre-recorded sample of the issuer's ~ign~tllre. A digital ~ign~tllre is also inserted into the image to allow authentication of the source and to allow detection of any subsequent alteration of the information contained in the check5 10. The check 10 may then be sent by facsimile transmission with an appl..pliate information slip 24 identifying the nature of the payment to the receiver/payee 22 . To deposit the check 10 to his bank account, the payee 22 transmits the check 10 and any other comparable checks (not shown) together with the deposit request form 12 by facsimile transmission to a service center 26 10 established specifically to handle such checks. The service center 26 authenticates the check 10 and instructs the necessary funds transfer between the issuer's bank 28 and the receiver's bank 30. It also sends receipt 39 by facsimile tr~nsmission to the payee 22 confirming the deposit Reference is made to fig. 2 which illustrates the overall operating 15 procedure of the service center 26. To request services, a user must have a service request document. The service center 26 or an associated financial institution may provide the user with several reusable service request documents. Each document may request a different service such as depositing, authentication, certification, or registration of a check or checks. The user may 20 also be given service request documents for requesting account balances or other account management services. Each document, such as the deposit request form 12 referred to above, will typically have data fields identifying basic user information: the name of his financial institution, the official name of the user as recorded by the financial institution, his account number with the 25 financial institution, and his return facsimile telephone number.
Services respecting checks are provided in a common manner. The user selects the service request document identifying the required service. He then transmits the selected service request document together with the check or checks to be processed to the service center 26 as a facsimile set 32 (single facsimile tr~nsmission) containing images of all documents, which permits the service center 26 to relate the requested service to the particular checks. The service center 26 receives the facsimile tr~n~mi~ion with a receiving fax modem 34 and stores the tr~n~mittrd facsimile set 32 on magnetic disk 36 or other applupliate storage medium. The service center 26 checks 5 whether a proper facsimile set has been received. To simplify procedures and avoid confusion, a proper set must identify a single checking service and one ofmore checks to which that service is to be applied. The service center 26 identifies and implements the required service and transmits a report to the user via one of several out-going fax modems 38 confirming the service or 10 identifying, where possible, any document or processing error.
The check 10 has the form diagrammatically shown in fig. 3. It has a central message region 40 surrounded by a processing frame 42. The message region 40 contains a transaction record cont~ining text that identifies details of the transaction. The transaction record somewhat resembles a conventional check, 15 containing sufficient information in human-readable form that the payee 22 can identify the document as a check and can identify details of the funds transfer involved. Such information is provided in distinct fields that are contained in message lines designated Mesl-Mes7. Headers and general background information in the check 10 have been shown in italics in fig. 3. Such matter is20 treated purely as graphics, not text that is somehow to be processed.
The check 10 also contains two image fields. One is a signature stamp 44 that is scanned or otherwise recorded by the issuing station software and is simply pasted into the document to provide a familiar visual indication that the check 10 is authorized. The other image field, immediately to the right of the 25 signature stamp 44, is referred to in this specification as the "endorsement area"
and identified with reference numeral 46. The endorsement area 46 may contain various m~rking~, allowing for countersigning, a teller's initials, and prûcessing information, such as the depositor's driver's licence number. A

216S24 ~

distinguishing marking may also be applied to the endorsement area to make a particular copy of the check 10 unique and thus the only negotiable copy of the check 10.
Several fields in the transaction record of fig. 3 are shown in 5 alphanumeric form, but their data is intended primarily for machine interpretation. These fields are contained in message lines Mes8-Mes 11. Each such field is represented in fig. 3 by a string of identical alphabetic characters.
The characters "h" identify a field that contains a sign~tllre stamp hash code.
The characters of the ~ign~tllre stamp hash code are simply generated in a 10 conventional manner from a digitally coded representation of the pixel positions of the signature image and provide a code uniquely corresponding to that representation of the signature. The characters "i" identify a field cont~ining an issuer's key identification. The issuer 14 may be permitted to use multiple private/public key sets, and the key identification field identifies that particular 15 public key required to authenticate the document. The characters "f~' identify a field containing a transaction fingerprint that effectively encodes the sequencing of a series of checks issued by the issuer 14. The characters "t" identify a field containing a time and date stamp indicating precisely when the check 10 was issued. The characters "q" identify a field cont~ining a transaction sequence 20 number, a two digit code incremented with each issued check and restarted as required. The characters "x" identify a field containing a code corresponding toa form vector (whose function is described below) that identifies the nature andformat of the document. This field is included to allow subsequent reconstruction of the document from extracted transaction record data and to 25 ensure that the format of the document is unalterably recorded within the digital signature. The characters "s" identify a field cont~ining the digital sign~tllre.
Although these data fields may be composed of characters comprehensible only to a machine, use of alphanumeric characters perrnits a human operator to interpret the document if optical character recognition errors do not permit machine intel~r~L~Lion.
Several fields in the transaction record have been shown blank in fig. 3. For example, two blank fields are associated with titles "Deposit to:" and "Trans:." These are optional fields in the transaction record. Data can be entered into the field titled "Deposit to:" that identifies the payee's financial institution and account number, to allow for direct transfers of funds. The field "Trans:"
may receive general processing information specified by the payor's financial institution.
The characters "E" in fig. 3 identify a field cont~ining the characters of a conventional cyclic re~ n-l~ncy check ("CRC"). These are calculated in a conventional manner from the characters in the text fields of the transaction record. There is freedom to select the fields that constitute the transaction record. For example, the "Memo:" field can be excluded. Generally, any text field that contains informaton needed to instruct or authenticate the financial transaction should be treated as part of the transaction record and reflected in the CRC, to permit checking for recognition errors. For example, fields identifying the dollar amount of the transaction, the payor and the payee 22 are critical and should be included in the transaction record. The CRC is not itself part of the transaction record.
The digital signature may be produced according to procedures specified by the proposed Digital Signature Standard of the U.S. Federal Government. For the check 10, the signature is produced by combining a private key of the issuer 14 with the characters of the text fields of the transaction record (basically all text characters contained in the fields in lines Mesl-Mesl 1 except the CRC and the digital sign~tllre itself). Basically, any text field in the transaction record whose alteration is to be detected, should be included in the generation of the digital signature. The private key is normally a code with a length between 512 and 1024 bits, and the software operating the issuer's issuing station 16 preferably generates and securely stores the private 21652 1 ~

key. In practice, the issuer's bank 28 will preferably provide to the issuer 14 the software for issuing checks and generating private keys. The bank 28 will also obtain from the issuer 14 a corresponding public key that can be used to authenticate his checks, a digitized sample of the handwritten ~ign~tllre that will 5 be appended to the issuer's checks, and a secure hash code representation of his signature. The data and signature specimen are stored in applopliate databases at the service center 26. Processes for authenticating a text message Cont~ininga digital signature by combining the characters of the document and ~ign~tllre with an authentication key are well known and will not be described. Other 10 procedures for generating and authenticating digital sign~tllres may be substituted.
The processing frame 42 includes an indexing frame 48 that assists with optical character recognition. The indexing frame 48 constitutes positioning indicia for optical character recognition, defining the borders of the check image and 15 serving as a reference that permits the location of various fields and data to be specified. The upper right-hand corner 50 has a unique shape that permits the orientation of the image to be identified. If the image is tr~n.~mittP~l inverted or skewed, the image can be flipped or rotated with conventional software techniques to achieve a proper orientation for optical character recognition. The 20 indexing frame 48 also identifies or defines columns and rows within its boundaries. A particular font with fixed character spacing will typically be used, and characters will be aligned in the distinct columns and rows during image composition to facilitate subsequent optical character recognition. The repeating pattern of alternating black and white areas in the indexing frame 48 25 should be noted. In the innermost rectangle 52 of the indexing frame 48, eachof the black or white rectangles along the top and bottom identifies the position of a column and along the lateral sides, the position of a row. In the outermostrectangle 54 of the indexing frame 48, each of the black and white spans two 216524~

columns or two rows. This permits the location of up to four missing rows or columns to be identified. Processing of the document can be adjusted accordingly.
The processing frame 42 also contains processing vectors that are S located immediately adjacent to the upper and lower edges of the indexing frame 48 in rows designated PV1 and PV2. The processing vectors control how a document is handled and converted to digital text. These vectors include a service vector whose character positions are identified with the letter "V", a form vector whose character positions are identified with the letter "F", and a 10 coding vector whose character positions are identified with the letter "C."
The processing vectors must be retrieved error-free to permit processing of the document. Each processing vector is essentially a digital codethat includes its own parity characters to allow for proper recovery despite optical character recognition errors. Since fax machines are notorious for producing 15 vertical lines obliterating an entire column, the characters of the various vectors are interleaved in a predetermined manner, rather than contiguous, and the processing vectors in the lower row PV2 are duplicates of the processing vectors in the upper row PV1 but with a different predetermined distribution of characters. What should be noted is that no character of any processing vector 20 in the upper row PV1 is in the same column as any character of the duplicate processing vector in the lower row PV2. Thus, if a column or several columns are lost because of faulty sc~nning and facsimile transmission, a processing vector can still potentially be retrieved.
The service vector identifies the service center responsible for 25 processing the check 10. The particular service center 26 will have the issuer's public key and other data required to process and authenticate the check 10.
The service vector can be used to route the check 10 (or any other document similarly formatted) to an appropriate service center that can handle the document. The facsimile telephone number or other communications address of 21652 1 ~

the service center specified by the service vector may be retrieved from an appropriate database.
The form vector is essentially a code identifying a predetermined form~tting template required to process the text and image data in the document.5 The form~tting template identifies the nature of the document (in this case a check), the nature (names) of the various information fields in the document, the relative locations of the various fields, and the data types of the fields (numeric, alphabetic, dollar or otherwise) to optimize optical character recognition. For the check 10, the form vector would refer to a template that 10 identifies the location and nature of each of the text and image fields discussed in detail above. This is imperative to permit the service center 26 to properly record the check 10 among the issuer's check records. The deposit request form 12 is formatted in a substantially identical manner, and its form vector causes the service center 26 to retrieve a form~tting template identifying a 15 requirement to transfer of funds between accounts and permitting the service center 26 to extract data fields necessary to instruct the transfer.
The coding vector identifies the coding algorithm used to generate the error correcting characters (parity characters) and the relative positions of the transaction record characters, CRC characters and error correcting characters in the 20 document image. The procedures used to compose the image of the check 10 are adapted to accommodate problems unique to facsimile tr~n~mi.~ion and accommodate poor paper handling practices. Noise on telephone lines normally results in the loss of entire horizontal scan lines, often in groups, potentially distorting the image of an entire row of characters beyond recognition. Sticking25 or slippage while a paper copy of the check 10 is conveyed by rollers through a conventional fax machine can result in stretching or contraction of horizontal lines, once again jeopardizing a row of characters. Dust on a scanning surface or a failed optical sensor can introduce a vertical black line into the image, and the transmitting party often has no knowledge of such a problem, potentially 216S2~6 resulting in the loss of an entire column of data. There are additional problemssuch as spots, stains, or fingerprints that can affect closely clustered groups of characters, spanning multiple columns and rows.
The characters of the message region 40 and the parity characters of 5 the processing frame 42 are effectively arranged or grouped into coding blocksfor purposes of computing the values of the parity characters. Any systematic error-correcting coding system that adds correcting symbols can be used. For an error correcting code of block size B, capable of correcting E errors within the coding block, there are certain basic requirements. The minimllm length or 10 width of the document in rows or columns should be greater than or equal to B/E. The number of members of any coding group sharing a common row or column should be minimi7rd and should be less than or equal to E. In general practice, given how lines are lost during sc~nning and transmission, it is desirable to avoid placing any two characters of a coding block in the same row 15 or column. It is also desirable to maximize the vertical and horizontal distance between proximate code block symbols, within the constraints of the code and the document size.
A document composed according to the invention may be viewed as a document array D[x, y] where x, y are column and row coordinates for 20 characters. For such purposes, rows of the form that contain only fixed titles are not part of the document array, and such information is specified by the form vector and associate form~tting template. The processing vectors can be viewed as lines separate from the document array and are governed by their own error recovery algorithms. The message text is an array M[x, y]=D[x+LM, 25 y+TM], where LM and TM are respectively the left and top margins of the document as specified by the coding vector. The message array is smaller and is preferably centered within the document. With respect to the check 10, as apparent in fig. 3, there are 11 message lines whose width is 48 characters. For 216524~

coding purposes, all positions in a row are treated as filled with characters, blank or otherwise. The coding system selected in this instance is a H~mming Code (15, 11), which involves logic blocks consisting of 11 message characters and 4 parity characters and which permits correction of one error among the members of the block. Since the coding arrangement can only correct one error per coding block, no two members of any coding block should be in the same column or row. Since the check 10 has 11 message lines, 4 lines of parity characters are required. These are provided in two lines Parl, Par2 above the message region 40 and two lines Par3, Par4 below the message region 40. The check 10 must thus have 15 rows to meet the desired requirement that no two members in any given coding block are in the same row or same column. There are consequently 48 logical coding blocks. Other coding arrangement can be used that allow block members to be recovered in the presence of multiple errors in a given block. However, the length of the document will tend to increase significantly with the degree of error correcting capability added.
Although the width of the message region 40 is a factor affecting the coding algorithm used, it is contemplated that most practical applications will involvefewer message lines than message columns, and the length of the document will tend to be the limiting factor.
The distribution pattern used for the logic blocks of the check 10 are shown in fig. 4. The area within the graph of fig. 4 corresponds essentiallyto the document array D whose dimensions are 15 by 48 characters. Only one logic block consisting of 11 message characters and 4 parity characters has beenshown so that the distribution of block characters will be apparent. The fifteenmembers of the block have simply been identified with the numeric positions in the block, that is, with the numbers " 1" to " 15." The other 47 logic blocks are essentially interleaved in similar patterns.
The character spacing pattern shown in fig. 4 is specified by a distribution vector Dis(m) whose values are listed in fig. 4. Dis(m) is an array of 216~24~

[x,y] coordinates with each element representing the relative location of each member of a particular code block with respect to the code block' s home position, Home(b), where b identifies a specific code block and m is the number of the code block member within its block. The distribution array, Dis(m), and home positionS coordinate, Home(b), are used to calculate the position for each code block member. By example, the location of the third member of the fifth coding block can be computed by adding the location coordinates of Dis(3) and Home(5).
For the coding block shown in fig. 4, the home position is [1,1]. In performing the coordinate addition, should the resulting x coordinate exceed the10 document width, then the width is subtracted from x to provide a valid x coordinate (effectively wrapping around on the same row). In the same manner, should the resulting y coordinate exceed the document length then the length is subtracted from y to provide a valid y coordinate (effectively wrap around within the same column).
lS The Dis(m) and Home(b) arrays are determined at the time of message region and form design and are permanently stored as part of the coding template files that must be accessed by the document coding system when placing and computing parity characters and by the interpreting systems to locate and compute corrections for recognition errors. The specific template file 20 used for coding a particular form is, as mentioned above, identified by the coding vector encoded on the form. Each message character in the example of fig. 4 is a member of one coding block; however, other implementations can allow each message character to be a member of multiple coding blocks.
The Dis(m) array values and Home(b) array values may be 25 determined during form design using computer-aided sim~ tion techniques, which perform trial block member placements and then test and select the placement pattern that obtains the largest minimllm distance between any two members of a coding block, while also ensuring that each member occupies a different row and column. In the example shown, the coding block size has been selected to match the document length, simplifying the distribution processby allowing the home position of each code block to be in the first row of the document array and allowing all code blocks to use the same Dis(m) vector.
As apparent in fig. 4, no two members of the coding block are in the S same column or row. Also, each member of the block is spaced for practical purposes substantially an equal distance from the nearest other member of the block. This achieves the desired results that only a single member is potentially lost if a facsimile transmission results in a lost vertical or horizontal line. The substantially equal spacing of the members from nearest members reduces the 10 risk that an entire coding block will be irrecoverable if a spot or stain is formed on the document. If a coding algorithm is selected that permits each coding block to recover from a loss of two or more block members, computer simul~tions can be performed to arrange block members so that the number of block members in any column or row does not exceed the number of errors that 15 can potentially be recovered while also maximi7ing minimum character separation.
The significance of providing the coding vector should now be apparent. For the check 10, the coding vector identifies that a H~mming Code (15,11) was used to create the parity characters and identifies the spacing or 20 distribution algorithm used to position the characters of the coding blocks. A
universal arrangement assuming a maximum number of lines and a maximum width would elimin~te the need for a coding vector. However, documents would be constrained to fit a particular format, and excessive computational time would be required for comparatively small documents. Providing a coding 25 vector permits the format of a document and the coding arrangement to be optimized. The relevant coding information is simply stored by the service center 26 and retrieved according to the coding vector extracted from the particular document received.

216524~

Digital signature techniques can be used to establish the authenticity of a document. However, there remains a potential for "digital impersonation."
This may occur, for example, if an employee or officer of a corporation obtains the PIC and manages to duplicate the check issuing software and any other confidential 5 information required to produce apparently authentic checks. The transaction fingerprint and transaction sequence number are provided to address that potential problem.
The transaction sequence number simply identifies the sequence in which the checks are produced. There are two basic principles governing generation 10 of the transaction fingerprint. First, a random element is introduced into the transaction fingerprint for each new check that is issued. The random element may be a (pseudo) random number generated with conventional cryptographically secure algorithms. It can alternatively be derived from the time at which the check is processed, using the least significant bits of an 15 internal clock of the issuing station 16. What is important is that the element be sufficiently random that a digital impersonator cannot reliably anticipate and generate the element. Second, the transaction fingerprint effectively combines transaction fingerprint codes from earlier checks so that the sequencing of the checks is effectively encoded into the transaction fingerprint. A digital 20 impersonator may be able to produce apparently authentic checks, but the sequencing of checks issued by the legitim~te issuer 14 and the digital impersonator will diverge, normally when each has written a single check. The service center 26 can compare transaction finge~ , extracted from earlier or later checks to identify such a divergence and steps can be taken to alert the 25 legitim:~te issuer 14 and to arrange for a new PIC and new public and private keys.
The preferred algorithm for encoding the transaction fingel~ l with a check sequencing history will be described. In typical practice, the check issuing software may calculate a new transaction fingerprint whenever a check is issued and 216~246 the new transaction fingerprint can be stored for use on the next check. To start the process, the transaction fingerprint may be initiated to a random 50 element array.
The elements of a new transaction fingerprint may be composed from the elements of the last transaction fingerprint with the following algorithm:
TFPnew[i] = TFPold[i-l] for i = 2 to 50 TFPnew[l] = a random 5 bit number where, TFPnew and TFPold are one-dimensional arrays respectively representing the elements of the new transaction fingerprint and the immediately preceding transaction fingerprint. In effect, to produce the new transaction fingerprint, the new random number is concatenated with the previous transaction fingel~fi and the random number associated with the oldest check in the series is discarded from the previous transaction fingerprint.
The center which processes the issuer's checks records the transaction fingerprints for all the issuer's transactions. When a new check is faxed to the service center 26, the transaction sequence number and transaction fingerprint are extracted. The service center 26 retrieves a recorded transaction record for another check that is preferably closest in date and transaction sequence number to the received check. The transaction fingerprints of the two checks are compared according to the following algorithm:
j=TSNlater - TSNearlier Is TFPlater[i+j] = TFPearlier[i], for i = 1 to (50 - j) where, TSNlater and TSNearler are respectively the transaction sequence number of the later and earlier checks, and TFPlater and TFPearlier are one-dimensional arrays representing the transaction fingerprints of the two checks. If for any of the values of i there is a mi.~m~tch then the checks do not reflect the same issuingsequence and did not originate with the same issuer 14. The comparison will typically be performed twice, once with the closest prior transaction and once with the closest later transaction, whenever possible. The comparison need not be done directly with the transaction fingerprints in other checks. The service center 16 may extract the random elements from the issuer's processed checks, organize the random elements in sequence according to transaction sequence numbers generated to create a sequencing string, and compare the transaction fingerprint of any new check apparently authorized by the issuer with the string5 to detect a sequencing discrepancy resulting from digital impersonation.
The transaction sequence number may be incorporated, if desired, into the transaction fingerprint, thus elimin~ting a distinct field in the transaction record. Transaction fingerprints can also be compared without reliance on distinct sequencing numbers. A valid transaction fingerprint must have a trailing string of 10 elements that matches a starting string of elements of an earlier transactionfingerprint. It must also have a starting string of elements that matches a trailing string of elements in a later transaction fingerprint. The transaction fingerprint of a newly received check can thus be compared with fingelL.linl~ of recently recorded checks for a correlation or absence of correlation among fingerprints.
15 However, such a process requires additional computational time and is somewhat subject to error. Also, a failure to find a correlation may arise wherethe issuer 14 has many outstanding standing checks, and transaction sequencing numbers can immediately identify such a problem.
To reduce the size of the transaction fingerprint, the algorithm 20 producing the transaction fingerprint can be weighted more heavily in favour of recent checks. For example, the first 10 elements of the transaction fingerprintcan be encoded using 5 bits each; elements 11-20, using 4 bits; elements 21-30, using 3 bits; element 31-40, using 2 bits; and elements 41-50, using one bit. As the elements of a transaction fingerprint are effectively shifted to25 form a new transaction fingerprint, the least significant bits of older elements can be dropped as each element shifts through the various ranges specified.
During comparison of transaction fingel~ , the elements in an earlier transaction fingerprint must be adjusted accordingly.

21652~ i~

If the form vector and associated form~tting template indicate that a signature stamp must be present in the document, authentication of the document will involve authentication of sign~hlre stamp data. The center responsible for authenticating the document will have a stored representation of the ~ign~tllre stamp 5 44 and the associated hash code. The signature stamp hash codes are compared and must match exactly. The signature stamp images are compared and must match within tolerances accommodating scanning and processing distortions.
To compare the images, the signature stamp image is extracted from the document, scaled to match the stored image, and filtered to remove pixel noise 10 and small groups of isolated dark or light pixels. Masks are then prepared from both the extracted and stored signature images by replacing dark pixels in each with circles of darkened pixels with a 3-11 pixel diameter. Using conventional graphic processing techniques, the mask formed from the stored stamp image is superimposed on the extracted stamp image, and the number of dark pixels of 15 the extracted stamp image that are covered by the mask is tallied and compared with the total number of dark pixels in the extracted ~ign~tllre stamp image. The processes is then reversed, and the mask of the extracted stamp image is superimposed on the stored stamp image. The number of dark pixels of the stored image that are contained within the mask is tallied and compared with the20 total number of dark pixels in the stored image pixels. If ratios of dark image pixels within the masks to total dark image pixels for both tests meets a presetminimllm value, for example, 90 per cent, then the two signature stamps are assumed to match with tolerances accommodating sc~nning and processing distortions. Otherwise, the ~ign~tllre stamp in the newly received document is 25 assumed not be authentic. Other image correlation techniques may be used.
The endorsement area of the check 10 is similarly processed to ensure that any m~rking~ that were present within the endorsement area of a previously registered copy of the check 10 remain present in the copy currently being processed. The verification center will scan its data base to identify whether the check 10 was previously processed and registered. If it has been, the endorsement area image of the registered check 10 is retrieved from storage 56.
The endorsement area is extracted from the check 10 being processed, scaled to correspond to the stored endorsement area, filtered to remove isolated dark or light S pixels (noise), and processed to remove any new markings that may have been made since the document was last registered. To remove new m~rking~ from the extracted endorsement area, a large outline-mask is constructed from the stored endorsement area by replacing the dark pixels of the stored image with filled circles 20 or more pixels in diameter. The extracted image is then 10 modified by performing a logical AND operation with the outline-mask, removing all the dark image components lying outside of the outline-mask area and preserving the portion of the extracted image lying within the dark area of the outline mask. The stored and modified endorsement areas are then compared using the same process described above for ~ign~tllre stamp images, 15 and the stored and modified endorsement area must match within the tolerances allowed for scanning and processing distortions.
The deposit request form 12 and other service request documents are configured in the same overall manner as the check 10. Each has an indexing frame, error checking codes, error recovery codes, and processing vectors 20 including a service vector, a coding vector and a form vector. These ensure accurate conversion of data into digital text form, proper identification of data fields, and identification of the nature of the document and the service requested. As mentioned above, the service request documents may typically be supplied to the user by the financial institution that m~int~in~ his accounts.
25 Each document may contain a digital signature field composed with a key code of that financial institution and the characters of the text fields in the document to ensure that basic user information contained in the document is not altered and remains consistent with service center records.
How the service center 26 processes the facsimile set cont~ining 216 3 2 ~ 6 deposit request form 12, the check 10 and other accompanying checks will be described below. The description includes general proces~ing steps applicable tovarious documents that might be received by the service center 26.
Preliminary processing involves extracting the processing vectors from each document image within the facsimile set cont~ining the deposit request form 12 and check 10 and then assessing whether the set can be processed. Fig. 5 indicates the preliminary process of extracting processing vectors from the received documents. The document image is scanned to locate the top and bottom of the document' s indexing frame. If the indexing frame 10 does not have preset proportions, as apparent for example from the indicia provided in the indexing frame, the document image is scaled accordingly. The two areas cont~ining processing vectors are then identified and subjected to optical character recognition to convert the processing vectors. The parity characters of the processing vectors are used to check and to correct any processing errors using standard algorithms. If errors remains in both copies, one attempt is made to correct the errors by subjecting the document image to conventional two-dimensional noise filtering and image distortion compensation, and then repeating the processing steps. If the conversion process is successful, the processing vectors together with frame and scaling information is recorded for further processing steps. Otherwise the document image is tagged with an error flag indicating that the processing vectors cannotbe interpreted for this document image.
The service center 26 then determines if a service vector for a recognized service request document has been successfully extracted and checks the service vector to determine if the requested service can be locally processed. If local processing is not supported, the service vector can be used to retrieve a stored facsimile telephone or other fol~1varding address for the applopflate service center. The facsimile set may then be tr~nsmitte~ to that other center for 216~ 2 4 6 processing. If no stored tr~n.~mitt~l information is available for the particular service vector then the system tags the document set with an error flag indicating that the service vector is unrecognized and transfers the document set to an exception h~n(lling system. Otherwise, the service center 26 examines the S form vectors in the various documents, to determine the nature of the service requested and to determine if the documents are consistent with the service requested. If a service request document and consistent documents cannot be identified, then the facsimile set is tagged with an error flag and transferred to the exception handling system which may further process the received 10 documents so as to be able to send a message back to the user indicating that the requested service cannot be provided and providing a description of the nature of the processing error. It will be assumed that the processing vectors that identify the deposit request form 12, the check 10 and the other accompanying checks have been successfully extracted.
Each document in the facsimile set is then subjected to an image-to-text conversion process. The objective of this process is to convert each document image into an error-free text message or to otherwise tag the document image with an applupliate error message to aid in further processing steps. Fig. 6 shows the steps of a procedure for performing image-to-text 20 conversion of a document after extraction of its processing vectors. The extracted coding vector is used to retrieve the associated coding template and thereby to identify the location of the message area within the document. The form template corresponding to the extracted form vector is retrieved from storage, and the nature and locations of the various data fields of the document25 are identified. The field locations are subjected to optical character recognition to extract field data. For the check 10, the various fields of the transaction record together with the CRC are extracted. An error check is then performed using the CRC to determine whether a recognition error has occurred. If a recognition error is detected, the coding template identified by the documents 216524~

coding vector is retrieved, and the parity regions of the document are subjectedto optical character recognition. The recovered parity characters, along with the block distribution pattern and parity equations indicated by the coding template, are then used to compute the location and correct value of text data conl~ining 5 errors to attempt reconstruction of the transaction record and CRC. For the check 10, the parity lines Parl-Par4 are converted, and the transaction record and CRC are reconstructed. A further error check is performed using the reconstructed CRC and transaction record characters. If an error is again detected, the image may be enhanced, once again using conventional 10 techniques. The various steps are then repeated with the enhanced image to attempt to convert or recover the data fields error-free. If an error still remains, the check 10 is tagged with an error flag indicating that it cannot be correctlyconverted. Otherwise, the extracted text data fields are stored for further processing and the transaction record and the form template are checked to 15 determine if any image fields are contained within the document. Two image fields are potentially incorporated into various documents involved in handling financial transactions: a signature stamp, and an endorsement area. If one or both fields are present, both being present in the check 10 document, then thesefields are each extracted from the image and encoded for separate storage and 20 process handling. Other checks in the facsimile set are similarly processed.
The deposit request form 12 is subjected to essentially the same image-to-text conversion process. If converted error-free, the facsimile telephone number in the deposit request form 12 is of particular importance as it may be used in later processing to transmit a message to the depositor identifying which of the 25 checks included with the request, have been successfully processed and whether any of the checks were rejected or should be retransmitted with another deposit request form to reattempt deposit processing.
After all documents in the facsimile set have been processed through the image-to-text conversion routine, the document set is examined by a service selection routine to determine if a sufficient number of documents (the deposit request form 12 and at least one check) have been successfully converted to allow execution of the requested service. If the service can be performed with the available documents then the routine initiates the procedure necessary to complete 5 the requested service. For each service offered to the users of the system there is a corresponding service procedure at the service center 26. The service procedure for the check deposit is further described below. If no service can becompleted with the available text documents the service selection routine passesthe document set to the exception handling system. If the facsimile telephone 10 number in the service request document was successfully recovered, then the exception handling routine would transmit a report to the user to indicate the nature of the processing problem and suggest possible action by the user. The exception handling system m~int~ins a log of exception events for review and possible intervention by human operators Fig. 7 illustrates the procedure used by the service centre to process the deposit request. The first step in the procedure is to verify the deposit information to confirm that the payee, as identified on the deposit request form, is the true holder of the bank account identified on the form as the destination of the funds. This information can be verified by cross-checking it 20 with trusted information available in a database or, if the deposit request document was digitally signed by a trusted authority, such as the payee's bank, then the digital signature may be tested to establish the validity of the information. The payee identified in each check is then correlated with the official name of the depositor to ensure an adequate match. If a match is not 25 confirmed, the relevant cheque is tagged with an error flag to indicate the result for later processing.
Each cheque is then tested to establish that the payor has authorized release of the funds. The results of the authorization test is tagged to each cheque 216524~

document for later interpretation and processing. The procedure followed by the service center to authenticate each cheque is shown in fig. 8. First, a conventional digital signature verification algorithm is used to test whether the extracted digital sign~tllre is valid. If the digital signature is valid, the transaction fingel~filll is then 5 tested as described above. If the transaction fingerprint matches others in other recorded funds transfers of the issuer, but a weak match occurs (the difference between transaction sequence number is large and exceeds a preset value), the weakness in the match is flagged and reported in an internal security log. In response, the issuing station may be contacted to request a download of data 10 regarding issued, but unprocessed, cheques, particularly sequence numbers andtransaction fingerprints, and the conversion authentication procedure may be repeated, to ensure that no digital impersonation has gone undetected. The transaction sequence number is also compared with sequence numbers in previous cheques of the issuer already recorded by the service. If the cheque l S appears to be a duplicate (previously recorded) then database records are retrieved to identify whether the check was previously deposited and is thus no longer negotiable. If the check is a duplicate, but has not been deposited, the endorsement area of the check is compared with the stored endorsement area of the previously recorded check. If the endorsement area of the cheque does not 20 match (contain all markings of) the stored endorsement area, then the check is non-negotiable and flagged as such. If the form vector associated with the cheque identifies that a sign~tllre stamp is required, then a stamp test is performed, as described above, comparing the stamp area and signature hash code contained in the cheque with stored copies of the issuer' s signature stamp25 and stamp hash code. The authentication test results are tagged to each cheque document identifying that the cheque has been properly authenticated or has failed a specific authentication test.
The service center system then examines the authentication results for the deposit request document and each of the cheque documents to determine if any 216~24~

funds transfers can be authorized, if security alerts are to be posted, and to determine the updates necessary to account transaction records. Transaction logs are then updated to indicate current status and funds transfer request messages are formatted fortr~nsmission to the issuers' banks. These messages will ultimately result in the release of funds by the issuers' banks to the payee's account. A summary report is prepared for the user that initiated the deposit request, that report describing the status of each cheque submitted for deposit, whether the cheque was accepted or rejected and if rejected for what reasons and what action by the user is recommended. The summary report is sent to the user by facimilie transmission 10 to the fax number identified by his service request document.
A request to register the check 10 would be handled in a similar manner to the deposit request except that a funds transfer is not effected and accounting records are not updated to reflect a funds transfer. To effect registration of the check 10, the user places a distinguishing mark in the endorsement area of the check 10, and transmits the marked check 10 together with a registration request document to the center, as a facsimile set. The service center 26 extracts the transaction record from the check image, including the images of the sign~ re stamp and endorsement areas. It then tests the authenticity of the check 10, which, as described above, includes retrieving any previous record regarding the check 10 and comparing any stored endorsement area with the endorsement area 46 extracted from the received check image to assess whether the extracted endorsement area 46 contains all m~rkings of the stored endorsement area. If the authenticity tests are met, the service center 26 stores the extracted endorsement area 46, replacing the endorsement area image already on file. If another copy of the check 10 is subsequently received by the service center 26, for any purpose, the normal authenticity testing procedure used by the service will compare the endorsement area of the subsequent copy with the newly recorded endorsement area. If the endorsement area of the subsequent copy does not contain the distinguishing mark applied by the user who requested 216524~

registration, the subsequent copy will fail authenticity testing and cannot be deposited. Registration thus makes the registered copy unique. A user may request such service if he has concern that a copy of a received check has been made and may be submitted for processing.
It will be appreciated that particular embodiments of the invention have been described and that modifications may be made therein without departing from the spirit of the invention or necessarily departing fromthe scope of the appended claims.

Claims (33)

1. A method permitting text in human-readable image form to be converted with high reliability into text in digital form, comprising:
generating error checking characters corresponding to the characters of the text according to a predetermined error checking algorithm;
generating error recovery characters corresponding to both the text characters and the error checking characters according to a predetermined coding algorithm;
forming an image in electronic or printed form containing image characters corresponding to the text characters, the error checking characters, and the error recovery characters;
performing image-to-text conversion on the image with a digital computing machine, the image-to-text conversion comprising:
(a) performing optical character recognition on the image thereby to convert the image characters into digital form;
(b) reconstructing the text characters and the error checking characters using the converted error recovery characters and the converted text and error checking characters; and, (c) performing an error calculation with the reconstructed text and error checking characters thereby to confirm whether the text characters have been reconstructed error-free.

2. The method of claim 1 in which the forming of the image comprises:
orienting the image characters in columns and rows;
selecting sets of the image characters to constitute members of error-handling coding blocks; and, selecting the positions of the members of the coding blocks such that, for each of the coding blocks, the number of its members in any one of the columns or rows is less than or equal to the number of character errors that the coding block can correct.

3. The method of claim 2 in which the selecting of the positions comprises spacing the image characters such that, for each of the coding blocks,each of its members is substantially equally spaced from a closest one of its other member.

4. The method of claim 1 in which the forming of the image comprises: forming positioning indicia; and, placing the image characters in columns and rows.

5. The method of claim 4 in which:
the forming of the image comprises arranging the image characters in error-handling coding blocks according to a predetermined distribution algorithm, and inserting a code into the image in a predetermined location relative to the positioning indicia, the predetermined code identifyingthe coding algorithm and the distribution algorithm; and, the image-to-text conversion comprises performing optical character recognition at the predetermined location thereby to extract the predetermined code and to identify the coding algorithm and the distribution algorithm.

6. The method of claim 5 in which:
the forming of the image comprises arranging the text characters in data fields within the image according to a predetermined format defining field types and field locations, and inserting a formatting code identifying theformat into the image in a predetermined location relative to the positioning indicia; and, the image-to-text conversion comprises performing optical character recognition at the predetermined location before the conversion of theimage characters thereby to extract the formatting code and to identify the field types and field locations in the image.

7. A method of producing a document comprising text in human-readable form that can be interpreted with high reliability by a machine using optical character recognition, comprising:
composing an image of the document with a digital computing machine, the composing comprising:
(a) generating error checking characters corresponding to the characters of the text according to a predetermined error checking algorithm;
(b) generating error recovery characters corresponding to both the text characters and the error checking characters according to a predetermined codingalgorithm; and, (c) inserting into the image the text characters, the error checking characters, and the error recovery characters such that the text characters are presented in fields and such that sets of the inserted characters are members oferror-handling coding blocks positioned according to a predetermined distribution algorithm; and, storing the composed image in electronic or printed form.

8. The method of claim 7 in which the composition of the image comprises:
orienting the inserted characters in columns and rows; and, selecting the positions of the members of the coding blocks such that, for each of the coding blocks, the number of its members in any one of thecolumns or rows is less than or equal to the number of character errors that thecoding block can correct.

9. The method of claim 8 in which the selecting of the positions comprises spacing the inserted characters such that, for each of the coding blocks, each of its members is substantially equally spaced from a closest one of its other members.

10. The method of claim 7 in which the composition of the image comprises:
inserting positioning indicia into the image; and, inserting a code identifying the coding algorithm and the distribution algorithm into the image at a predetermined location relative to the positioningindicia.

11. The method of claim 7 in which the composition of the image comprises:
inserting positioning indicia into the image; and, inserting a formatting code identifying the fields contained in the image and the locations of the fields.

12. In a financial transaction involving transfer of an asset from a transferor to a transferee, a method of delivering a financial instrument authorizing the transfer over telephone lines and of authenticating the delivered financial instrument, comprising:
forming an image of the financial instrument in electronic or printed form, the image comprising a transaction record including human-intelligible characters identifying the transaction and including digital signature characters generated from the human-intelligible characters and a digital key code of the transferor, error checking characters corresponding to the characters of the record, and error recovery characters corresponding to the record characters andthe error checking characters;
transmitting the image of the financial instrument over the telephone lines;
performing image-to-text conversion on the transmitted image to convert the record characters into digital form, the conversion comprising performing optical character recognition on the transmitted image, performing anerror calculation with the record characters and the error checking characters after performing the optical character thereby to detect any recognition error, and recovering the record characters with the error recovery characters if a recognition error is detected; and, testing the authenticity of the transmitted financial instrument after the conversion, the authenticity testing comprising combining a digital key codecorresponding to the digital key code of the transferor with the converted characters of the transaction record.

13. The method of claim 12 adapted to identify the transmitted image as a unique copy of the financial instrument, the method comprising:
inserting a distinguishing mark into a designated area of the image before the transmitting; and, recording the financial instrument after the authenticity testing, the recording comprising storing a representation of the designated area; and, testing the authenticity of a subsequently transmitted copy of the financial instrument by comparing the designated area of the subsequently transmitted copy with the stored representation of the designated area to determine whether the distinguishing mark is contained within the designated area of the subsequently transmitted copy.

14. The method of claim 12 in which the financial instrument is one of a series of financial instruments issued sequentially by the transferor and in which:
the forming of the image comprises generating a transaction code according to a predetermined algorithm that combines a randomly generated code with transaction codes in earlier financial instruments in the series such that the sequencing of the earlier financial instruments is encoded in the transaction code, and inserting the transaction code into the transaction record in the image;
and, the testing of authenticity comprises comparing the transaction code contained in the transmitted image with a transaction code contained in another of the series of financial instruments and generated according to the algorithm thereby to confirm whether the compared transaction codes correspond to the same sequence of financial instruments.

15. The method of claim 12 in which the forming of the image comprises:
inserting the record characters, the error checking characters and the error recovery characters into the image in columns and rows;
selecting sets of the inserted characters to constitute members of error-handling coding blocks; and, selecting the positions of the members of the coding blocks such that, for each of the coding blocks, the number of its members in any one of thecolumns or rows is less than or equal to the number of character errors that thecoding block can correct.

16 . The method of claim 15 in which the selecting of the positions comprises spacing the inserted characters such that, for each of the coding blocks, each of its members is substantially equally spaced from a closest one of its other members.

17. The method of claim 12 in which the forming of the image comprises:
forming positioning indicia;
arranging the record characters, the error checking characters and the error recovery characters in error-handling coding blocks according to a predetermined encoding algorithm and in a predetermined distribution algorithm;
inserting a code into the image in a predetermined location relative to the positioning indicia, the predetermined code identifying the coding algorithm and the distribution algorithm;
the image-to-text conversion comprises performing optical character recognition at the predetermined location thereby to extract the predetermined code and to identify the coding algorithm and the distribution algorithm.

18. The method of claim 17 in which:
the forming of the image comprises arranging the record characters in data fields according to a predetermined format defining the fields and the locations of the fields, and inserting a formatting code identifying the format into the image at a predetermined location relative to the positioning indicia; and, the image-to-text conversion comprises performing optical character recognition at the predetermined location of the formating code before the conversion of the record characters thereby to extract the formatting code and to identify the fields and the field locations in the image.

19. A method of producing a financial instrument authorizing a transfer of funds from an account of a transferor to a transferee such that the instrument can be interpreted by a person and can also be transmitted over telephone lines for interpretation and authentication by a machine, comprising:
composing an image of the financial instrument with a digital computing machine, the composing comprising:
(a) generating a transaction record comprising human-intelligible characters arranged in fields identifying the transfer and a digital signature corresponding to the characters identifying the transaction and a digital key code of the transferor;
(b) generating error checking characters corresponding to the characters of the record;
(c) generating error recovery characters corresponding to both the record characters and the error checking characters according to a predeterminedcoding algorithm; and, (d) inserting into the image the record characters, the error checking characters, the error recovery characters such that the record characters are presented in fields and such that the characters inserted the image are arranged in error-handling blocks positioned according to a predetermined distribution algorithm; and, storing the composed image in printed or digitized form.

20. The method of claim 19 in which the financial instrument is one of a series of financial instruments issued sequentially by the transferor and in which the forming of the image comprises:
generating a transaction code according to a predetermined algorithm that combines a randomly generated code with transaction codes in earlier financial instruments in the series such that the sequencing of the earlier financial instruments is encoded in the generated transaction code; and, inserting the generated transaction code into the transaction record of the image;
whereby, the transaction code of the financial instrument can be compared with a transaction code contained in another of the series of financialinstruments and generated according to the algorithm to confirm whether the compared transaction codes correspond to the same sequence of financial instruments.

21. The method of claim 20 in which the predetermined algorithm comprises concatenating the random code with the transaction code contained in an immediately previous one of the series of financial instruments and produced according to the algorithm, whereby the algorithm encodes the sequencing of the earlier financial instruments in the generated code.

22. The method of claim 21 in which the predetermined algorithm comprises deleting elements from the transaction code of the immediately previous financial instrument, the deleted elements corresponding to a transaction code of an earliest one of the financial instruments whose sequencing is encoded in the transaction code of the immediately previous financial instrument.

23. The method of claim 19 in which the composing of the image comprises:
orienting the inserted characters in columns and rows;
selecting sets of the image characters to constitute members of error-handling coding blocks; and, selecting the positions of the members of the coding blocks such that, for each of the coding blocks, the number of its members in any one of the columns or rows is less than or equal to the number of character errors that the coding block can correct.

24. The method of claim 23 in which the selecting of the positions comprises spacing the inserted characters such that, for each of the coding blocks, each of its members is substantially equally spaced from a closest one of its other members.

25. A method of testing whether a particular financial instrument instructing a transfer of funds is one of a series of financial instruments issued sequentially by a particular issuer, comprising:
inserting into each of the series of financial instruments a new transaction code generated according to a predetermined algorithm that combines a randomly generated code with transaction codes in earlier financial instruments in the series such the sequencing of the earlier financial instruments is encoded in the new transaction code; and, comparing a transaction code contained in the particular instrument with the transaction code contained in one of the financial instruments in the series thereby to identify whether the compared transaction codes identify the same series of financial instruments.

26. The method of claim 25 in which the predetermined algorithm comprises concatenating the random code with the transaction code of an immediately previous one of the series of financial instruments, whereby the algorithm encodes the sequencing of earlier financial instruments in each of the transaction codes of the series of financial instruments.

27. The method of claim 26 in which the predetermined algorithm comprises deleting elements from the transaction code of the immediately previous financial instrument, the deleted elements corresponding to a transaction code of an earliest one of the financial instruments whose sequencing is encoded in the transaction code of the immediately previous financial instrument.

28. A method of authorizing a transfer of funds and of authenticating the authorization, comprising:
forming a funds transfer document authorizing the transfer of funds, the funds transfer document comprising a transaction record containing data fields identifying details of the transfer of funds including an account of the transferor with a financial institution, the amount of the funds transfer, and the transferee, the funds transfer document comprising a digital signature formed from the characters of the fields of the transaction record, and a digital key code of the transferor;
forming a service request document identifying a service requiring at least authentication of the funds transfer document;
transmitting a facsimile set comprising images of the funds transfer document and the service request document over telephone lines to a processing center;
processing the transmitted facsimile set with computing equipment, the processing comprising:
(a) performing image-to-text conversion on the facsimile set;
(b) extracting the data fields of the funds transfer document after the conversion;
(c) authenticating the funds transfer document after the extraction of the data fields, the authentication comprising combining the characters of the transaction record with a digital key code corresponding to the digital key code of the transferor; and, (d) recording the funds transfer document in a database.

29. The method of claim 28 adapted to identify the transmitted image of the funds transfer document as a unique copy of the funds transfer document, the method comprising:
inserting a distinguishing mark into a designated area of the funds transfer document before the transmitting the facsimile set; and, storing a representation of the designated area during the recording of the funds transfer document; and, testing the authenticity of any subsequently transmitted copy of the funds transfer document by comparing the designated area of the subsequently transmitted copy with the stored representation to determine whether the designating area of the subsequently transmitted copy contains the distinguishing mark.

30. The method of claim 28 adapted to instruct the transfer of funds, in which:
the forming of the service request document comprises inserting data fields into the service request document that identify the transferee, an account of the transferee with a financial institution, and a code identifying arequest for a transfer of funds;
processing the transmitted facsimile set with computing equipment comprises extracting the data fields of the service request document after the conversion, and issuing instructions after authentication of the funds transfer document for one of the financial institutions to transfer funds specified in the funds transfer document from the transferor's account to the transferee's account.

31. The method of claim 28 in which:
the service request document contains a data field that specifies a facsimile telephone number; and, the processing of the facsimile set comprises transmitting confirmation of the authentication of the authenticity of the funds transfer document over telephone lines using the specified facsimile telephone number.

32. The method of claim 28 in which:
the forming of each of the document comprises inserting positioning indicia into the documents, and inserting processing codes into the document at a predetermined location relative to the positioning indicia, the processing codes identifying the nature of the document and the nature and location of data fields of the document; and, the image-to-text conversion comprises scanning the transmitted facsimile set to locate each of the positioning indicia in the facsimile set, and performing optical character recognition at the predetermined locations of the processing codes relative to the positioning indicia thereby to identify the documents within the facsimile set.

33. The method of claim 28 in which:
the forming of the funds transfer document comprises inserting into the funds transfer document a prerecorded image of a handwritten authorizing signature and inserting into the transaction record a signature code derived according to a predetermined algorithm from the authorizing signature;
the authentication of the funds transfer document comprises:
(a) retrieving the signature code and an image of the authorizing signature from storage means;
(b) comparing the retrieved signature codes with the signature code extracted from the transmitted image of the funds transfer document; and, (c) comparing the retrieved image of the authorizing signature with the image of the authorizing signature contained in the transmitted image of the funds transfer document.