AU2009202196B2 - Loan portfolio management and automatic loan repayment method and system - Google Patents

Abstract

LOAN PORTFOLIO MANAGEMENT AND AUTOMATIC LOAN PAYMENT METHOD AND SYSTEM A method and system is disclosed for a financial institution lender to manage a portfolio of loans and perform automatic loan repayment thereon. The repayment of the loan is made automatic when, upon a risk analysis of the merchant borrower's card transactions, a correlation is drawn between each merchant's card transaction activity processed through the bank lender's card 10 processing facilities and the merchant's ability to repay the loan with the bank lender. The information is integrated from the card transaction business systems within the bank lender and applied to the loan repayment management process within the bank lender for risk analysis of the merchant's ability to repay the loan. If it is determined upon analysis that the risk is high or greater than had been envisaged, all or a portion of the settlement payment is applied to reduce 15 the obligation owed by the merchant borrower to the bank lender. OBTAIN TRANSACTION DATA 202 TRANSMIT TRANSACTION DATA TO 204 CARD TRANSACTION PROCESSING RECEIVE TRANSACTION DATA AND 206 SETTLEMENT PAYMENT AT PAYMENT PROCESSING SYSTEM STORE TRANSACTION DATA REVIEW TRANSACTION DATA FOR 210 PREDETERMINED CONDITION AT RISK ANALYSIS/PROCESSING MODULES OF LOAN MANAGEMENT INSTRUCT PAYMENT PROCESSING SYSTEM TO APPLY SETTLEMENT 212 PAYMENT TO REDUCE BORROWER'S LOAN IF 200 PREDETERMINED CONDITION MET

Description

