Patent Publication Number: US-8538124-B1

Title: Systems and methods for real-time validation of check image quality

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is related by subject matter to U.S. patent application Ser. No. 11/747,219 and U.S. patent application Ser. No. 11/747,222, both filed on even date herewith. 
     BACKGROUND 
     A variety of high-speed, special purpose check deposit systems for commercial use are available on the market today. Using such technologies, businesses can initiate deposits of large volumes of checks from remote non-bank locations. However, such technologies require specialized equipment, such as equipment that magnetically reads the Magnetic Ink Character Recognition (MICR) line printed across the bottom of checks. At present, individuals do not typically make use of such specialized equipment. Instead, most individuals deposit checks by presenting them at their bank, Automated Teller Machine (ATM), or by mail. 
     In the future, deposit at home systems may emerge, allowing individuals the flexibility and time savings of remote deposit. One such system is described in U.S. patent application Ser. No. 11/321,025. Such a system allows individuals to remotely deposit checks using a customer controlled general purpose computer with an Internet connection, and an image capture device such as a scanner or digital camera. A digital image of a check is made using the image capture device, and the customer computer sends the image to financial institution servers. The financial institution then processes the transaction using the received image. 
     Remote deposit systems adapted for personal use may prove advantageous for banks and bank customers alike, in part because they are well suited for today&#39;s mobile lifestyles experienced by individuals in military, government, and private sector careers, and in part because they successfully leverage electronic communications advances allowing unprecedented automation, speed, and security in deposit transactions. 
     However, technologies for automatically processing deposit transactions accurately and swiftly are in their infancy. Accuracy and speed are important to the financial institution, which is motivated by a desire for efficient, cost effective operation. They are equally important to the consumer, however, because consumers want to know with certainty at the time of deposit that the check was in fact received, meets the bank&#39;s requirements, and that the funds will be made available in their account in due course. 
     SUMMARY 
     The described embodiments contemplate a system, method and computer-readable medium with computer-executable instructions for real-time validation of check image quality. A check image received by a financial institution can be assessed during a customer on-line session, so that the customer is informed whether the image is acceptable in real-time. 
     In one embodiment, a method is provided for validating that a digital image of a check can be used in a deposit transaction. A digital image of a check in a first image format, such as the Joint Photographic Experts Group (JPEG) format, is received from a customer computer by financial institution electronics. Upon receiving the image, a series of automated steps may be triggered. The financial institution may produce a digital image of said check in a second image format, for example the Tag Image File Format (TIFF) that is presently required for inter-bank image transfer purposes by Check 21 legislation. Next, the financial institution may validate, in real time, that the digital image meets at least one image requirement, such as a requirement that the image is properly formatted, bitonal, has appropriate pixel density, is appropriately sized, of appropriate clarity, and the like. This may be done by the financial institution itself or outsourced to a 3 rd  party service provider that exposes an appropriate Application Programming Interface (API). If the image meets the requirements, the financial institution electronically communicates an approval of the deposit transaction to the customer computer. 
     In another embodiment, a sequence of attempts to recognize a check MICR line are performed in real time, the sequence being optimized for greatest speed in the majority of instances, while generating as few failures as practical. A first attempt includes digital image analysis that is optimized for a digital image in a second image format and comprising a white border. A second attempt includes digital image analysis that is optimized for a digital image in said second image format and comprising a black border. A third attempt includes digital image analysis that is optimized for a digital image in a first image format and comprising a white border. A fourth attempt includes digital image analysis that is optimized for a digital image in said first image format and comprising a black border. If any attempt is successful, subsequent attempts can be foregone and an approval can be sent to the customer. An error is sent to the customer only if all attempts fail. 
     In another embodiment, a 3 rd  party service is provided for validating check image quality. The third party may receive a digital image of a check from a financial institution server, for example a server that calls a 3 rd  party API as described in the first embodiment above. In response to said receiving, the 3 rd  party may automatically initiate an image validation process to ensure said digital image of a check meets an image requirement. A confirmation or an error is returned, in real time, to the financial institution. A confirmation is sent if the digital image of a check meets the image requirements. An error is sent if it does not. 
     Additional advantages and features of the invention are described below. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The foregoing summary, as well as the following detailed description of preferred embodiments, is better understood when read in conjunction with the appended drawings. Exemplary embodiments are provided for the purposes of illustration; however the invention is not limited to the specific methods and instrumentalities disclosed. In the drawings: 
         FIG. 1  illustrates a broad view of a system in which the described embodiments may be employed. 
         FIG. 2  illustrates a method for facilitating deposit of a check from a customer-controlled general purpose computer. 
         FIG. 3  illustrates a method for processing a check deposit. 
         FIG. 4  illustrates a generalized process for real-time validation of check image quality. 
         FIG. 5  illustrates an exemplary process for performing a real-time validation step in a method such as the method of  FIG. 4 . 
         FIG. 6  illustrates an alternative embodiment for performing a real-time validation step in which check image validation is outsourced to a third party. 
         FIG. 7  illustrates an exemplary process for real-time repairing and re-validating a check image. 
         FIG. 8  illustrates an exemplary process for making a plurality of sequential attempts to read a check MICR line in real time, the attempts arranged in a sequence for maximizing speed and accuracy. 
         FIG. 9  illustrates a real-time validation process that may be performed by a third party that provides a check validation service to one or more financial institutions. 
     
    
    
     DETAILED DESCRIPTION 
     Certain specific details are set forth in the following description and figures to provide a thorough understanding of various embodiments of the invention. Certain well-known details often associated with computing and software technology are not set forth in the following disclosure, however, to avoid unnecessarily obscuring the various embodiments of the invention. Further, those of ordinary skill in the relevant art will understand that they can practice other embodiments of the invention without one or more of the details described below. Finally, while various methods are described with reference to steps and sequences in the following disclosure, the description as such is for providing a clear implementation of embodiments of the invention, and the steps and sequences of steps should not be taken as required to practice this invention. 
     In general, it is contemplated that the various systems, methods, and computer readable media disclosed herein will be implemented within a system for processing remote deposit of checks. Such a system will generally include subsystems for electronically receiving check images from customers, said check images corresponding to at least one payor check, and for automatically initiating a deposit of funds associated with said payor check into a customer account. Such a system may also beneficially automatically initiate a process for clearing the payor check with a payor bank. 
       FIGS. 1 ,  2 , and  3  are generally directed to a variety of aspects of a system for processing remote deposit of checks as contemplated for use in connection with various embodiments of the invention.  FIG. 1  illustrates an example system in which the described embodiments may be employed. System  100  may include account owner  110 , e.g., a bank customer who may be located, for example, at the customer&#39;s private residence. The account owner  110  may be utilizing a customer-controlled, general purpose computer  111 . A general purpose computer  111  is generally a Personal Computer (PC) running one of the well-known WINDOWS® brand operating systems made by MICROSOFT® Corp., or a MACINTOSH® (Mac) brand computer, running any of the APPLE® operating systems. General purpose computers are ubiquitous today and the term should be well understood. A general purpose computer  111  may be in a desktop or laptop configuration, and generally has the ability to run any number of applications that are written for and compatible with the computer&#39;s operating system. The term “general purpose computer” specifically excludes specialized equipment as may be purchased by a business or other commercial enterprise, for example, for the specialized purpose of high-speed, high-volume check deposits. A particular advantage of a system as illustrated in  FIG. 1  is its ability to operate in conjunction with electronics that today&#39;s consumers actually own or can easily acquire, such as a general purpose computer, a scanner, and a digital camera. 
     General purpose computer  111  may also be “customer-controlled.” A common example of a customer-controlled computer would be a typical computer located in a private residence. The owner of such a computer typically has the power to install programs and configure the computer as they wish, subject to certain security restrictions that may be imposed by the hardware or software manufacturers. A customer-controlled computer need not be located in a private residence, however. For example, computers in college dormitories, in workplace offices, and so forth may also be considered “customer-controlled.” 
     An example of a computer that would not be considered customer-controlled would be an Automatic Teller Machine (ATM) that is typically controlled by a bank or other business. Although a customer may access and utilize an ATM machine, the ATM machine is not customer-controlled because the allowed uses of the ATM machine are highly restricted. Relevant factors in determining whether a computer is customer controlled are thus the scope of operations that a customer may perform using the computer, and extent to which the customer can reconfigure the machine in some way by adding software and/or hardware components. In general, any customer ability to add software and/or hardware components is adequate to qualify a computer as customer-controlled. 
     One of the applications that may run on a general purpose computer  111  in connection with the invention is a browser. Common browsers in use today are, for example, the popular INTERNET EXPLORER® line of browsers made by MICROSOFT® Corp., the FIREFOX® browsers distributed via the MOZILLA® open source project, and the NETSCAPE NAVIGATOR® browsers also distributed via the MOZILLA® open source project. Browsers generally allow users to point to a Uniform Resource Locator (URL), and thereby retrieve information such as a web page. For example, a browser application on computer  111  could retrieve a web page that is kept at server  131 , and display the web page to the account owner  110 , as is generally known and appreciated in the industry and by the general public. 
     Another application, or set of applications, that may run on a general purpose computer  111  in connection with the invention comprises “virtual machine” technologies such as the JAVA® virtual machine software distributed by SUN MICROSYSTEMS® Corp, and .NET® Framework distributed by MICROSOFT® Corp. In general, such applications facilitate execution of computer programs in a variety of computing environments. For example, a JAVA® applet is a computer program (which may be alternatively referred to herein as a “software component”) that can execute on any computer running the JAVA® virtual machine software. The applet may be provided to virtual machine software in a “source code” format, and may be compiled by a “just in time” compiler, so as to put the applet in a form that can be executed by the hardware associated with the particular computing device. These technologies are known in the art and may be utilized in connection with a system as illustrated in  FIG. 1 . 
     An image capture device  112  may be communicatively coupled to the computer  112 . Image capture device may be, for example, a scanner or digital camera. Computer  111  may comprise software that allows the user to control certain operations of the image capture device  112  from the computer  111 . For example, modern scanner users may be familiar with the TWAIN software often used to control image capture from a computer  111 . Similarly, digital cameras often ship with software that allows users to move images from the camera to a computer  111 , and may also provide additional functions, such as photo editing functions crop and rotate. 
     Financial institutions  130 ,  140  and  150  may be any type of entity capable of processing a transaction involving a negotiable instrument. For example, financial institutions  130 ,  140  and  150  may be retail banks, investment banks, investment companies, regional branches of the Federal Reserve, clearinghouse banks and/or correspondent banks. A negotiable instrument is usually a type of contract that obligates one party to pay a specified sum of money to another party. By way of example, and not limitation, negotiable instruments may include a check, draft, bill of exchange, promissory note, and the like. 
     Financial institution  130  is illustrated as associated with a server  131 . Financial institution  130  may maintain and operate server  131  for the purposes of communicating with customers such as  110 . Alternatively, such server may be maintained and operated by one or more third party vendors who act under the instructions of the financial institution  130 , but possess skills and resources that may be more effective in competent operation of electronics. Such arrangements are well known in the industry and in this case the server  131  is nonetheless considered to be “associated” with the financial institution  130 . 
     Furthermore, one or more third parties may provide electronic services to a financial institution. For example, a third party image validation service provider  135  may expose an API  136  to financial institution server  131 . By appropriately calling the API  136 , the server  131  can cause the third party  135  to perform requested functions and return results. For example, the financial institution may request the third party to inspect check images to determine if they meet specified requirements. Server  131  may then pass images to third party  135 , which will automatically perform the requested tasks, and return errors/approvals and the like to the server  131 . This arrangement has advantages in that third party  135  may specialize in performing certain operations that financial institution  130  would prefer not to invest in. It will be appreciated that the third party  135  may also expose its API  136  to a network such as  120  and  125 , and thereby make it more generally available to other financial institutions  140 ,  150 . 
     Account owner  110  may be an individual who owns account  160 , which may be held at financial institution  130 . As such, account owner  110  may be described as a customer of financial institution  130 . Account  160  may be any type of account for depositing funds, such as a savings account, checking account, brokerage account, and the like. Account owner  110  may communicate with financial institution  130  by way of communication network  120 , which may include an intranet, the Internet, a local area network (LAN), a wide area network (WAN), a public switched telephone network (PSTN), a cellular network, a voice over internet protocol (VoIP) network, and the like. Account owner  110  may communicate with financial institution  130  by phone, email, instant messaging, facsimile, and the like. 
     In one contemplated embodiment, network  120  is a publicly accessible network such as the Internet, which can presently be accessed from many private residences and many public places such as college campuses, airports, coffee shops, and restaurants throughout the United States as well as many other countries of the world. A variety of technologies are available to establish secure connections over such a public network, so that data transmitted between computer  111  and a server  131  associated with the institution  130  remains either inaccessible or indecipherable by third parties that may intercept such data. The invention may make use of any such security technologies. 
     Financial institutions  130 ,  140  and  150  may communicate with each other via a network  125 . Network  125  may be a publicly accessed network such as  120 . Alternatively, network  125  may have certain characteristics that differ from network  120 , due to the different requirements of bank-to-bank communications. For example, one might envision certain security features and access restrictions being more important in bank-to-bank communications. 
     In an embodiment, account owner  110  may wish to deposit a check that is drawn from payor account  170  at financial institution  150 . Account owner  110  may deposit the check into customer account  160  by converting the check into electronic data, e.g., a digital image, and sending the data to financial institution  130 . Various embodiments of the invention described herein may be carried out by financial institution  130  electronics such as server  131  upon receipt of a check image from computer  111 . However, those of skill in computing and software technologies will appreciate that functionality can be distributed across a variety of devices and therefore some of the method steps, subsystems, and computer readable media associated with the invention may in some embodiments be located outside of the range of what would be considered financial institution  130  electronics, e.g., might be located at computer  111 , elsewhere in the networks  120  and  125 , or at third party electronics  135 . 
     Account owner  110  may convert the check into a digital image by scanning the front and/or back of the check using image capture device  112 . Account owner  110  may then send the image to financial institution  130 . Sending the image may be referred to as “presenting” the check. Upon receipt of the image, financial institution server  131  may conduct a variety of automated operations to establish authenticity and quality of the received image, communicate with the customer, initiate a check clearing operation, and credit the customer&#39;s account. One aspect of the invention described in greater detail below comprises operations for establishing check image quality and authenticity in real-time, i.e. with sufficient speed to allow communication of results to a depositing customer during a same on-line session. 
     Financial institution  130  may credit the funds to account  160  in a “soft post” operation. In a soft post operation, the funds appear to be available for use by a customer, and may in fact be available for use, but at least some indication is retained to note that the funds have not actually been received from the payor bank. When the funds are received from the payor bank, the “soft post” is converted to a “hard post” and the indication is removed, along with any further restriction on the use of the funds. Financial institution  130  may clear the check by presenting the digital image to an intermediary bank, such as a regional branch of the Federal Reserve, a correspondent bank and/or a clearinghouse bank. 
     For example, the check may be cleared by presenting the digital image to financial institution  140 , which may be a regional branch of the Federal Reserve, along with a request for payment. Financial institution  130  and  150  may have accounts at the regional branch of the Federal Reserve  140 . As will be discussed in greater detail below, financial institution  130  may create a substitute check by converting an image provided by account owner  110  into a second format, and may present the substitute check to financial institution  140  for further processing. Upon receiving the substitute check, financial institution  140  may identify financial institution  150  as the paying bank (e.g., the bank from which the check is drawn). This may be accomplished using a nine-digit routing number located on the bottom left hand corner of the check. A unique routing number is typically assigned to every financial institution in the United States. Financial institution  140  may present the substitute check to financial institution  150  and request that the check be paid. If financial institution  150  verifies the check (i.e., agrees to honor the check), financial institution  140  may then settle the check by debiting funds from financial institution  150  and crediting funds to financial institution  130 . Financial institution  150  may then debit funds from account  170 . 
     It will be appreciated that the preceding examples are for purposes of illustration and explanation only, and that an embodiment is not limited to such examples. For example, financial institution  150  may be a correspondent bank (i.e., engaged in a partnership with financial institution  130 ). Thus, financial institution  130  may bypass the regional branch of the Federal Reserve and clear the check directly with financial institution  150 . In addition, account  160  and account  170  may both be held at financial institution  130 , in which case the check may be cleared internally. 
       FIG. 2  illustrates a method for facilitating deposit of a check from a customer-controlled general purpose computer. The various steps of  FIG. 2  may be viewed as performed by a server computer associated with a financial institution, in conjunction with a software component that operates from a customer-controlled general purpose computer. Various of the steps are contemplated as performed by the server, while various other steps are contemplated as performed by the software component. 
     In the embodiment illustrated in  FIG. 2 , the darker boxes indicate steps that are performed by the server, for example by delivering information to the user through the user&#39;s browser application. Making information available on a server to customers with a browser is considered to be effectively “delivering” such information for the purposes of this document. The lighter boxes inside  211  indicate steps that are performed by the software component as it executes on the customer computer. Those of skill will recognize that alternative configurations are readily achievable by moving functions from server to software component or vice-versa. 
     The server may first deliver a software component to the customer-controlled general purpose computer  200 . This may be done in response to a customer request for the capability of making deposits from his computer. In one embodiment, the financial institution may provide such capability only to customers that meet predetermined criteria of trustworthiness. For example, it can be required that the customer&#39;s accounts are in good standing, that the customer relationship has lasted a predetermined amount of time, that the customer has a predetermined number of financial service products with the financial institution (e.g. bank accounts, mortgages, insurance policies, etc.), that the customer has a predetermined level of assets with the financial institution, and so forth. 
     The software component may be configured to facilitate the deposit transaction. In one embodiment, the software component may be compatible with the JAVA® or .NET® technologies described above. Such configurations allow for widespread dissemination and successful operation in a wide variety of computing environments as may exist on customer-controlled general purpose computers. 
     Where the software component is written for JAVA®, .NET®, or any other such technology, it is useful in step  200  to first determine whether the customer-controlled general purpose computer has an appropriate virtual machine application installed, e.g. JAVA® Virtual Machine (JVM) or .NET® framework. If the computer does not have the appropriate application installed, such application may be automatically installed, or the customer may be directed to a location from which such application may be downloaded and installed. The software component may then be delivered  200 , and should work as intended. The various other steps of  FIG. 2  may now take place, or may take place at some subsequent time using the software component as previously downloaded. 
     After downloading or otherwise accepting the software component, and assuming the customer has an appropriate image capture device, the customer now has the capability to make deposits from his general purpose computer. For example, the customer points his browser to a bank website, where a link may be available that causes the bank server to initiate a deposit transaction  201 . The customer may be asked to log in using a user name and password. 
     The customer may next be instructed to identify an account into which the deposit will be made  202 . This can be done, for example, by providing a webpage that lists the available accounts, along with an instruction to select an account. Alternatively, a box may be provided into which the customer may type an account number, along with an appropriate instruction to type the number of the desired account. The account may be any account, and need not necessarily be the customer&#39;s own account, although it is contemplated that a large number of customer deposits may be made into the transacting customer&#39;s account, and embodiments may find it useful to restrict the allowed accounts to the customer&#39;s own accounts. In such embodiments, if the customer has just one account with the financial institution, step  202  may be eliminated because the only available allowed account would be the customer&#39;s single account. 
     The customer may next be instructed to identify an amount of a check or other negotiable instrument he wishes to deposit into the selected account  203 . In one embodiment, this can be done similarly to step  202  by providing a webpage with a box into which the customer may type an amount, along with an appropriate instruction to type the amount of the check. The customer may also be instructed to endorse the check  204 , e.g., by signing his or her name on the back of the check. 
     The customer may next be instructed to provide an image of a front side of a check  205 , for example, by using an image capture device. In one embodiment, the customer may be instructed to place the check face down on a flatbed scanner, and may further be instructed as to the location and orientation of the check on the scanner. If the customer is instructed to take a digital photograph of the check using a digital camera, the customer may be instructed as to the position and orientation of the check, lighting, angle of camera, distance and focal length (zoom) of camera, and so forth. The software component may be useful at this point in providing a graphical illustration of just how the customer should provide the image. The customer may further be given instructions as to how to activate the image capture device and/or move the image from the device to the general purpose computer. 
     In one embodiment, it is contemplated that the software component allows for control of the transaction and transaction data throughout the various aspects thereof. For example, the software component may open a folder in a storage location, such as the hard drive of the general-purpose computer, and may work in conjunction with any software that interfaces with the image capture device to deposit the image in such folder. This may advantageously be conducted in a secure manner to prevent any unwanted image diversion or tampering. The hard drive of the general-purpose computer is considered to be a storage location that is controlled by said customer-controlled general purpose computer, but other storage locations such as disk drives, networked drives, and so forth may also be effectively controlled by the general purpose computer. 
     The software component may itself perform operations such as opening a folder and placing the images therein, or may effectively achieve such operations by instructing the customer and/or other applications to do so. All software operates to some extent under the control and with the support of an operating system running on the general purpose computer, and such support is of course appropriate in embodiments of the invention. 
     The software component may next cause the image of the check to be presented to the customer for editing, e.g. by asking the customer to crop and/or rotate the check image to a predetermined orientation  206 . In embodiments using a scanner, an image of the entire scanner bed, or some otherwise too large image may be generated. If the check was placed in the top left corner of the scanner bed, the customer may be asked to indicate the bottom right corner of the check image, and the image may be cropped to contain only the check image, thereby removing a portion of the originally obtained image. 
     An appropriately edited image of the check may be placed in the storage location  207 . If further images are necessary  208 , steps  205 - 207  may be repeated as necessary. For example, the customer may be instructed to endorse and provide an image of the back side of a check. To ensure the check is appropriately voided, the customer may be asked to write “void” on the check and re-scan the front of the check. 
     A log file may be generated  209  to collect data for processing or troubleshooting the deposit transaction. The log file may be placed in the storage location along with the various images of the check. 
     Once the desired images are collected and edited, they may be delivered to the server for processing the deposit  210 . The log file may also be delivered at this time. Once such files are delivered, they may be deleted from the customer&#39;s general purpose computer. If the server determines that the delivered images and any corresponding data are sufficient to go forward with the deposit, the customer&#39;s account may be provisionally credited with a soft post, and a confirmation page may be delivered to the customer via the customer&#39;s browser application  212 . The customer may be instructed to destroy, e.g. by shredding, the actual physical check or other negotiable instrument. Under the current check handling procedures in the United States, the physical check is not necessary in processing a deposit, nor is it necessary to keep the original check in bank or customer records. 
       FIG. 3  illustrates a method for processing a check deposit. The method of  FIG. 3  is designed to complement that of  FIG. 2  and to illustrate exemplary steps that may be carried out by a server or other electronics operated by a financial institution before, during, and after the various steps of  FIG. 2  are carried out. 
     In general, as illustrated in  FIG. 3 , such server may receive a request for deposit at home capability  300 A, and in response to such request may deliver a software component to the requesting customer  300 B. As with  FIG. 2 , intermediate steps may comprise determining if the customer is in fact eligible for a remote deposit program, and ensuring the customer has an appropriate virtual machine environment installed on their general purpose computer—in embodiments where the software component requires such an environment. 
     A transaction may be initiated  301  upon receiving a customer indication that a deposit transaction is desired. The customer is instructed to identify an account per  FIG. 2 , and as a result the financial institution electronics receive an account identifier (ID)  302 . Similarly, financial institution electronics receive check amount  303 . At this juncture the software component handles image capture processes, which may or may not involve the server until such time as check image(s) are received  304 . 
     Upon receipt of check images, an Optical Character Recognition (OCR) process may be invoked to determine certain information about the check. For example, OCR may be performed on the check&#39;s MICR line location  305  to determine information such as payor bank routing number, account number, and check number. In one embodiment, multiple attempts may be made to read a check MICR line as described further below. Once the MICR line is established, the bank routing number may then be validated against a list of valid routing numbers to ensure that it corresponds to a legitimate bank, and in some embodiments, to ensure it corresponds to a United States bank. In one embodiment, the OCR is conducted in real time, i.e. during a same on-line session in which the customer initiated the deposit, so as to validate some initial deposit information immediately, and provide a customer with an on-the-spot error or approval of the transaction. 
     In one embodiment, additional OCR operations may be performed, such as upon other aspects of the front side of the check (drafter&#39;s name, amount, etc.) and upon an image of a back side of a check. One problem that occurs involves customer submission of two front images, instead of one front image and one back image. OCR may be performed on a MICR line location of an alleged image of a back side of said check to confirm that said alleged image of a back side of said check does not bear a MICR line. If no MICR line is present in such location then it is more likely that the alleged image of a back side of said check is in fact the back, and not the front, of the check. 
     Another advantageous use of OCR is on the endorsement location on the back of a check. By performing OCR, it may be possible in some embodiments to determine that the signature matches that of the payor or drafter of the check. However, often signatures are illegible. Thus in one embodiment it is advantageous to determine that some mark or signature is present in the endorsement location on the back of the check, without conducting any further signature identification procedures. 
     If the routing number determined using OCR cannot be validated, an error may result  317 , and the deposit transaction can be aborted. An error message can be delivered to the customer  314 , explaining a reason that the transaction could not be processed. 
     Real-time validation of check image quality may also be performed  306 . In this step, bank electronics may automatically convert the received digital image into a format that will be used for presenting the check, such as TIFF. The TIFF image may then be analyzed to ensure it meets any of a variety of requirements. This analysis may be performed by the financial institution&#39;s own electronics, or may be outsourced to a third party as discussed with element  135  in  FIG. 1 . If the image in a second format meets all requirements, the process continues, and may lead to ultimate approval delivery  314 . If the image in a second format does not meet requirements, an error  317  may be sent to the customer, or the image may be repaired and validation may be re-attempted. Further description of this aspect is provided below. 
     Representment and kiting detection processes may be carried out to determine whether the check was previously deposited or is suspected to be part of a kiting operation  307 . 
     There are numerous possibilities for false positives in representment and kiting detection  307 . Because of this, it is advantageous in some embodiments to proceed with a deposit transaction regardless of the fact that a representment may be initially identified in  307 . As illustrated in  FIG. 3 , if a representment or kiting operation is detected in  307 , the transaction may be either flagged for further scrutiny at a later time, delayed, or terminated  315 . If the transaction is flagged, it will be allowed to proceed through the various other steps and result in a soft post  313  to the customer account. If it is delayed or terminated, the soft post  313  will be made only after further scrutiny of the transaction, or will be avoided entirely. If a representment or kiting indicator is not detected, the transaction need not be flagged, delayed, or terminated, and step  315  is unnecessary. 
     OCR may further be performed on a check amount location  306 , and the amount as determined using OCR may be compared against the customer-entered amount received pursuant to step  303 . If the amounts do not match, an error  316  can result, terminating the transaction and delivering appropriate information concerning the error to the customer  314 . OCR may further be performed on any other aspects of the check image at this time if it is advantageous in specific embodiments to do so. 
     The server may further receive and modify a deposit transaction log file  310 . Alternative versions of the images received may be generated an placed in the log file. Check 21 regulations require a bi-tonal TIFF formatted image, which is generally a low-quality image format as compared to other available image formats. Therefore, it is desirable in some embodiments to retain both a “good” image in an initial format, e.g., in a JPEG format, as well as the modified bi-tonal TIFF required by Check 21. This way, if any troubleshooting is necessary, a good image of the check remains available. 
     In some embodiments, a bank stamp may be overlaid on the image of the back of the check  311 , just as if the check was physically deposited at a bank. Appropriate images may be forwarded to the payor bank for payment  312 , and meanwhile, the customer&#39;s account may be provisionally credited in the amount of the check  313 . A confirmation can be delivered to the customer  314 . 
     At  312 , in one embodiment, the bank may forward an image or images to a payor bank. Provisionally crediting the customer account  513  with a “soft post” and delivering a confirmation to the customer-controlled general purpose computer  514  may be done before, after, or contemporaneously with step  312 . 
     In one embodiment, forwarding an image or images to a payor bank  512  may be performed pursuant to an Automated Clearinghouse (ACH) transaction. ACH transactions typically include payment instructions to debit and/or credit an account. Banks often employ ACH service providers to settle ACH transactions. Examples of ACH service providers include regional branches of the Federal Reserve and the Electronic Payments Network (EPN). 
     In an ACH transaction, the payee&#39;s (customer&#39;s) bank may be referred to as the originating depository financial institution (ODFI). Upon receipt of appropriate check information, the payee&#39;s bank may credit funds to the payee&#39;s account and generate an ACH debit entry to the payor&#39;s account, which may be presented to the ACH service provider for processing. 
     The ACH service provider may process the debit entry by identifying the account and bank from which the check is drawn. The bank from which the check is drawn (i.e., the payor&#39;s bank) may be referred to as a receiving depository financial institution (RDFI). If the payor&#39;s bank verifies the transaction, the ACH service provider may settle the transaction by debiting the payor&#39;s bank and crediting the payee&#39;s bank. The payor&#39;s bank may then debit the payor&#39;s account. 
     A substitute check is typically a paper reproduction of an original check and may be the legal equivalent of the original check. Substitute checks were authorized under The Check Clearing for the 21st Century Act, commonly known as Check 21. The Act was enacted to facilitate the check clearing process by allowing banks to transmit electronic images of checks (e.g., substitute checks) to other banks rather than physically sending the original paper checks. Check 21 does not require that banks use substitute checks. In fact, many banks may have voluntary agreements to accept certain electronic images of checks even though the images may not qualify as substitute checks under Check 21. If a bank does not have a voluntary agreement and/or refuses to accept an electronic image, the financial institution is required under Check 21 to accept a substitute check in lieu of the original check. 
     The bank may process the ACH debit entry, substitute check, and/or electronic image. As noted above, the bank may present the ACH debit entry to an ACH service provider (e.g., EPN), which may be responsible for settling the transaction between the payee&#39;s bank and the payor&#39;s bank. The bank also may convert the digital image into a substitute check and present the substitute check to an intermediary bank (e.g., a regional branch of the Federal Reserve) to complete the check clearing process. If the payor&#39;s bank and the payee&#39;s bank are the same, the transaction can be handled internally at the payor bank by simply debiting the account of one customer and crediting the account of another. Thus, an intermediate step may comprise identifying if the payor bank and the payee bank are one and the same, or otherwise operating in a closely cooperative manner. 
     Each of  FIGS. 4 ,  5 , and  6  provide exemplary methods for real-time validation of a check MICR line and/or check image quality as may be carried out in a system comprising features as disclosed in  FIGS. 1 ,  2 , and  3 , and in particular as part of steps  305  and  306  in  FIG. 3 . However, it should be emphasized that while the various aspects of  FIGS. 1 ,  2 , and  3  provide useful context for  FIGS. 4 ,  5 , and  6 , the disclosed aspects of  FIGS. 1 ,  2 , and  3  are in no way required to carry out the steps of  FIGS. 4 ,  5 , and  6 . 
     Furthermore, while  FIGS. 4 ,  5 , and  6  are illustrated and discussed as methods, it will be acknowledged that they also disclose corresponding systems and computer readable media designed to carry out such methods.  FIGS. 4 ,  5 , and  6  may be carried out by electronic subsystems within financial institution electronics such as server  131 , which may comprise a variety of other electronics such as routers, switches, and modems. The steps of  FIGS. 4 ,  5 , and  6  may also be recorded as instructions on computer readable media designed for causing financial institution electronics to carry out the disclosed methods. 
     Referring now to  FIG. 4 , in one embodiment, a method is provided for validating that a digital image of a check can be used in a deposit transaction. A digital image of a check in a first image format, such as the Joint Photographic Experts Group (JPEG) format, is received  401  from a customer computer by financial institution electronics. 
     Upon receiving the image, a series of automated steps may be triggered. The financial institution may produce a digital image of said check in a second image format  402 , for example the Tag Image File Format (TIFF) that is presently required by Check 21 legislation for inter-bank image transfer purposes. Next, the financial institution may validate, in real time, that the digital image meets at least one image requirement  403 , such as a requirement that the image is properly formatted, bitonal, has appropriate pixel density, is appropriately sized, of appropriate clarity, and the like. This may be done by the financial institution itself or outsourced to a 3 rd  party service provider that exposes an appropriate Application Programming Interface (API). 
     If the image meets the requirements, the financial institution electronically communicates an approval  404  of the deposit transaction to the customer computer. If an image repair is necessary, it can be performed by  404 . If no repair is possible, and the image does not meet requirements, an error may be sent to the customer  405 . 
       FIG. 5  illustrates an exemplary process for performing a real-time validation step  403  in a method such as the method of  FIG. 4 . A goal of a process such as  FIG. 5  is to establish that a check image meets one or more requirements. To this end, a plurality of tests may be available, each test comprising computer software or hardware configured to analyze a digital image and determine whether it meets a requirement. A test  501  may fail, in which case an error  504  can be thrown. The error  504  may indicate the failed test. A test  501  may also pass, in which case a determination can be made regarding whether additional tests must be applied  502 . If so, a next test is run  501 . If not, an approval is generated  503 . 
     One requirement presently imposed by Check 21 legislation is that images must be bitonal. A first test  501  may thus ensure that a check image is bitonal. Such a test may, in one embodiment, analyze the information in an image file to ensure that the file does not contain grayscale or color data. Additional tests may be performed in similar fashion to determine whether the image is properly formatted (present embodiments require TIFF), has appropriate pixel density, is appropriately sized, and of appropriate clarity. 
       FIG. 6  illustrates an alternative embodiment for performing a real-time validation step in which check image validation is outsourced to a third party. In  FIG. 6 , validating comprises sending the digital image of a check in a second image format to a third party real time image quality validation service  601 . This may be accomplished, for example, by calling an API for a web-enabled application exposed by third party electronics. A function call generated by financial institution electronics may indicate a storage location associated with financial institution electronics and comprising the image to be validated, so the image does not have to be sent across a network. Instead, it can be operated upon by third party agent software located executed by financial institution servers. This approach reduces security concerns. 
     Alternatively, a call to the third party API may include the image to be validated, thereby sending the image to the third party electronics. Third party electronics may specialize in performing validation, for example, by performing a series of tests as described in connection with  FIG. 5 . Utilizing a third party service in this manner allows for increased specialization and concomitant optimization of image requirements and testing operations. 
     The third party may supply the financial institution with either an approval  602 , or an error  603 . When approval is received  602 , the financial institution may relay the approval to the customer in real-time. An error may, in one embodiment, also be relayed in real-time to the customer. In preferred embodiments, however, repair operations may be attempted prior to delivering the error. To this end, the third party may itself attempt a repair, or may supply the financial institution with an error code to facilitate repair by said financial institution. 
       FIG. 7  illustrates repair processing. In general, repair processing may comprise the following steps: an image error is identified during validation processing  701 . Error identification may comprise a part of local image validation processing, or receiving an error code from a third party real-time image quality validation service. In one embodiment, the error code corresponds to an image requirement that the analyzed image did not meet. In another embodiment, it identifies a specific and addressable error in the analyzed image. Financial institution electronics may then utilize the error code to determine a repair operation, and perform the repair for example by passing a check image along with the error code to an error processing computer program loaded onto financial institution electronics. 
     Repairing the digital image of a check in a second image format is accomplished, in one embodiment, by first repairing the digital image of a check in a first image format  702 , e.g. repairing a JPEG image received from the customer computer. A repaired image in said first image format is thereby produced. Returning to the first format (JPEG) image in this manner facilitates repair because the JPEG image is higher quality than the second format (TIFF) image, and repairs are easier and more accurate when additional digital image data is present. 
     Once the repaired image in a first format is available, a repaired image in the second image format is produced  703 . In one embodiment, this is accomplished by converting the repaired image in a first format into a repaired image in a second format. Said repaired image in said second image format may now be re-validated  704  locally, or sent to said real time image quality validation service, in similar fashion as before. An approval is then received indicating said repaired image in said second image format meets applicable image requirements. Alternatively, if the repaired image again fails to meet all requirements, another error may instead be received. Another repair may be attempted if sufficient time remains without degrading customer experience. 
     As an example of the above, consider a customer attempt to deposit a check with a torn corner. The customer scans the check and produces a JPEG image. The JPEG is sent to the financial institution. The financial institution then generates a bi-tonal TIFF, and validates the TIFF, either locally or using a third party service. An error is identified. The error may identify, for example, a torn upper left corner. In response, a repair process performs an automated upper left corner repair process on the original JPEG. For example, image data may be copied from the upper right corner, rotated 90 degrees, and pasted onto the upper left corner of the image. The repaired JPEG is then converted into a repaired bitonal TIFF, and the repaired TIFF is again validated. All of the above occurs in real-time, i.e. while the customer is waiting for approval of the transaction or error. 
     In another embodiment, as illustrated in  FIG. 8 , a sequence of attempts to recognize a check MICR line are performed in real time, the sequence being optimized for greatest speed in the majority of instances, while generating as few failures as practical.  FIG. 8  thus provides a more detailed illustration of an embodiment of step  305  in  FIG. 3 . 
     A digital image of a check is received from a customer computer  801 , as explained above. The image may be received in a first format, e.g., JPEG, and an image in a second format, e.g., TIFF, may be produced. 
     We note that OCR processing of a MICR line in a digital image can be frustrated by several factors. First, OCR processing is faster, but more error prone, on a low quality TIFF image than on a high-quality JPEG. Second, OCR processing can be optimized for white border images or for black border images. 
     Thus, the process illustrated in  FIG. 8  is optimized for speed of OCR processing of a MICR line, so that such processing is adapted for real-time use. A first MICR read attempt includes digital image analysis that is optimized for a digital image in a second image format, e.g., TIFF, and comprising a white border  802 . If the first attempt is a success, an approval is generated  807  and the illustrated process ends. 
     If the first attempt fails, a second MICR read attempt may be performed which includes digital image analysis that is optimized for a digital image in said second image format, e.g., TIFF, and comprising a black border  803 . If the second attempt is a success, an approval is generated  808  and the illustrated process ends. 
     If the second attempt fails, a third MICR read attempt may be performed which includes digital image analysis that is optimized for a digital image in a first image format, e.g., JPEG, and comprising a white border  804 . If the third attempt is a success, an approval is generated  809  and the illustrated process ends. 
     If the third attempt fails, a fourth MICR read attempt may be performed which includes digital image analysis that is optimized for a digital image in said first image format, e.g., JPEG, and comprising a black border  805 . If the fourth attempt is a success, an approval is generated  809  and the illustrated process ends. Otherwise, an error may be sent  806  to the customer when all attempts fail. 
     As with image quality validation discussed above, the processes of  FIG. 8  may be performed by financial institution electronics or by a third party who exposes an API to the financial institution. Where the third party API is utilized, the steps of  FIG. 8  may further comprise electronically communicating an approval of said digital image to financial institution computers. In either embodiment, electronically receiving the original check image and electronically communicating an approval to the customer are performed during a same online customer session with the financial institution. 
       FIG. 9  illustrates an embodiment in which a 3 rd  party service is provided for validating check image quality. The third party may receive a digital image of a check from a financial institution server  901 , for example a server that calls a 3 rd  party API as described in the embodiment of  FIG. 4  above. 
     In response to said receiving, the 3 rd  party may automatically initiate a real-time image validation process  902  to ensure said digital image of a check meets an image requirement. Repair processing may be conducted  905  if necessary. Once an image meets all requirements  903 , an approval  904  is returned, in real-time, to the calling financial institution. An error is sent  906  if the image does not meet all pertinent requirements. 
     In connection with performing the process of  FIG. 9  in real-time, it can be said that receiving  901 , automatically initiating  902 , and sending approval  904  are performed during a first time interval. Said first time interval is contained within a second time interval, i.e. it starts after the start of said second time interval and ends before the end of the second time interval. Said second time interval corresponds to an online customer session comprising communications between the financial institution server and a customer computer. This is more formal way of stating that the processing occurs during a same customer on-line session in which the customer initiated the deposit transaction. 
     The various techniques described herein may be implemented with hardware or software or, where appropriate, with a combination of both. Thus, the methods and apparatus of the disclosed embodiments, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the disclosed embodiments. In the case of program code execution on programmable computers, the computer will generally include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device and at least one output device. One or more programs are preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations. 
     The described methods and apparatus may also be embodied in the form of program code that is transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via any other form of transmission, wherein, when the program code is received and loaded into and executed by a machine, such as an EPROM, a gate array, a programmable logic device (PLD), a client computer, a video recorder or the like, the machine becomes an apparatus for practicing the invention. When implemented on a general-purpose processor, the program code combines with the processor to provide a unique apparatus that operates to perform the processing of the disclosed embodiments. 
     In addition to the specific implementations explicitly set forth herein, other aspects and implementations will be apparent to those skilled in the art from consideration of the specification disclosed herein. It is intended that the specification and illustrated implementations be considered as examples only, with a true scope and spirit of the following claims.