As shown in FIG. 2, lockbox platform 210 may transmit biller data. For example, lockbox platform 210 may provide biller lockbox address and reference data via real time updates. Lockbox platform may provide this information at 212 via API. Reference data elements may be represented at 214, which may include participant identifier, biller address, lockbox participant central account DDA, etc. Reference data may also include an update reject flag shown by 216. Other flags may be applied to identify other conditions, status, etc. Although not explicitly illustrated, once the biller data has been provided to the IIN 204 or a check matching system, the IIN 204 consolidates the biller data into a lockbox directory stored at the IIN 204.

Bill pay platform 218 may pull the lockbox directory stored at the IIN 204 and transmit check print files to a lockbox provider included in the lockbox directory. For example, bill pay platform 218 may provide daily (or other interval) check print data at 220 via an API. According to exemplary aspects, the check print data may include text data and image data/file, which may be generated by the bill pay platform 218 or the paper check originator. Data elements 222 may include biller name (e.g., payee), biller address, amount, payer name, payer reference account, date, bill pay identifier, an image file, remittance information, etc.

IIN 204 may support nodes or other interfaces to receive data. This may include bill pay provider nodes, lockbox provider nodes, etc. IIN 204 may generate a unique identifier 224, which may be based on biller address information, for example. IIN 204 may match datasets from bill pay provider 202 and lockbox service provider 206 to identify IIN participants. At 226, IIN 204 may perform a match or lookup that compares data elements 222 and reference data 214. IIN 204 may then identify and assign an IIN participant indicator to qualifying transactions at 228. At 230, check print data may be updated. At 232, a lockbox file may be created. IIN may send an updated file with flags that identify which transactions require check print and which transaction go through IIN at 234. IIN may distribute data to bill pay provider 202 and lockbox service provider 206. For example, data may be published on a distributed ledger where access to data may be restricted and/or protected.

At 236, bill pay platform 218 may send non-IIN transactions to check print facility 238. At 240, bill pay platform 218 may send IIN participants to ACH services 242. At 244, ACH payment may be sent from ACH Services 242 to centralized lockbox deposit account 246. For example, ACH Services 242 may create nightly (or other interval) ACH files to each lockbox provider corresponding to the IIN flagged transactions. Simultaneously (or near simultaneously) with 244, IIN participant lockbox data file may be sent to lockbox platform 210 via 248.

At 250, data and ACH files may be integrated into lockbox platform 210. At 252, lockbox rules may be applied to determine whether transactions are accepted or rejected. Other rules and/or conditions may be applied. If accepted, transaction data may be distributed to client transmission, at 256. Payments may be distributed to clients DDAs (or other accounts) via book transfer, at 258. Client distributions may be made at 260. If rejected, the flow may proceed to FIG. 3. However, aspects of the present disclosure are not limited thereto, such that if a transaction is rejected, then the transaction may be sent to a check print vendor or system for printing and mailing of a check to an intended recipient.

An embodiment of the present invention is directed to ACH files as one illustrative example. Other forms of payment may be applied. For example, an embodiment of the present invention may be applied to digital currency and other forms of payment.

FIG. 3 is an exemplary flow illustrating an electronic exchange for bill pay transactions via IIN, according to an embodiment of the present invention. According to exemplary aspects, IIN may referred to as a check matching system. FIG. 3 demonstrates interactions between bill pay provider 202, IIN 204 and lockbox service provider 206. FIG. 3 provides details when lockbox rules may determine a rejected transaction at 252. At 310, data of rejected transactions may be sent to IIN 204. At 312, instructions may be sent to centralized lockbox deposit account 246 to revert funds back to a bill pay deposit account. At 314, rejected data may be sent from lockbox service provider 206 to IIN 204, centralized lockbox deposit account 246 may return funds with associated reference data via 316 to bill pay deposit account 318. At 320, data may be received by IIN and distributed to an associated bill pay provider. At 322, a reject database may log a specific remitter of the transaction to the specific lockbox and then reject future transactions of the remitter to the specific lockbox going forward. As shown by 322, a reject flag may be updated. Other flags may be applied to identify other conditions, status, etc. At 324, reject data may be sent to bill pay providers 202 via bill pay platform 218. At 326, rejected transactions received may be recycled back into business as usual (BAU) check print files and follow BAU legacy model at check print facility 238.