P/00/011 Regulation 3.2 AUSTRALIA Patents Act 1990 ORIGINAL COMPLETE SPECIFICATION STANDARD PATENT Invention Title: "LOAN PORTFOLIO MANAGEMENT AND AUTOMATIC LOAN REPAYMENT METHOD AND SYSTEM" The following statement is a full description of this invention, including the best method of performing it known to me/us: LOAN PORTFOLIO MANAGEMENT AND AUTOMATIC LOAN REPAYMENT METHOD AND SYSTEM 5 FIELD OF THE INVENTION This invention relates generally to the management of a portfolio of loans and automatic loan repayment thereon, and more particularly to a method and system for a financial institution lender to manage a portfolio of merchant loans and perform automatic loan repayment based on a 10 correlation drawn between each merchant's card transaction activity processed through the lender's card processing facilities and the merchant's ability to repay the loan with the lender. BACKGROUND 15 Financial systems have evolved to facilitate commerce between customers, merchants and financial institutions. Conventional financial systems have been established by financial institutions such as lender banks for the repayment of loans extended to merchant borrowers. The lender banks typically charge a premium or interest rate on the principal amount of the loan 20 that is based on several factors. One major factor reflected in the cost of the loan to the merchant is the risk of default of the loan. Another factor reflected in the cost of the loan is the lender's repayment process required to secure scheduled repayment of the loan from the merchant borrower. 25 The cost for default on any loan for a lender bank is a major factor that is reflected in the overall borrowing cost of the loan. Any improvement in the risk analysis of the loan repayment process to warn or alert the lender bank of any potential default by a specific merchant borrower can reduce or help limit the risk to the lender bank. With any lowered risk to the lender bank, profit margins for the bank can be optimized and/or the savings may be passed on to the merchant 30 borrower. Existing loan repayment systems are generally geared for individual loan management and collection of loan repayments on a loan by loan basis which are typically made on fixed monthly term. This aspect of existing loan repayment systems contributes to the lender's risk exposure 35 and the overall borrowing cost because the merchant borrower's repayment is entirely out of the lender bank's control since the repayment is subject to the merchant borrower's management and 2 ability to timely honor the loan repayment. As the loan repayment is subject to a relatively long term between payments in existing loan management and repayment systems, the lender bank is likely unaware of the merchant borrower's ability to meet the loan repayment at any time during the repayment schedule until payment is actually received. Throughout this period, the bank has 5 relatively significant exposure to risk of default or late payment. Assessment of the risk is complicated by the fact that banks typically have a portfolio of such loans on the scale of hundreds or thousands of such loan agreements with merchant borrowers. As the scale of the loan portfolio increases, the systemic risk to the lender bank may actually increase as the difficulty and complexity of risk assessment of the loan portfolio is compounded. This 10 compounded complexity is reflected in the lender bank's costs and charges for such merchant loan agreements. Performing the administration, repayment and risk management of each loan within a portfolio of loans is made more difficult and compounded by the size and scale of the loan portfolio. 15 Therefore, a system and method is required to improve or at least alleviate a lender's risk and/or exposure associated with administration, repayment and management of a loan portfolio. SUMMARY 20 An aspect of the invention is a method for the management of a merchant borrower's repayment of an outstanding obligation to a lender. The method comprises receiving at a merchant card transaction processing module card transaction data representing a customer card payment transaction for a purchase amount between a customer and the merchant borrower and storing 25 the transaction data; receiving at a payment processing module a settlement payment for the purchase amount of the customer card transaction; analyzing at a risk analysis module the transaction data associated with the merchant borrower and determining whether the transaction data meets a predetermined condition; and generating an instruction to the payment processing module to distribute the payment settlement according to whether the predetermined condition is 30 met by applying at least a portion of the settlement payment to a lender account to reduce the merchant borrower's outstanding obligation if the predetermined condition is met, otherwise applying the settlement payment to an account of the merchant borrower. An aspect of the invention is a system for the management of a merchant borrower's repayment 35 of an outstanding obligation to a lender, the system comprises a merchant card transaction processing module for receiving card transaction data representing a customer card payment 3 transaction for a purchase amount between a customer and the merchant borrower and storing the transaction data; a payment processing module for receiving a settlement payment for the purchase amount of the customer card transaction; a risk analysis module for analyzing the transaction data associated with the merchant borrower and determining whether the transaction 5 data meets a predetermined condition, and generating an instruction to the payment processing module to distribute the payment settlement according to whether the predetermined condition is met by applying at least a portion of the settlement payment to a lender account to reduce the merchant borrower's outstanding obligation if the predetermined condition is met, otherwise applying the settlement payment to an account of the merchant borrower. 10 In embodiments, the method and system is for the management of a plurality of merchant borrower's outstanding obligations to the lender, and each merchant borrower transmits card transaction data to the lender. 15 In an embodiment the predetermined condition is determined by an agreement between the merchant borrower and the lender. The instruction may apply a percentage of the settlement payment to the lender's account. The predetermined condition may also be when the transaction data represents financial activity of the merchant borrower for a predetermined period that is less than the financial activity for a previous predetermined period with respect to the merchant 20 borrower itself or a comparable merchant. The predetermined period may be a day, a week, a month or the like. In an embodiment the method and system may have a user override to direct all or a portion of the settlement payment to the lender's account to reduce the merchant borrower's outstanding 25 obligation. The instruction may be to apply all of the settlement payment to the lender's account if the predetermined condition is met. The instruction may be to apply the settlement payment in accordance with an agreed portion of the merchant's daily transaction activity. A portion or all of the settlement payment may be applied to the lender's account. The instruction may be to apply the settlement payment to the lender's account in accordance with a floating charge over the 30 settlement payment. The merchant processing system and/or payment processing system may be located remotely to a third entity. The system may further comprise a database for storing the transaction data. The predetermined condition may be based on an extrinsic factor. An aspect of the invention is a risk analysis subsystem for use in a system for management of a 35 merchant borrower's repayment of an outstanding obligation to a lender, the system having a merchant card transaction processing module for receiving card transaction data representing a 4 customer card payment transaction for a purchase amount between a customer and the merchant borrower and storing the transaction data; and a payment processing module for receiving a settlement payment for the purchase amount of the customer card transaction; wherein the risk analysis subsystem comprises a transaction data analyzer module for analyzing 5 the transaction data associated with the merchant borrower and determining whether the transaction data meets a predetermined condition, and an instruction generating module for generating an instruction to the payment processing module to distribute the payment settlement according to whether the predetermined condition is met by applying at least a portion of the settlement payment to a lender account to reduce the merchant borrower's outstanding obligation 10 if the predetermined condition is met, otherwise applying the settlement payment to an account of the merchant borrower. BRIEF DESCRIPTION OF THE DRAWINGS 15 In order that embodiments of the invention may be fully and more clearly understood by way of non-limitative examples, the following description is taken in conjunction with the accompanying drawings in which like reference numerals designate similar or corresponding elements, regions and portions, and in which: 20 FIG. 1 illustrates a schematic illustration of a system showing a payment transaction from agreement of purchase to financial settlement of the payment transaction in which an embodiment of the invention may be implemented; 25 FIG. 2 illustrates the schematic illustration of the system of FIG. 1 with the financial settlement actions in greater detail; FIG. 3 illustrates the schematic illustration of the system of FIG. 2 with the initiation of a loan agreement with a loan management system; 30 FIG. 4 illustrates the schematic illustration of the system of FIG. 3 showing the interaction of the loan management system in greater detail in accordance with an embodiment of the invention; FIG. 5 shows a block diagram of the loan management system of FIG. 4 in greater detail with 35 respective inputs and outputs to the system in accordance with an embodiment of the invention; and 5 FIG. 6 is a flow diagram of a method in accordance with an embodiment of the invention. 5 DETAILED DESCRIPTION As mentioned, conventional financial systems have been developed to facilitate commerce between customers, merchants and financial institutions. Conventional financial systems have been established by banks for repayment of loans extended to borrowers. Additional financial 10 systems have been implemented for card payment transactions between a customer and a merchant. Typically, these two types of financial systems are both provided by the same financial institution or lender bank for each merchant. However, traditionally these two systems for loans and card payment transactions have evolved as two separate and distinct business units, for example divisions or departments, within a financial institution. This disparity between the two 15 disjoined facilities provided by a financial institution has evolved for the most part for the sake of perceived efficiency, and not necessarily by deliberate design. Embodiments of the invention improve or at least alleviate the problems associated with administration, repayment and risk management of a portfolio of loans by integrating the two 20 divisions and systems. Specifically, embodiments of the invention integrate information, relative to the merchant, that is gathered and available to the financial institution from the card transaction business unit with the loan repayment management business unit for risk analysis of the merchant's ability to repay the loan. A major factor reflected in the borrowing cost of the loan for the merchant borrower is the risk of default of the loan, which can be mitigated in a number of 25 ways such as for example, by increasing the frequency or shortening the interval of payments, for example from monthly to daily, by effecting repayment from the merchant borrower's other assets/monies in the bank's possessions, and by more precisely monitoring the merchant's sales as a measure of the merchant's ability to continue making payments on the loan. Accordingly, this feature permits more effective risk management analysis resulting in savings to the bank 30 which may be reflected in increased profits for the bank and/or competitive pricing or interest rates with lowered borrowing costs for the merchant borrower. Additionally, since card payment transactions are typically processed on a much shorter term basis of a few hours to days, than compared with the typical fixed monthly term for loan repayment, the access to more immediate information regarding card transaction activity which may be indicative of merchant borrower's 35 ability to meet the loan repayment reduces the lender bank's risk. Also, as the lender bank is involved in the settlement process and in this relationship actually receives the settlement 6 payment for the card transactions that is due to the merchant, the lender's bank's exposure is reduced as the bank may apply the settlement payment amount to the loan repayment. As the automatic daily repayment from the borrower merchant card transaction proceeds are 5 within the lender bank's possession, the lender bank's exposure on the outstanding loan and risk are reduced. For example if the borrower merchant's card transaction activity is above normal for the merchant borrower, the lender bank may take no action and send an instruction for the settlement repayment for the card transaction to be transmitted directly to the merchant's account. If, for example, the borrower merchant's card transaction activity is below normal for the 10 merchant borrower, then the lender bank may take action and send an instruction for all of or part of the settlement repayment for the card transaction to be transmitted to the loan account to offset the loan or repayment amount. In this way, embodiments of the invention reduce the lender bank's risk and exposure. 15 In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It is apparent to one skilled in the art, however, that the present invention may be practiced without these specific details or with equivalent arrangements. In some instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention. 20 An embodiment of the invention is generally applicable wherein a lender bank provides or facilitates two services or facilities for a merchant. The lender bank provides card transaction services for the merchant to conduct business and accept payment through card transactions with a customer, wherein the bank effectively purchases merchant's credit card transactions at a 25 discount to face value with typically next day settlement to the merchant, and the bank subsequently collects payment on such credit card transactions through the applicable network. The lender bank also provides a loan service to the merchant borrower, wherein the bank charges interest on the loan and the merchant is obligated to make payments of specific amounts at specific periods, for example, monthly. The system and method in accordance with 30 embodiments of the invention provides a tool for a lender bank to recognize funds the bank has in the bank's settlement accounts that are associated with the merchant transaction card processing business in one section or part of the bank and to consider those merchant funds in the context of the merchant's loan obligations before those funds are released to the merchant. 35 Specifically, the system and method may then assess the lender bank's risk using information gathered from the transaction card processing to determine whether none, a portion, or all of the 7 transaction card settlement proceeds should be applied to the merchant borrower's loan repayment account instead of the merchant account. In this way, the analysis may be applied across the entire loan portfolio with respect to each loan wherein the lender bank also processes the borrower merchant's card transactions. In this way the risk to the lender bank is reduced and 5 minimized as the activity of the borrower merchant's card transactions is an early indication of the borrower merchant's ability to repay the loan and payment obligations owed to the lender bank. Information from the transaction card processing division of the bank is used to manage risk on a portfolio of loans in another section or part of the bank. As these two divisions of the financial institution or bank have typically been separate and distinct from one another, earlier attempts to 10 limit risk to the lender bank have not achieved the results achieved by the integrated shared approach of embodiments of the method and system of the invention. With embodiments of the invention, a bank can more effectively extend and manage a portfolio of loans, including specifically automated collection of loan repayment from credit card transaction settlement proceeds and also risk management on borrow merchants' unpaid balance of the loan or 15 outstanding payment obligations. The collection of the data pertaining to a merchant's card transactions or financial activity over a particular period, such as a daily record or financial transaction proceeds, provides a good barometer into that merchant's ability to repay a loan. Comparing a merchant's financial 20 transaction activity over the predetermined period or a particular day against the merchant's prior financial activity and history, or when compared with the history or current trading patterns of similar merchants within the bank's loan portfolio, a bank can more effectively and accurately identify accounts which may be in difficulty relative to the loan repayment. Advantageously, embodiments of the invention provide the settlement proceeds of underlying card transaction 25 records to permit an effective system for a bank to secure some or all of the outstanding debt via a floating charge over the merchant's transaction proceeds in the bank's accounts. In card payment transactions, the customer or cardholder payment card may be a debit card, credit card, smart card, charge card and the like. Card transactions appear automatic in nature to 30 the cardholder and the merchant in that details of the payment card and merchant are automatically transmitted to financial institutions and financial networks for authorization and settlement of the card transaction. FIG. 1 illustrates a schematic illustration of a system 10 showing a payment transaction from 35 agreement of purchase to financial settlement of the payment transaction in which an embodiment of the invention may be implemented. The system 10 includes a cardholder 12 with 8 a payment card 14 and a merchant 16. Once the cardholder and merchant agree to a purchase by card payment, the merchant communicates 42 transaction data to a bank's merchant card processing system 30 or module in a financial institution or bank 20. 5 The transaction data may include for example transaction amount, transaction currency, merchant account number (i.e. "merchant ID" or "MID"), merchant DBA (i.e. doing business as) or trading name which may be different from the merchant's legal name, cardholder account number, date, merchant name, authorization approval number, retrieval reference number, card type (i.e., Visa, Mastercard, American Express, etc.), currency of the transaction, a description of 10 the purchase, and the like. It will be appreciated that the transaction data may vary for specific transactions and may include additional information not listed. The bank's merchant processing system processes the request for authorization to complete the sale and to initiate subsequent financial settlement for the transaction. The bank's merchant card 15 processing system 30 communicates 44 the transaction data to network 22, for authorization to complete the sale and to initiate subsequent financial settlement for the transaction. The network 22 communicates 46 the transaction data to the card issuing bank 24. The card issuing bank 24 authorizes 48 the merchant to complete the transaction in order to complete the sale. At some point after the transaction at the point of sale (POS) at the merchant's business (often before the 20 daily store closing or a shift change), the merchant sends a request for financial settlement for the transaction that has been authorized, which request may be in a batch process form, including all sale transactions authorized during the period. The request for financial settlement is further communicated by the bank's payment processing system 34 or module to the network 22, which obtains financial settlement 48from card issuing bank 24, which financial settlement is transferred 25 50 from network to bank's designated settlement accounts 32. Regarding the transaction data in a batch of settlement transactions, the transaction data may be for example the total number of transactions in the batch in aggregate and/or by card type, the total transaction amount transaction currency and merchant account number, and the like. 30 Essentially, the batch transaction data is a summary of all of the individual transactions which occurred prior to batch closing, and so need not repeat the same level of transaction data of the constituent individual transactions. The network 22 includes such conventional networks as VISA, Mastercard, American Express, 35 and the like. The network 22 is a system that facilitates the authorization and settlement of payment card transactions between financial institutions.

