GB2135484A - Improved equity access system - Google Patents

Abstract

Data processing for an improved equity access and management account flexibly permits owner access to a line of credit. The line of credit may typically be secured, as by the equity in a client's home or other asset. Charges against the client account may be of varying forms, e.g., by cheque, charge card or cash advance, and decrement available credit remaining in the credit line when authorized. Account loan principle is increased when charges are incurred, and reduced upon full or partial payment. Charges for interest, late fees and the like, sometimes differing in rate or amount based upon an independent variable such as security situs, are assessed against client accounts, and account status and balances are periodically reported.

Description

SPECIFICATION Improved equity access system Disclosure of the Invention This invention relates to financial business systems and, more specifically, to an improved data processing arrangement for permitting and administering a flow of charges and credits against a preestablished, typically secured line of credit.

It is an object of the present invention to provide an improved equity access acount.

More specifically, it is an object of the present invention to provide a data processing implementation for an equity access and management system which flexibly permits and accounts for client access to and charges and credits against a pre-established line of credit via checks, charge cards and the like.

The above and other objects of the present invention are realized in a specific, illustrative data processing arrangement for an improved equity access and management account which flexibly permits owner access to a line of credit. The line of credit may typically be secured, as by the equity in a client's home or other asset. Charges against the client account may be of varying forms, e.g., by check, charge card or cash advance, and decrement available credit remaining in the credit line when authorized.

Account loan principle value is increased when charges are incurred, and reduced upon full or partial payment. Charges for interest, late fees and the like, sometimes differing in rate or amount based upon one or more independent variables such as security situs state, are assessed against client accounts; and account status and balances are periodically reported.

The foregoing and additional features and advantages of the instant invention will become more readily apparent from the following detailed description of a specific, illustrative embodiment thereof, presented hereinbelow in conjunction with the accompanying drawings in which: Fig. 1 is a flow chart depicting data processing for authorization requests for the equity access accounts of the instant invention; Fig. 2 depicts in flow chart form post-transaction processing for the instant equity access-type accounts; and Fig. 3 is a schematic flow chart depicting periodic account processing and reporting in accordance with the principles of the present invention for an improved equity access system of accounts.

Beginning first in overview, the equity access methodology and apparatus of the instant invention illustratively relate to client or customer accounts where each customer is permitted to incur charges against a pre-determined line of credit. The credit line will typically be supported by a security interest in the client's equity in some underlying asset. As one example, the line of credit may be secured by a perfected, possibly subordinated lien on the client's home or other real property. The credit limit thus represents a fraction within pre-determined norms of the client's equity in the underlying asset remaining after more senior lens are taken into account.

Each client is given access to his/her pre-established line of credit by a client-implemented device of any known kind, e.g., via bank checks, credit cards, cash advances, or the like. In practice, each client establishes a line of credit with the system proprietor - and has his/her equity interest in the collateral form the subject of a recorded mortgage or the like. Once the security interest is perfected, the client may draw down against the pre-established credit limit by writing checks, making charges, or the like in amounts and at times of the client's own choosing without need for obtaining separate "loans" or fund releases.

The credit available to each individual will, of course, be reduced as the gross amounts of prior charges or take downs increases. Similarly, repayment of principle by subscribers pro ton to increases their available credit.

At periodic times, the system operator makes various charges against each subscriber. Most obviously, the operator renders an interest charge based upon the time use of the outstanding loan principle balance from time to time. Other charges may also be made depending upon user/system options, e.g., late charges for belated payments, life insurance charges to forgive indebtedness upon demise of a system client, or the like. The basis of the several charges, e.g., interest, may be uniform (as some increment over the prime or federal funds rate applicable to all). Alternatively, such charges may depend upon independent variables, e.g., the state in which the underlying asset is located to accommodate local usury, late charge limitation or other laws, regulations or practices. Obviously, other dependencies may obtain as well for other system operator services.Also at like or other periodic times, the system operator provides reports to individual clients, identifying such parameters as outstanding loan balance and subscriber charges for interest and insurance premiums.