FIG. 4 is an exemplary flow illustrating an electronic exchange for bill pay transactions via IIN, according to an embodiment of the present invention. According to exemplary aspects, IIN may referred to as a check matching system. FIG. 4 may represent a variation of the exemplary flow illustrated in FIG. 2. FIG. 4 illustrates a digital bill pay lockbox platform via IIN. FIG. 4 demonstrates interactions between bill pay provider 402, IIN 404 and lockbox service provider 406. Lockbox platform 410 may provide biller lockbox address and reference data via real time updates. Lockbox platform may provide this information at 412 via API. Reference data elements may be represented at 414, which may include participant identifier, associated addresses, associated deposit DDA's, participant DDA account information, etc.

Bill pay platform 418 may provide daily check print data at 420 via an API. Data elements 422 may include biller name (e.g., payee), biller address, amount, payer name, payer reference account, date, bill pay identifier, etc.

IIN 404 may generate a unique identifier 424, which may be based on a data element, such as an associated address information, for example. At 426, IIN 204 may perform a match or lookup that compares data elements from bill pay 422 and data elements from lockbox 414. IIN 404 may then identify and assign an IIN participant indicator at 428. At 430, a previously rejected payer to a specific lockbox may be identified. At 432, a lockbox file may be created. At 434, IIN participant lockbox data file may be sent to lockbox platform 410. At 436, lockbox rules may be applied. For example, the rules may identify rejected transactions and also provide reject reasons, such as “Stop/Go” file, unacceptable payee, client driven exceptions, etc. At 438, IIN participant may send accepted and/or rejected transactions. At 440, check print data may be updated. At 442, a reject flag may be updated. Other flags may be applied to identify other conditions, status, etc. At 444, an updated file may be sent to bill pay platform 418. The updated file may include accepted IIN participant transactions with associated lockbox provide indicator; rejected IIN participant transactions; previously rejected payers for a lockbox and non IIN participant transactions. Other types of transactions may be included. At 446, bill pay platform 418 may send updated file data, e.g., rejected IIN participant transactions; previously rejected payers for a lockbox and non IIN participant transactions, to check print facility 448. At 450, bill pay platform 418 may send updated file data, e.g., accepted IIN participant transactions with associated lockbox provide indicator, to ACH facility 452. For example, ACH facility 452 may create nightly (or other interval) ACH files to each lockbox provider. At 454, ACH payment may be sent from ACH facility 452 to centralized lockbox deposit account 456. At 458, centralized lockbox deposit account 456 may notify of an ACH receipt to lockbox platform 410. As shown in FIG. 4, ACH is one illustrative example. Other forms of payment, including digital currency, may be applied. At 460, payments may be distributed to clients DDAs (or other accounts) as shown by 462. Transaction data may be distributed via client transmission as shown by 464. Client distributions may be made at 466.

FIG. 5 is an exemplary system diagram, according to an embodiment of the present invention. FIG. 5 illustrates interactions between bill pay provider 502, IIN application 504 and lockbox provider 506. As shown in FIG. 5, digital bill pay & lockbox 550 may include nodes, e.g., bill pay provider nodes and lockbox provider nodes. Bill pay and lockbox providers send data to digital lockbox application, such as IIN application that executes on a platform or central system. According to exemplary aspects, IIN may referred to as a check matching system.

Lockbox provider 506 may include bank 1 and bank 2. Bank 1 may transmit biller data to digital bill pay & lockbox 550 via 510. Digital bill pay & lockbox 550 may include a user interface to receive data. Bank 1 biller data 512 may include participant identifier (ID), biller address, biller deposit DDA, etc. Address information may be represented by PO Box numbers, for example. Bank 2 may transmit biller data to digital bill pay & lockbox 550 via 520. Bank 2 biller data 522 may include participant ID, biller address, biller deposit DDA, etc.