9 It will be appreciated that the bank's merchant card processing system 30 and/or the bank's payment processing system 34 as indicated by the dashed box in FIG. 1 may be within the same financial institution or bank 20 as shown, or may be located remotely to the bank 20. For 5 example, the bank 20 may outsource the bank's merchant card processing system 30 and/or the bank's payment processing system 34 to a separate entity or third party processor. While the bank has extended a loan to a borrower merchant, the lender bank may have received from the network 22 a post-settlement or lump settlement 50 into the bank's settlement accounts 10 32, a portion of which is typically to be paid 52 as a matter of course to the borrower merchant 16 to the merchant's settlement account 66. In this manner, the bank may allocate the settlement proceeds it has received or will receive from the merchant in a more effective manner by integrating the two disparate business units of the bank, i.e. the card transaction and loan capabilities of the bank, using the proceeds of the card transaction data to facilitate repayment 15 and provide enhanced risk analysis with respect to the underlying loan. This process of settlement typically happens within a 24-hour period or within a few days. A statement 26 will be rendered 54 by the card issuing bank 24 and sent 55 to the cardholder 12 on a periodic basis, usually monthly. Upon receipt of such billing, the cardholder pays 56 the card 20 issuing bank, and the payment cycle is complete. FIG. 2 is a schematic illustration of a system 60 with the financial settlement actions shown in FIG. 1 in greater detail. Specifically, the bank's merchant card processing system 30 communicates 62 payment instructions to the bank's payment processing system 34. The 25 payment instructions may include a payment information file (PIF) having the transaction data such as for example merchant account number, merchant name, merchant's bank account #, total amount to be credited to merchant's account and the like. The PIF may also include the bank's account number from which the funds will be drawn, as well as possible descriptor information to explain the basis for the payments. Such descriptors may include for example a 30 description summary of the card transaction or batch card transactions, and/or to note any deductions or fees which have reduced the deposit from the face amount of the original transactions such as merchant discount rate (MDR), and the like. It will be appreciated that the transaction data for the PIF may vary for specific transactions and may include additional information not listed. 35 10 The bank's payment processing system 34 draws 64 from the bank's settlement accounts 32 to initiate the financial settlement 52 to merchant's account 66. As a practical matter, the merchant's bank account is often (but need not be) at the same institution, in which case financial settlement is an intra-bank transfer between the bank's settlement accounts and the merchant's 5 account. If the merchant's bank account is not at the same financial institution, financial settlement is an interbank transfer between the bank's settlement accounts and the merchant's account. FIG. 3 shows a system 70 with the initiation of a loan agreement between the bank 20 and the 10 merchant 16 and the card transaction system of FIG. 1 and FIG. 2. The system includes a loan management system 102 and shows in further detail the financial settlement from the network is into specifically enumerated accounts at the bank dedicated for the purpose of the bank's merchant payments business. Specifically, the bank's settlement accounts 32 include loan accounts (i.e.: those accounts under the control of the bank, which are established to facilitate the 15 bank's lending business unit) 74 and card accounts (i.e.: those accounts under the control of the bank, which are established to facilitate the bank's merchant card transaction processing business unit) 72. The bank's loan account may or may not be the same account into which the credit card financial settlement is rendered 72. In this embodiment, the accounts are proprietary to the bank. 20 The bank disburses 80 a loan to the borrower merchant 16. The merchant 16 makes repayments 82 to the bank 20, either by cheque or electronically, at agreed times, typically, monthly. The bank 20 clears the repayments through bank's internal accounts dedicated for that purpose 74. The bank's loan management system 102 notes payment, relative to outstanding loan balance, 25 and transmits or notes deposit of proceeds 84 into the bank's loan accounts 74. FIG. 4 shows a system 100 of FIG. 3 showing the interaction of the loan management system 102 with the bank's merchant card processing system 30, bank's payment processing system 34 and settlement accounts 32 in greater detail in accordance with an embodiment of the invention. 30 FIG. 1-3 show the environment that embodiments of the invention may be configured, and FIG. 4 shows the interaction of the loan management system 102 in accordance with an embodiment of the invention. The loan management system 102 is configured such that the bank's merchant card processing system 30 generates the payment information file (PIF) with the loan management system 102, and the bank's merchant card processing system 30 communicates 35 120 with the loan management system 102 and provides the card transaction data. The bank's merchant card processing system 30 may communicate 120 the card transaction data to the loan 11 management system 102 on a per transaction basis, or in batch having a number of transactions on a daily basis, or the like, prior to initiating settlement. The PIF may instruct 62, 122 the bank's payment processing system 34 module to pay 124 all of the payment settlement to the merchant's deposit account 66, or upon risk analysis module 144 determination, as shown in FIG. 5 5, that none, partial or all of the payment settlement must be paid 64, 84 into the merchant borrower's loan account 74 for repayment towards the outstanding loan. Referring to FIG. 5, a block diagram 130 of the loan management system 102 of FIG. 4 is shown in greater detail with respective inputs and outputs to the system in accordance with an 10 embodiment of the invention. The loan management system 102 comprises a processing module 104, memory 106, input/output (1/O) interface 108 and database 110. The database 110 comprises for example a merchant account file 132, loan account file 134, transaction history 136, loan balance 138, calculation of daily repayment amount 140, payment instruction file 142, risk analysis module 144, and the like. It will be understood that the repayment amount 140 may 15 be calculated and the payment instruction file (PIF) may be generated upon risk analysis module or subsystem 144 for example with transaction data analyzer and instruction generating modules by the processing module 104 at other times and is not only limited to a daily calculation. The merchant account file 132 may comprise data such as the merchant account number and the 20 batch summary value by card type, and the like. The merchant account number may be provided by the bank 20, and the batch summary value may be defined as the total amount (for example, dollar amount) of all transactions submitted by that borrower merchant to the lender bank for settlement during a particular period, for example, daily. The loan account file 134 may comprise the loan account number that is cross-referenced to a 25 merchant account number, and may utilize in its' composition some or all of the merchant account number, and the like. The transaction history file 136 may comprise for example the loan account number which retrieves a file containing the merchant's daily transaction history, merchant category code (MCC) code description, merchant discount rate (MDR), loan principal, remaining repayment plan, for 30 example, as a percentage (%) of daily proceeds, and the like. The loan balance 138 may comprise the repayment plan that is applied against the amount in the merchant's batch summary, i.e. the card transaction daily balance, to ascertain the amount of the merchant's pending financial settlement that will be re-directed towards reducing the remaining balance of the loan, and the like.

