Automated trustee payments system

The present automated trustee payments system implements a series of automated processes which significantly reduce, and in many cases, eliminate a creditor user's work that is required to accurately and timely process incoming Chapter 13 Trustee remittances. The automated trustee payments system also effects application of the funds to the proper bankrupt debtor accounts and accounts for the funds against the proper creditor's loan account segments (e.g., the bankruptcy estate pre-petition indebtedness or the post-petition ongoing payments).

BACKGROUND

The conventional processing of payments from Chapter 13 Trustees to a creditor can often be time-consuming and error prone due to the need to cross-reference numerous entries on a given remittance check to locate the correct loan and debtor loan data on the creditor's internal systems and properly identify the nature of the payment. New systems are desired to reduce a creditor's workload while improving accuracy and timeliness of the remittance processing and properly identify the nature of payment being remitted with regard to pre-petition indebtedness, post-petition payments, and/or applicable fees.

SUMMARY

The present automated trustee payments system implements a series of automated processes which significantly reduce, and in many cases, eliminate a creditor user's work that is required to accurately and timely process incoming Chapter 13 Trustee remittances. The automated trustee payments system also effects application of the funds to the proper bankrupt debtor accounts and accounts for the funds against the proper creditor's loan account segments (e.g., the bankruptcy estate pre-petition indebtedness, interest on a claim, or the post-petition ongoing payments).

In various illustrative examples, the automated trustee payments system enables automated logging of the check's receipt and tracking its disposition by capturing the salient check information from the minimum data amount required to be input, for example by retrieving, parsing, and storing the check voucher data automatically from the Trustees' data repository, and queuing it for processing.

The automated trustee payments system may further enable automated cross-referencing of each remittance item to internal loans using Trustee case record identifiers, avoiding the requirement for a user to make inquiries to the Trustees' data repository for each remittance item on the Trustee's check, or make inquiries to the creditor's loan system for each remittance item on the Trustee's check, or needing to compare the two systems' data and assess the cross-reference of the case and claim data elements against the possible loan data elements, or make a determination of the correct case-to-loan reference from the possible loans. For example, an automated system-to-system interface is typically implemented to retrieve each remittance item's case and claim information and to interface with and interrogate the user's loan system and to analyze and rate matches of case information to loan information based on multiple-system, multiple loan borrower and loan status based business rules, and queuing each remittance item for processing.

The automated trustee payments system may further enable automated determination of the proper application or alternate disposition of each remittance item to the proper loan account segment, avoiding the requirement for a user to analyze the Trustee's claim data to determine whether the remittance item is for a pre-petition plan payment, a post-petition ongoing loan payment, interest on the claim, or for a post-petition fee based on identifiers which are vague, ambiguous, and/or inadequate to effect proper determination, or needing to timely and correctly calculate claimed and ongoing loan fees and loan payments to be applied from the remittance items in combination with suspensed funds (from prior partial receipts). For example, an automated system-to-system interface may be implemented to interrogate the user's loan system to determine suspensed debtor funds, suspensed Trustee funds, claimed and unpaid fees, interest on claims, claimed and unpaid delinquent loan payments, unpaid post-petition fees, unpaid post-petition loan payments, analyzing the remittance item and its voucher descriptions along with Trustee case and claim information and making the calculation of fee and payment applications based on multiple-system, multiple loan borrower, loan status indicator and case/claim status indicator based business rules and queuing each item for further processing.

The automated trustee payments system may further enable automated routing, review, analysis, disposition, tracking and alternate-routine processing of exceptions in all categories, with re-entry to processing paths. For example, exception handling for out-of-balance checks or unretrieved checks is supported. In addition, the system supports an escalation feature so that any item presented to a user may be selected for an additional higher level reviews.

The automated trustee payments system may further enable automated application of each payment's component to each loan account, avoiding the requirement for a user to make multiple-step, often time-constrained multiple-day payment application entries to the loan account, or make update entries to the loan's ledger(s) for the pre-petition, post-petition, and full contractual loan histories. For example, an automated system-to-system interface may be implemented to execute payment and update transactions to the user's loan system and alternate application exception re-processing of payment application transactions due to post-analysis pre-application loan system status changes based on business rules. Such interface can advantageously enable automated handling of conflicting activities.

The automated trustee payments system may further enable automated support of daily remittance balancing, avoiding manual batch tallies and control log entries. The automated trustee payments system may further enable automated handling of transactions involving inter-company fund transfers to areas associated with portfolios that are typically handled separately and funds returns that are determined not be processed by any area.

The automated trustee payments system may further enable automated tracking of the each remittance item's disposition, avoiding the manual entry of all the remittance advice information (e.g., by only entering a check number, amount, date, and payor).

The automated trustee payments system may further enable self-check and follow-up when a voucher entry disposition includes one or more payment applications to ensure proper post-application loan condition and status are verified, and exceptions are presented to the user for disposition or further processing, for example, by decision or additional entries.