Bill pay provider 502 may include bank A and bank B. Bank A may transmit a check print file to digital bill pay & lockbox 550 via 530. Bank A print file 532 may include biller name, biller address, amount, payer name, payer reference account, date and bill pay ID, etc. Bank B may transmit check print file to digital bill pay & lockbox 550 via 540. Bank B check print file 542 may include biller name, biller address, amount, payer name, payer reference account, date and bill pay ID, etc.

FIG. 6 is an exemplary system diagram, according to an embodiment of the present invention. An embodiment of the present invention may match bill pay and lockbox provider data sets to identify IIN participants. As shown in FIG. 6, data sets may be matched at 660. Bank 1 biller data 610 and Bank 2 biller data 620 may be compared with data from Bank A and Bank B. According to exemplary aspects, IIN may referred to as a check matching system.

Bank A check print file may be processed to identify participating lockboxes at 630. Bank B check print file may be processed to identify participating lockboxes at 640. At 660, a unique identifier may be used for matching as shown by 612 and 622 (from biller data) and 632 and 642 (from check print files). Data sets may be matched to identify IIN participants at 670. Matched identifiers may be processed by comparing biller addresses, as shown by 632 and 642. In this example, matched participants may be identified as PO1, PO2, PO3 (at bank A check print file) and PO5 (at bank B check print file). Mismatched participants may be identified as PO4 (at bank A check print file) and PO6 (at bank B check print file).

FIG. 7 is an exemplary system diagram, according to an embodiment of the present invention. IIN application distributes data to bill pay and lockbox providers. FIG. 7 illustrates interactions between bill pay provider 702, IIN application 704 and lockbox provider 706. Digital bill pay & lockbox 760 may publish data on a distributed ledger. For example, a single distributed ledger with built-in entitlements may be provided for restricted access.

Bank 1 may receive an expected payment from bank A, as shown by 710. The payment file may include payee, biller address, amount, payer name, payer reference account, bill pay ID, etc. Bank 1 may also receive an expected payment from bank B, as shown by 712. Restricted access may be provided at 714.

Bank 2 may receive an expected payment from bank A, as shown by 720. The payment file may include payee, biller address, amount, payer name, payer reference account, bill pay ID, etc. Restricted access may be provided at 722.

Bank A may access payment instructions 730, which may include biller name, biller address, amount, payer name, payer reference account, date, bill pay ID, etc. Payment instructions may be sent to multiple recipients, including bank 1 and bank 2. Bank A may also send to check print 732. Restricted access may be provided at 734.

Bank B may access payment instructions 740, which may include biller name, biller address, amount, payer name, payer reference account, date, bill pay ID, etc. Payment Instructions may be sent to one or more recipients, including Bank 1. Bank B may also send to check print 742. Restricted Access may be provided at 744.

FIG. 8 is an exemplary system diagram, according to an embodiment of the present invention. IIN may be deployed as a Distributed Application with a layered approach for UI, service, orchestration, and integration layers. According to exemplary aspects, IIN may referred to as a check matching system.

As shown in FIG. 8, Bank 810 may support distributed applications 812, which may include front end (e.g., web server), back end (e.g., application server) and a local database. For example, application server may provide a service based approach for message parsing, logging, business logic and other services. Distributed apps 812 may communicate with authentication/authorization plugin 802. Distributed apps 812 may also communicate with internal systems 820, via communication network 822 which may provide API based integration and support HTTP/event bus. An embodiment of the present invention may provide an adaptor-based approach for Integration with underlying blockchain. Distributed apps 812 may communicate with a quorum node/dB 834 via API 814. Bank 810 may further implement block chain adaptor 816 and application boundary 818.

As shown in FIG. 8, each participant node may integrate with an underlying blockchain. An embodiment of the present invention may provide various key features including configuration based permissioning; privacy via private contracts and transactions; RAFT based consensus for high performance (other consensus algorithms may be applied); and smart contracts.

Blockchain quorum 830 may be smart contracts based, as shown by 832. Quorum nodes/dB may communicate with each bank or other participant. For example, Quorum node/dB 834 may communicate with bank 810; quorum node/dB 836 may communicate with bank A 850; and quorum node/dB 838 may communicate with bank B 870. Private transactions may be supported by P2P networks, represented by 840, 842 and 844.