12 The calculation of daily repayment amount 140 is generated by the processing module 104 of the system for the payment instruction file (PIF) 142 in the format required by the bank's payment processing system 34. The payment instruction file 142 is generated by the processing module 104 and communicated 122 to the bank's payment processing system 34, which contains the 5 instructions for the bank to draw 64 from the card settlement accounts and issue credit to the proper account at the bank for the repayment of the loan proceeds 74, and also to issue credit 124 to the merchant's own account 66 of the remainder of the card transaction daily balance. For example, the remainder may reflect the amount less MDR and other fees. It will be appreciated that the communication 122 of the payment instruction file 142 to the bank's payment processing 10 system 34 can occur before, after or coincident with the financial settlement communication 50 from network 22 to the bank's designated settlement accounts 72. It will be appreciated that as indicated previously, in this and other embodiments the merchant settlement account 66, bank's merchant card processing system 30 and/or bank's payment 15 processing system 34 may be within the same financial institution or bank 20 as shown, or may be located remotely to the bank 20. For example, the bank 20 may outsource the bank's merchant card processing system 30 and/or bank's payment processing system 34 to a third entity. 20 In another configuration (not shown in FIG. 5), the card transaction data from the merchant 16 first passes through the loan management system 102, for onward transmission to the bank's card processing system 30 after collecting the relevant data. An additional feature can be derived from the daily card transaction data, in the form of risk 25 management relative to the likelihood of the loan repayment. By comparing the merchant's daily credit card transaction activity to a historical record of that same merchant's daily card transaction activity, and/or the daily card transaction activity of similarly situated merchants, the loan management system can provide early warning of potential difficulties in the merchant's ability to repay the loan, enabling corrective action by the bank or user. These predetermined conditions 30 or thresholds are factors that may be considered in changing the percentage of the settlement payment from payment to the merchant account to repayment of the loan instead. Other factors that may be taken into consideration may be seasonality, holidays, day of the week, and the like. It will be appreciated that as for various businesses, some days have a significant characteristic such as having higher turnover than other days. A merchant may be compared with or 35 considered against a similar merchant, i.e. a similarly situated merchant, that shares similar characteristics in common such as similar merchant category code (MCC), merchant business 13 sector, targeted customer base, physical neighborhood/geographic location of the business, average sales volume and/or number of transactions, customer complaints, repudiations of transactions, i.e. "chargebacks", and the like. Also, there may be certain conditions that act as triggers to increase the percentage of settlement payment to be repaid into the loan account 74 5 rather than paid into the merchant's account 66. Such triggers may include for example any perceived breach of the loan terms and conditions, a falsehood on the loan application, and the like. Additionally, extrinsic factors may be considered as factors for risk analysis. Such extrinsic factors include for example a sale or intended sale of the merchant business, a bankruptcy filing, notice of a claim by other debtors, and the like. The notice of a claim by other debtors is 10 particularly relevant in the context of the floating charge. Referring to FIG. 4 and FIG. 5, the loan management system 102 associates the merchant's card transaction daily balance with the loan details in the system, and calculates the amount of such merchant's card transaction daily balance which should be directed to repayment of the loan 15 balance, as agreed with the merchant upon loan origination. In an embodiment, the loan management system 102 initiates 122 payment instructions 142 to transfer the agreed-portion of merchant's daily balance into the bank's dedicated settlement accounts, or accounts associated with the loan management system. 20 The repayment of the loan is made automatic when, upon a risk analysis of the merchant borrower's card transactions, a correlation is drawn between each merchant's card transaction activity processed through the bank lender's card processing facilities and the merchant's ability to repay the loan with the bank lender. The information is integrated from the card transaction business unit within the bank lender and applied to the loan repayment management business 25 unit within the bank for risk analysis of the merchant's ability to repay the loan. If it is determined upon analysis that the risk is high or greater than had been envisaged, all or a portion of the settlement payment is applied to reduce the obligation owed by the merchant borrower to the bank lender. 30 In another configuration, the bank's merchant card processing system 30 suppresses its' typical payment information files, and the loan management system 102 initiates two payment information files 142: the first to transfer 64 the agreed-portion of merchant's daily balance into bank's dedicated settlement card accounts 72; and the second to initiate 124 financial settlement to merchant settlement account 66 for the remainder of the merchant's card transactions daily 35 balance.

