Patent Publication Number: US-8121385-B1

Title: System and method for generating magnetic ink character recognition (MICR) testing documents

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of application Ser. No. 11/853,434, filed Sep. 11, 2007, now issued as U.S. Pat. No. 7,916,925 which claims priority to provisional application Ser. No. 60/889,114, filed Feb. 9, 2007. The contents of these priority applications are herein incorporated by reference in their entirety. 
    
    
     FIELD OF THE INVENTION 
     The present disclosure is directed to systems and methods for generating, for generating MICR testing documents that contain error-free lines or transactions. 
     BACKGROUND OF THE INVENTION 
     In the year 2000, an estimated 70 billion checks were written in the United States alone. This translates into approximately 270 million checks being processed every business day. Monitoring and tracking the flow of checks is a complex procedure that is highly error-prone. 
     The check processing system is based on the special numbers and symbols on the bottom of checks and their ability to be recognized magnetically by devices called readers or sorters. These numbers and symbols—and the technology that process them—are generally referred to as Magnetic Ink Character Recognition (or “MICR”). MICR is a character recognition system that uses special ink and characters to identify banks and accounts to or from which funds will be deposited or withdrawn. When a document (e.g., check) that contains this ink needs to be read, it passes through a machine (e.g., sorter) which magnetizes the ink and then translates the magnetic information into characters. 
     When properly implemented, MICR provides a secure, high-speed method of scanning and processing information. However, when a reader/sorter cannot process the MICR number and characters automatically, or the MICR number and characters are incorrect, a check may be rejected. The MICR information must then be manually re-keyed by someone on a special encoding device, a correction label applied to the bottom of the check, and the check resubmitted. Common MICR errors include the listing of applications types (e.g., deposit, withdrawal, and loan systems implemented by a bank) on the MICR line that do not correspond to the customer&#39;s selected bank. For example, if a customer bank is in Illinois, an check processing error will result if the application type (e.g., deposit system) listed on the MICR line does not correspond to the deposit system actually used by the Illinois bank. In such a case the MICR line numbers would not match up, and the check will not be processed properly. 
     To reduce the likelihood of errors, quality assurance testing on MICR lines is typically conducted. The process currently involves the generation of MICR “decks” which consist of spreadsheets that include credit and debit entries or transactions that simulate customer activity (e.g., deposit, withdrawal, etc.). A particular deck may include an amount of money to be deposited into a particular account at a particular bank. Test decks are fed into a MICR system to verify system integrity and detect any errors that may be occurring during processing. 
     However, current MICR line testing suffers from several notable drawbacks. For one thing, the process is completely manual and thus error-prone. MICR decks include large amounts of data that must be manually entered onto a spreadsheet by a team member. Once completed, the spreadsheet is delivered to other team members who conduct quality review and perform necessary edits. During the review and editing process, each line must be carefully reviewed to ensure that all related data has been entered correctly. If an error is located, the reviewer must sift through a large binder of information to identify the correct data or information, and then must take steps to correct the mistake. Needless to say, the level of detail required to check for errors makes the review process itself vulnerable to error, all of which further compounds the problem. 
     These and other problems exist. 
     SUMMARY OF THE INVENTION 
     An object of the present disclosure is to overcome the aforementioned and other drawbacks existing in prior art systems and methods. 
     According to numerous embodiments, the various systems and methods described herein may comprise a MICR test tool for accessing, creating, revising or modifying documents or decks of MICR lines or transactions that simulate customer credit or debit transactions. In some embodiments, the decks may be used to conduct MICR testing procedures relating to the sorting and processing of checks. In some embodiments, the MICR test tool may comprise an online, web-based tool designed to generate test decks containing error-free MICR lines or transactions that are found on the bottom of checks, for example, and are used by routers or sorters to determine the relevant account to or from which funds will be deposited or withdrawn. Common errors found on MICR lines include the listing of applications (e.g., DDA and SBF—deposit, withdrawal and loan systems, for example) not offered by a particular bank, and the inclusion of incorrect bank name or number, account number, serial numbers, routing or transit number, or tran codes. A tran code is used in a demand deposit account (DDA) to identify the item type to the system (e.g., differentiate between a check and a deposit). By ensuring the decks—and more specifically the lines or transactions within a deck—are error-free, a testing team may stop spending extensive time editing MICR decks and focus more on executing testing procedures as planned. Accordingly, the various systems and methods described herein reduce processing time as individual deck files may be stored for future use and modified as necessary. 
     In some embodiments, the MICR test tool may comprise a MICR testing station that further comprises a MICR line testing module. The MICR line testing module may include additional modules that present a tester, for example, with various interfaces that solicit information relating to the creation, editing, revision or modification of MICR decks, and more specifically MICR lines or transactions that simulate customer credit or debit transactions. In some embodiments, a MICR line or transaction may comprise data or information that may be used during processing to determine which bank and/or account funds will be deposited to or withdrawn from. For example, a MICR line or transaction may comprise a bank number, an application type, serial number, routing/transit number, account number, Iran code, and amount. A deck may comprise a series of MICR lines or transactions which may collectively result in a total credit amount, total debit amount, and balance (e.g., credits+debits). 
     In some embodiments, the MICR testing station may be accessed by a MICR tester to generate MICR decks based on inputs provided. For example, interfaces may query the tester for particular information about a MICR line or transaction, such as bank name, serial number, account, number, and amount of the transaction. In some embodiments, the various and methods described herein may determine particulars about the MICR line or transaction based on information provided. For example, upon the tester selecting a bank to associated with a MICR line or transaction, the various systems and methods described herein may identify application types that correspond to such bank. In some embodiments, drop-down menus may be used to ensure that banks and applications are properly correlated. For example, if a user selects a particular bank, drop-down menus may only offer applications that are associated with the selected bank. The tester may then select the desired application type from the list deemed to be relevant to the selected bank. Other particulars of a MICR line or transaction may be similarly determined. In this way, the various systems and methods of the invention directly improve upon the error-prone procedures currently utilized to test MICR processing. 
     According to one embodiment, a system for accessing and generating documents for use in MICR line testing is provided. The system comprises a MICR testing station for testing MICR processing, the MICR testing station comprising: a MICR line testing module for generating at least one MICR testing document for use in testing MICR processing, the MICR line testing module further comprising: (1) an application determination module for determining an application based on a bank selection provided by a tester, (2) a routing/transit number determination module for determining a routing/transit number based on the bank and the application determined, and (3) a tran code determination module for determining a tran code based on the routing/transit number determined; and at least one client station connected to the MICR testing station via a communications network, the at least one client station being used by at least one tester to provide particulars about at least one MICR line. 
     In another embodiment, a method for accessing data to generate at least one transaction comprising part of at least one document for use in MICR testing is provided. The method comprises the steps of receiving a bank selection signal from a tester selecting a bank associated with a MICR line transaction; determining at least one related application associated with the bank selected by the tester, the at least one related application being determined by an application determination module associated with a MICR testing station; receiving an application selection signal from the tester selecting an application associated with the MICR line transaction, the application being selected from the at least one related application determined to be associated with the bank; determining at least one related routing/transit number associated with the bank and/or the application selected by the tester, the at least one related routing/transit number being determined by an routing/transit number determination module associated with a MICR testing station; receiving a routing/transit number selection signal from the tester selecting a routing/transit number associated with the MICR line transaction, the routing/transit number being selected from the at least one related routing/transit number determined to be associated with the bank and/or the application; determining a tran code that corresponds to the routing/transit number selected by the tester, the tran code being determined by an tran code determination module associated with a MICR testing station; and associating the tran code with the MICR line transaction. 
     In yet another embodiment, a system for accessing and generating documents for use in MICR line testing is provided. The system comprising: a MICR testing station for testing MICR processing, the MICR testing station comprising: a MICR line testing module for generating at least one MICR testing document for use in testing MICR processing, the MICR line testing module further comprising: (1) an application determination module for determining an application based on a bank selection provided by a tester, (2) a routing/transit number determination module for determining a routing/transit number based on the bank and the application determined, (3) a tran code determination module for determining a tran code based on the routing/transit number determined, (4) a deck selection module for selecting a deck to create or revise, wherein the deck selection module further comprises a search module for searching existing decks, a build new deck module for creating a new deck, and an open existing deck for opening and revising, modifying or editing an existing deck, (5) a view deck module for viewing selected decks, wherein the view deck module further comprises a search module for searching existing decks, a copy deck module for copying an existing deck, an add items module for adding transactions to a deck, a save deck module for saving a deck, and a submit deck module for submitting a deck for MICR testing, (6) a view item module for viewing at least one transactions within a deck, wherein the view item module further comprises a search module for searching existing decks, a view deck module for viewing at least one deck associated with the at least one transaction, and a post item module for posting the at least one transaction to the deck; and at least one client station connected to the MICR testing station via a communications network, the at least one client station being used by at least one tester to provide particulars about at least one MICR line. 
     The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various embodiments of the invention and, together with the description, serve to explain the principles of the invention. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram illustrating a system for testing MICR lines, according to an exemplary embodiment. 
         FIG. 1   a  is a table  150  illustrating a MICR deck, according to the an exemplary embodiment. 
         FIG. 2  is a block diagram illustrating exemplary modules associated with a MICR testing station  105 , according to an exemplary embodiment. 
         FIG. 3  illustrates a method  300  for testing a MICR line, according to an exemplary embodiment. 
         FIG. 4  illustrates a method  400  for testing a MICR line, according to an exemplary embodiment. 
         FIG. 5  illustrates an interface  500  of system  100  for testing MICR lines, according to an exemplary embodiment. 
         FIG. 6  illustrates an interface  600  of system  100  for testing MICR lines, according to an exemplary embodiment. 
         FIG. 7  illustrates an interface  700  of system  100  for testing MICR lines, according to one embodiment of the invention. 
         FIG. 8  illustrates an interface  800  of system  100  for testing MICR lines, according to one embodiment of the invention. 
         FIG. 9  illustrates an interface  900  of system  100  for testing MICR lines, according to one embodiment of the invention. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     Reference will now be made to illustrative embodiments of the invention(s) described herein, examples of which are illustrated in the accompanying drawings in which like reference characters refer to corresponding elements. 
     The present embodiments are described in relation to various systems and methods for enabling a user to test MICR lines in connection with the processing of checks. Nonetheless, the characteristics and parameters pertaining to the various embodiments of the systems and methods described herein may be applicable to test MICR lines in any context. 
     While the exemplary embodiments illustrated herein may show various embodiments (or portions thereof) collocated, it is to be appreciated that the various components of the various embodiments may be located at distant portions of a distributed network, such as a local area network, a wide area network, a telecommunications network, an intranet and/or the Internet, or within a dedicated object handling system, for example. Thus, it should be appreciated that the components of the various embodiments may be combined into one or more devices (or modules) or collocated on a particular node of a distributed network, such as a telecommunications network, for example. As will be appreciated from the following description, and for reasons of computational efficiency, the components of the various embodiments may be arranged at any location within a distributed network without affecting the operation of the respective system(s). 
     According to the various embodiments, the systems and methods described herein enable a user (e.g., tester) to generate MICR transactions that simulate customer activity (including new functionality). These MICR transactions may be organized as decks which may then be used to conduct MICR testing to make sure MICR processing proceeds properly. For example, an administrator of a MICR sorting process, for example, may use the various systems and methods described herein to anticipate and test the accurate processing of transactions based on MICR. 
     The various systems and methods described herein present the following advantages/benefits: (1) the tool may make it easier to request a MICR deck by having informational online screens that will eliminate the need for detailed MICR knowledge; (2) drop downs and edits may prompt the user to build an error free deck; (3) the new system may allow the requestor to create the transactions closer the execution cycle allowing for retests; (4) the tool may allow the testers to reuse previous test decks from prior tests, reducing data entry time; (5) less time training may be required due to online training and job aids; (6) help screens may be available during execution with examples in detail as well as video demos (7) the line of business (“LOB”) tester may be freed up to focus on testing their new code, not generating decks; (8) supervisors may not have to review, edit and correct test decks; (9) MICR procedure testers may receive their input accurately and in a timely manner for processing to enabling them to meet their processing schedule; (10) enable quick generation of MICR decks; (11) ability to enter data and then verify the processing results before the next set of input data is entered; (12) allow the requestor to request MICR in business language rather than in specific tran codes; (13) ability to generate the tran code in the correct format, such as by pulling together the account, script and MICR information; (14) ability to have manual control taken over by the automated tool; (15) eliminate one or more of the manual audits and controls that are currently in place; (16) ability to automate the process of creating and submitting MICR test decks which are used as test input for application testing during enterprise wide projects; and (17) enable testing for new enhancements. 
       FIG. 1  depicts an exemplary data processing environment or system  100  comprising one or more user or client stations  110 , communications network  120 , and one or MICR testing stations  130 . As shown, client station  110  may connect to or communicate with MICR testing station  130  through any number of communication networks, such as communication networks  120 , for example. 
     According to various embodiments, client station  110  may comprise a typical home or personal computer system where a user (e.g., tester) may interact with a network, such as the Internet, for example. Client station  110  may comprise or include, for instance, a personal or laptop computer. Client station  110  may include a microprocessor, a microcontroller or other general or special purpose device operating under programmed control. Client station  110  may also include a network-enabled appliance, a browser-equipped or other network-enabled cellular telephone, or another TCP/IP client or other device. 
     Client station  110  may be utilized by a tester, for example, to interact with MICR testing station  130  in connection with the creation, accessing, editing or modification of a MICR line or transaction that is part of a deck that may be used for testing MICR processing. In some embodiments, the tester may use client station  110  to provide MICR testing station  130  with particulars about a MICR line or transaction, such as bank name, application type, serial number, routing/transit number, account number, tran code, amount, or any other data or information that may be used to simulate customer credit or debit transactions. 
     MICR testing station  130  may enable the administration, control, and/or monitoring of the generation of test decks or that contain error-free MICR lines or transactions. In some embodiments, MICR testing station  130  may further comprise a terminal for an administrator of system  100 . Such a terminal may be used, for example, to enable the administrator to control and oversee network operations, including but not limited to control and interaction between any client station  110  and MICR testing station  130 . 
     MICR testing station  130  may comprise a single server or engine. In some embodiments, MICR testing station  130  may comprise a plurality of servers or engines, dedicated or otherwise, which may further host modules for performing desired system features and functionality. MICR testing station  130 , for example, may comprise one or more modules that function to perform, control, administer, and/or direct the various MICR testing features and functionality described herein. MICR testing station  130  may include a MICR line testing module  105  for generating, accessing, revising or modifying MICR lines or transactions that comprise a MICR deck used in testing MICR processing. MICR testing station  130  may also include an administration module (not shown) for an agent of MICR testing station  130 , for example, to input information related to MICR decks and MICR lines or transactions, for example. According to various embodiments, an agent of MICR testing station  130  may interface with a graphical user interface (or GUI) to MICR line testing module  105  to input necessary information and data. 
     Data and information maintained by MICR testing station  130  may be stored and cataloged in one or more databases  140  which may comprise or interface with a searchable database. For example, databases  140  may store data or information about particular MICR decks and corresponding parameters. For example, databases  140  may store decks by tester, deck name, capture site, event, cycle, predefined set, and/or date. Other parameters are possible. Databases  140  may also store MICR line or transaction particulars, such as bank name, application type, serial number, routing/transit number, account number, tran code, amount, for example. In addition, databases  140  may also store tables that enable the various systems and methods described herein to determine and identify parameters associated with a MICR line or transaction based on tester inputs, such as for example, application types, routing/transit number, and tran codes, for example. Databases  140  may comprise, include or interface to a relational database. Other databases, such as a query format database, a Standard Query Language (SQL) format database, a storage area network (SAN), or another similar data storage device, query format, platform or resource may be used. Databases  140  may comprise a single database or a collection of databases, dedicated or otherwise. In one embodiment, databases  140  may store or cooperate with other databases to store contextual information described herein. 
     Communications network  120  may comprise any type of communication network such as one able to transmit and receive data or information used by the various systems and methods described herein. Communications network  120  may be comprised of or may interface to any one or more of, the Internet, an intranet, a Personal Area Network (PAN), a Local Area Network (LAN), a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a storage area network (SAN), a frame relay connection, an Advanced Intelligent Network (AIN) connection, a synchronous optical network (SONET) connection, a digital T1, T3, E1 or E3 line, a Digital Data Service (DDS) connection, a Digital Subscriber Line (DSL) connection, an Ethernet connection, an Integrated Services Digital Network (ISDN) line, a dial-up port such as a V.90, a V.34 or a V.34 bis analog modem connection, a cable modem, an Asynchronous Transfer Mode (ATM) connection, a Fiber Distributed Data Interface (FDDI) connection, or a Copper Distributed Data Interface (CDDI) connection. Communications network  120  may also comprise, include or interface to any one or more of a Wireless Application Protocol (WAP) link, a General Packet Radio Service (GPRS) link, a Global System for Mobile Communication (GSM) link, a Code Division Multiple Access (CDMA) link or a Time Division Multiple Access (TDMA) link such as a cellular phone channel, a Global Positioning System (GPS) link, a cellular digital packet data (CDPD) link, a Research in Motion, Limited (RIM) duplex paging type device, a Bluetooth radio link, or an IEEE 802.11-based radio frequency link. Communications network  120  may further comprise, include or interface to any one or more of an RS-232 serial connection, an IEEE-1394 (Firewire) connection, a Fibre Channel connection, an infrared (IrDA) port, a Small Computer Systems Interface (SCSI) connection, a Universal Serial Bus (USB) connection or another wired or wireless, digital or analog interface or connection. 
     In some embodiments, communication network  120  may comprise a satellite communications network, such as a direct broadcast communication system (DBS) having the requisite number of dishes, satellites and transmitter/receiver boxes, for example. Communications network  120  may also comprise a telephone communications network, such as the Public Switched Telephone Network (PSTN). In another embodiment, communication network  120  may comprise a Personal Branch Exchange (PBX), which may further connect to the PSTN. 
       FIG. 1   a  illustrates a MICR deck  150  that is typical of the decks processed by the various systems and methods described herein. As shown, deck  150  comprises four MICR lines or transactions that may simulate customer credit or debit transactions. In some embodiments, a MICR line or transaction may comprise various parameters, including, for example, a bank name/number, application type, serial number, routing/transit number, account number, tran code and/or amount. In some embodiments, some of the parameters are provided by the tester, while others are determined by the various systems and methods described herein. For example, the various systems and methods described herein may determine the application type parameter based on the tester&#39;s selection of a bank name. In some embodiments, such determination may be based on predefined rules or tables that may be stored in databases  140 , for example. Other parameters may be determined by the tester or by the various systems and methods described herein. 
       FIG. 2  illustrates various exemplary modules associated with MICR line testing module  105 , according to some embodiments. In some embodiments, MICR lines testing module  105  enables a tester to selectively create, access, revise, or modify MICR decks used to test MICR processing, and more specifically create, access, revise or modify MICR lines or transactions that are comprise the MICR deck. In some embodiments, the various modules may be accessed through any number of graphical user interface(s) that enable a user to provide and receive data or information. As shown, the following modules may be provided: (1) deck selection module  210 ; (2) view deck module  235 ; (3) application determination module  290 , (4) routing/transit determination module  292 ; and (5) tran code determination module  295 . Each is described below: 
     Deck selection module  205  may, in some embodiments, enable a tester to select a particular MICR deck to create, access, revise or modify. In some embodiments, deck selection module  205  may further comprise additional modules for selecting decks: a search module  215 , a build new deck module  220 , and an open existing deck module  225 . For example, interfacing with search module  215 , a tester may conduct a search of the various decks stored in databases  140 . Such a search may be conducted by tester name (e.g., the tester that created the deck), deck name, capture site (e.g., the site or location where the deck was printed), event (e.g., a project currently participating in testing to be brought to production or a past or future scheduled project lined up for testing before being brought into production), cycle (e.g., the timeframe within an event that certain tasks may be completed; there may be multiple cycles per event) predefined set (e.g., a listing of numbers and codes that may have already been placed in the MICR tool drop down boxes for users to select from based on the area being completed by the tester), and date range. A tester may also interface with build new deck module  220  to create a new deck by providing deck particulars, such as deck name, bank number, application type, serial number, routing/transit number, account number, tran code, and amount, for example. Open existing deck module  225  may be used to open any decks that are associated with a MICR line or transaction the tester is currently working on. In some embodiments, each of the above modules may generate appropriate interfaces (e.g., graphical user interfaces (or “GUIs”)) that enable the tester, for example, to easily provide and obtain data or information relating to the MICR lines or transactions or MICR decks. In some embodiments, a help module  230  may be provided to assist the tester with use of deck selection module  210 . 
     View deck module  235  may, in some embodiments, be used to view particulars of a MICR deck selected by deck selection module  210 , for example. In some embodiments, view deck module  235  may further comprise additional modules for viewing decks, such as: a search module  240 , a copy deck module  245 , an add items module  250 , a save deck module  255 , and a submit deck module  260 . For example, interfacing with search module  215 , a tester may conduct a search of the line or transactions within a specific deck. Such a search may be conducted by any of the line or transaction parameters, such as bank number, application type, serial number, routing/transit number, account number, tran code, and amount, for example. A tester may also interface with a copy deck module  245  to create a copy of the deck being viewed or any designated deck, for example. Add items module  250  may be used to add lines or transactions to a deck. For example, a tester may add new lines or transactions to an existing deck corresponding to credit or debit transactions. Save deck module  255  may be used to save a particular deck once one or more particulars of its lines or transactions have been entered. In some embodiments, decks may be stored in database  140 , for example, for subsequent access and use. Submit deck module  260  may be used to submit a deck for processing in connection with testing of MICR procedures. For example, a completed deck may be printed (e.g., in the form of individual checks or transactions) and submitted to sorters and routers for processing and to identify one or more possible errors. In some embodiments, each of the above modules may generate appropriate interfaces that enable the tester, for example, to easily provide and obtain data or information relating to the MICR lines or transactions or MICR decks. In some embodiments, a help module  265  may be provided to assist the tester with use of view deck module  235 . 
     View item module  270  may, in some embodiments, be used to view particulars of a MICR line or transaction with a deck selected by deck selection module  210 , for example. In some embodiments, view item module  270  may further comprise additional modules for viewing lines or transactions, such as: a search module  275 , view deck module  235 , and a post item module  280 . Search module  215  may be used to conduct a search of a line or transaction within a deck. From within view item module  270 , a tester may also interface with a view deck module  235  to view one or more of the other lines or transactions associated with the deck. Post item module  280  may be used to add lines or transactions to a deck. In some embodiments, items are posted to a deck which may then be stored in database  140 , for example, for subsequent access and use, In some embodiments, each of the above modules may generate appropriate interfaces that enable the tester, for example, to easily provide and obtain data or information relating to the MICR lines or transactions or MICR decks. In some embodiments, a help module  285  may be provided to assist the tester with use of view item module  270 . 
     Sign-in module  205  may, in some embodiments, enable a tester to sign-in to MICR testing station  130  to access the various features and functionality described herein. In some embodiments, signing in may involve entering an authorized user name and password, for example. In some embodiments, sign-in module  205  may ensure that only authorized personnel are granted permission to access and utilize the various features and functionality described herein. For example, only select members of a team may be permitted to create, edit or revise MICR lines or transactions that may comprise a part of a deck to be used in MICR testing procedures. 
     Application determination module  290  may, in some embodiments, determine application types that may relate to a particular bank that a tester has designated in connection with creating, accessing, revising or modifying a MICR line or transaction. In some embodiments an application may refer to the particular deposit/withdrawal or loan systems that a particular bank has implemented. Thus, if a tester specifies a particular bank in connection with a new or revised line or transaction or deck, application determination module  290  may process the selection and identify all application types that correspond to the bank. In some embodiments, all application types that correspond to the bank may then be presented to the tester for selection. In some embodiments, application types may be presented in a drop down menu that the tester may then scroll to identify the desired application type. 
     Routing/transit determination module  292  may, in some embodiments, determine routing/transit numbers that may relate to a particular bank and/or application type that a tester has designated in connection with creating, accessing, revising or modifying a MICR line or transaction. Thus, if a tester specifies a particular bank and application type in connection with a new or revised line or transaction or deck, routing/transit determination module  292  may process the selection(s) and identify one or more routing/transit numbers that correspond to the bank and/or application type. In some embodiments, one or more routing/transit numbers that correspond to the bank and/or application type may then be presented to the tester for selection. In some embodiments, routing/transit numbers may be presented in a drop down menu that the tester may then scroll to identify the desired routing/transit number. 
     Tran code determination module  295  may, in some embodiments, determine a tran code that relates to a particular routing/transit number that a tester has designated in connection with creating, accessing, revising or modifying a MICR line or transaction. Thus, if a tester specifies a particular routing/transit number in connection with a new or revised line or transaction or deck, tran code determination module  295  may process the selection and identify a tran code number that corresponds to the routing/transit number. In some embodiments, one or more Iran codes that correspond to the routing/transit number may be presented to the tester for selection. In some embodiments, tran codes may be presented in a drop down menu that the tester may then scroll to identify the desired routing/transit number. In some embodiments, tran code determination module  295  may auto-populate the line or transaction with the appropriate tran code. 
     Deck generation module  298  may, in some embodiments, generate particular documents with MICR lines or transactions that have been created, revised or modified using the various systems and methods described herein. In some embodiments, the documents generated may be printed at an associated printer and may be submitted for processing by sorters and routers for testing purposes. In some embodiments, the documents generated and printed may resemble checks that simulate customer credit or debit transactions. In some embodiments, a tester may interface with deck generation module  298  and specify, via appropriate interfaces, which lines or transactions or decks may be generated and printed. 
     Exemplary methods that may be performed by the various systems described above will now be discussed. In some embodiments, the methods described herein may be performed by system  100 , and more specifically MICR line testing module  105 . 
       FIG. 3  illustrates one embodiment of a method  300  for crating, accessing, revising or modifying a deck, according to one embodiment of the systems and methods described herein. At step  305 , a tester may sign on to MICR testing station  130 . In some embodiments, the tester may provide an appropriate username and password to verify access rights. At step  310 , the tester may specify a particular deck the tester would like to create, edit or revise. At step  315 , the tester may request to add a line or transaction to the deck. In some embodiments, the tester may so specify by initiating an add item icon that may be related with add items module  250 , for example. At step  320 , the tester may select a bank name or number associated with the line or transaction the tester is creating or adding. In some embodiments, application determination module  290  may determine at least one application type that corresponds to the bank name or number that was selected by the tester. At step  325 , the tester may select an application type from the list of application types that the application determination module  290  has identified as corresponding to the selected bank. In some embodiments, the application type may be selected from a drop down menu. 
     At step  330 , the tester may select a serial number for the line or transaction. At step  335 , the tester may select a routing/transit number for the line or transaction. In some embodiments, the routing/transit number may be selected from a group of routing/transit numbers that routing/transit number determination module  292  has determined as corresponding to the bank and/or application type selected by the tester. In some embodiments, the application type may be selected from a drop down menu. At step  340 , tran code determination module  295  may determine a corresponding Iran code based on the routing/transit number selected by the tester. In some embodiments, tran code determination module  295  may auto-populate the parameter of the line or transaction with the appropriate Iran code. At step  345 , the tester may select an account number and/or a transaction amount for the line or transaction. At step  350 , the tester may post the line or transaction as part of a MICR deck for future use in testing MICR processing. 
       FIG. 4  illustrates one embodiment of a method  400  for determining parameters of a MICR line or transaction, according to an embodiment of the systems and methods described herein. At step  405 , a bank selection signal may be received from a tester selecting a bank associated with a MICR line transaction. At step  410 , at least one related application associated with the bank selected by the tester may be identified. In some embodiments, the at least one related application may be determined by application determination module  290  associated with MICR testing station  130 . At step  415 , an application selection signal may be received from the tester selecting an application associated with the MICR line transaction. In some embodiments, the application is selected from the at least one related application determined to be associated with the bank. At step  420 , at least one related routing/transit number associated with the bank and/or the application selected by the tester may be identified. In some embodiments, the at least one related routing/transit number may be determined or identified by routing/transit number determination module  292  associated with a MICR testing station  130 . 
     At step  425 , a routing/transit number selection signal may be received from the tester selecting a routing/transit number associated with the MICR line transaction. In some embodiments, the routing/transit number is selected from the at least one related routing/transit number determined to be associated with the bank and/or the application. At step  430 , a tran code that corresponds to the routing/transit number selected by the tester may be determined. In some embodiments, the tran code is determined by a tran code determination module  295  associated with MICR testing station  130 . 
       FIGS. 5-9  illustrate various interfaces that a user interacting with MICR testing station  130  and more particularly MICR line testing module  105  to conduct testing of MICR lines or transactions, such as demonstrated by methods  300  and  400  of  FIGS. 3 and 4 , respectively. 
       FIG. 5  illustrates an Interface  500  for testing MICR lines, according to an embodiment of the systems and methods described herein. Interface  500  may comprise a sign-in screen where an authorized user may access the features and functionality of MICR Testing Station  205  by entering the user name and password, for example. In some embodiments, Interface  500  may ensure that only authorized personnel are granted permission to access and utilize the various features and functionality described herein. For example, only select members of a team may be permitted to create, edit or revise MICR line transactions that may comprise a part of a deck to be used in MICR testing procedures. In some embodiments, Interface  500  may request any data or information that may be used to identify or authenticate a user. 
       FIG. 6  illustrates an Interface  600  that may correspond to a deck selection screen. As shown, Interface  600  may comprise icons for logging out, running a search, building a new deck, opening an existing deck, and a help icon. In some embodiments Interface  600  may enable a tester, for example, to identify and select a deck that will either be created, edited, revised, or modified. In some embodiments, a tester may select a deck for creation or modification by searching for such a deck by user, deck name, capture size, event, cycle, predefined set, or date range. The tester may populate any of the above enumerated parameters and conduct a search based on said parameters. Any search results resulting from such a search may be posted under search results as shown in Interface  600 . The user may then initiate any of the search results that appear by clicking open existing deck as shown. In so doing, the tester may call up the particulars of the corresponding deck selected. 
       FIG. 7  illustrates an Interface  700  that may correspond to a view deck module as described herein. Some embodiments, Interface  700  may appear once a tester selects a deck as described above in connection with  FIG. 6 . For example, as shown on Interface  700  the corresponding deck selected by a tester is designated “CHI CERT UAT Cycle 1 20051123 103151.” Also shown on Interface  700  are particulars of such a deck such as the number of transactions in the deck, the bank number for each of those transactions as well as the application type, serial number, routing transit number, account no., corn code, amount and item comments. Also shown on Interface  700  are various parameters that a tester may initiate in working with the selected deck. For example, the tester may designate a capture site, an event, a cycle number, provide comments. Some embodiments, Interface  700  may further specify a credit total, a debit total and a balance associated with the various deck transactions. As shown, the credit total $160 is based on the various credits shown in the four transactions listed below. Similarly, the debit total $360 is the amount of debits as shown on the four transactions listed below. The balance is, of course, the sum of these two amounts and is shown as being −$200. 
     Interface  700  also provides the tester with various icons that can be initiated to perform select features or functionality. For example, the tester may log out, conduct a search, copy the selected deck, add additional items or transactions to the deck, save the deck, or submit the deck for future use in MICR testing procedures. 
       FIG. 8  illustrates an Interface  800  that may correspond to a view item screen that may appear following a testers initiation of the add items icon shown on Interface  700  of  FIG. 7 . In some embodiments, such initiation of an add items icon designates a tester&#39;s desire to add an item or transaction to a selected deck. Thus, the tester may wish to add additional transactions to the four that are currently shown as listed on Interface  700 , for example. Some embodiments, entering additional items or transactions may comprise providing a bank number associated with the transaction and application type item of transaction comments as well as a serial number, a routing transit number, an account number, a TRAN code, an amount and any other data or information that may be required. In some embodiments, the tester may provide such information via drop-down menus as shown, for example, in connection with the bank number, application type and the routing transit number. 
     In some embodiments, once a tester designates a particular bank number, the various systems and methods described herein may determine at least one application type that may be associated with the selected bank number. For example, as shown, the tester has selected JPMorgan Chase Bank, N.A. of Ohio as the corresponding bank of the audit transaction. Responding thereto, the various systems and methods described herein may generate a listing of at least one application type that is associated with JPMorgan Chase N.A. of Ohio. In some embodiments, such a list may be included in the drop-down menu designated along side of application type. The tester may then select from the provided drop-down menu the corresponding application type that he or she would like associated with the added transaction. 
     The tester may also designate a serial number that corresponds to the added transaction as well as a routing transit number, In some embodiments the routing transit number may be selected from a list of relevant routing transit numbers that may be generated by various systems and methods described herein based on the bank number selected and/or the application type selected by the tester. In some embodiments, the various systems and methods described therein may also determine corresponding tran code number based on the routing transit number ultimately selected by the tester. Such a tran code number may be then automatically populated on Interface  800  where shown. In some embodiments, a tester may also provide an account number as well as an amount that are to be associated with the transaction being added. Once all particulars of the added transactions have been provided, the tester may then post the item of transaction onto the deck for future use in MICR testing procedures. 
       FIG. 9  illustrates an Interface  900  that illustrates the various transactions that were added via Interface  800 . In comparison to Interface  700  of  FIG. 7 , Interface  900  now includes 3 additional transactions that were added according to the procedures set forth above in connection with  FIG. 8 . As shown, Interface  900  includes new added transactions  5 ,  6 , and  7 . The effect of these three added transactions on the credit total is an increase of $250. Its effect on the debit total is a decrease of $150, and the effect on the overall balance is +$100. In some embodiments, the deck shown as revised with the three new transactions may then be saved by the tester for future use in MICR testing procedures. 
     Other embodiments, uses and advantages of the present invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. The specification and examples should be considered exemplary only.