Bank A 850 may support distributed applications 852, which may include front end (e.g., web server), back end (e.g., application server) and a reporting database. For example, application server may provide a service based approach for message parsing, logging, business logic and other services. Bank A 850 may also communicate with Bank A internal systems 860, via an API based integration. Distributed apps 852 may communicate with a quorum Node/dB 836 via API 854. Bank A 850 may further implement application boundary 856.

Bank B 870 may support distributed applications 872, which may include front end (e.g., web server), back end (e.g., application server) and a reporting database. For example, application server may provide a service based approach for message parsing, logging, business logic and other services. Bank B 870 may also communicate with Bank B internal systems 880, via an API based integration and/or HTTP/event bus. Distributed apps 872 may communicate with a quorum node/dB 838 via API 874. Bank B 870 may further implement application boundary 876.

FIG. 9 is an exemplary flow illustrating an electronic exchange for bill pay transactions via IIN, according to an embodiment of the present invention. According to exemplary aspects, IIN may referred to as a check matching system.

At 912, lockbox data may be sent from lockbox providers 910 to lockbox blockchain node 914. Billers may include clients that have few rules and possibility of exceptions. Lockbox data may include addresses and reference data, which may be sent via real-time updates. At 916, reference data transmission may be sent via blockchain to bill pay blockchain node 918.

Application functionality may be deployed on bill pay blockchain nodes and lockbox blockchain nodes. Bill pay blockchain nodes may include API to check print systems; UI to monitor status of transactions and other functionality. In addition, bill pay blockchain nodes may interact with other lockbox nodes only (e.g., no interaction with other bill pay nodes); receive and store lockbox reference data from lockbox nodes; match bill pay and lockbox reference data to identify eligible transactions; parse and transmit bill pay transactions to appropriate lockbox nodes; and receive enriched check print transactions from lockbox nodes indicating transactions that are rejected by lockbox and initiate settlements.

Lockbox blockchain nodes may include API to remittance systems and rules engines; UI to monitor status of transactions and other functionality. In addition, lockbox blockchain nodes may interact with other bill pay nodes only; send lockbox reference data periodically or real-time; store own lockbox reference data; ingest bill pay transactions from other bill pay nodes; transmit bill pay transactions to lockbox rules engine; ingest feedback from rules engine indicating rejected transactions; and transmit enriched check print transmission to appropriate bill pay nodes indicating transactions that are rejected.

At 920, bill pay platform 922 may send check print data, which may occur daily or at other intervals, to bill pay blockchain node 918. For example, an additional channel may be implemented for check print transmission. As shown in FIG. 9, check print data may be sent to IIN app residing on a node via an API automated channel. Node 918 may execute an IIN application.

At 924, IIN app may match the two data sets to determine eligible transactions. At 926, IIN app may flag the IIN eligible transactions, as well as the transactions eligible for settlement via digital coin network 934. At 928, IIN app may create an updated file. At 930, IIN app may parse eligible transactions and transmit the same to lockbox blockchain node 914.

At 932, IIN app may send instructions for issuance, transfer and redemption requests via a digital coin API. Digital coin network 934 may send the updated notification once the funds have settled to bill pay platform 922, via 936, and lockbox providers 910, via 938.

FIG. 10 is an exemplary flow illustrating an electronic exchange for bill pay transactions via IIN, according to an embodiment of the present invention. According to exemplary aspects, IIN may referred to as a check matching system. FIG. 10 demonstrates interactions between bill pay provider 1002, IIN infrastructure 1004 and lockbox service provider 1006. Lockbox providers 1010 may provide biller lockbox address and reference data via real time updates, via 1012. This information may be provided to a lockbox blockchain node 1014 via API. Reference data elements may be represented at 1015, which may include participant identifier, associated addresses (e.g., biller address), lockbox participant central account, DDA, etc. At 1016, reference data may be transmitted via IIN network to bill pay blockchain node 1018.

Bill pay platform 1020 may provide daily check print data at 1022 via API. Data elements 1017 may include biller name (e.g., payee), biller address, amount, payer name, payer reference account, date, bill pay identifier, etc.

