Patent Application
20080086419
In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form.
Embodiments of the invention provide methods and systems for processing various financial transactions initiated by or otherwise involving use of a check as a form of payment. In some such embodiments, the processes are executed by an entity on behalf of one or more client organizations. The description below sometimes provides illustrations that use an example where a client organization is a financial institution, but there is no such requirement for the invention and the methods are intended also to be applicable to other types of organizations that make use of large collections of data. For example, embodiments of the invention may also be used for managing health-care documents or information.
The description herein sometimes refers to “clients” and to “customers.” Reference to “clients” is intended to refer to persons, i.e. individuals, entities, or their agents, on whose behalf a set of information is managed. Reference to “customers” or “consumer” is intended to refer to persons, i.e. individuals, entities, or their agents, who are the subject of or related to that information. Thus, merely for purposes of illustration, in the case where the information comprises credit-card account records for a credit card issued to Mr. Jones by Bank A, Bank A corresponds to a client and Mr. Jones corresponds to a customer or consumer.
The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It being understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth in the appended claims.
Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
Also, it is noted that individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed, but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.
The term “machine-readable medium” includes, but is not limited to, portable or fixed storage devices, optical storage devices, wireless channels, and various other mediums capable of storing, containing, or carrying instruction(s) and/or data. A code segment or machine-executable instructions may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
Furthermore, embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine readable medium. One or more processors may perform the necessary tasks.
Generally speaking, embodiments of the present invention provide methods and systems to support back office conversions of paper checks received at a point-of-sale. For example, at the end of the day, or at several times throughout the day, a merchant closes their register and takes the paper checks to the back office. The checks may be submitted through a terminal that scans the Magnetic ink Character Recognition (MICR) information of the check and images the front and back of the check. In other cases, the point-of-sale device may be adapted to scan or otherwise image the check upon receipt and supply the image data to the back office merchant system. The merchant may then either: (1) utilize a software package that reconciles, allows for item correction, and performs file creation/submission; (2) outsource the back office function; or (3) use a combination of the two. Files can be submitted either directly to the merchant's bank or to the merchant's check processing service.
According to one embodiment, a point-of-sale authorization may be added to the back office conversion check processing service. That is, a merchant can submit a live authorization request to a check processing service or other authorization service and receive instructions back from the service. The intent of the authorization can encompass several purposes including but not limited to: (1) risk/fraud management; (2) ACH eligibility; (3) Settlement eligibility; (4) capture of information; and/or (5) image capture instructions. With the addition of risk/fraud management, an approval or decline response can be given based on the risk of the transaction and the type of merchant. The addition can also allow the merchant to receive warranty protection for their returned checks. The authorization may be to determine whether or not an item is eligible to be converted to an ACH item. ACH eligibility can be based on several criteria including but not limited to: (1) ACH rules; (2) Routing number validity; (3) Account Number Validity; (4) Settlement history on that MICR; and/or (5) merchant parameters. Broader defined settlement eligibility could be determined by a rules-based system that determines a settlement path based on parameters established globally or at the merchant level—example: an ACH item can be settled by an ACH process while other items can be tagged for image settlement. In another example, a scoring methodology or by merchant instructions can be used (an example is where a consumer opts out of ACH conversion, the merchant can notify the authorization system and the item can be “tagged” as non-ACH-eligible). The authorization system can be used as the front end capture of transaction information. A merchant may use this in order to provide a reconciliation tool between the front end capture of transaction information and the back end capture of information. It can also be used to determine image capture requirements at the point of sale i.e. if an item is ACH ineligible, capture an image of both the front and back of the check for the purposes of image settlement. Or if an item is higher risk, you may want to capture the front and back in case an Image Replacement Document (IRD) needs to be created in the future. The authorization process may be used for any combination of the above.
According to one embodiment, a merchant may choose to convert their checks either at the point-of-sale or in the back office, or both. With the addition of the front end authorization, a merchant may choose “split settlement processing”. Under split settlement, items approved at the point-of-sale as eligible for ACH can be processed through the ACH Network from the point-of-sale capture data. Items not approved as ACH eligible can wait to be processed as image exchange items when the image is received from the merchants hardware/software package. In this model, the ACH items may settle to the merchants account prior to the image items processed at the point-of-sale on the same day as the ACH items. It should be understood that, while discussed herein with reference to an ACH settlement process and a Check 21 settlement process, additional and/or different settlement processes may be used. For example, other settlement processes may handle checks as a remotely created check, a photo-in-lieu of a check, or in another manner as known in the art. Regardless of the exact implementation, such settlement methods are considered to be within the scope of the present invention.
The data and/or rules received by the central host 100 may originate with one or more repositories of financial information 104 and be transmitted to the central host 100 through a financial network 108. The network may can be any type of network familiar to those skilled in the art that can support data communications using any of a variety of commercially-available protocols, including without limitation TCP/IP, SNA, IPX, AppleTalk, and the like. Merely by way of example, the network 108 maybe a local area network (“LAN”), such as an Ethernet network, a Token-Ring network and/or the like; a wide-area network; a virtual network, including without limitation a virtual private network (“VPN”); the Internet; an intranet; an extranet; a public switched telephone network (“PSTN”); an infra-red network; a wireless network (e.g., a network operating under any of the IEEE 802.11 suite of protocols, the Bluetooth protocol known in the art, and/or any other wireless protocol); and/or any combination of these and/or other networks.
The repositories of financial information 104 may comprise information collected from or on behalf of such entities as banks, credit unions, trust-management companies, mutual fund companies, discount brokerage firms, and the like. Additionally or alternatively, the repositories of financial information may include information provided by merchants related to various transactions. For example, such information may include information from or related to checks submitted to the merchants for payment of a transaction. By permitting communication with the repositories of financial information 104 through the financial network 108, the central host 100 may perform functions on behalf of a plurality of financial entities or may perform functions that report on information from multiple repositories of financial information 104 via one or more terminals 140. The terminals 140 may be any of a variety of possible types of devices including thin clients, personal computers, etc.
The computer system 200 may additionally include a computer-readable storage media reader 225; a communications system 230 (e.g., a modem, a network card (wireless or wired), an infra-red communication device, etc.); and working memory 240, which may include RAM and ROM devices as described above. In some embodiments, the computer system 2000 may also include a processing acceleration unit 235, which can include a DSP, a special-purpose processor and/or the like.
The computer-readable storage media reader 225 can further be connected to a computer-readable storage medium, together (and, optionally, in combination with storage device(s) 220) comprehensively representing remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing computer-readable information. The communications system 230 may permit data to be exchanged with a network and/or any other computer or other type of device.
The computer system 200 may also comprise software elements, shown as being currently located within a working memory 240, including an operating system 245 and/or other code 250, such as an application program. The application programs may implement components of a the system and/or the methods of the invention as described herein. It should be appreciated that alternate embodiments of a computer system 200 may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. Further, connection to other computing devices such as network input/output devices may be employed.
According to one embodiment, software of the computer system 200 can perform functions to support back office conversions of paper checks received at a point-of-sale and/or processing of check images provided by a point-of-sale device so equipped. For example, the software can support the processing of paper check items from a merchants location either through the ACH Network, paper drafts or by image exchange. Transactions can be sent to the bank, for example, as a NACHA formatted file or an X9.37 file.
As noted above, embodiments of the present invention can provide various functions related to the submitted paper check. For example, processing can include, but is not limited to, providing an authorization and settlement process.
At the end of the day, or at several times throughout the day, a merchant closes their register and takes the paper checks to the back office or other location. The checks can be submitted to the back office merchant system 320 through a terminal that scans the MICR and images the front and back of the check. In other cases, when the point-of-sale device 310 is so equipped, image data obtained at the point-of-sale device 310, for example by scanning or otherwise imaging the check, can be provided to the merchant system 320. Once scanned or image data is received, the paper checks can be stored 325 for some period and, after such period, destroyed 330. The merchant can utilize a software package of the merchant system 320 that reconciles transactions, allows for item correction, and performs file creation/submission. That is, the scanned and or imaged checks can be submitted to the software package of the merchant system 320 and matched to point-of-sale transactions for authorization by a check processing service 335, reconciliation of transactions at the point-of-sale 310, etc.
The images and other files submitted to the check processing service 335 can be sent to the Originating Depository Financial Institution (ODFI) 345 where the submitted files can be archived 340 and possibly made available to the merchant via a web interface. Additionally or alternatively, other entities such as the other financial institutions 365 and 370 and the check processing service 335 can make the images available to the merchant. The ODFI 345 can create ACH 350 and/or Image Exchange 355 records and process the settlement. For example, the ODFI 345 can send the ACH transaction to the Federal Reserve 360. The Federal Reserve bank 360, upon receipt of the ACH transaction, can in turn instruct the receiving banks 365 and 370 to complete the transaction and fund the merchant.
Stated another way, the point-of-sale device 310 can be adapted to receive information from the check 305, request authorization of the transaction based on information from the check and possibly other information, and, in response to the transaction being authorized, provide a notification of the transaction to the merchant system 320. For example, the point-of-sale device 310 can be adapted to request authorization of the transaction from a check processing service 315. The merchant system 320 can be adapted to receive the notification of the transaction from the point-of-sale device 310, receive image data representing an image of the check, for example by later scanning or otherwise imaging the check or by receiving the image data from the point-of-sale device, and perform a reconciliation process based on the notification and the image data. Settlement of the transaction can be performed by a single settlement process or a split-settlement process as will be described below.
According to one embodiment, different processing models can be provided for settling transaction. These models can include a single settlement process and a split settlement process.
The check processing service 515 can match the items in the file to the authorized items from the point-of-sale 505 and make a transaction decision on how to best settle the item, either as an ACH or image exchange or other settlement method depending, for example, on a least cost routing. If the check processing service 515 does not receive an image for an item approved at the point-of-sale 505 in this model, the service may not settle the item through the ACH (as this may be a violation of the NACHA Operating Rules) or as a Check 21 item (since this process uses image data of the check to settle). The settlement to the merchant can include both ACH and Check 21 items aggregated for one settlement to the merchant.
According to one embodiment, if an item is received by the check processing service 515 through an image file and the check processing service 515 declined the item at the point-of-sale 505, a record can be displayed in an exception section of the merchants periodic Funding Report provided by the check processing service 515 as a “Transaction Declined”. In such cases the image can be maintained for information purposes. If an item is received through the image file and the check processing service 515 cannot match it to an authorized item received at the point-of-sale 505, the record can be displayed in an Exception Section of the merchants Funding Report as “No Matching Transaction”. Again the image can be maintained for information purposes. Matching of transactions and items by the check processing service 515 can be based on raw MICR data, check number, check amount, store number, or other criteria.
More specifically, under split settlement, items can be approved at the point-of-sale 505 as ACH'able and processed through the ACH Network by the check processing service 515 for settlement with one or more financial institutions 520. Items not approved as ACH'able can wait to be processed as Check 21 items when the image is received by the check processing service 515 from the merchant system 510. As noted, the ACH items may settle to the merchants account prior to the Check 21 items processed at the point-of-sale on the same day as the ACH items. However, Check 21 items may be included in the aggregated merchant settlement that where processed at the point-of-sale on previous days but the service processed the image file received from the merchant on that processing day. For example: Monday, merchant processes 100 items at the point-of-sale, 95 ACH and 5 Check 21. On Tuesday, the service processes the 95 items in the ACH file for settlement on Wednesday. Tuesday, the merchant processes 120 items at the point-of-sale, 100 ACH and 20 Check 21. On Wednesday, the service processes the 100 ACH items for settlement on Thursday. On Tuesday night, the merchant sends up all the images from point-of-sale transactions processed on Monday and Tuesday. In Wednesday's processing, the service also process the 25 Check 21 items and combines the settlement to the merchant with the 100 ACH items processed on Wednesday.
In the foregoing description, for the purposes of illustration, methods were described in a particular order. It should be appreciated that in alternate embodiments, the methods may be performed in a different order than that described. Additionally, the methods may contain additional or fewer steps than described above. It should also be appreciated that the methods described above may be performed by hardware components or may be embodied in sequences of machine-executable instructions, which may be used to cause a machine, such as a general-purpose or special-purpose processor or logic circuits programmed with the instructions, to perform the methods. These machine-executable instructions may be stored on one or more machine readable mediums, such as CD-ROMs or other type of optical disks, floppy diskettes, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, flash memory, or other types of machine-readable mediums suitable for storing electronic instructions. Alternatively, the methods may be performed by a combination of hardware and software.
While illustrative and presently preferred embodiments of the invention have been described in detail herein, it is to be understood that the inventive concepts may be otherwise variously embodied and employed, and that the appended claims are intended to be construed to include such variations, except as limited by the prior art.
This application claims the benefit of U.S. Provisional Application No. 60/828,727, filed Oct. 9, 2006, entitled BACK OFFICE CONVERSION, the complete disclosure of which is incorporated herein by reference in its entirety for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 60828727 | Oct 2006 | US |