The automated trustee payments system may further implement a self-learning function in which, as exceptions are resolved and/or as actions are validated, the system “learns” the characteristics of the payment (pre-/post-/fees, cross-referenced system/loan and application route) and, based on the user's configuration, applies the end-state to the next processing of a payment for the same case and claim with the same identifiers, thus eliminating redundant handling of exceptions or validations. The configuration supports a multiple-affirmation threshold limit before auto-applying the prior decision. Prior to the satisfaction of the threshold, the system will present the subsequent exception or validation items with the prior dispositions noted for reference. If the threshold has not been met and a subsequent user action contradicts a prior, then the user is presented with a decision—reset prior event learning for the case/claim remittance item or a one-time variance and don't count against the threshold.

The automated trustee payments system may further implement user-configurable review-level threshold settings, auto-processing thresholds and secondary-review settings. This feature enables the remittance items to be, based on characteristics, routed for human review only when needed based on variable characteristics and further enables management control of changes, deviations from tolerances, and the like.

DETAILED DESCRIPTION

FIG. 1shows an illustrative computing environment2in which the present automated trustee payments system may be implemented. The environment includes a client computer5that is operatively connected to a network such as the Internet10. The Internet connection facilitates communication with an automated trustee payments system15that exposes various features, capabilities, and functionalities via web services to the client computer5. A trustee data repository20, for example a National Data Center site, a client loan system25, and a remote database27are also located in the computing environment2, as shown.

The present automated trustee payments system is further described in the flowcharts and screen captures shown in the drawings. More particularly,FIGS. 2A, 2B and 2Cshow a flowchart of a first illustrative method200in which remittance checks from a bankruptcy trustee are processed. Unless specifically stated, the methods or steps shown in the flowcharts and described in the accompanying text are not constrained to a particular order or sequence. In addition, some of the methods or steps thereof can occur or be performed concurrently and not all the methods or steps have to be performed in a given implementation depending on the requirements of such implementation and some methods or steps may be optionally utilized.

Step205in method200comprises creating a processing worklist from the remittance check data. Step210comprises navigating to a web-based trustee data repository system. Step215comprises executing a login to the trustee data repository system. Step220comprises capturing the login response from the trustee data repository system. Step225comprises assessing the captured response to verify success of the login.

If the login is unsuccessful, then step230comprises re-performing the steps of executing and capturing the login. Step235comprises navigating to a voucher page on the trustee data repository system. Step240comprises capturing a response to the voucher page navigation. Step245comprises assessing the captured response to verify that the navigation to the correct page was successful.

If the navigation was unsuccessful, then step250comprises re-performing the steps of if navigation unsuccessful, re-performing steps of navigating to the voucher page and capturing the response. Step255comprises executing a voucher search. Step260comprises capturing a response to the voucher search. Step265comprises assessing the captured response. Step270comprises executing a voucher download.

Step270comprises capturing a response to the voucher download. Step280comprises assessing the captured response. Step285comprises saving data from the voucher download. Step290comprises generating a remittance item worklist and step295comprises summing entries in the worklist.

FIGS. 3-13respectively show various illustrative screen captures300,400,500,600,700,800,900,1000,1100,1200, and1300of sources of information that are accessed as the first illustrative method200described above is practiced.

FIGS. 14A, 14B, 14C and 14Dshow a flowchart of a second illustrative method1400in which remittance checks from a bankruptcy trustee are processed and associated details are retrieved. Step1402comprises receiving input from a client. Step1404comprises creating a processing worklist. Step1406comprises navigating to a web-based trustee data repository system. Step1408comprises executing a login to the trustee data repository. Step1410comprises capturing the response to the login. Step1412comprises assessing the captured response to verify the success of the login. If the login was unsuccessful, the step1414comprises re-performing the steps of executing and capturing the login.

Step1416comprises executing a case search. Step1418comprises capturing a response to the case search. Step1420comprises assessing the captured response to verify that the correct case was retrieved. Step1422comprises navigating to a case summary page. Step1424comprises capturing a response to the case summary page navigation. Step1426comprises assessing the captured response to verify that the navigation to the correct case summary page was successful. If navigation was unsuccessful, then step1428comprises re-performing the steps of navigating to the case summary page and capturing the response.

Step1430comprises storing results data from the case summary page. Step1432comprises parsing the stored results data. Step1434comprises navigating to a claim summary page. Step1436comprises capturing a response to the claim summary page. Step1438comprises assessing the captured response to verify that navigation to a correct account ledger page with a correct case was successful. Step1440comprises storing results data from the claim summary page. Step1442comprises parsing the stored results data to create claim data elements populated into processing database and appending results.

Step1444comprises navigating to a remittance item claim on the claim summary page. Step1446comprises capturing a response to the remittance item claim navigation. Step1448comprises assessing the captured response to the remittance item claim navigation to verify that navigation to correct remittance item claim was successful. Step1450comprises storing results data from the remittance item claim and step1452comprises parsing the stored results data to create remittance item claim data elements populated into processing database.