Bill pay node 1024 may generate a unique identifier 1026, which may be based on a data element, such as an associated address information, for example. At 1028, bill pay node 1024 may perform a match or lookup that compares data elements. Bill pay node 1024 may then identify and assign an IIN participant indicator to qualifying transactions at 1030. At 1032, check print data may be updated.

At 1034, data transmission to bill pay platform 1020 may include data with flags that identify which transactions require check print and which transactions go through IIN with an indicator that associates a lockbox provider. At 1036, a lockbox file may be created. IIN app on lockbox node may consolidate bill pay transaction data at lockbox blockchain node 1014.

At 1038, bill pay platform 1020 may send non-IIN transactions to check print, via business as usual legacy systems.

At 1042, lockbox blockchain node 1014 may integrate data into lockbox platform 1040. Lockbox rules may be applied at 1044 to determine accepted and rejected transactions. A list or other communication may be sent via 1046 to lockbox blockchain node 1014, via API. At 1048, lockbox blockchain node 1014 may send a list of accepted and rejected transactions to bill pay blockchain node 1018. At 1050, the list may be communicated to bill pay platform 1020. At 1052, a list of rejected transactions may be sent to check print facility 1039. At 1054, a list of accepted transactions may be sent to a settlement process at 1056. The settlement process is illustrated in further detail by FIGS. 11 and 12.

FIG. 11 is an exemplary flow illustrating a settlement flow, according to an embodiment of the present invention. The settlement flow of FIG. 11 illustrates a settlement flow for ACH services. As shown in FIG. 11, bill pay platform 1020 may debit customers' bank accounts. For banks, this may happen at the same (or near same) time as the initiation of the bill pay transaction. At 1054, a list of accepted transactions may be sent to a settlement process at 1056.

At 1112, ACH services 1110 may send a notification of payment initiation to bill pay blockchain node 1018, which communicates to lockbox blockchain node 1014.

At 1118, ACH services 1110 may route an electronic payment (e.g., CTX file) and addendum to lockbox via ACH 1120. ACH 1120 may represent a centralized lockbox deposit account. At 1122, notification of payment initiation may be sent to reconciliation service 1126. At 1124, ACH 1120 may send a notification of payment receipt to reconciliation service 1126. At 1128, payment confirmation may be sent to lockbox platform 1040. At 1132, data may be integrated into lockbox platform 1040. Distribution may be triggered to client accounts at 1134.

FIG. 12 is an exemplary flow illustrating a settlement flow, according to an embodiment of the present invention. The settlement flow of FIG. 12 illustrates a settlement flow for digital checks. As shown in FIG. 12, bill pay platform 1020 may debit customer's bank accounts. For banks, this may happen at the same (or near same) time as the initiation of the bill pay transaction. In addition, debiting a customer's account may or may not happen depending on a bank's model or if it's coming from a third party check originator. At 1054, a list of accepted transactions may be sent to a settlement process at 1056.

As shown in FIG. 12, digital check printing Services 1210 may centrally print images (e.g., 6 or more) on a page than scan these images into an image file, at 1212. Other formats may be implemented. At 1214, image file and data files may be indexed to align each transaction to an image. At 1216, both files may be transmitted to bill pay blockchain node 1018 and lockbox blockchain node 1014. Service 1218 may print check images received from a check originator and then scan those pages into a check image file. IIN may then distribute the data and image files to an identified lockbox provider for which that transaction belongs. According to exemplary aspects, IIN may referred to as a check matching system. Lockbox blockchain node 1014 may send a notification of payment initiation to lockbox platform 1040. Lockbox blockchain node 1014 may distribute assigned transactions and accompanying data and image. At 1220, both files may be transmitted to lockbox platform 1040.

At 1224, data may be integrated into lockbox platform 1040. Image cash letter (ICL) may create an image cash letter using check image files to send for clearing, at 1226.

FIGS. 2-4 and 10-12 illustrate exemplary flows, according to the various embodiments of the present invention. The flows include a representative timing in the form of T+X time, which is illustrative and exemplary and do not intend to limit the invention to a specific timing. The order of flows illustrated in FIGS. 2-4 and 10-12 is merely exemplary. While the processes of FIGS. 2-4 and 10-12 illustrate certain steps performed in a particular order, it should be understood that the embodiments of the present invention may be practiced by adding one or more steps to the processes, omitting steps within the processes and/or altering the order in which one or more steps are performed.