14 An additional feature of an embodiment of the invention is to permit a user/lender to over-ride the anticipated process described above, such that some or all of the merchant's financial settlement can be suppressed in order to provide security for the unpaid balance of the loan. When utilized with a "floating charge", this procedure permits the creation of a pool of assets when such a 5 charge crystallizes, where a floating charge is applied in the loan that changes in value until charge conversion or crystallization when the charge becomes fixed to secure the repayment of the loan. With this feature, when the bank extends a loan to a merchant or business which includes a floating charge over the loan settlement proceeds of payment card transactions which are passing anyway through the bank's other systems, the loan management system can instruct 10 the bank to hold all transaction proceeds otherwise to be paid to the merchant. While the merchant continues to send in payment card transaction data for settlement at the bank, the bank accumulates merchant monies over which the bank has both physical possession and a floating security interest. In this way, the management of the merchant loan is tied together to the merchant's daily (or other predetermined period) settlement of payment card proceeds. The 15 bank's payment processing system 34 draws 64 from the bank settlement accounts 72 for the merchant financial settlement, and credits 126 to the appropriate account for the loan proceeds 74. In the system and method described in accordance with an embodiment of the invention, only one merchant 16 is shown in FIG. 1-5 for the sake of clarity and ease of understanding the 20 description of embodiments of the invention. It will be understood that embodiments of the invention may be configured for a lender having a portfolio of loans with a financial relationship with a plurality of merchant borrowers. The merchant borrowers may have single or multiple loan obligations with the lender bank. Embodiments of the invention may be arranged for automatic loan repayment as described above for each loan in the portfolio of loans. Advantages of 25 embodiments of the invention may be realized in loan portfolio management where there are multiple merchant borrowers and loan agreements to reduce or alleviate the lender bank's risk and exposure across the loan portfolio. It will be appreciated that in embodiments of the invention there may also be multiple or a plurality of loan accounts 74, card accounts 72, and merchant settlement accounts 66. 30 FIG. 6 is a flow diagram of a method 200 in accordance with an embodiment of the invention. The method for the management of a borrower merchant's repayment of an outstanding obligation to a lender, and comprises obtaining 202 transaction data representing payment by card for a customer transaction between a customer and the borrower merchant. The customer transaction data is transmitted 204 to a merchant card transaction processing system and 35 received 206 at a payment processing payment system or module with the settlement payment at 15 a payment processing system. The transaction data is stored 208 in a storage means, and the transaction data is reviewed 210 for data associated with the borrower. Instead of applying the settlement payment directly to an account of the merchant, if certain predetermined conditions or thresholds are met, payment processing system is instructed 212 to apply all of or at least a 5 portion of the settlement payment to reduce the borrower merchant's outstanding obligation to the lender in view of the stored transaction data associated with the borrower merchant. The exemplary methods and systems described with respect to FIGs. 1-6 can communicate, for example, over a communication network, and can include any suitable servers, workstations, personal computers (PCs), laptop computers, handheld devices, with visual displays and/or 10 monitors, telephones, cellular telephones, wireless devices, PDAs, Internet appliances, set top boxes, modems, other devices, and the like, capable of performing the processes of the disclosed exemplary embodiments. The devices and subsystems, for example, may communicate with each other using any suitable protocol and may be implemented using a general-purpose computer system and the like. One or more interface mechanisms may be employed, for 15 example, including Internet access, telecommunications in any suitable form, such as voice, modem, and the like, wireless communications media, and the like. Accordingly, network may include, for example, wireless communications networks, cellular communications network, Public Switched Telephone Networks (PSTNs), Packet Data Networks (PDNs), the Internet, intranets, hybrid communications networks, combinations thereof, and the like. 20 It will be appreciated that the transaction data may be obtained by means well known in the industry, for example equipment, devices and machines to facilitate card transactions between a customer and a merchant at a point of sale (POS). For example, such means may be electronic/magnetic card swipe reader machines, contactless readers, contactless near field communication readers, contactless RFID readers, cash register and the like to receive a card 25 with a magnetic stripe or the like and read the customer-identifying account numbers and details associated with the card as well as the amount of the payment and other transaction data and transmit the data to the bank's merchant card processing system 30 of the lender bank 20 which is arranged with means to receive the transaction data and transmit the transaction data accordingly. Of course the merchant may key in this information manually or transmit this 30 information directly to the bank manually over the telephone after receiving a customer's consent over the telephone, internet, or the like. The transmission may be transmitted electronically. It is to be understood that the embodiments, as described with respect to FIGs. 1-6, are for exemplary purposes, as many variations of the specific hardware used to implement the 16 disclosed exemplary embodiments are possible. For example, the functionality of the devices and the subsystems of the embodiments may be implemented via one or more programmed computer system or devices. To implement such variations as well as other variations, a single computer system may be programmed to perform the functions of one or more of the devices and 5 subsystems of the exemplary systems. On the other hand, two or more programmed computer systems or devices may be substituted for any one of the devices and subsystems of the exemplary systems. Accordingly, principles and advantages of distributed processing, such as redundancy, replication, and the like, also may be implemented, as desired, for example, to increase robustness and performance of the exemplary systems described with respect to FIGs. 10 1-6. The exemplary systems described with respect to FIGs. 1-6 may be used to store information relating to various processes described herein. This information may be stored in one or more memories, such as hard disk, optical disk, magneto-optical disk, RAM, and the like, of the devices 15 and sub-systems of the embodiments. One or more databases of the devices and subsystems may store the information used to implement the exemplary embodiments. The databases may be organized using data structures, such as records, tables, arrays, fields, graphs, trees, lists, and the like, included in one or more memories, such as the memories listed above. 20 All or a portion of the exemplary systems described with respect to FIGs. 1-6 may be conveniently implemented using one or more general-purpose computer systems, microprocessors, digital signal processors, micro-controllers, and the like, programmed according to the teachings of the disclosed exemplary embodiments. Appropriate software may be readily prepared by programmers of ordinary skill based on the teachings of the disclosed exemplary 25 embodiments. In addition, the exemplary systems may be implemented by the preparation of application-specific integrated circuits or by interconnecting an appropriate network of component circuits. The exemplary embodiments described herein may be employed in offline systems, online systems, and the like, and in applications, such as TV applications, computer applications, DVD applications, VCR applications, appliance applications, CD play applications, and the like. 30 Throughout this specification, including the claims, where the context permits, the term "comprise" and variants thereof such as "comprises" or "comprising" are to be interpreted as including the stated integer or integers without necessarily excluding any other integers.