Accordingly, an equity access system as above outlined in essence permits a client to have unilateral access to the equity value in his/her underlying property, i.e., to flexibly make expenditures or incur debt collateralized by equity in what is often an unliquid asset. Subject to contractual obligations, the subscriber may repay when and in such amounts as he/she chooses, thus providing great financial flexibility.

Discussion will now be had with respect to the implementation of the above-described equity access system by the arrangement of the instant invention. In accordance with such processing, several schematic programming variables are utilized. The variables bearing running index "I" are on a perclient basis, i.e., represent the subject parameter for the i-th client of the system. The more substantial of the variables employed are as follows: Variable Subject Matter Designated CRDAV(I) The credit available to a particular (i.e., to the "i-th") client remaining from his/her initially available credit line.

TD(I) The take down or net charges (after any repayments) incurred to date for a particular client which may be conceptually viewed as the principle or loan balance of that customer at any point in time.

TFEES(I) The system fees or charges to a particular customer, principally consisting of interest and late fees, if any.

ADMD(I) The amount of a particular request for a charge authorization from a client such as the authorization to incur a credit card charge.

MDMD(I) The amount of an actual monetary charge, credit or payment for a particular customer.

TINT(I) The total interest incurred by a client during a portion of the processing for an accounting interval, e.g., a portion of a month for a static (constant) outstanding principle balance.

INSP(I) Insurance premium for a customer during such a static (constant condition) period of a periodic accounting cycle.

D The number of days for a periodic accounting interval of static or common account take down conditions.

TRANS(J) A posted transaction, reflective of a prior monetary expenditure (that is, a previously encountered MDMD(I) transaction) from an array of possible such transactions for a customer.

TRANS An interim processing variable to keep a running total of transactions TRAUS(J) over a processing interval.

RT The operative daily interest rate to be charged.

RT(DY,S) The daily interest rate (doubiy indexed) for the day of year given by DY and state where the real property security is located (S).

RTN The interest rate which obtains for the next accounting cycle day, i.e., the day following the date of RT.

RT((DY+ 1 ),S) An interest rate from the double indexed interest rate table which follows by one day the rate of RT(DY,S).

LTC(S) The rate charge from a scaler array which varies with the state situs (S) of the underlying real property asset.

ITFE(I) The amount of fees charged by the system operator - as for interest, and which are due and unpaid at the beginning of a subject period, e.g., at the beginning of an accounting month.

RST(I) Any limit restraints on authorizing new charges for a client - such as a credit card previously reported lost, or a check stopped for any reason.

PRT Daily insurance premium rate per unit quantity of outstanding loan principle TD(I).

RPY Value of principle TD(I) repayment being made by a system client.

With the above variables in mind, the processing of the system arrangement of the instant invention will now be specifically considered. Variable designations and computer processing steps are schematic and illustrative only; and may be implemented in any coding language in any computing equipment. Turning first to Fig. 1, there is shown a flow chart depicting the way authorization requests for the instant arrangement are processed. That is, the Fig. 1 flow chart generates an affirmative response (output message from block 21) or a negative response (output message from functional block 18) when a client attempts to implement a charge, e.g., attempts to make a purchase with a charge card, write a check or make any other form of expenditure request.The amount ADMD(I) for which credit is desired is entered into the system (block 12) and the credit remaining available to that client CRDAV(I) is read in from memory - step 13. Also recovered as a processing variable is any restraint (RST(I)) on credit for that customer, e.g., a lost credit card, check stop order or the like. Test 1 5 examines the restraint data field for that client (RST(I)) for a flag bit signalling that no charge for the subject item is to be permitted. Most simply, the restraint data field may be a limited array of binary "1 's" and "O's" where for example each "0" bit permits a transaction of an associated kind whereas a "1 " bit does not.If the restraint flag bit stops the transaction (YES output of test 1 5), block 1 8 generates an output message by signal light, teletype or the like which indicates that the requested authorization is not to be granted, and thus the transaction does not proceed.