FIG. 13 is an exemplary process flow diagram for performing a digital transmission of a paper check and associated remittance information with exception handling, according to an embodiment of the present invention.

As illustrated in FIG. 13, the system for performing the check matching process includes an originator system or device, a check match system, a lockbox system, and a check print system. According to exemplary aspects, the originator system may include one or more computing devices that may be utilized to initiate a paper check transaction. The check match system may include a server or network of servers configured to facilitate an exchange for electronically or digitally processing paper check transactions, whether they are for purposes of bill payment, payment disbursements, reimbursements and the like. According to exemplary aspects, the exchange may include an electronic exchange and a digital exchange. Although language of electronic processing or electronic exchange may be referenced, aspects of the present disclosure are not limited thereto, such that electronic processing or electronic exchange may include electronic and/or digital processing and electronic and/or digital exchange, respectively.

In an example, the check match system may have the same or a similar system configuration as the IIN. The check print system may be an internal system of printers for performing printing of checks. According to exemplary aspects, the check print system may include both (i) specialized check printers that may utilize specialized printer ink, such as magnetic ink character recognition (MICR) ink or toner, and/or ANSI conforming paper (e.g., at least 20-pound long grain with paper moisture content being between 4.7 to 5.5%) for printing of paper checks that may be durably be handled by mechanical sorters and recognized by commercial check readers, and (ii) ordinary printers that may utilize ordinary (i.e., non-MICR) printer ink and/or ordinary paper (i.e., non-ANSI conforming) for printing of check images, which may not be recognized by a commercial check reader and unable to withstand physical handling by mechanical sorters. In an example, the ordinary print ink may include carbon black ink, and non-ANSI conforming paper may include paper that does not include at least 20-pound long grain with paper moisture content being between 4.7 to 5.5%.

In step 1301, the lockbox system submits reference data to the check match system. According to exemplary aspects, reference data may include, without limitation, one or more of participant identifier, address, city, state, P.O. Box, zip code and the like. In an example, the reference data may be sent as a batch file, at regular intervals to include updates, and/or in real-time to reflect any changes to the reference data.

In step 1302, the check match system consolidates or otherwise combines the received lockbox reference data into a lockbox directory. According to exemplary aspects, the lockbox directory may be stored at the check match system. However, aspects of the present disclosure may not be limited thereto, such that the lockbox directory may be stored at another location or system.

In step 1303, the originator system pulls the lockbox directory from the check match system. In step 1304, the originator system performs upfront matching to flag check match system eligible transactions. For the ineligible transactions, such transactions may be handled by a traditional check printing process, which utilizes MICR ink or toner and ANSI conforming paper. For the eligible transactions, the process proceeds to step 1305.

In step 1305, a check print/image file or data may be created and stored for the check system eligible transactions. However, aspects of the disclosure are not limited thereto, such that the check print/image file or data may be stored in different formats.

In step 1306, the originator system submits the pre-matched transactions (i.e., check match system eligible transactions) to the check match system. According to exemplary aspects, one or more of the submitted pre-matched transactions may include a flag indicating whether if the respective transactions include data only or whether an image data or file (e.g., check image and remittance information, or a print file) is provided in the data fields.

In step 1307, the check match system validates the pre-matched transactions and updates a status for each of the pre-matched transactions. For example, the status for the pre-matched transaction may indicate that the transaction has been created. In response to the validation performed by the check match system, the check match system may further transmit real-time indication of validation processing completion to the originator system and the check print system.

In step 1306a, the originator system receives the real-time acknowledgement of validation completion from the check match system. Contemporaneously, the check print system acquires or pulls the matched transaction from the check match system in step 1308. Although the check print system is described as pulling the matched transaction, aspects of the present disclosure are not limited thereto, such that the match transactions may be pushed by the check match system to the check print system.