17 While embodiments of the invention have been described and illustrated, it will be understood by those skilled in the technology concerned that many variations or modifications in details of design or construction may be made without departing from the present invention.

Claims (35)

1. A method for the management of a merchant borrower's repayment of an outstanding obligation to a lender, the method comprising: receiving at a merchant card transaction processing module card transaction data representing a customer card payment transaction for a purchase amount between a customer and the merchant borrower and storing the transaction data; receiving at a payment processing module a settlement payment for the purchase amount of the customer card transaction; analyzing at a risk analysis module the transaction data associated with the merchant borrower and determining whether the transaction data meets a predetermined condition; and generating an instruction to the payment processing module to distribute the payment settlement according to whether the predetermined condition is met by applying at least a portion of the settlement payment to a lender account to reduce the merchant borrower's outstanding obligation if the predetermined condition is met, otherwise applying the settlement payment to an account of the merchant borrower, wherein the predetermined condition is when the transaction data represents financial activity of the merchant borrower for a predetermined period that is lower than financial activity for a previous predetermined period.

2. The method of claim 1 wherein the method is for the management of a plurality of merchant borrower's outstanding obligations to the lender, and each merchant borrower transmits card transaction data to the lender.

3. The method of claim 1 or 2 wherein the instruction is to apply a percentage of the settlement payment to the lender's account.