In the usual case, the transaction will not be blocked (N# output of test 1 5) and a test 1 7 next determines whether the credit available to the subject i-th client is sufficient to accommodate the authorization inquiry then being processed, as by the inequality, CRDAV(I) > ADMD(I) (1: If there is insufficient credit available (N# output of test 1 7) a negative output message is produced by block 18; no further processing of the transaction occurs; and system processing flow returns to the START block 10 to await a next request.

Assuming that sufficient credit is available, i.e., that the inequality (1) above is satisfied, the available credit remaining to the client is decremented by the amount ADMD(I) of the expenditure for which authorization is sought (block 20), as by, CRDAV(I) = CRDAV(I) - ADMD(I). (2) Step 21 generates an affirmative response to the authorization request in any desired form, e.g., as before by illuminating an "APPROVED" light, printing an output message, or the like.

Approval/disapproval for a check item will cause the check to be paid (and the system operator's account at the payor bank to be debited) for the ADMD(I) account, or to be returned. A charge card request will permit the underlying charge transaction to proceed or to terminate - at least on a credit basis.

The fact of the affirmative authorization command ADMD(I) is placed in the client's file to maintain a client table of approved authorization requests (block 25). System control then returns to the START block 10 to await any subsequent authorisation for any system client.

The above processing thus either approves or disapproves an attempted client expenditure. When approved, the credit availability to the client (the contents of the storage address/processing variable CRDAV(I)) is decremented by the amount of the approved expenditure and a record of the authorization is maintained in the client file of all approvals. The pending authorizations are purged when matched with a completed transaction (MDMD(I)) processing discussed regarding Fig. 2 or after a period of time elapses to clear authorizations which never in fact resulted in expenditures - as when a retail customer obtained charge card approval but ultimately decided against a purchase.

Turning now to Fig. 2, there is shown data processing for accounting for expenses after they have in fact occurred, beginning with a conceptual START point 30. As a first matter (step 38), the subject monetary expenditure (MDMD(I)) is entered into the system. It is noted that MDMD(I) is normally positive, representing a monetary disbursement or expenditure such as a check or charge. The MDMD(I) variable is made negative for a client credit (e.g., a merchandise return for a credit card purchase in a retail charge situation, or a client check to make a fee or principle (or both) repayment). Fig. 2 processing in step 40 fetches from memory the total take down, i.e., the prior principle balance TD(I) of the customer, as well as his/her available credit variable CRDAV(I).

Test 42 determines whether or not the item MDMD(I) being processed is a principle payment. To constitute a principle payment, the item must be a negative expense, i.e., a credit, which may be determined by MDMD(I) < O (YES output of test 42). When this obtains test 43 determines whether or not the absolute value of the payment MDMD(I) exceeds the amount of the free TREES(I) which the customer owes. If not, the amount is simply credited against fees (step 46) and control returns to the start block 10 to begin processing anew.

If, however, the amount of the payment exceeds the fees, the fee amount TREES(I) is set to "O" (step 44) and the remainder RPY computed as the difference between the credit (the negative value of MDMD(I)) and the fee amount. This differential then reduces the outstanding loan value (step 48).

The next following step 50 reduces the credit availability of the customer by the amount RPY of repaid principle. This reduction (shown with an asterisk in step 50) is for a limited time only to prevent a bounced check or kiting situation. Thus, a fixed time later, e.g., seven days after principle repayment, credit availability is restored by the amount RPY. Following execution of the principle reduction steps 48 and 50, processing flows to step 60 to post the updated take down and available credit variables in computer memory following which system control returns to the starting point to process the next transaction.

Assume now the normal case where the transaction being processed is an actual charge and not a principle repayment (N~ output of test 42). The next following operation 55 decrements the credit available to the customer (CRDAV(I)) by the amount of the charge MDMD(I). Similarly, step 58 increases the amount of the client take down (TD(I)) by the amount of the charge MDMD(I). Following step 58, the updated circuit availability and client take down variables CRDAV(I) and TD(I) are stored in memory, i.e., posted in the memory file and system control returns to its starting point to process the next item.

Accordingly, Fig. 2 operation accommodates each executed monetary transaction, adjusting the appropriate customer's available credit and principle balance.

Finally, referring to Fig. 3, there is shown in schematic form a flow chart of periodic, e.g., monthly processing to update the subscriber accounts and to generate the data required for subscriber billing and billing statements. As a first matter for each particular subscriber functional block 72 initializes processing variables. The D parameter (number of days for constant loan balance TD(I)) is initialized to "1", indicating that the next iteration through the subscriber functional loop will be the first for a fixed, constant set of conditions. The insurance INSP(I), interest TINT(I) and running transactions sum TRANS variables are each initialized to "O".Block 75 sets the prevailing daily interest rate parameter RT to the appropriate value from a doubly indexed look-up table corresponding to the state where the real property security is located and the day of year value specified by S and DY. Day of year may be derived from an internal computer calendar and the state identity S is identified as by an information block corresponding to the i-th subscriber whose data is then being processed. Thus, the value of RT is the daily interest rate appropriate for a particular day for the customer then being processed. The computation value RTN is comparable to the RT parameter, but is the rate obtaining for the next day, and is used for limited comparison purposes below discussed.Block 77 extracts from the data file the transactions for the day of the year (DY) being considered (for the i-th client) by the subject initial interaction through the Fig. 3 upper loop.

Test 82 first determines whether or not a late fee must be charged, i.e., determines whether or not there has been a credit for processing for the i-th customer which has equaled or exceeded the total fees due at the beginning of the month as stored in ITFE(I). If a late charge is appropriate (YES output of test 82), the amount of fees TFEES(I) due from the client is incremented by the appropriate amount given by the product of the state-dependent late charge rate LTD(S) multiplied by the amount due at the beginning of the month ITFE(I) (block 85). If no late charge is incurred, as when the customer had paid the ITFE(I) amount prior to the assumed late fee date, a N~ output obtains for test 82 and in either event processing then flows to functional block 90.

In block 90, the running variable TRANS which accumulates the amount of transactional expenditures, is incremented by the day's transactions (if any) and test 93 determines whether or not there has been any change for interest billing purposes. More specifically, the amount of interest charge for the next day will change if either the prevailing interest rate RT changes (RTN * RT), or if the amount upon which interest is charged has changed which will occur if there have been any transactions. If neither of these change events occurs (YES output of test 93), the interest for the following day will be the same as the computer iteration previously processed since both the interest and principle balance are the same.Under these circumstances, block 96 increments by one the number of days (D variable) for which like or static principal balance and rate conditions obtain (corresponding to the number of iterations through the Fig. 3 common condition upper processing loop). Control then passes back to the block 75 to begin the next day processing.

Where, however, there has been a change (N~ output of test 93) control passes to the block 102 and subsequent operations. This processing branch is invoked when it is no longer possible to simply update interest for one more day with all other conditions remaining fixed.

As a first matter, the functional block 102 computes the insurance for the subject client by the product of his outstanding loan balance multiplied by the premium rate (PRT) and the number of days (D) for the common customer condition processing. This may be done as by, INSP(I) = TD(I) * PRT* D. (3) Functional block 102 also increments the subscriber's total take down or principle balance by the amount of the charged transactions (TRANS) and insurance premiums (under most state law, a proper loan principal item), TD(I) = TD(I) + TRANS + INSP(I). (4) The interest contribution for the previous common processing interval (step 105) is next updated by determining the product of the loan balance (TD(I)) times the rate obtaining (RT) times the number of days over which processing is being run as stored in the variable D, TINT(I) = TD(I) * RT * D. (5) Similarly, the fee variable TFEES(I) for the customer is updated (step 106), by this newly computed interest income, TFEES(I) = TFEES(I) + TINT(I). (6) The computational variables for the number of days or iterations of the loop for static conditions (D), the interest rate obtaining (RT), the total interest over the interval TINT(I) and the loan balance at the end of the interval (TD(I)) are then supplied as computational outputs (step 109).These variables are stored in memory and also provided as outputs as part of a reporting line over the time interval, i.e., over the Ddays either directly or, if desired, following all processing for the subscriber or all processing over the monthly or other accounting interval.

Test 1 10 determines whether or not all processing is finished for the i-th customer which is simply a matter of determining that the appropriate number of days in the month have been cycled through so that all transactions and charges for the customer are completed. If the customer processing is not completed (N~ output of test 1 10), processing returns to the block 72 to begin the above discussed iterative operation anew. When the processing resumes, the running variables D, INSP(I), TINT(I) and TRANS are re-initialized as above discussed to begin computation for the next day or series of days if common conditions prevail. This operation continues until account processing for the customer is completed, that is, until the account is processed for each day of the reporting period. Following this, (a YES output of test 1 10) control passes to a test 1 13.Test 1 13 returns system functioning to the beginning of block 72 to initiate work for the next (i + 1st) customer (as by simply incrementing the indexing variable I) until all customer accounts have been processed at which point the resulting YES output of test 1 13 directs processing to a FINISHED point 1 5 to begin the next computer task.

The above arrangement has thus been shown to process all of the system transactions over any desired periodic interval; to update all requisite variables during such processing, including the computer system charges for insurance, interest and the like; and to generate the parameters necessary for meaningful and complete output information for client reports. Moreover, the entire system as depicted in Figs. 1-3 provides a complete, flexible and integrated basis for access by an array of system clients to their loanable equity in an underlying asset or assets, and to unilaterally permit exercise of discretion to incur obligations against that credit on a demand basis in a variety of demand implementing forms.

The above-described arrangement is merely illustrative of the principles of the present invention.

Numerous modifications and adaptations thereof will be readily apparent to those skilled in the art without departing from the spirit and scope of the present invention.

Claims (7)

1. in combination in a system for processing and supervising a plurality of client equity access accounts each permitting client credit line charges via client-implemented charge means, credit authorization means responsive to client instituted charges for determining and for signalling whether the client's remaining credit availability is sufficient to accommodate the charge requested, credit availability storage means and loan balance storage means for each client account, executed transaction means for processing transactions authorized by said authorization means for decrementing the contents of said credit availability storage means and for incrementing the contents of said loan balance storage means, and account processing means for assessing interest charges responsive to the contents of said loan balance storage means, said credit authorization means comprising means for storing account restraint information, comparison means for comparing the amount for which authorization is requested with the amount stored for the requestor in said credit availability storage means, and means responsive to said comparison means and to the stored contents of said account restraining storing means for selectively providing an output authorization message.

2. In combination in a system for processing and supervising a plurality of client equity access accounts each permitting client credit line charges via client-implemented charge means, credit authorization means responsive to client instituted charges for determining and for signalling whether the client's remaining credit availability is sufficient to accommodate the charge requested, credit availability storage means and loan balance storage means for each client account executed transaction means for processing transactions authorized by said authorization means for decrementing the contents of said credit availability storage means and for incrementing the contents of said loan balance storage means, and account processing means for assessing interest charges responsive to the contents of said loan balance storage means, wherein said executed transaction means includes means for differentiating charges and principle repayments, and repayment processing means responsive to an interest repayment by decrementing the contents of said loan balance storage means.

3. A combination as in claim 2 wherein said repayment processing means includes means for decrementing said credit availability storage means, and means for restoring said credit availability storage means after a predetermined period of time.

4. A combination as in claims 2 or 3, wherein said executed transaction processing means further includes means for incrementing said loan balance storage means and for decrementing said credit availability storage means responsive to a differentiated charge item.

5. A combination as in claims 2, 3 or 4, wherein said credit authorization means comprises means for storing account restraint information, comparison means for comparing the amount for which authorization is requested with the amount stored for the requestor in said credit availability storage means, and means responsive to said comparison means and to the stored contents of said account restraining storing means for selectively providing an output authorization message.

6. A combination as in claim 1 or 2 wherein said client/implemented charge means includes checking means and credit card means.

7. A processing system substantially as herein described with reference to and as illustrated in the accompanying drawings.