In step 1309(1) of step 1309, the check print system retrieves or receives from the originator system, the print/image file or data for transactions flagged as including the image data or file. In step 1309(2) of step 1309, the check print system further transmits the acquired print/image file or data to a component of the check print system for further processing. According to exemplary aspects, step 1309(1) may be performed contemporaneously with step 1309(2). However, aspects of the present disclosure are not limited thereto, such that the step 1309(1) and step 1309(2) may be performed in sequence.

More specifically, in step 1310, the check print system performs further processing of the acquired print/image file or data for splitting check data from the remittance data. More specifically, the check print system identifies only the check data to be printed and subsequently scanned, whereas remittance data or files may be stored for further processing.

In step 1311, the check print system performs a printing operation for the acquired print/image file or data. According to exemplary aspects, the printing operation may be performed using any ordinary ink that is capable of printing and/or using ordinary (i.e., non-ANSI conforming) printing paper. More specifically, the printing operation may be performed using non-MICR ink that is conventionally required for processing of checks. In an example, the image file or data may include an image of a check. Once the image file or data is physically printed on a paper using ordinary ink, the paper printed image may then be scanned to capture an image of the printed image. At least since scanned image for electronic processing does not require specialized ink for processing of the scanned image, an ordinary printer may be utilized without any special equipment. Accordingly, printing operation of such transactional instruments (e.g., checks) may be more easily achieved without the requirement of any specialized equipment or materials thereby increasing scaling efficiencies of such processing.

In step 1312, the lockbox system pulls transaction data, scanned check image, and corresponding remittance data. Further, the lockbox system updates its status after pulling of such information. Although the lockbox system is described as pulling the above noted information, aspects of the present disclosure are not limited thereto, such that the check print system may push such information to be received by the lockbox system.

In step 1313, the lockbox system checks the information obtained in step 1312 against lockbox rules using the lockbox rules engine. According to exemplary aspects, the lockbox rules engine may determine that the obtained information including the scanned check image may be eligible or ineligible for digital processing or conveyance. If the obtained information including the scanned check image is determined to be eligible for digital processing or conveyance, the lockbox system marks the respective transaction as being accepted for processing in step 1315. Alternatively, if the obtained information including the scanned check image is determined to be ineligible for digital processing or conveyance, then a request to perform substitute check printing and mailing operation may be transmitted to the check print system in step 1314. According to exemplary aspects, the substitute check may be printed using specialized ink (e.g., MICR ink or toner) and specialized paper (e.g., ANSI conforming check print paper), and mailed to a respective recipient.

In step 1316, the accepted status for the digital processing or conveyance is communicated to the originator system for updating the status transaction, which may also be communicated or displayed to a participating paper check transaction originator or a participant of the originator system.

FIG. 14 is an exemplary system flow diagram illustrating a method for performing a digital remittance of a paper check and associated remittance information with exception handling, according to an embodiment of the present invention.

In step 1401, a lockbox (lbx) client submits reference data to a check match system. In step 1402, check match system consolidates the reference data into a lockbox directory. In step 1403, an originator client pulls or otherwise obtains the lockbox directory from the check match system. In step 1404, the originator client uses the lockbox directory to indicate and flag check match system eligible transactions (txs). In step 1405, the originator client will generate and store check and remittance image file. In step 1406, the originator client submits eligible transactions to the check match system differentiating between data only or including an image (data or field).

In step 1407, the check match system validates the transactions indicated as being eligible by the originator client, and creates a matched transaction. According to exemplary aspects, a matched transaction may be created using P.O. Box and Zip Code information. However, aspects are not limited thereto, such that the matched transactions may be created using other data fields or information.

In step 1408, the check match system rejects any transaction that are deemed ineligible for check match system processing, and accepts the remaining transactions as being eligible for digital processing or conveyance. According to exemplary aspects, the check match system ineligible transactions may include, without limitation, any transaction that fails validation, business rules, and/or check match matching operations. In step 1408(a), transactions not eligible for check match system processing are sent to the originator client for performing check printing operations. According to exemplary aspects, the originator client may perform the check printing operation itself or send the transaction to a check printing facility. The check match system ineligible transactions may be printed by a specialized check printing machine using MICR ink and ANSI standard conforming paper.