4. The method of claim 1 wherein the financial activity for a previous predetermined period is for the financial activity of the merchant borrower.

5. The method of claim 1 wherein the financial activity for a previous predetermined period is for the financial activity of a similarly situated merchant. 19

6. The method of any one of claims 1-5 wherein the predetermined period is a day.

7. The method of any one of claims 1-5 wherein the predetermined period is a week.

8. The method of any one of claims 1-5 wherein the predetermined period is a month.

9. The method of claim 1 or 2 further comprising applying all of the settlement payment to the lender's account if the predetermined condition is met.

10. The method of claim 1 or 2 wherein applying the settlement payment is in accordance with an agreed portion of the merchant's daily transaction activity.

11. The method of claim 1 or 2 wherein a portion of the settlement payment is applied to the lender's account.

12. The method of claim 1 or 2 wherein all of the settlement payment is applied to the lender's account.

13. The method of any one of the preceding claims wherein applying the settlement payment to the lender's account in accordance with a floating charge over the settlement payment.

14. The method of any one of the preceding claims further comprises locating the merchant processing system and/or payment processing system remotely to a third entity.

15. The method of any one of the preceding claims wherein the storing of the transaction data is in a database.

16. The method of any one of the preceding claims wherein whether the predetermined condition is met is further influenced by extrinsic factors, wherein extrinsic factors are any one of the following :- a sale or intended sale of the merchant borrower's business, a bankruptcy filing and a notice of a claim by other creditors.

