Patent Application
20070255651
A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The present invention relates generally to electronically processing financial transactions and more specifically to improving batch processing techniques for processing a plurality of related electronic payments as a single transaction.
In processing systems relating to financial transactions, one common advantage is batch processing operations. These operations allow for the consolidation of a large number of financial transactions to a similar account. For example, if a business receives a large number of deposits to a payment account, it can be onerous to process each payment individually. In one example, a business such as an electrical utility company may have monthly bill payments from the large number of utility customers. The business receives a significant volume of checks or other types of payments on a daily basis, for example credit or electronic debt transactions. These payments are collected by the financial institution that is servicing the account of the business.
In previous systems, each payment presented to the financing institution would need to be individually processed, which is not only time consuming but also complicated for the accounting system recording and maintaining the large number of payment entries. In existing batch processing systems, similar payments are bundled together for a single payment. Using the example of a utility company, the financial institution may compile all of the day's payments into a single batch. This batch, containing anywhere from a couple to hundreds to potentially thousands of payments, is then presented to the business in a single batch which contains the details of each single payment.
If the financial institution were to process several thousand payments on any single day, batch processing would allow for those single payments to be processed as a single one-time batch payment. This one-time payment would be recorded in the accounting system as a single data entry field.
The existing batch processing techniques can be problematic when there are issues with one or more of the payments included in the batch. While the batch itself may include an itemized list of payments, the accounting system processes the batch in a single transaction.
For example, one common problem with a debit payment to the account of the business may be insufficient funds on the account of the business. If the business is issuing checks to pay bills and the debit entries on their account are processed within a batch the financial institution should not cash the checks there is not enough funds on the account of the business when the checks are presented to the bank. In common parlance, the check will bounce because the bank will not honor the check. In this scenario, the bank takes a risk if due to the batch processing of multiple checks each check is not checked against the available amount on the account before the check is accepted and processed within the batch. The bank risks that it will cash checks where there are no funds available. This could potentially cause a loss if the business is not able to cover the overdraft.
In another example, a business might have placed a hold or other type of restriction on the payment. For example, in common parlance there might be a stop-payment placed on the check itself. In this case, the payment will be erroneously processed as part of the batch. As in the above case, because the payment has been initially processed without a detection of problems associated with the payment, the bank will have to offer credit to the business to cover the processed check that should have been blocked.
It is commonplace for the existing systems in financial institutions to operate using both a payment system and an account management system. The payment system may process the individual payments or credits for submission to the account management system. The payment system can then bundle like transactions for the above-mentioned bundled transaction. In these systems, the bundling being performed in the payment system contributes to the problem. The account management system is primarily designed for processing the transactions including the ability to perform troubleshooting operations when problems arise. Using the two above-noted examples of overdraft and stop payments on a check, the account management system operates to process the payment and to ensure the functionality to prevent overdraft or stop payment transactions. Therefore, the existing systems are extremely limited in the ability to both bundle the payments and to prevent the erroneous processing of payments that cannot or should not be processed as part of a bundle.
A payment system of a payment processing system includes additional functionality and the ability to perform additional operations allowing for single-entry batch processing within an account management system. Through the inclusion and operation of various pre-closing operations, the payment system can overcome the above-noted shortcomings associated with batch processing operations, including problems associated with processing unauthorized payments or payments that would exceed an account limit. Additionally, through the batch process, the account management system manages a single batched payment entry, thus reducing the number of account postings and administration concerns in the account management system.
As illustrated in
In one embodiment, the payment system 102 and the account management system 104 may be incorporated within existing financial software packages. Additionally, these systems 102 and 104 may also be stand alone processing applications or processing devices. The systems 102 and 104 are in operative communication with each other across a connection, shown generally at 106. This connection may be a local physical connection, may be internal processing connections if the systems are incorporated on the same processing environment, the connection may be across a local area network, wide area network or any other type of networked connection.
In one embodiment, the payment system 102 receives data representing a plurality of payments 108. These payments 108 might be received from, for example, a clearing system (Automated Clearing House), from another banking application, from a lock box provider, from user entry or other suitable input sources. The payments 108 include, among additional information, a financial amount, an account identifier and an indication of whether the payment is a credit payment or a debit payment. In one embodiment, the credit payment is a positive amount indicating a credit is to be applied to the indicated account and the debit payment is a negative amount indicating a debenture amount to be withdrawn from the indicated account.
In one embodiment, the payment system 102 sorts the payments 108 by the payment type. If the payment is a credit payment, the credit payment is written to a credit bundle (not shown) associated with the indicated account. If the payment is a debit payment, the payment system 102 performs a booking simulation 110 with the account management system 104. The booking simulation 110 is similar to a normal booking operation with the account management system, except the account management system does not actually book or close the transaction. The simulation 110 allows the account management system 104 to simulate booking the transaction to determine if the debit payment would be accepted. For example, if the debit payment was a check and the payee has placed a stop payment on the check, the account management would detect if a stop payment is in place.
Based on this simulated booking 110, the account management system 104 provides a yes or no indicator 112 to the payment system 102. If the simulation 110 indicates the debit payment would be processed, the payment system 102 adds the debit payment into a debit bundle (not shown) associated with the indicated account. If the account management system 104 indicates, through the simulation 110, that the debit payment would not be accepted, the payment system 102 may sort the corresponding debit payment into a temporary buffer or choose to book the single debit payment on the account and let the account management system reject the payment.
Once all of the payments 108 have been processed, the payment system 102 may thereupon perform several bundle processing operations 114. A first bundle operation is to process the credit bundle. Processing the credit bundle first allows for the account management system to include the applicable credits before the debit bundle is processed.
In closing the debit bundle, the system 100 determines if the associated account has the financial reserves to cover the bundle transaction. In one embodiment, this may be performed by the payment system 102 communicating with the account management system 104 to verify the financial reserves of the associated account.
In the event the debit bundle would exceed the financial reserves, this would mean that if the bundle was processed, the account management system 104 would either have to reject the complete bundle or the underlying financial entity would have to extend credit to the payee to cover such overdraft. The payment system 102 is operative to remove debit payments until the bundle itself is below the financial reserves. In one embodiment, the payments are removed in a simple first in last out process.
Once the credit bundle is below the financial reserve, the payment system performs another bundle processing operation 114. In the account management system 104, the bundle may then be properly processed. In the account management system 114, the single bundle is listed as a debit entry, reducing accounting overhead. The bundle can also be processed with the assurance that the bundle does not include rejected or blocked payments and the processing of the bundle will not require the payee to be extended credit to a payee.
As further illustrated in
In the embodiment of
Through the payment system 102, the bundle 126 is provided in a single transaction to the account management system 104, as illustrated by the account entry of $600. In this embodiment, the account management system 104 thereupon logs the single $600 credit entry instead of three separate entries. It is also recognized that the payment system 102 operates with any suitable number of payments and as such the bundle may include hundreds, thousands or more credit entries provided as a single transaction to the account management system 104.
The account management system 104 includes the account information for account 12345 and indicates a starting balance of $500. Back in the payment system 102, the payments 130, 132 and 134 are provided to a debit bundle 136, which may be similar to the credit bundle 126 of
Therefore, in this embodiment because the full combination of all payments 130, 132 and 134 (combined total of $600) exceeds the full reserve ($500) in the account management system 104, debit payments are removed until the bundle 136 includes a sum of payments below the account reserve. In this embodiment, a first in last out technique is utilized, therefore the payment 134 is removed from the bundle 136. Without payment 136, the bundle amount is $300 and can be processed 138 as a single transaction, leaving a remaining balance of $200 in the account. Then, the payment system 102 may separately process the third payment 134 so that payment may be properly rejected as exceeding the reserve.
In the account management system 104, account 12345 is illustrated as having a beginning balance of $150. In this embodiment, a first transaction 150 is processing the credit bundle 126. This thereupon insures the account has all applicable credits before processing any debit transactions. Thus, as illustrated in the account management system, the account is credited $200 giving a balance after the first transaction of $350.
The second processing step in this embodiment is to thereupon process 152 the debit bundle 136. Thus, the debit bundle amount of $300 is removed from the account, giving a remaining balance of $50. Had the order of the transactions been reversed, the debit bundle 136 would have been rejected as exceeding the reserve because the account balance without applicable credit would have been less than the debit bundle 136 amount. As with the other embodiments described above, the illustrated example shows three sample payments, but the payment system 102 is operative to process a significant volume of payments, thereby performing the above-described operations on any number of transactions and associated transaction values.
The next step, step 164, is to determine if the payment would have been accepted, based on the determination in step 162. If the payment would not have been accepted, this may indicate that a stop payment has been placed on the debit payment and it should not be included in a bundled transaction. Therefore, if the payment is not accepted, the next step is to not add the debit payment to the debit bundle, step 166. In one embodiment, as described in further detail below, the debit payment may be assigned to an individual processing bundle or other storage device as appropriate.
In the event the debit payment is acceptable, the next step, step 168 is to add the debit payment to the debit bundle. Steps 162-168 are repeated for all debit payments associated with the associated account. Thereupon, once all the payments have been processed for inclusion in or exclusion from the debit bundle, the next step, step 170 is to determine if the account in the account management system has enough reserves to the cover the debit bundle. If the reserve is not available, the next step, step 172, is to remove the last entered debit payment into the bundle. The process with regards to step 170 is repeated until the reserve is available, including continuing to remove debit payments from the debit bundle. Not specifically illustrated in the flow chart of
Once the reserve is available in step 170, the next step, step 174 is to process the payment bundle as single financial transaction. As described and illustrated above, this provides the processing of a single accounting transaction in the account management system. The next step, step 176, is to then process the individual payments that were either excluded from the bundle or included but later removed from the bundle. In this step, the account management system may then properly process the payments that are to be rejected. This then insures that the single transaction from the credit bundle is properly processed and the remaining transactions will not be improperly processed by the account management system. Thereupon, in this embodiment, the method is complete.
In one embodiment, the processing operations of the payment processing system of
The next step, step 242, is sorting the payments by parsing the credit payments into a credit bundle. Referring back to
The next step of the method, step 250, is performing a simulated posting from the payment system to the account management system for each debit payments. With reference to
If the simulated posting is not acceptable, step 254, the next step is to write the debit payment to an individual posting bundle, step 256. As illustrated in
Whether the debit payment was written to the debit bundle or the individual posting bundle, the next step, step 264, is providing the credit payments in the credit bundle to the account management system so that the credit bundle is processed as a single transaction. In
The next step, step 270, is to determine if the identified account in the account management system 104 includes an acceptable reserve to cover the debit bundle amount. As illustrated in
If the answer to step 270 is negative, the next step, step 276, is to remove debit payments until the account reserve can cover the debit bundle. In
If the reserve is not met, either through decision step 270 or through the removal step of 276, the next step, step 284 is to process the debit bundle as a single financial transaction in the account management system. In the payment system 102 of
The next step, step 288, is posting the individual debit payments to the account management system 104. As illustrated in
Through the above-described operations, the payment system allows pre-processing operations to facilitate proper batch processing of payments. The pre-processing operations allow for the detection of payments that would be rejected and payments which would cause the account management system to exceed an account reserve. Through these operations, the payment system may then effectively insure the batch processing operations will result in the batched transaction being accepted in the account management system. Additionally, the system allows for the follow-up processing of the troubled payments such that the account management may effectively process all payments and handle the blocked or overdraft transactions separate from the bundled transaction. The assurance of a properly processed bundled transaction further allows for the reduction in the overhead of the account management system as the batch processes are insured to be properly processed and can reduce the number of account transactions for multiple payment processing.
Although the preceding text sets forth a detailed description of various embodiments, it should be understood that the legal scope of the invention is defined by the words of the claims set forth below. The detailed description is to be construed as exemplary only and does not describe every possible embodiment of the invention since describing every possible embodiment would be impractical, if not impossible. Numerous alternative embodiments could be implemented, using either current technology or technology developed after the filing date of this patent, which would still fall within the scope of the claims defining the invention.
It should be understood that there exist implementations of other variations and modifications of the invention and its various aspects, as may be readily apparent to those of ordinary skill in the art, and that the invention is not limited by specific embodiments described herein. It is therefore contemplated to cover any and all modifications, variations or equivalents that fall within the scope of the basic underlying principals disclosed and claimed herein.