In step 1409, the check print system pulls matched or created transactions for digital processing or conveyance from the check match system. According to exemplary aspects, check print system may be a part of the check match system or may be a separate entity or system.

In step 1410, for transactions with image provided flag, the check print system calls its API to download the image file or data from the originator client.

In step 1411, the check print system splits the check image data or file from the remittance data. The separated remittance data is then stored for subsequent transmission while the check image data or file is printed. Once the check image data or file is printed, it is subsequently scanned to produce a scanned check image for performing digital processing or conveyance.

According to exemplary aspects, the printing step of step 1411 may be performed using any ordinary ink that is capable of printing and/or using ordinary (i.e., non-ANSI conforming) printing paper. More specifically, the printing operation may be performed using non-MICR ink that is conventionally required for processing of checks. In an example, the image file or data may include an image of a check. Once the image file or data is physically printed on a paper using ordinary ink, the paper printed image may then be scanned to capture an image of the printed image. At least since scanned image for electronic processing does not require specialized ink for processing of the scanned image, an ordinary printer may be utilized without any special equipment. Accordingly, printing operation of such transactional instruments (e.g., checks) may be more easily achieved without the requirement of any specialized equipment or materials thereby increasing scaling efficiencies of such processing.

In step 1412, the check system provider updates a status of the respective transaction to reflect the printed state of the check. In step 1413, the lockbox client pulls, or otherwise obtains, transaction data payload with the updated transaction status. In step 1414, the lockbox pulls, or otherwise obtains, check images using an identifier (e.g., reference ID or refID) of the transaction included in the transaction data. In step 1415, the lockbox client pulls remittance image file, which is separated from the printed check image file, using the identifier, such as the refID, of the transaction included in the transaction data. In step 1416, image collection receipt is then transmitted from the lockbox client to the check print system.

In step 1417, the lockbox client applies the lockbox rules engine to the transaction data payload acquired in step 1413 and the check images acquired in step 1414 to determine whether the corresponding transaction may be digitally processed or not. If the transaction is eligible to be digitally processed, the method proceeds to step 1418a, in which the lockbox client sends terminal transaction status. In an example, the transaction status may include, without limitation, post, bill pay, close, and the like. On the other hand, if the transaction is ineligible to be digitally processed, the method proceeds to step 1418b, in which the lockbox client requests the check print system to print and mail a paper check for the ineligible transaction. In response to such request, the check print system in step 1418c prints and mails the printed check or remittance to the corresponding recipient. According to exemplary aspects, the check printed in step 1418b may be printed using specialized ink (e.g., MICR ink or toner) and specialized paper (e.g., ANSI conforming check print paper), and mailed to the respective recipient.

Moreover, in step 1418d, the lockbox client may obtain the transaction by the status or the reference ID. In step 1418e, the check match system transmits a notification indicating that the terminal status is available to the original client. In step 1419, the original client pulls transaction terminal status from the check match system. In step 1419a, the original client obtains transaction recon by status and time zone.

Although all of the steps are illustrated in FIG. 14, one or more of step 1414, step 1416, step 1418c, step 1418d and 1419a may be optionally executed or omitted.

The foregoing examples show the various embodiments of the invention in one physical configuration; however, it is to be appreciated that the various components 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. Thus, it should be appreciated that the components of the various embodiments may be combined into one or more devices, collocated on a particular node of a distributed network, or distributed at various locations in a network, for example. As will be appreciated by those skilled in the art, the components of the various embodiments may be arranged at any location or locations within a distributed network without affecting the operation of the respective system.

Those skilled in the art will appreciate that the system diagrams discussed above are merely examples of an electronic exchange system and are not intended to be limiting. Other types and configurations of networks, servers, databases, mobile devices, and personal computing devices (e.g., desktop computers, tablet computers, mobile computing devices, smart phones, etc.) may be used with exemplary embodiments of the invention. Although the foregoing examples show the various embodiments of the invention in one physical configuration; it is to be appreciated that the various components 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. Thus, it should be appreciated that the components of the various embodiments may be combined into one or more devices, collocated on a particular node of a distributed network, or distributed at various locations in a network, for example. The components of the various embodiments may be arranged at any location or locations within a distributed network without affecting the operation of the respective system.