17. A system for the management of a merchant borrower's repayment of an outstanding obligation to a lender, the system comprising: a merchant card transaction processing module for receiving card transaction data 20 representing a customer card payment transaction for a purchase amount between a customer and the merchant borrower and storing the transaction data; a payment processing module for receiving a settlement payment for the purchase amount of the customer card transaction; a risk analysis module for analyzing the transaction data associated with the merchant borrower and determining whether the transaction data meets a predetermined condition, and generating an instruction to the payment processing module to distribute the payment settlement according to whether the predetermined condition is met by applying at least a portion of the settlement payment to a lender account to reduce the merchant borrower's outstanding obligation if the predetermined condition is met, otherwise applying the settlement payment to an account of the merchant borrower, wherein the predetermined condition is when the transaction data represents financial activity of the merchant borrower for a predetermined period that is lower than financial activity for a previous predetermined period.

18. The system of claim 17 wherein the system is for the management of a plurality of merchant borrower's outstanding obligations to the lender, and each merchant borrower transmits card transaction data to the lender.

19. The system of claim 17 or 18 wherein the instruction is to apply a percentage of the settlement payment to the lender's account.

20. The system of claim 17 wherein the financial activity for a previous predetermined period is for the financial activity of the merchant borrower.

21. The system of claim 17 wherein the financial activity for a previous predetermined period is for the financial activity of a similarly situated merchant.

22. The system of any one of claims 17-21 wherein the predetermined period is a day.

23. The system of any one of claims 17-21 wherein the predetermined period is a week.

24. The system of any one of claims 17-21 wherein the predetermined period is a month. 21

25. The system of claim 17 or 18 wherein the instruction is for applying all of the settlement payment to the lender's account if the predetermined condition is met.

26. The system of claim 17 or 18 wherein the instruction is for applying the settlement payment is in accordance with an agreed portion of the merchant's daily transaction activity.

27. The system of claim 17 or 18 wherein a portion of the settlement payment is applied to the lender's account.

28. The system of claim 17 or 18 wherein all of the settlement payment is applied to the lender's account.

29. The system of any one of claims 17-28 wherein the instruction is for applying the settlement payment to the lender's account in accordance with a floating charge over the settlement payment.

30. The system of any one of claims 17-29 wherein merchant processing system and/or payment processing system is located remotely to a third entity.

31. The system of any one of claims 17-30 further comprising a database for storing the transaction data.

32. The system of any one of the preceding claims wherein whether the predetermined condition is met is further influenced by extrinsic factors, wherein extrinsic factors are any one of the following :- a sale or intended sale of the merchant borrower's business, a bankruptcy filing and a notice of a claim by other creditors.

33. A risk analysis subsystem for use in the system of any one of the claims 17-32.

34. A risk analysis subsystem for use in a system for management of a merchant borrower's repayment of an outstanding obligation to a lender, the system having: a merchant card transaction processing module for receiving card transaction data representing a customer card payment transaction for a purchase amount between a customer and the merchant borrower and storing the transaction data; and 22 a payment processing module for receiving a settlement payment for the purchase amount of the customer card transaction; wherein the risk analysis subsystem comprises a transaction data analyzer module for analyzing the transaction data associated with the merchant borrower and determining whether the transaction data meets a predetermined condition, and instruction generating module for generating an instruction to the payment processing module to distribute the payment settlement according to whether the predetermined condition is met by applying at least a portion of the settlement payment to a lender account to reduce the merchant borrower's outstanding obligation if the predetermined condition is met, otherwise applying the settlement payment to an account of the merchant borrower , wherein the predetermined condition is when the transaction data represents financial activity of the merchant borrower for a predetermined period that is lower than financial activity for a previous predetermined period.

35. A loan portfolio management system for a lender having a financial relationship with a plurality of merchant borrowers, each of the plurality of merchant borrowers having a plurality of outstanding obligations with the lender, the loan portfolio management system comprising the risk analysis subsystem of claim 34 to manage each of the plurality of merchant borrowers repayment of each of the plurality of outstanding obligations to the lender.