FIGS. 15-20respectively show various illustrative screen captures1500,1600,1700,1800,1900, and2000of sources of information that are accessed as the second illustrative method1400described above is practiced.

FIGS. 21A and 21Bshow a flowchart of a third illustrative method2100in which data is retrieved from a client loan system and processed. Step2102comprises performing an automated login to a client loan system. Step2104comprises executing an inquiry to the client loan system. Step2106comprises utilizing processing rules and criteria to implement multiple-pass searches for data to cross reference. Step2108comprises storing results data from the retrieved presented data. Step2110comprises parsing the stored results data. Step2112comprises assessing the validity of the stored results data. Step2114comprises executing analyses to determine a creditor asset basis. Step2116comprises executing analyses to determine a discreet loan match or multiple possible loan matches. If multiple possible loan matches are indicated, then step2188comprises presenting the result on the user interface.

FIGS. 22-26respectively show various illustrative screen captures2200,2300,2400,2500, and2600of user interfaces that are displayed on a client computer as the third illustrative method2100described above is practiced.

FIGS. 27A and 27Bshow a flowchart of a fourth illustrative method2700in which data is retrieved from a client loan system and processed. Step2702comprises performing an automated login to a client loan system. Step2704comprises executing an inquiry to the client loan system. Step2706comprises utilizing processing rules and criteria to acquire detailed loan information. Step2708comprises storing results data from the retrieved presented data. Step2710comprises parsing the stored results data. Step2712comprises assessing the validity of the stored results data. Step2714comprises executing analyses to determine if the remitted item is a pre-petition plan payment. Step2716comprises executing analyses to determine payment applications and updates and step2718comprises presenting results of analyses in an online user interface.

FIG. 28shows an illustrative screen capture2800of a user interface that is displayed on a client computer as the fourth illustrative method2700described above is practiced.

FIG. 29shows a flowchart of a fifth illustrative method2900in which collected case, claim, and loan data elements are analyzed using logical comparison and fractal analyses to determine eligibility for payment application decision-making. Step2902comprises accessing a client loan system to retrieve and store results data. Step2904comprises parsing stored results data. Step2906comprises executing iterative analysis routines. Step2908comprises flagging remittance item worklist entries determined eligible. Step2910comprises presenting exceptions. Step2912comprises flagging remittance item worklist entries that are determined as being ineligible. Step2914comprises iterating exceptions until no remaining exception conditions are evident.

FIG. 30shows an illustrative screen capture3000of a user interface that is displayed on a client computer as the fifth illustrative method2900described above is practiced.

FIGS. 31A and 31Bshows a flowchart of a sixth illustrative method3100in which payment applications are made to a loan and loan fields are updated in records held in a client loan system. Step3102comprises connecting to client loan system. Step3104comprises executing inputs through an API (application programming interface) or web services. Step3106comprises capturing results. Step3108comprises validating success of each payment application input entry. Step3110comprises storing results of the validating step. If the payment application routine is successful, the step3112comprises marking the status as complete.

If any payment application input routine has an unsuccessful result, then step3114comprises resetting remittance item worklist status to incomplete. Step3116comprises executing analyses of remittance items. Step3118comprises analyzing a remittance item aggregate worklist. Step3120comprises determining any required alternate payment application routines. Step3122comprises re-executing payment applications. Step3124comprises performing iterations until all remittance item worklist entries achieve a status of being complete. Step3126comprises generating payment application or non-application reports.

FIG. 32shows a flowchart of a seventh illustrative method3200in which daily balancing of check remittances is controlled. Step3202comprises maintaining a hierarchal association. Step3404comprises maintaining remittance item processing status. Step3406comprises maintaining check processing status, and step3408comprises performing a drill down.

FIGS. 33-37respectively show various illustrative screen captures3400,3500,3600, and3700of user interfaces that are displayed on a client computer as the seventh illustrative method3200described above is practiced.

FIG. 38shows a flowchart of an eighth illustrative method3800in which detailed data elements, processing paths, intermediate and final statuses, user entries, and user comments are maintained as a detailed supplement to loan processing records for audit purposes. Step3802comprises enabling an online inquiry and step3804comprises providing search result population and data.

FIGS. 39A and 39Bshow a flowchart of a ninth illustrative method3900for performing a self-check and follow-up when a voucher entry disposition includes one or more payment applications to ensure verification of proper post-application loan condition and status. Step3902comprises working from a post-application follow-up worklist. Step3904comprises connecting to a client loan system. Step3906comprises executing a login or connection. Step3908comprises executing an inquiry using APIs or web services. Step3910comprises storing results data. Step3912comprises executing comparisons and analyses. If a result of the executing is that expected client loan conditions and data is present, then step3914comprises performing tagging as appropriate.

If a result of the executing is that expected client loan conditions and data is not present, then step3916comprises performing tagging as appropriate. Step3918comprises presenting an entry in an online user interface.

FIGS. 40-43respectively show various illustrative screen captures4000,4100,4200, and4300of user interfaces that are displayed on a client computer as the ninth illustrative method3900described above is practiced.