« PreviousContinue »
SECURITIES BROKERAGE-CASH MANAGEMENT SYSTEM WITH SHORT TERM INVESTMENT PROCEEDS ALLOTTED AMONG MULTIPLE
This application is a continuation-in-part of co-pending application Ser. No. 430,670 for "SECURITIES BROKERAGE-CASH MANAGEMENT SYSTEM" filed 9-30-82, now U.S. Pat. No. 4,597,046, which, in 10 turn, is a continuation-in-part of application Ser. Nos. 173,331, filed 7-29-80, and 199,408, filed 10-22-80, now U.S. Pat. Nos. 4,346,442 and 4,376,978, respectively. The disclosure of such applications and patents is hereby incorporated herein by reference. '15
DISCLOSURE OF THE INVENTION
This invention relates to financial business systems and, more specifically, to data processing methodology and apparatus for effecting an improved securities bro- 20 kerage and cash management system.
It is an object of the present invention to provide an improved brokerage/cash management system.
More specifically, it is an object of the present invention to provide a data processing implementation for a 25 brokerage-cash management financial system which provides for automatic investment of free credit cash balances in short term investments which include an insured savings account option; a full range of security brokerage transaction functions; which permits con- 30 sumer transaction ("charge") card and check charges; and which includes safeguards against abuses, e.g., check kiting.
The above and other objects of the present invention are realized in specific illustrative improved securities 35 brokerage-cash management system for supervising, integrating and coordinating a margin securities brokerage account; participation in one or more short term investments; and subscriber-initiated use of a transaction charge card and/or checks. Subscriber expenditures as 40 by charge card use, check, and/or cash advance are applied on a hierarchal basis against the subscriber's free credit cash balance, short term investment and, finally, his securities equity. On a periodic basis, e.g., daily, received card, check, securities and deposit transactions 45 for the ensemble of account participants are verified and employed to compute an updated credit limit for each subscriber.
In accordance with one aspect of the present invention, the short term investments available to subscribers 50 include an ordered ensemble of insured savings accounts.
The foregoing and additional features and advantages of the instant invention will become more readily apparent from the following detailed description of a specific 55 illustrative embodiment thereof, presented hereinbelow in conjunction with the accompanying drawing, in which:
FIGS. 1A and IB are respectively the upper and lower portions of a schematic flow chart depicting the 60 data processing methodology and structure in accordance with the principles of the present invention for an improved brokerage/cash management system of accounts;
FIG. 2 is a flow chart depicting data processing for 65 the credit limit updating and overdraft functional blocks 26, 31 and 33 of the FIG. 1 overall data processing disclosure;
FIG. 3 is a flow chart illustrating updating a short term investment position functional block 45 of FIG. 1; and
FIG. 4 is a flow chart depicting representative insured savings account processing 68 of FIG. 1.
Referring now to FIG. 1, there is shown in overall scope a data processing and system operational flow chart for implementing an improved securities brokerage/cash management system incorporating the principles of the present invention. As contemplated by the present invention, there are three fundamental aspects of service offered to each of plural system subscriber. At the kernel of the overall system is a margin brokerage account in which each customer may effect the usual diverse array of securities and related transactions—e.g., those offered by a full service brokerage house. As a second facet, there is at least one and in general a plurality of vehicles for short term investment of funds, e.g., pooled trusts and, importantly for present purposes, insured savings accounts ("ISA"). These investment accounts and/or trusts, managed by a bank, fiduciary or custodian with ancillary services possibly furnished by an investment advisor or the like, provide each system subscriber with one or more ways of earning yield on funds not then required for other purposes herein discussed. Such excess funds may be generated by subscriber deposits; by dividends or interest paid on securities in the subscriber's brokerage account; may represent proceeds of sale, securities redemption or like transactions in the brokerage account; or the like. The third and final aspect of the instant system arrangement comprises a transaction ("charge") card and a checking account. The transaction card is usable at the subscriber's sole discretion, under his control, to charge goods and services offered by those accepting the charge card. The charge card may be independent or may be affiliated with some charging system, e.g., the well known "VISA" charge system. The bank checks require no explanation and are simply payment orders drawn against the bank. The check amounts are satisfied from the subscriber's free credit balance, short term investment position or his securities margin account in that order.
By way of brief overall philosophy, charges created by the transaction card and checks drawn against the bank are accumulated by the bank and transmitted to the brokerage house. The brokerage house establishes a credit limit against which each subscriber may use his transaction card and bank checks. The credit limit applicable to each subscriber is in the most fundamental of terms the value of the subscriber's free credit cash as represented by free cash in the brokerage account and by the subscriber's short term investment(s), plus the remaining loanable value of the subscriber's securities. A more precise statement of credit limit and the data processing methodology to determine same is set forth below. Any income or receipts for the subscriber's account, e.g., dividends, interest, sale or redemption proceeds from a securities account or the like, are applied to the overall subscriber's account in a predetermined, hierarchal manner to offer the subscriber either a maximized return or a minimum interest charge. In particular, any received or generated funds are first applied to reduce or eliminate any subscriber overdrafts. Following this, the funds or any remaining portion thereof reduce the subscriber's margin balance. Any excess as a general matter is then automatically invested for the subscriber in the one or more short term investment
vehicles which the subscriber has selected or is entitled to pursue.
Correspondingly, when funds are required of the subscriber to satisfy any transaction or check charges or the like, they are obtained from the composite sub- 5 scriber account in a hierarchal, priority sequence least negatively impacting the customer. Such funds exceeding yet uncommitted brokerage account cash are first obtained by liquidation of the appropriate short term investments. Any excess requirement is then generated 10 in the form of a margin loan against the subscriber's securities. Should this be insufficient, the overage takes the form of an overdraft loan by the bank to the subscriber subject to the bank's discretion and willingness to provide such an overdraft loan. 15
With the above overview in mind attention will now be directed to FIGS. 1A and IB herein, referred to as composite FIG. 1, which is a schematic flow chart in overall scope of the data processing of the instant invention for effecting the above described operations. The 20 functional blocks 26,31, and 33,45, and 68 of FIG. 1 are expanded in the more detailed level flow charts of FIGS. 2-4, respectively.
Beginning at the top of FIG. 1, the bank first transmits to the brokerage central processing unit a record of 25 all transactional information for each of the system subscribers, together with subscriber identification. Thus, each entry will include a subscriber identification, and transactional information such as a transaction card charge or credit (e.g., credit for returned charged mer- 30 chandise) or a check identification and amount (functional block 10). A cross reference file 13 is maintained at the brokerage central processing unit of system subscribers, this being updated by manual or automatic entries 12. The incoming transactional information from 35 the bank is verified at functional block 14. The verification assures (i) that the reported transaction is for a subscriber who is in fact known to and authorized by the system; and (ii) it verifies transmission and accuracy of the incoming information—e.g., by the per se well 40 known system of verifying totals across batched lots of fixed, predetermined size of incoming transactional records.
Most typically, the verification will prove out ("N0" output of "OUT-OF-BALANCE" test 15), and system 45 flow passes to the next following test 20 to assure that the customer is identified in the master file which also will typically be a test that is satisfied ("YES" output of block 20). If, however, test 15 fails ("YES" output), the OUT-OF-BALANCE total is corrected from a sus- 50 pense account (block 17), and a printed report of the discrepancy generated (function 18) before passing to the next following customer verification. Similarly, if test 20 fails, a proper identity is created in the Master File for the customer whose transaction is being pro- 55 cessed, and system flow passes for succeeding operations. Finally for initializing processing, manual transaction entry 22 is employed to correct items needing manual intervention to account for errors, fraud items, stolen checks, or the like. 60
Following such reception and verification of incoming items, the received transactional information is employed in functional block 26 to compute or update the then obtaining credit limit for each customer. As above noted, the functions performed by the block 26 are set 65 forth in expanded detail in the flow chart of FIG. 2 discussed below. In brief terms at this point, it is the office of processing for block 26 to provide a credit
limit computational variable CRDLT(I) which is the credit remaining available to each of the I customers or subscribers to the system. That is, CRDLT(I) is the amount of credit remaining to the I-indexed customer for use of his transaction card and checks. This credit limit CRDLT(I) is reported for each customer to the bank for purposes of honoring charges, checks, credit advances and the like. For convenience and conciseness of presentation, all indexed variables (such as CRDLT(I) above discussed) are sometimes shown without their index. It will readily be appreciated that all per-subscriber variables are in fact so indexed. Further for ISA processing set forth below, doubly indexed variables (I-for subscriber; J-for bank) are utilized.
The functional block 26 is supplied with all customary brokerage data stored in a brokerage account data file 27. The particular ensemble of variables supplied to the credit limit computational processing 26 via file 27 are set forth in detail below in conjunction with the FIG. 2 expanded presentation of credit limit computation. In very brief terms, they include such as the short term (e.g., ISA and/or money market) investment position of each subscriber, the worth of his securities in the brokerage account, margin buying or loan power, and the like. The file 27 is as above noted maintained in the customary fashion in the brokerage house to reflect the customer's status. As one additional external entry (functional block 28), the short term investment dividends and interest earned for the customer is periodically reported and reflected at the customer's storage in the account data file 27.
As part of credit limit updating, the customer's account is examined for an overdraft condition (test 31). Overdraft examination and processing is also set forth in detail in the FIG. 2 processing. If the customer has overdrawn his account, i.e., overdrawn his "credit limit", a temporary loan is extended to the customer (functional block 33). The customer is notified of the overdraft condition and required to clear the overdraft unless the bank is willing to extend a loan to the customer in a manner de hors his brokerage account and the FIG. 1 system.
Following credit limit functioning, the ensemble of credit limit variables CRDLT are supplied to the bank (function 29). This list of customer credit limits is employed at the bank to limit the credit available in its several forms to each of the subscribers, i.e., to limit the aggregate of usage of the customer charge card, checks and cash advances (via the card or check) which are supportable, from the customer's assets. As a further matter, and as part of the functioning block 26, the credit limit variable also updates each customer's record in the master file (operation 122, FIG. 2).
A history file or stored record is kept of the customer's transactions (block 35) for various purposes, including preserving data to generate periodic monthly statements. Following this, tests 37 and 39 operate on the historical transactional data for the customer to flag possible system abuses, e.g., check "kiting" where deposits are made to obtain money market interest, and the deposited proceeds withdrawn to cover the initial check before it clears. To uncover and prevent repetitive such abuses and others, the tests 37 and 39 respectively determine whether or not three substantial deposits (test 37) or withdrawals (test 39—e.g., card charges, cash advances or checks) exceeding some predetermined threshold such as $10,000 have occurred within a predetermined time period such as one month. If either
of the tests 37 or 39 is answered in the affirmative, an output report is printed 40 to signal the incidence as a matter for investigation. Thus, for example, a dump of the entire account history might take place for evaluation. 5
The overall program flow next passes to operation 45 to selectively update the short term investment position (increment or decrement) depending upon whether excess cash has been generated by subscriber transactions and should be placed for short term investment; or 10 whether cash is required for varying purposes. Again, detailed processing for the functional routine 45 is set forth in FIG. 3, which will be described in detail hereinbelow. Accordingly, functioning for the block 45 is discussed only briefly at this point in overview. The 15 processing 45 is supplied with several variables such as manual entries 48 which might reflect monetary deposits by the customer with short term investment buy instructions; is supplied with master file information for all customers at block 49; and is finally supplied with 20 information at block 43 reflecting security transactions (e.g., as part of the per se normal brokerage account data file). The output of update money market position processing 45 are a buy vis-a-vis sell variable for each account, together with the amount to be bought and 25 sold.
As above noted, each system subscriber has the option to participate in one or more of several short term investment opportunities. To this end, test 65 determines whether these customers' excess funds are to be 30 invested in an insured savings account. If they are not, i.e., if the subscriber whose account is then being processed has opted for one or more of the other funds to the exclusion of ISA participation, one or more additional tests 53 determine the proper short term invest- 35 ment money market account for the customer and a report is then generated to the custodian of the appropriate money market trust to reflect the increase/decrease for the subject customer. Thus, for the assumed situation of one taxable and one tax free money market 40 funds (in addition to the insured savings account), if test 53 determines from the subscriber's data block that a tax free (or some other) money market fund has been elected as the customer's primary short term investment vehicle, block 57 issues an appropriate data report to the 45 custodian for the tax free money market trust. Correspondingly, if test 53 notes a taxable trust election by the customer, block 55 issues a data report to the custodian of that trust.
Assuming that block 65 confirms that the customer 50 has opted to have his short term investments in an insured savings account (i.e., money market deposit ("MMDA") account insured by the Federal Deposit Insurance Corporation, or Federal Savings and Loan Insurance Corporation, test 65 supplies a "YES" deter- 55 mination. There follows one or more functional block 68(J) associated with the processing of the subscriber's short term investment at that specific (J-th) bank. More specifically, by government regulation, there is a limit (currently $100,000) on federal insurance for the money 60 market deposit account at any one banking institution. Accordingly, for each system subscriber there is an ordered hierarchy of banks in which the subscriber's short term investment is placed such that the subscriber deposits do not exceed the $100,000 limit in any institu- 65 tion. Thus, for subscribers with less than $100,000 in short term investable funds, only one bank need be involved such that only one functional block 68 is in
voked for that subscriber. As the subscriber's deposit grows near or above the insurance threshold (preferably with a margin as discussed below), other functional blocks 68 associated with other banks are called upon. Suffice it for present summary description purposes, the incremental funds to be added to or removed from the customer's insured money market deposit account(s) are accommodated by iterative operation of one or more of the similar bank processing functional routines 68. As part of such processing, reports are generated to the respective institution(s) for deposit/liquidation purposes.
Finally, the short term investment transactions are reported to the account data processing 60 to update each subscriber's account data file; are employed to update the subscriber's master file (61); and are used to update the customer's local data base (step 62) as in his local brokerage office.
That completes the data processing in overview for one complete operation of the system, as for a daily iteration. The next following day, the system will reexecute the functional operations of FIG. 1 employing the new set of operands generated during the day following the previous iteratin in the manner above discussed.
Referring now to FIG. 2, there is shown a detailed flow chart for credit limit updating and overdraft processing corresponding to functional blocks 26, 31 and 33 of composite FIG. 1. It is again the overall purpose of the FIG. 2 flow chart to generate the credit limit variable CRDLT for each of the I-system customers to reflect the remaining available worth of that customer's assets. For purposes of FIG. 2 processing, the following variables (again, all indexed by subscriber but shown without index which remains understood) are employed:
CKS, CRGS, CASHAV, CREDT
Special and miscellaneous value of
the customer's account, reflecting
the customer's borrowing power
based on the securities he holds
in his brokerage account. This is
measured as the then obtaining
percentage of the value of the
customer's brokerage assets as
established by Regulation T of the
Federal Reserve Board. The
presently obtaining value, for
example, is 50% for common stocks.
Firm maintenance excess of the
customer's account representing
the customer's borrowing power
based upon the brokerage house
definition of the loan value of
the customer's securities. A
typical presently obtaining value
might be 70% of the security
The value of the customer's short
term investment fund account.
The value of the checks, charges,
cash advances, and credits
respectively, reported by the bank
for the interval since the
Represents the amount of any
Regulation T call against the
The amounts of any maintenance
call against the account.
This variable represents the cash
required for transactions in the
customer's securities cash account.