US8392304B1 - Method, system and computer program product for managing funds in custodial deposit accounts - Google Patents

Method, system and computer program product for managing funds in custodial deposit accounts Download PDF

Info

Publication number
US8392304B1
US8392304B1 US13/245,538 US201113245538A US8392304B1 US 8392304 B1 US8392304 B1 US 8392304B1 US 201113245538 A US201113245538 A US 201113245538A US 8392304 B1 US8392304 B1 US 8392304B1
Authority
US
United States
Prior art keywords
individual
omnibus
funds
mmda
balance
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
US13/245,538
Inventor
Douglas E. Phillips
Robert N. Hyland
Anthony R. Carlino
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intrafi LLC
Original Assignee
Promontory Interfinancial Network LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Promontory Interfinancial Network LLC filed Critical Promontory Interfinancial Network LLC
Priority to US13/245,538 priority Critical patent/US8392304B1/en
Priority to US13/774,239 priority patent/US8744942B1/en
Application granted granted Critical
Publication of US8392304B1 publication Critical patent/US8392304B1/en
Assigned to MORGAN STANLEY SENIOR FUNDING, INC., AS COLLATERAL AGENT reassignment MORGAN STANLEY SENIOR FUNDING, INC., AS COLLATERAL AGENT PATENT SECURITY AGREEMENT (FIRST LIEN) Assignors: PROMONTORY INTERFINANCIAL NETWORK, LLC
Assigned to MORGAN STANLEY SENIOR FUNDING, INC., AS COLLATERAL AGENT reassignment MORGAN STANLEY SENIOR FUNDING, INC., AS COLLATERAL AGENT PATENT SECURITY AGREEMENT (SECOND LIEN) Assignors: PROMONTORY INTERFINANCIAL NETWORK, LLC
Assigned to PROMONTORY INTERFINANCIAL GROUP, LLC reassignment PROMONTORY INTERFINANCIAL GROUP, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CARLINO, ANTHONY R., HYLAND, ROBERT N., PHILLIPS, DOUGLAS E.
Assigned to INTRAFI NETWORK LLC reassignment INTRAFI NETWORK LLC CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: PROMONTORY INTERFINANCIAL GROUP, LLC
Assigned to INTRAFI NETWORK, LLC (F/K/A PROMONTORY INTERFINANCIAL NETWORK, LLC) reassignment INTRAFI NETWORK, LLC (F/K/A PROMONTORY INTERFINANCIAL NETWORK, LLC) RELEASE (REEL 050988 / FRAME 0969) Assignors: MORGAN STANLEY SENIOR FUNDING, INC.
Assigned to NOMURA CORPORATE FUNDING AMERICAS, LLC, AS COLLATERAL AGENT reassignment NOMURA CORPORATE FUNDING AMERICAS, LLC, AS COLLATERAL AGENT SECURITY AGREEMENT (2ND LIEN) Assignors: INTRAFI NETWORK, LLC
Assigned to INTRAFI LLC reassignment INTRAFI LLC CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: INTRAFI NETWORK LLC
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12Accounting

Definitions

  • the present invention relates generally to the management of financial accounts and more particularly, to a method, system and computer program product for managing funds in custodial deposit accounts.
  • deposit accounts may be established at one or more depository institutions by an agent and/or custodian on behalf of a plurality of customers.
  • deposit accounts are referred to herein as “omnibus” deposit accounts.
  • the agent and/or custodian responsible for establishing and holding such deposit accounts may be, for example, a broker-dealer registered under the Securities Exchange Act of 1934 as amended (referred to herein as a “broker-dealer”), another depository institution, a credit union, or another regulated financial institution.
  • broker-dealer a broker-dealer registered under the Securities Exchange Act of 1934 as amended
  • custodian is referred to herein as a “custodial agent”.
  • Custodial agents that are registered broker-dealers typically offer their customers various types of liquid investments into which customer “free credit balances,” as defined in Rule 15c3-3 adopted by the SEC pursuant to the Exchange Act, are automatically invested, or “swept,” from a customer's brokerage account.
  • a free credit balance is created in a customer's brokerage account when the customer sells investments in the account the customer receives interest or dividend payments on investments in the account or the customer deposits funds in the account.
  • broker-dealers can offer to automatically invest, or “sweep,” customers' free credit balances into liquid investments. If the customer then needs funds to settle securities transactions or for cash management activity, the broker-dealer withdraws funds to cover such transactions.
  • An automated service that sweeps customers' end-of-day cash, for example, into an interest-bearing account affords customers an opportunity to receive interest on excess cash that would otherwise not earn interest.
  • Broker-dealers also commonly offer customers check-writing, debit card and other cash management features in connection with brokerage accounts. Debits in a customer's brokerage account created by check, debit card, purchases of securities or other transactions are typically satisfied from available cash balances, funds in the customer's sweep investment and, if applicable, margin credit. A sweep investment, therefore, may be offered to a broker-dealer's customers as part of a cash management component of a brokerage account.
  • FDIC Federal Deposit Insurance Corporation
  • the FDIC currently insures deposits up to $100,000 per depositor in any one insured depository institution for many insurable capacities (e.g., individual accounts and joint accounts) and up to $250,000 for IRAs and certain self-insured employee benefit plans.
  • the basic deposit insurance limit was temporarily raised on Oct. 3, 2008 by the Emergency Economic Stabilization Act of 2008 from $100,000 to $250,000 per depositor. This increase is scheduled to end and return to $100,000 per depositor after Dec. 31, 2009.
  • One option for broker-dealers and other custodial agents is for the custodial agent to place customer funds in a plurality of depository institutions in amounts that do not exceed the deposit insurance limit for each customer at each depository institution, permitting customer funds to be eligible for insurance coverage in excess of the basic FDIC limit.
  • a sweep arrangement in which customer funds are placed in deposit accounts at a plurality of depository institutions can benefit participating depository institutions by providing a large, stable source of deposits.
  • a multi-bank sweep arrangement can also benefit customers, by offering additional investment opportunities together with increased access to FDIC deposit insurance protection. Even without regard to FDIC deposit insurance protection, a multi-bank sweep arrangement can spread and thereby mitigate risk and can provide greater access to competitive returns.
  • Swept customer funds that are placed in deposit accounts at a plurality of depository institutions may be deposited in interest-bearing money market deposit accounts (“MMDAs”), however, such MMDAs are not transaction accounts.
  • MMDAs interest-bearing money market deposit accounts
  • Regulation D of the Board of Governors of the Federal Reserve System (“Regulation D”) limits transfers from an MMDA to six per calendar month or other statement cycle. Accordingly, funds swept into MMDAs must be properly managed so that transfers from MMDAs are in compliance with transaction limits.
  • the present invention is directed to a method, system and computer program product for managing aggregate funds held in custodial deposit accounts by a custodial agent on behalf of a plurality of individuals.
  • the custodial deposit accounts comprise an omnibus transaction account (“Omnibus TA”) and an omnibus money market deposit account (“Omnibus MMDA”).
  • Omnibus TA omnibus transaction account
  • Omnibus MMDA omnibus money market deposit account
  • a corresponding individual transaction account (“Individual TA”) and individual money market deposit account (“Individual MMDA”) are kept on the books and records of the custodial agent for each individual, representing the amount of the individual's funds deposited in the Omnibus TA and Omnibus MMDA, respectively.
  • transfers from the Omnibus MMDA to the Omnibus TA are reduced by daily allocation of the funds in the Individual TAs and Individual MMDAs, thereby decreasing the likelihood that an established transfer limit for the Omnibus MMDA (e.g. the limit of six transfers per month in Regulation D) will be reached.
  • an established transfer limit for the Omnibus MMDA e.g. the limit of six transfers per month in Regulation D
  • an Individual TA data set comprising Individual TA data representative of the amount of the individual's funds allocated to the Omnibus TA and an Individual MMDA data set comprising Individual MMDA data representative of the amount of the individual's funds allocated to the Omnibus MMDA are established for each individual in a memory of a computer.
  • an Omnibus TA data set representative of the amount of the aggregate funds allocated to the Omnibus TA and an Omnibus MMDA data set representative of the amount of the aggregate funds allocated to the Omnibus MMDA are established in the memory of the computer.
  • a processor of the computer receives individual transaction data representative of individual withdrawals and/or deposits by one or more of the plurality of individuals.
  • the processor modifies the Individual TA data and the Individual MMDA data for one or more of the plurality of individuals to reflect a net change to the amount of the individual's funds allocated to the Omnibus TA and the Omnibus MMDA, respectively, based on the received individual transaction data and stores the modified Individual TA data in the Individual TA data set and the modified Individual MMDA data in the Individual MMDA data set. Thereafter, the processor compares the Individual MMDA data and the Omnibus MMDA data, calculates a net adjustment to be made to the amount of funds in the Omnibus MMDA, and stores the net adjustment in a memory of the computer.
  • the processor compares the net adjustment to the Omnibus TA data and, if said net adjustment is a negative net balance change in an amount not greater than the amount of funds in the Omnibus TA, the processor further modifies the Individual TA data and the Individual MMDA data for one or more of the plurality of individuals to offset the net adjustment and stores the further modified Individual TA data in the Individual TA data set and the further modified Individual MMDA data in the Individual MMDA data set. Then, the processor modifies the Omnibus TA data based on the Individual TA data stored in the Individual TA data set and modifies the Omnibus MMDA data based on the Individual MMDA data stored in the Individual MMDA data set.
  • a processor receives net daily transaction data for one or more of the plurality of individuals representative of a net daily withdrawal from or a net daily deposit to the custodial deposit accounts and stores the net daily transaction data in a memory of a computer.
  • the processor derives a net balance change data for the Omnibus MMDA from the net daily transaction data and stores the derived net balance change data in the memory.
  • the processor compares the derived net balance change data to data representing the amount of funds in the Omnibus TA and, if the derived net balance change data is a negative net balance change in an amount not greater than the amount of funds in the Omnibus TA, the processor modifies the Individual TA data and the individual MMDA data for one or more of the plurality of individuals to offset the net adjustment and stores the further modified Individual TA data in the Individual TA data set and the further modified Individual MMDA data in the Individual MMDA data set. Then, the processor modifies the Omnibus TA data based on the Individual TA data stored in the Individual TA data set and modifies the Omnibus MMDA data based on the Individual MMDA data stored in the Individual MMDA data set.
  • a processor allocates a percent greater than 0% of the aggregate funds to the Omnibus TA, such that each of the individuals has funds allocated to both the Omnibus TA and the Omnibus MMDA. Thereafter, the processor receives net daily transaction data for one or more of the plurality of individuals representative of a net daily withdrawal from or a net daily deposit to the custodial deposit accounts and stores the net daily transaction data in a memory of a computer. The processor determines whether the net daily transaction data will result in an aggregate transfer of funds from the Omnibus MMDA to the Omnibus TA.
  • the processor modifies the Individual TA data and the Individual MMDA data for one or more of the plurality of individuals to offset the net adjustment and stores the further modified Individual TA data in the Individual TA data set and the further modified Individual MMDA data in the Individual MMDA data set. Then, the processor modifies the Omnibus TA data based on the Individual TA data stored in the Individual TA data set and modifies the Omnibus MMDA data based on the Individual MMDA data stored in the Individual MMDA data set.
  • FIG. 1 is a block diagram of an exemplary deposit sweep program according to the present invention.
  • FIG. 2 is a flowchart providing one embodiment of a process for allocating funds in Individual TAs and Individual MMDAs.
  • FIG. 3 is a flowchart providing one embodiment of a process for allocating aggregate funds in an Omnibus TA and an Omnibus MMDA.
  • FIG. 4 is a flowchart providing one embodiment of a rebalancing process for allocating funds in Individual TAs and Individual MMDAs at the beginning of each month or statement cycle.
  • FIG. 5 is a block diagram of an exemplary computer system useful for implementing the present invention.
  • FIG. 6A provides a table representative of data produced by an exemplary deposit sweep engine processor managing custodial deposit accounts according to one embodiment of the present invention for a first day.
  • FIG. 6B provides a table representative of data produced by an exemplary deposit sweep engine processor managing custodial deposit accounts according to one embodiment of the present invention for a second day.
  • FIG. 6C provides a table representative of data produced by an exemplary deposit sweep engine processor managing custodial deposit accounts according to one embodiment of the present invention for a third day.
  • FIG. 6D provides a table representative of data produced by an exemplary deposit sweep engine processor managing custodial deposit accounts according to one embodiment of the present invention for a fourth day.
  • FIG. 6E provides a table representative of data produced by an exemplary deposit sweep engine processor managing custodial deposit accounts according to one embodiment of the present invention for a fifth day.
  • FIG. 6F provides a table representative of data produced by an exemplary deposit sweep engine processor managing custodial deposit accounts according to one embodiment of the present invention for a sixth day.
  • FIG. 6G provides a table representative of data produced by an exemplary deposit sweep engine processor managing custodial deposit accounts according to one embodiment of the present invention for a seventh day.
  • FIG. 6H provides a table representative of data produced by an exemplary deposit sweep engine processor managing custodial deposit accounts according to one embodiment of the present invention for an eigth day.
  • the present invention manages funds held in custodial deposit accounts so as to limit transfers of funds from money market deposit accounts at both the individual and omnibus account levels in a dual account structure to a specified number per month or other statement cycle, as may be required by regulation, while preserving customer access to funds through transaction accounts with unlimited transfers. Transfers are limited for both the Individual MMDA and the Omnibus MMDA through managed allocation of funds in Individual TAs and Individual MMDAs.
  • each custodial agent establishes a money market deposit account (“MMDA”) and a transaction account (“TA”) with each depository institution in the name of the custodial agent as agent and/or custodian for its customers.
  • MMDA money market deposit account
  • TA transaction account
  • Omnibus MMDA Omnibus TA
  • Omnibus MMDA Omnibus TA
  • OTA Omnibus MMDA
  • the Omnibus MMDA is subject to lower reserve requirements than the Omnibus TA. Accordingly, it is desired that a maximum of the deposited funds at each depository institution be placed in the Omnibus MMDA. Regulation D currently limits transfers from money market deposit accounts to six per calendar month or other statement cycle.
  • a set percent of the deposited funds is retained in the Omnibus TA, as discussed further below, as a cushion to satisfy withdrawals.
  • the percent of the deposited funds retained in the Omnibus TA is referred to herein as the target OTA percent (TTP).
  • IMMDA Intelligent MMDA
  • ITA Intelligent TA
  • IMMDA Individual MMDA
  • ITA Intelligent TA
  • fund withdrawals to outside entities are directed from the Individual TA and the entire balance in the Individual MMDA account is transferred to the Individual TA before the customer exhausts the monthly transfer limit.
  • the Individual TA may be, for example, a negotiable order of withdrawal (NOW) account.
  • each depository institution agrees to pay an “all-in cost of funds” in respect of the money held in the custodial deposit accounts.
  • the “all-in cost of funds” may be based on the Federal Funds Effective Rate plus a set basis point spread.
  • This “all-in cost of funds” can then be allocated into interest to be paid into the custodial deposit accounts and fees paid to the custodial agent and/or others involved in the maintenance and operation of the deposit sweep arrangement, such as a third party manager or administrator.
  • Interest paid into the custodial deposit accounts is allocated to the Individual MMDAs and the Individual TAs on the books and records of the custodial agent, as would be apparent to one of ordinary skill in the art, based on each customer's individual account balances.
  • Each customer earns interest on all funds deposited in the IMMDA and the ITA. Accordingly, it is irrelevant to the customer whether the customer's swept funds are allocated to the customer's Individual MMDA or to the customer's Individual TA.
  • Custodial agents may place customer funds in a plurality of depository institutions in amounts that do not exceed the deposit insurance limit for each customer at each depository institution, permitting customer funds to be eligible for insurance coverage in excess of the basic FDIC limit. To the extent a customer has funds swept into more than one depository institution, the custodial agent will maintain separate Individual TA and Individual MMDA accounts on its books and records for the customer corresponding to the Omnibus TA and Omnibus MMDA at each depository institution. In one embodiment, customer funds are deposited and withdrawn at one or more depository institutions according to a first in first out (FIFO) accounting basis.
  • FIFO first in first out
  • transfer limitations such as the limitation under Regulation D of 6 transfers per month or other statement cycle, can be managed for both the Individual MMDA and the Omnibus MMDA by managed allocation of funds in the Individual TAs and Individual MMDAs, as described below with respect to FIGS. 2-4 .
  • FIG. 1 is a block diagram providing an overview of the flow of customer funds in an exemplary deposit sweep arrangement 100 according to the present invention.
  • Deposit sweep arrangement 100 includes a broker-dealer back office service provider 102 , a deposit sweep engine 104 , a settlement agent 106 and one or more depository institutions 108 .
  • deposit sweep engine 104 is operated by a third party agent or administrator that reports to both the custodial agent and the depository institutions. The agent or administrator manages transfers of funds between the individual sweep accounts of each customer and the custodial accounts held at the depository institutions.
  • deposit sweep engine 104 may be implemented using hardware, software or a combination thereof and may be implemented in one or more computer systems or other processing systems.
  • deposit sweep engine 104 allocates funds deposited in the Omnibus TA and Omnibus MMDA and allocates funds within Individual TAs and Individual MMDAs, representing each individual's portion of the aggregate funds deposited in the custodial deposit accounts as recorded on the books of the custodial agent, and provides instructions to the depository institutions and custodial agent as to the allocation of such funds.
  • Back office service provider 102 collects brokerage activity and cash management activity of customers of the broker-dealer and transmits net customer transactions to sweep engine 104 .
  • Sweep engine 104 performs a daily sweep, for example, at night. Sweep engine 104 optimizes swept balances for FDIC insurance coverage and bank network requirements. The allocation and posting processing of sweep engine 104 is further discussed below with respect to FIGS. 2-4 .
  • Sweep engine 104 transmits aggregate transactions to settlement agent 106 .
  • Settlement agent 106 provides an interface to the bank network on an aggregate level (e.g., omnibus level rather than customer level).
  • Settlement agent 106 sends aggregate funds flow to one or more depository institutions 108 in the bank network. Settlement agent 106 processes aggregate transactions daily for example, at night. Aggregate funds are invested in omnibus accounts at each depository institution 108 .
  • communication of information between the various components of deposit sweep arrangement 100 is accomplished over a network consisting of electronic devices connected either physically or wirelessly, wherein digital information is transmitted from one device to another.
  • Such devices may include, but are not limited to, a desktop computer, a laptop computer, a handheld device or PDA, a telephone, a set top box, an Internet appliance, or the like.
  • Exemplary networks include a Local Area Network, a Wide Area Network, an organizational intranet, the Internet, or the like. The functionality of an exemplary computer and network are further explained in conjunction with FIG. 5 , below.
  • System balancing is divided into five phases that serve as building blocks on each other starting with the net daily activity received from back-office service provider 102 and concluding with settlement agent 106 reconciliation. By dividing this process into phases it is possible to detect an out-of-balance condition before starting the end of day funds transfer process.
  • the first phase balances the data received from the broker-dealer back office service provider against the data accepted by the sweep engine.
  • All inbound activity files contain a trailer record that stores the number of records on the file and the total of all debit and credit transactions.
  • the three data values referenced are internally computed and stored.
  • the inbound activity file processing is complete the internally computed record count, aggregated debit and credit transactions are matched to the values stored on the inbound trailer record. These values must be in agreement for processing to continue.
  • the sweep engine will begin core processing or allocation of the net daily activity, described below with respect to FIGS. 2-4 .
  • a second balancing phase occurs during the allocation and posting process, when the sweep engine internally counts the number of transactions received and accumulates the value of credits and debits received. At the conclusion of the processing, these values are compared against the retained control totals from an internal transmission balancing process. This is done to confirm that all transactions provided to the sweep engine have either been posted to the account or, in the case of an error, duly reported.
  • the sweep engine will create a funds transfer report detailing the allocation of the daily activity among the various depository institutions.
  • the total sum of funds allocated across these depository institutions should balance to the net total of credits and debits processed in the allocation and posting phase.
  • the settlement agent After the final allocation and posting of daily activity transactions, the settlement agent will receive an electronic transmission of wire instructions from or on behalf of the custodial agent. The wires will be posted to a settlement account pending transmissions to/from the depository institutions.
  • a fourth balancing phase occurs at the conclusion of the day, when the settlement account is reconciled to validate that all transmissions have been completed and that expected funds from the depository institutions were received. The net balance of the settlement account should equal the net total on an expected funds settlement balancing report.
  • the custodial accounts balances and accrued interest from the depository institutions will be obtained for balancing against derived aggregate deposit balances (e.g., as calculated by applying the all-in rate to the individual account balances) stored within the sweep engine.
  • the first three phases of reconciliation described above can be monitored and verified by a series of daily reports.
  • the settlement agent contracts with the custodial agent to perform the fourth level of reconciliation described above utilizing standard reconciliation processes which include daily verification of “zero balances” in all settlement accounts.
  • the fifth phase of reconciliation may be performed by utilizing a reconciliation dashboard, such as disclosed in pending U.S. patent application Ser. No. 11/556,662, incorporated herein by reference in its entirety
  • Regulation D limits transfers from an MMDA account to six per month or other statement cycle.
  • sweep engine 104 manages allocation of funds swept into the Individual and Omnibus TAs and MMDAs on a daily and monthly (or other periodic) basis, so that transfers from the Individual and Omnibus MMDAs are limited.
  • the allocation and posting processing are incorporated into deposit sweep engine 104 .
  • Data registers or data sets are established in an allocation database for storing data representative of the amount of funds deposited in the Omnibus TA and the Omnibus MMDA.
  • Data registers or data sets are also established in the allocation database for each customer for storing data representative of the allocation of funds between the customer's Individual TA and Individual MMDA.
  • the Individual TAs and MMDAs correspond to the Omnibus TA and Omnibus MMDA at each depository institution, such that the sum of the balances recorded in the Individual TAs is equal to the balance of funds deposited in the Omnibus TA and the sum of the balances recorded in the Individual MMDAs is equal to the balance of funds deposited in the Omnibus MMDA.
  • Data registers or data sets are also established for storing data representative of the number of transfers from the individual MMDA and Omnibus MMDA for use in Tracking regulatory compliance.
  • an IMMDA transfer counter and OMMDA transfer counter are established in the deposit sweep engine database for storing data representative of the number of transfers from the IMMDA and OMMDA, respectively.
  • a set percent of the aggregate deposited funds is retained in the Omnibus TA, for example 1%, 5%, or any other percent, may be retained in the Omnibus TA. It is desirable that this set percent, or target OTA percent (TTP), be as small as possible.
  • the TTP may be based on a number of factors, such as transaction history in the individual and/or custodial deposit accounts, or may be set arbitrarily, as would be apparent to one of ordinary skill in the art. Additionally, as would be apparent to one of ordinary skill in the art, the TTP may be optimized so that the minimum amount of funds are kept in the Omnibus TA while still ensuring compliance with transfer limits. For example, the TTP may be managed and altered during the calendar month or other statement cycle, as discussed below,
  • the target OTA percent can be set lower, but increased during the month or statement cycle each time a transfer is required from the OMMDA.
  • TTP target OTA percent
  • the month or statement cycle may begin with the TTP set to 1% and the OMMDA transfer counter set to 0.
  • the OMMDA transfer counter in increased to I and the TTP is raised to 3%.
  • the Individual TA data and the Individual MMDA data are modified for one or more of the plurality of individuals so that the OTA will contain 3% of the total omnibus hinds after settlement of the account. If a second transfer is needed from the OMMDA during the month or statement cycle, the OMMDA transfer counter is incremented from 1 to 2 and the TTP is raised to 4%. If a third transfer is needed during the month or statement cycle, the OMMDA transfer counter is incremented from 2 to 3 and the T′I′P is raised to 5%. If a fourth transfer from the OMMDA is needed during the month or statement cycle, the OMMDA transfer counter is incremented from 3 to 4 and the TTP is raised to 10%.
  • the OMMDA transfer counter is incremented from 4 to 5 and the TTP is raised to 20%. Finally, if a sixth transfer is needed (and if six transfers is the transfer limit), the OMMDA transfer counter is incremented from 5 to 6 and the TTP is raised to 100%.
  • the transfer limit is reached, the Individual TA data and the Individual MMDA data are modified so that the entire balance of each Individual MMDA is transferred to its respective Individual TA.
  • the exact percentages for the TTP that correspond to each transfer can be modified as would be apparent to one of skill in the art, to optimize the process. For example, percentages may be set differently depending on how large the depository institution's balances are, since banks with large balances tend to have a lower percentage of outbound transfers.
  • the TTP may be reduced at the end of the calendar month or other statement cycle, if the number of transfers from the OMMDA to the OTA during the month were low as compared to the transfer limit. For example, if there are four transfers remaining before reaching a transfer limit of six in a given calendar month or statement cycle (i.e. the OMMDA transfer counter is less than three), but only three days remaining in the calendar month or statement cycle, the TTP can be reduced to 0% for the remainder of the calendar month or statement cycle, since there can be transfers out of the OMMDA each of the remaining days of the month or statement cycle without reaching the transfer limit.
  • the TTP can be reset (e.g., returned to 1%) at the start of the following calendar month or statement cycle as discussed further below with respect to FIG. 4 .
  • a deposit sweep engine processor receives customer transaction data from back office service provider 102 representative of a daily deposit and withdrawal information for each customer.
  • the customer transaction data is a daily net deposit or daily net withdrawal made by each individual.
  • the sweep engine processor optimizes swept balances for FDIC insurance coverage and bank network requirements, in some instances splitting swept balances among a plurality of banks, in amounts that do not exceed the deposit insurance limit for each customer at each depository institution, permitting customer funds to be eligible for insurance coverage in excess of the basic FDIC limit.
  • the sweep engine processor determines an aggregate amount of funds to be deposited or withdrawn from the Omnibus TA and Omnibus MMDA to cover the customer activity, based on the net daily transaction data, and allocates funds for each Individual TA and Individual MMDA corresponding to the custodial deposit accounts. Funds needed for satisfaction of transfers out of the individual sweep accounts are satisfied by funds withdrawn in the aggregate from the custodial accounts and funds transferred into the individual sweep accounts are deposited in the aggregate to the custodial accounts.
  • FIG. 2 is a flow chart providing an example of an allocation process 200 that allocates deposits and withdrawals on the individual account level for both the IMMDA and ITA.
  • the deposit sweep engine processor reads the customer transaction data and first determines whether the customer's net daily transaction is a withdrawal (step 202 ). If it is not a withdrawal, the processor adds the net daily deposit amount, if any, to the customer's ITA (step 216 ). The processor then moves to the next customer, if any, and starts over (step 218 ). If there are no remaining customers, the processor proceeds to step 302 , as discussed below with respect to FIG. 3 .
  • the deposit sweep engine processor determines whether the customer's net withdrawal is greater than the amount of funds in the customer's ITA (step 204 ). If the net withdrawal is not greater than the amount of funds in the ITA, the processor subtracts the withdrawal amount from the ITA (step 214 ). The processor then moves to the next individual, if any, and starts over (step 218 ). If, however, the net withdrawal is greater than the amount of funds in the ITA, the processor adds 1 to the individual's IMMDA transfer counter (step 206 ). The processor then determines whether the individual's IMMDA transfer counter is equal to 6 or some other established transfer limit (step 208 ).
  • the processor transfers the entire balance of funds in the IMMDA to the ITA (step 210 ). If it is less than the transfer limit, the processor transfers the net withdrawal amount from the IMMDA to the ITA (step 212 ). In either case, the processor will then subtract the withdrawal amount from the ITA (step 214 ). The processor then moves to the next individual, if any, and starts over (step 218 ).
  • the deposit sweep engine processor updates the allocation database for each customer's ITA and IMMDA account based on the allocations described above.
  • FIG. 3 is a flow chart providing an example of an allocation process 300 that allocates ITA and IMMDA balances on the customer account level to minimize the number of transfers from the OMMDA for a given period.
  • the deposit sweep engine processor first determines the net balance change for the OMMDA (step 302 ), based on a comparison of a sum of the data generated for each customer's IMMDA during allocation process 200 against the data received from the depository institution and/or stored in the allocation database representing the current balance of funds in the OMMDA.
  • the deposit sweep engine processor determines whether the net balance change for the OMMDA is a negative amount greater than the OTA balance (step 304 ), by comparison to the data received from the depository institution and/or stored in the allocation database representing the current balance of funds in the OTA.
  • the processor adds 1 to the OMMDA transfer counter (step 316 ).
  • the processor determines whether the OMMDA transfer counter is equal to 6 or some other established transfer limit (step 318 ). If the OMMDA transfer counter is equal to the transfer limit, then the processor sets the TTP to 100% (step 319 ) and transfers every individual's entire IMMDA balance to their respective ITA (step 320 ). If it is not equal to the transfer limit, the processor increases the TTP to a larger percentage based on the number of remaining transfers (step 321 ) and transfers funds from one or more of the plurality of individual's IMMDA to their respective ITA until the Target OTA balance is reached (step 322 ).
  • the processor determines whether the net balance change is negative (step 306 ). If the net balance is negative, the processor transfers funds from one or more ITAs to their respective IMMDAs until the net balance change amount is reached (step 314 ). In one embodiment, the processor determines which, if any, customers hold eligible ITA balances. Eligible customers have IMMDA transfer counters of less than 6 or some other established transfer limit. Then, beginning with eligible customers that hold the largest ITA balances, the processor transfers all or a portion of the ITA balance to the respective IMMDA. When the net balance change amount is reached, the processor stops ITA balance transfer processing. If the net balance change is exceeded with the transfer of funds from a single ITA, the processor transfers only the funds required. The processor repeats this determination-and-transfer process until the OMMDA net balance change is reduced to zero.
  • the processor first determines whether the OMMDA transfer counter is equal to 6 or some other transfer limit (step 308 ). If the OMMDA transfer counter is equal to the transfer limit, the processor does not transfer any ITA funds to the IMMDA (step 310 ). If the OMMDA transfer counter is not equal to the transfer limit, the processor transfers funds from one or more ITAs to their respective IMMDAs until the Target OTA balance is reached (step 312 ).
  • the processor determines whether the OTA balance is greater than the target OTA balance.
  • the target OTA balance is calculated by multiplying the target OTA percent (TTP), discussed above, by the sum total of the OMMDA and OTA balances. If the OTA balance is greater than the target OTA balance, then the processor transfers funds from the ITAs to the IMMDAs until the target OTA is reached. Beginning with customers that hold the largest ITA balance, the processor transfers funds from the ITAs to the IMMDAs. When the target OTA balance is reached, the processor stops transferring funds from the ITAs. If the target OTA balance is reached with funds from a single ITA, the processor only transfers the funds required from that customer's ITA,
  • the processor updates the database for the Omnibus TA and Omnibus MMDA, as well as each customer's ITA and IMMDA, based on the allocations described above.
  • the sweep engine processor then creates a funds transfer report for each depository institution detailing the allocation of the daily activity among the OTA and OMMDA, as well as instructions for either a net withdrawal from or net deposit to the custodial deposit accounts, for daily settlement of the OTA and OMMDA accounts (step 324 ).
  • the settlement agent receives an electronic transmission of wire instructions from or on behalf of the custodial agent and then transmits funds to or from the depository institutions based on those instructions.
  • the sweep engine process also creates a funds allocation report detailing the allocation of the daily activity between each customer's Individual TA and individual MMDA and forwards such instructions to the custodial agent for reconciliation with the custodial agent's books and records for each customer
  • a rebalance process 400 is employed for rebalancing the ITA and IMMDA accounts, as shown in FIG. 4 .
  • the processor reviews the data sets representative of the amount of funds allocated to the individual and omnibus accounts as well as the IMMDA transfer counter for the previous month or statement period.
  • the processor For each customer where the IMMDA transfer counter reached 6 during the previous period, the processor transfers from the ITA to the respective IMMDA an amount of funds equal to the total ITA balance minus the product of the target OTA percent (TTP) and the total ITA balance (step 402 ). In this manner, only the target OTA percent of the total ITA balance of funds is retained in the ITA with the remainder of the funds allocated to the IMMDA.
  • the processor determines a modified OTA and OMMDA balance based on the rebalancing in step 402 and determines whether the OTA balance is now greater than the target OTA balance (step 404 ).
  • the target OTA balance is calculated by multiplying the target OTA percent (TTP) by the sum total of the OMMDA and OTA balances. If the OTA balance is not greater than the target OTA balance, the processor makes no further modification to the allocation of funds in the ITAs and IMMDAs.
  • the processor determines the delta or excess percent over the target OTA percent (TTP) (step 406 ). In particular, the processor determines the delta or excess percent by calculating the percent of funds in the customer ITAs for the customers where the IMMDA transfer counter did not reach 6 during the previous period, as compared to the total balance of funds in both the ITAs and IMMDAs for the customers where the IMMDA transfer counter did not reach 6 during the previous period. The target OTA percent (TTP) is then subtracted from this calculated percent.
  • the processor transfers the delta or excess percent from the ITA to the IMMDA, so that the target OTA balance is reached (step 408 ). For example, if the TTP is set at 1%, but the sum of the funds allocated to the ITAs for the customers where the IMMDA transfer counter did not reach 6 during the previous period, as compared to the total balance of funds in both the ITAs and IMMDAs for the customers where the IMMDA transfer counter did not reach 6 during the previous period is 3%, then 2% of the balance of funds in the ITAs of each customer where the IMMDA transfer counter did not reach 6 during the previous period is transferred to their respective IMMDA. After steps 402 and 408 , the OTA balance will be reached.
  • the processor finishes rebalance process 400 by resetting the IMMDA and OMMDA transfer counters to zero (step 410 ).
  • IMMDA and OMMDA transfer counters are resetting the IMMDA and OMMDA transfer counters to zero.
  • a more elaborate rebalancing process could also be employed to further optimize the allocation of funds, so that a minimum amount of funds are kept in the Omnibus TA while still ensuring compliance with established transfer limits.
  • the TTP is returned to at a set percent (e.g., 1%) at the beginning of each month or statement cycle
  • the TTP could be increased or decreased on a monthly or other periodic basis based on activity in the individual and custodial deposit accounts, as would be apparent to one of ordinary skill in the art, so that a minimum amount of funds are kept in the Omnibus TA while still ensuring compliance with established transfer limits.
  • the deposit sweep engine processor creates a funds transfer report detailing the rebalancing allocation for the OTA and OMMDA accounts.
  • the settlement agent then receives an electronic transmission of wire instructions from or on behalf of the custodial agent and transmits these instructions to the depository institution to reallocate funds in the custodial deposit accounts.
  • instructions are provided to the custodial agent to rebalance funds allocated to the Individual TAs and Individual MMDAs on the books and records of the custodial agent.
  • a plurality of customers of a custodial agent are provided with FDIC insurance for funds in excess of $100,000 at an agreed-to interest rate.
  • the depository institutions are provided with a stable source of funds with reduced reserve requirements.
  • the custodial agent and the agent or administrator receive fees from the “all in cost of funds” paid by the depository institution for managing allocation of funds at the individual and custodial levels and for facilitating transfers between the individual accounts and the custodial accounts to satisfy daily transactions.
  • Regulatory compliance is managed through allocation of funds in the individual accounts by the deposit sweep engine processor prior to instructing the depository institutions as to the omnibus account, such that a minimum or reduced amount of funds are kept in the Omnibus TA while still limiting transfers.
  • the present invention i.e., components of deposit sweep arrangement 100 (e.g., back office service provider 102 , deposit sweep engine 104 and its associated database and processor, settlement agent 106 ), process 200 , process 300 , process 400 or any parts or functions thereof) may be implemented using hardware, software or a combination thereof and may be implemented in one or more computer systems or other processing systems.
  • the manipulations performed by the present invention are often referred to herein in terms, such as comparing or identifying, which are commonly associated with mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein which form part of the present invention. Rather, the operations are machine operations.
  • Useful machines for performing the operation of the present invention include general purpose digital computers or similar devices, such as a computer system 500 , as shown in FIG. 5 , in which the present invention, or portions thereof, can be implemented as computer-readable code.
  • Computer system 500 includes one or more processors, such as processor 504 .
  • Processor 504 can be a special purpose or a general purpose digital signal processor.
  • Processor 504 is connected to a communications infrastructure 506 (for example, a bus or network).
  • a communications infrastructure 506 for example, a bus or network.
  • Computer system 500 can include a display interface 502 that forwards graphics, text, and other data from communication infrastructure 506 (or from a frame buffer not shown) for display on a display unit 530 .
  • Computer system 500 also includes a main memory 508 , preferably random access memory (RAM), and may also include a secondary memory 510 .
  • Secondary memory 510 may include, for example, a hard disk drive 512 , a removable storage drive 514 , and/or a memory stick or the like.
  • Removable storage drive 514 may comprise a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, or the like.
  • Removable storage drive 514 reads from and/or writes to a removable storage unit 518 in a well known manner.
  • Removable storage unit 518 may comprise a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 514 .
  • removable storage unit 518 includes a computer usable storage medium having stored therein computer software and/or data.
  • secondary memory 510 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 500 .
  • Such means may include, for example, a removable storage unit 522 and an interface 520 .
  • Examples of such means may include a program cartridge and cartridge interface, a removable memory chip (such as an erasable programmable read only memory (EPROM), programmable read only memory (PROM)) and associated socket, and other removable storage units 522 and interfaces 520 which allow software and data to be transferred from the removable storage unit 522 to computer system 500 .
  • EPROM erasable programmable read only memory
  • PROM programmable read only memory
  • Computer system 500 may also include a communications interface 524 .
  • Communications interface 524 allows software and data to be transferred between computer system 500 and external devices.
  • Communications interface 524 may include a modem, a network interface (such as an Ethernet card), a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, wired or wireless systems, or the like.
  • Software and data transferred via communications interface 524 are in the form of signals 528 which may be electronic, electromagnetic, optical or other signals capable of being received by communications interface 524 . These signals 528 are provided to communications interface 524 via a communications path 526 .
  • Communications path 526 carries signals 528 and may be implemented using wire or cable, fiber optics, a phone line, a cellular link, a radio frequency (RF) link and/or other communications channels.
  • RF radio frequency
  • computer program medium “computer usable medium” and “computer readable medium” are used to generally refer to media such as removable storage unit 518 , removable storage unit 522 , and a hard disk installed in hard disk drive 512 .
  • Computer program medium and computer usable medium can also refer to memories, such as main memory 508 and secondary memory 510 , which can be memory semiconductors (e.g., DRAMs, etc.). These computer program products are means for providing software to computer system 500 .
  • Computer programs are stored in main memory 508 and/or secondary memory 510 . Computer programs may also be received via communications interface 524 . Such computer programs, when executed, enable the computer system 500 to implement the present invention as discussed herein. In particular, the computer programs, when executed, enable the processor 504 to implement the processes of the present invention, such as the steps illustrated in FIGS. 2-4 , discussed above. Accordingly, such computer programs represent controllers of the computer system 500 . Where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system 500 using removable storage drive 514 , interface 520 , hard drive 512 or communications interface 524 . The control logic (software), when executed by processor 504 , causes processor 504 to perform the functions of the invention as described herein.
  • the invention may be implemented primarily in hardware using, for example, hardware components such as an integrated circuit (IC) customized for a particular use, also known as application specific integrated circuits (ASICs).
  • IC integrated circuit
  • ASICs application specific integrated circuits
  • the invention is implemented using a combination of both hardware and software.
  • the invention is also directed to computer program products comprising software stored on any computer useable medium.
  • Such software when executed in one or more data processing devices, causes the data processing device(s) to operate as described herein.
  • Embodiments of the invention employ any computer useable or readable medium, known now or in the future. Examples of computer useable mediums include, but are not limited to, primary storage devices (e.g., any type of random access memory), secondary storage devices (e.g., hard drives, floppy disks, CD ROMS, DVD ROMS, ZIP disks, tapes, magnetic storage devices, optical storage devices, MEMS, nanotechnological storage device, etc.), and communication mediums (e.g., wired and wireless communications networks, local area networks, wide area networks, intranets, etc.). It is to be appreciated that the embodiments described herein can be implemented using software, hardware, firmware, or combinations thereof.
  • FIGS. 6A-6H provide a table of data representative of data produced by an exemplary deposit sweep engine processor managing custodial deposit accounts according to one embodiment of the present invention.
  • FIG. 6 provides account balance information for an Omnibus TA and Omnibus MMDA and corresponding Individual TAs and Individual MMDAs for the first eight days in a given month for three customers: Andrew, Betty, and Carl.
  • the first day of data is shown in FIG. 6A .
  • Line 1 shows the respective account balances at the start of the first day.
  • the TTP is set to 5% and, as such, 5% of the total funds deposited by each customer is allocated to the customer's individual TA and the remaining 95% of the total funds is allocated to the customer's individual MMDA. This allocation provides a cushion for the Omnibus TA of 5%.
  • Lines 1 a and 1 b show the response of the deposit sweep engine processor to individual daily net account activity for day 1 . Specifically, Andrew writes a check for $10, Betty deposits a check for $5, and Carl has no account activity.
  • Line 1 a shows the updated account balances following two allocations performed by the processor: (1) an allocation of funds from Andrew's MMDA to his TA to cover his check; and (2) an allocation of funds to Betty's TA to reflect her deposit.
  • Line 1 b shows the updated account balances following a $10 Withdrawal from Andrew's TA to cover his check.
  • the processor determines that the daily net activity will result in a negative net balance change in the Omnibus MMDA of $5, caused by the transfer of funds from Andrew's MMDA to his TA to cover his $10 withdrawal.
  • Line 1 c shows the updated account balances following the processor's reallocation of funds in the Individual TAs and MMDAs to offset the negative net balance change.
  • the processor allocates funds first from an individual having the highest Individual TA balance to his or her corresponding Individual MMDA in order to offset the negative net balance change. This results in a $5 allocation from Betty's TA to her MMDA. This allocation reduces the cushion for the Omnibus TA to 3.39%.
  • Line 2 shows the updated account balances following the daily settlement of accounts during day 1 .
  • Lines 2 a and 2 b show the response of the deposit sweep engine processor to individual daily net account activity for day 2 . Specifically, Andrew writes a check for $5 and both Betty and Carl have no account activity.
  • Line 2 a shows the updated account balances following an allocation of funds from Andrew's MMDA to his TA to cover his check.
  • Line 2 b shows the updated individual account balances following a $5 withdrawal from Andrew's TA to cover his check.
  • the processor determines that the daily net activity will result in a negative net balance change in the Omnibus MMDA of $5, caused by the transfer of funds from Andrew's MMDA to his TA to cover his $5 withdrawal.
  • Line 2 c shows the updated individual account balances following the processor's reallocation of funds in the Individual TAs and MMDAs to offset the negative net balance change.
  • the processor allocates funds from Betty's TA to Betty's MMDA because Betty has the highest TA balance among the three individuals. This results in a $5 allocation from Betty's TA to her MMDA. Note that because Carl has an equally high TA balance, the processor could have transferred the $5 from Carl's TA to Carl's MMDA instead. However, regardless of whose account is used, the allocation reduces the cushion for the Omnibus TA to 1.72%.
  • Line 3 shows the updated account balance following the daily settlement of accounts during day 2 .
  • Line 3 a shows the response of the deposit sweep engine processor to individual daily net account activity for day 3 . Specifically, Betty deposits $20 and both Andrew and Carl have no account activity.
  • Line 3 a shows the updated account balances following an allocation of funds to Betty's TA to reflect her deposit.
  • the processor determines that the daily net activity will not result in negative net balance change from the Omnibus MMDA.
  • the processor determines that the daily net activity increases the Omnibus TA balance above the target Omnibus TA balance. That is, Betty's deposit increases the cushion for the Omnibus TA to 8.86%, which is above the TTP of 5%.
  • Line 3 b shows the updated account balances following a reallocation by the processor to reduce the cushion to the TTP of 5%. Specifically, $9.50 of Betty's $20.00 deposit is allocated to her MMDA, the rest being allocated to her TA.
  • Line 4 shows the updated account balance following the daily settlement of accounts during day 3 .
  • Lines 4 a and 4 b show the response of the deposit sweep engine processor to individual daily net account activity for day 4 . Specifically, Carl writes a check for $20 and both Andrew and Betty have no account activity.
  • Line 4 a shows the updated account balances following an allocation of funds from Carl's MMDA to his TA to cover his check.
  • Line 4 b shows the updated account balances following a $20 withdrawal from Carl's TA to cover his check.
  • the processor determines that the daily net activity will result in a negative net balance change in the Omnibus MMDA of $15, caused by the transfer of funds from Carl's MMDA to his TA to cover his $20 withdrawal. Unlike the situation in days 1 and 2 , however, the negative net balance change is greater than the balance of the Omnibus TA.
  • the custodial accounts are charged with an Omnibus MMDA transfer (as reflected by the incremented Custodial transfer counter) and the TTP is increased.
  • the TTP is increased by 7% for a resulting TTP of 12%.
  • the processor determines that the total amount of funds needed to be transferred from the various Individual MMDAs to their respective TAs to provide for a 12% TTP is equal to $24.30. Because Carl's Individual MMDA transfer counter will be incremented anyway and because he has enough funds to cover the transfer, the processor allocates the $24.30 from Carl's MMDA to his TA. Line 4 c shows the account balances following this allocation. If, however, Carl did not have enough funds to cover the transfer, the processor would allocate funds first from an individual having the highest TA balance. In another embodiment, the processor would rank potential individuals based on their Individual transfer counter and TA balance in order to minimize the number of individuals charged with an MMDA withdrawal while favoring individuals having lower Individual transfer counters.
  • Line 5 shows the respective account balances following the daily settlement of accounts during day 4 .
  • Lines 5 a and 5 b show the response of the deposit sweep engine processor to individual daily net account activity for day 5 . Specifically, Andrew writes a check for $10 and both Betty and Carl have no account activity.
  • Line 5 a shows the updated account balances following an allocation of funds from Andrew's MMDA to his TA to cover his check.
  • Line 5 b shows the updated account balances following a $10 withdrawal from Andrew's TA to cover his check.
  • the processor determines that the daily net activity will result in a negative net balance change in the Omnibus MMDA of $10, caused by the transfer of funds from Andrew's MMDA to his TA to cover his $10 withdrawal.
  • Line 5 c shows the updated account balances following the processor's reallocation of funds in the Individual TAs and MMDAs to offset the negative net balance change.
  • the processor allocates funds from Carl's TA to Carl's MMDA because Carl has the highest TA balance among the three individuals. This results in a $10 allocation from Carl's TA to his MMDA. This allocation reduces the cushion for the Omnibus TA to 8.86%
  • Line 6 shows the updated account balances following the daily settlement of accounts during day 5 .
  • Lines 6 a and 6 b show the response of the deposit sweep engine processor to individual daily net account activity for day 6 . Specifically, Andrew writes a check for $45 and both Betty and Carl have no account activity.
  • Line 6 a shows the updated account balances following an allocation of funds from Andrew's MMDA to his TA to cover his check.
  • Line 6 b shows the updated account balances following a $45 withdrawal from Andrew's TA to cover his check.
  • the processor determines that the daily net activity will result in a negative net balance change in Omnibus MMDA of $45, caused by the transfer of funds from Andrew's MMDA to his TA to cover his $45 withdrawal. Like the situation in day 4 , the negative net balance change is greater than the balance of the Omnibus TA. As a result, the custodial accounts are charged with an Omnibus MMDA transfer and the TTP is increased. Here the TTP is increased by 15% for a resulting TTP of 27%. The processor determines the total amount of funds needed to be transferred from the various Individual MMDAs to their respective TAs to provide for a 27% TTP is equal to $38.65.
  • the processor allocates funds first from an individual having the highest MMDA balance. As a result, Betty's MMDA counter is incremented and the $38.65 is moved from her MMDA to her TA. Line 6 c shows the account balances following this allocation.
  • Line 7 shows the updated account balances following the daily settlement of accounts during day 6 .
  • Line 7 a shows the response of the deposit sweep engine processor to individual daily net account activity for day 6 . Specifically, Andrew deposits $100 and both Andrew and Carl have no account activity.
  • Line 7 a shows the updated account balances following an allocation of funds to Andrew's TA to reflect his deposit.
  • the processor determines that the daily net activity will not result in a negative net balance change in the Omnibus MMDA.
  • the processor determines that the daily net activity increases the Omnibus TA balance above the target Omnibus TA balance. That is, Andrew's deposit increases the cushion for the Omnibus TA to 48.79%, which is above the TTP of 27%.
  • Line 7 b shows the updated account balances following a reallocation by the processor to reduce the cushion to the TTP of 27%. Specifically, $63.00 of Andrew's $100.00 deposit is allocated to his MMDA, the rest being allocated to his TA.
  • Line 8 shows the updated account balances following the daily settlement of accounts during day 7 .
  • Lines 8 a and 8 b show the response of the deposit sweep engine processor to individual daily net account activity for day 8 . Specifically, Andrew writes a check for $110, Carl deposits $5, and Betty has no account activity.
  • Line 8 a shows the updated account balances following two allocations performed by the processor: (1) an allocation of funds from Andrew's MMDA to his TA to cover his check; and (2) an allocation of funds to Carl's TA to reflect his deposit.
  • Line 8 b shows the updated account balances following a $110 withdrawal from Andrew's TA to cover his check.
  • the processor determines that the daily net activity will result in a negative net balance change in the Omnibus MMDA of $105, caused by the transfer of funds from Andrew's MMDA to his TA to cover his $110 withdrawal. Like the situations in days 4 and 6 , the negative net balance change is greater than the balance of the Omnibus TA. As a result, the custodial accounts are charged with an Omnibus MMDA transfer and the TTP is increased. Here the TTP is increased by 20% for a resulting TTP of 47%. The processor determines that the total amount of funds needed to be transferred from the various Individual MMDAs to their respective TAs to provide for a 47% TTP is equal to $39.65.
  • the processor allocates funds first from an individual having the highest MMDA balance. As a result, Betty's MMDA transfer counter is incremented and the $39.65 is moved from her MMDA to her TA. Line 8 c shows the account balances following this allocation.
  • the deposit sweep engine processor will continue to manage the custodial deposit accounts, as discussed above, for the remainder of the month or statement cycle, and then rebalance the individual accounts of Andrew, Betty and Carl at the beginning of the following month or statement cycle.

Abstract

A method, system and computer program product for managing aggregate funds held in custodial deposit accounts by a custodial agent on behalf of a plurality of individuals. According to the present invention, the custodial deposit accounts comprise an omnibus transaction account (“Omnibus TA”) and a Omnibus money market deposit account (“Omnibus MMDA”). A corresponding individual transaction account (“Individual TA”) and individual money market deposit account (“Individual MMDA”) are kept on the books and records of the custodial agent for each individual, representing the amount of the individual's funds deposited in the Omnibus TA and Omnibus MMDA, respectively. According to the present invention, limitations on transfers from the Omnibus MMDA to the Omnibus TA and limitations on transfers from the corresponding Individual MMDAs to the individual TAs are managed by daily allocation of the funds in the Individual TAs and Individual MMDAs.

Description

CROSS-REFERENCE
This application is a continuation of U.S. application Ser. No. 12/419,691, filed Apr. 7, 2009, which is hereby incorporated herein in its entirety by reference hereto.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to the management of financial accounts and more particularly, to a method, system and computer program product for managing funds in custodial deposit accounts.
2. Background Art
Through a custodial arrangement, deposit accounts may be established at one or more depository institutions by an agent and/or custodian on behalf of a plurality of customers. (Such deposit accounts are referred to herein as “omnibus” deposit accounts.) The agent and/or custodian responsible for establishing and holding such deposit accounts may be, for example, a broker-dealer registered under the Securities Exchange Act of 1934 as amended (referred to herein as a “broker-dealer”), another depository institution, a credit union, or another regulated financial institution. (Such agent and/or custodian is referred to herein as a “custodial agent”).
Custodial agents that are registered broker-dealers typically offer their customers various types of liquid investments into which customer “free credit balances,” as defined in Rule 15c3-3 adopted by the SEC pursuant to the Exchange Act, are automatically invested, or “swept,” from a customer's brokerage account. A free credit balance is created in a customer's brokerage account when the customer sells investments in the account the customer receives interest or dividend payments on investments in the account or the customer deposits funds in the account. As a service to their customers, broker-dealers can offer to automatically invest, or “sweep,” customers' free credit balances into liquid investments. If the customer then needs funds to settle securities transactions or for cash management activity, the broker-dealer withdraws funds to cover such transactions. An automated service that sweeps customers' end-of-day cash, for example, into an interest-bearing account affords customers an opportunity to receive interest on excess cash that would otherwise not earn interest.
Broker-dealers also commonly offer customers check-writing, debit card and other cash management features in connection with brokerage accounts. Debits in a customer's brokerage account created by check, debit card, purchases of securities or other transactions are typically satisfied from available cash balances, funds in the customer's sweep investment and, if applicable, margin credit. A sweep investment, therefore, may be offered to a broker-dealer's customers as part of a cash management component of a brokerage account.
Funds deposited in deposit accounts, in some banking systems around the world, are insured by government-run deposit insurance programs up to an established deposit insurance limit. In the United States, for example, such deposits are insured by the Federal Deposit Insurance Corporation (FDIC). The FDIC currently insures deposits up to $100,000 per depositor in any one insured depository institution for many insurable capacities (e.g., individual accounts and joint accounts) and up to $250,000 for IRAs and certain self-insured employee benefit plans. The basic deposit insurance limit was temporarily raised on Oct. 3, 2008 by the Emergency Economic Stabilization Act of 2008 from $100,000 to $250,000 per depositor. This increase is scheduled to end and return to $100,000 per depositor after Dec. 31, 2009.
One option for broker-dealers and other custodial agents is for the custodial agent to place customer funds in a plurality of depository institutions in amounts that do not exceed the deposit insurance limit for each customer at each depository institution, permitting customer funds to be eligible for insurance coverage in excess of the basic FDIC limit. A sweep arrangement in which customer funds are placed in deposit accounts at a plurality of depository institutions (a “multi-bank sweep arrangement”) can benefit participating depository institutions by providing a large, stable source of deposits. A multi-bank sweep arrangement can also benefit customers, by offering additional investment opportunities together with increased access to FDIC deposit insurance protection. Even without regard to FDIC deposit insurance protection, a multi-bank sweep arrangement can spread and thereby mitigate risk and can provide greater access to competitive returns.
Swept customer funds that are placed in deposit accounts at a plurality of depository institutions may be deposited in interest-bearing money market deposit accounts (“MMDAs”), however, such MMDAs are not transaction accounts. In the United States, for example, Regulation D of the Board of Governors of the Federal Reserve System (“Regulation D”) limits transfers from an MMDA to six per calendar month or other statement cycle. Accordingly, funds swept into MMDAs must be properly managed so that transfers from MMDAs are in compliance with transaction limits.
FDIC-insured sweep services have been in use by broker-dealers since at least the early 1980s, when Merrill Lynch offered a sweep option to its brokerage customers under which funds were swept into Omnibus MMDAs at multiple banks. Continuing through the 1990s, other broker-dealers offered similar services to their clients. Some such services sought to invoke the messenger exception of Regulation D, 12 C.F.R. §204.2(d)(2), to permit unlimited transfers from an Omnibus MMDA, but such an approach was contrary to Federal Reserve guidance. As a result, most such services either relied on transfer limitations at the Individual MMDA level or attempted other ways of overcoming the limitations, such as moving funds among banks. These services were frequently combined with other well-known features in the financial services industry, such as ATM cards, credit cards, checking, interest rate incentives, benefits for large depositors and preferred customers, and the like. None of the services operated as is described here, including limiting transfers from the Omnibus MMDA as well as the Individual MMDA (e.g., to six per month) through retaining portions of the deposited funds in Individual TAs to offset net transfers from the Omnibus MMDA that would otherwise occur.
BRIEF SUMMARY OF THE INVENTION
The present invention is directed to a method, system and computer program product for managing aggregate funds held in custodial deposit accounts by a custodial agent on behalf of a plurality of individuals. According to the present invention, the custodial deposit accounts comprise an omnibus transaction account (“Omnibus TA”) and an omnibus money market deposit account (“Omnibus MMDA”). A corresponding individual transaction account (“Individual TA”) and individual money market deposit account (“Individual MMDA”) are kept on the books and records of the custodial agent for each individual, representing the amount of the individual's funds deposited in the Omnibus TA and Omnibus MMDA, respectively. According to the present invention, transfers from the Omnibus MMDA to the Omnibus TA are reduced by daily allocation of the funds in the Individual TAs and Individual MMDAs, thereby decreasing the likelihood that an established transfer limit for the Omnibus MMDA (e.g. the limit of six transfers per month in Regulation D) will be reached.
In one embodiment, an Individual TA data set comprising Individual TA data representative of the amount of the individual's funds allocated to the Omnibus TA and an Individual MMDA data set comprising Individual MMDA data representative of the amount of the individual's funds allocated to the Omnibus MMDA are established for each individual in a memory of a computer. Also, an Omnibus TA data set representative of the amount of the aggregate funds allocated to the Omnibus TA and an Omnibus MMDA data set representative of the amount of the aggregate funds allocated to the Omnibus MMDA are established in the memory of the computer. A processor of the computer receives individual transaction data representative of individual withdrawals and/or deposits by one or more of the plurality of individuals. The processor modifies the Individual TA data and the Individual MMDA data for one or more of the plurality of individuals to reflect a net change to the amount of the individual's funds allocated to the Omnibus TA and the Omnibus MMDA, respectively, based on the received individual transaction data and stores the modified Individual TA data in the Individual TA data set and the modified Individual MMDA data in the Individual MMDA data set. Thereafter, the processor compares the Individual MMDA data and the Omnibus MMDA data, calculates a net adjustment to be made to the amount of funds in the Omnibus MMDA, and stores the net adjustment in a memory of the computer. The processor compares the net adjustment to the Omnibus TA data and, if said net adjustment is a negative net balance change in an amount not greater than the amount of funds in the Omnibus TA, the processor further modifies the Individual TA data and the Individual MMDA data for one or more of the plurality of individuals to offset the net adjustment and stores the further modified Individual TA data in the Individual TA data set and the further modified Individual MMDA data in the Individual MMDA data set. Then, the processor modifies the Omnibus TA data based on the Individual TA data stored in the Individual TA data set and modifies the Omnibus MMDA data based on the Individual MMDA data stored in the Individual MMDA data set.
In another embodiment, a processor receives net daily transaction data for one or more of the plurality of individuals representative of a net daily withdrawal from or a net daily deposit to the custodial deposit accounts and stores the net daily transaction data in a memory of a computer. The processor derives a net balance change data for the Omnibus MMDA from the net daily transaction data and stores the derived net balance change data in the memory. The processor compares the derived net balance change data to data representing the amount of funds in the Omnibus TA and, if the derived net balance change data is a negative net balance change in an amount not greater than the amount of funds in the Omnibus TA, the processor modifies the Individual TA data and the individual MMDA data for one or more of the plurality of individuals to offset the net adjustment and stores the further modified Individual TA data in the Individual TA data set and the further modified Individual MMDA data in the Individual MMDA data set. Then, the processor modifies the Omnibus TA data based on the Individual TA data stored in the Individual TA data set and modifies the Omnibus MMDA data based on the Individual MMDA data stored in the Individual MMDA data set.
In another embodiment, at the beginning of a period of time, a processor allocates a percent greater than 0% of the aggregate funds to the Omnibus TA, such that each of the individuals has funds allocated to both the Omnibus TA and the Omnibus MMDA. Thereafter, the processor receives net daily transaction data for one or more of the plurality of individuals representative of a net daily withdrawal from or a net daily deposit to the custodial deposit accounts and stores the net daily transaction data in a memory of a computer. The processor determines whether the net daily transaction data will result in an aggregate transfer of funds from the Omnibus MMDA to the Omnibus TA. If the net daily transaction data will result in an aggregate transfer of funds from the Omnibus MMDA to the Omnibus TA, the processor modifies the Individual TA data and the Individual MMDA data for one or more of the plurality of individuals to offset the net adjustment and stores the further modified Individual TA data in the Individual TA data set and the further modified Individual MMDA data in the Individual MMDA data set. Then, the processor modifies the Omnibus TA data based on the Individual TA data stored in the Individual TA data set and modifies the Omnibus MMDA data based on the Individual MMDA data stored in the Individual MMDA data set.
BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES
The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate the present invention and, together with the description, further serve to explain the principles of the invention and to enable a person skilled in the pertinent art to make and use the invention.
FIG. 1 is a block diagram of an exemplary deposit sweep program according to the present invention.
FIG. 2 is a flowchart providing one embodiment of a process for allocating funds in Individual TAs and Individual MMDAs.
FIG. 3 is a flowchart providing one embodiment of a process for allocating aggregate funds in an Omnibus TA and an Omnibus MMDA.
FIG. 4 is a flowchart providing one embodiment of a rebalancing process for allocating funds in Individual TAs and Individual MMDAs at the beginning of each month or statement cycle.
FIG. 5 is a block diagram of an exemplary computer system useful for implementing the present invention.
FIG. 6A provides a table representative of data produced by an exemplary deposit sweep engine processor managing custodial deposit accounts according to one embodiment of the present invention for a first day.
FIG. 6B provides a table representative of data produced by an exemplary deposit sweep engine processor managing custodial deposit accounts according to one embodiment of the present invention for a second day.
FIG. 6C provides a table representative of data produced by an exemplary deposit sweep engine processor managing custodial deposit accounts according to one embodiment of the present invention for a third day.
FIG. 6D provides a table representative of data produced by an exemplary deposit sweep engine processor managing custodial deposit accounts according to one embodiment of the present invention for a fourth day.
FIG. 6E provides a table representative of data produced by an exemplary deposit sweep engine processor managing custodial deposit accounts according to one embodiment of the present invention for a fifth day.
FIG. 6F provides a table representative of data produced by an exemplary deposit sweep engine processor managing custodial deposit accounts according to one embodiment of the present invention for a sixth day.
FIG. 6G provides a table representative of data produced by an exemplary deposit sweep engine processor managing custodial deposit accounts according to one embodiment of the present invention for a seventh day.
FIG. 6H provides a table representative of data produced by an exemplary deposit sweep engine processor managing custodial deposit accounts according to one embodiment of the present invention for an eigth day.
DETAILED DESCRIPTION OF THE INVENTION
The present invention manages funds held in custodial deposit accounts so as to limit transfers of funds from money market deposit accounts at both the individual and omnibus account levels in a dual account structure to a specified number per month or other statement cycle, as may be required by regulation, while preserving customer access to funds through transaction accounts with unlimited transfers. Transfers are limited for both the Individual MMDA and the Omnibus MMDA through managed allocation of funds in Individual TAs and Individual MMDAs.
An exemplary embodiment of the present invention is now described with reference to the figures, where like reference numbers indicate identical or functionally similar elements. This is for convenience only and is not intended to limit the application of the present invention. In fact, after reading the following description, it will be apparent to one skilled in the relevant art(s) how to implement the following invention in alternative embodiments. While the following embodiment is directed to a deposit sweep program between a broker-dealer and a plurality of its customers, it will be understood that this is an embodiment of the present invention and that the present invention can be applied in other arrangements where a custodial agent is an agent and or custodian for a plurality of individuals.
In one embodiment, each custodial agent establishes a money market deposit account (“MMDA”) and a transaction account (“TA”) with each depository institution in the name of the custodial agent as agent and/or custodian for its customers. These accounts are referred to herein as the “Omnibus” MMDA (OMMDA) and the “Omnibus” TA (OTA). Under Regulation D, the Omnibus MMDA is subject to lower reserve requirements than the Omnibus TA. Accordingly, it is desired that a maximum of the deposited funds at each depository institution be placed in the Omnibus MMDA. Regulation D currently limits transfers from money market deposit accounts to six per calendar month or other statement cycle. Consequently, according to the present invention, a set percent of the deposited funds is retained in the Omnibus TA, as discussed further below, as a cushion to satisfy withdrawals. The percent of the deposited funds retained in the Omnibus TA is referred to herein as the target OTA percent (TTP).
Individual MMDAs and TAs for each customer are also established, as evidenced by books and records maintained by the custodial agent. These accounts are referred to herein as the “Individual” MMDA (IMMDA) and the “Individual” TA (ITA). In order to comply with banking regulations, fund withdrawals to outside entities are directed from the Individual TA and the entire balance in the Individual MMDA account is transferred to the Individual TA before the customer exhausts the monthly transfer limit. The Individual TA may be, for example, a negotiable order of withdrawal (NOW) account.
In one embodiment, each depository institution agrees to pay an “all-in cost of funds” in respect of the money held in the custodial deposit accounts. For example, the “all-in cost of funds” may be based on the Federal Funds Effective Rate plus a set basis point spread. This “all-in cost of funds” can then be allocated into interest to be paid into the custodial deposit accounts and fees paid to the custodial agent and/or others involved in the maintenance and operation of the deposit sweep arrangement, such as a third party manager or administrator. Interest paid into the custodial deposit accounts is allocated to the Individual MMDAs and the Individual TAs on the books and records of the custodial agent, as would be apparent to one of ordinary skill in the art, based on each customer's individual account balances. Each customer earns interest on all funds deposited in the IMMDA and the ITA. Accordingly, it is irrelevant to the customer whether the customer's swept funds are allocated to the customer's Individual MMDA or to the customer's Individual TA.
Custodial agents may place customer funds in a plurality of depository institutions in amounts that do not exceed the deposit insurance limit for each customer at each depository institution, permitting customer funds to be eligible for insurance coverage in excess of the basic FDIC limit. To the extent a customer has funds swept into more than one depository institution, the custodial agent will maintain separate Individual TA and Individual MMDA accounts on its books and records for the customer corresponding to the Omnibus TA and Omnibus MMDA at each depository institution. In one embodiment, customer funds are deposited and withdrawn at one or more depository institutions according to a first in first out (FIFO) accounting basis.
According to the present invention, transfer limitations, such as the limitation under Regulation D of 6 transfers per month or other statement cycle, can be managed for both the Individual MMDA and the Omnibus MMDA by managed allocation of funds in the Individual TAs and Individual MMDAs, as described below with respect to FIGS. 2-4.
FIG. 1 is a block diagram providing an overview of the flow of customer funds in an exemplary deposit sweep arrangement 100 according to the present invention. Deposit sweep arrangement 100 includes a broker-dealer back office service provider 102, a deposit sweep engine 104, a settlement agent 106 and one or more depository institutions 108. In one embodiment, deposit sweep engine 104 is operated by a third party agent or administrator that reports to both the custodial agent and the depository institutions. The agent or administrator manages transfers of funds between the individual sweep accounts of each customer and the custodial accounts held at the depository institutions. As discussed below, deposit sweep engine 104 may be implemented using hardware, software or a combination thereof and may be implemented in one or more computer systems or other processing systems. For each depository institution, deposit sweep engine 104 allocates funds deposited in the Omnibus TA and Omnibus MMDA and allocates funds within Individual TAs and Individual MMDAs, representing each individual's portion of the aggregate funds deposited in the custodial deposit accounts as recorded on the books of the custodial agent, and provides instructions to the depository institutions and custodial agent as to the allocation of such funds.
Back office service provider 102 collects brokerage activity and cash management activity of customers of the broker-dealer and transmits net customer transactions to sweep engine 104. Sweep engine 104 performs a daily sweep, for example, at night. Sweep engine 104 optimizes swept balances for FDIC insurance coverage and bank network requirements. The allocation and posting processing of sweep engine 104 is further discussed below with respect to FIGS. 2-4. Sweep engine 104 transmits aggregate transactions to settlement agent 106. Settlement agent 106 provides an interface to the bank network on an aggregate level (e.g., omnibus level rather than customer level). Settlement agent 106 sends aggregate funds flow to one or more depository institutions 108 in the bank network. Settlement agent 106 processes aggregate transactions daily for example, at night. Aggregate funds are invested in omnibus accounts at each depository institution 108.
In accordance with an embodiment of the invention, communication of information between the various components of deposit sweep arrangement 100 is accomplished over a network consisting of electronic devices connected either physically or wirelessly, wherein digital information is transmitted from one device to another. Such devices may include, but are not limited to, a desktop computer, a laptop computer, a handheld device or PDA, a telephone, a set top box, an Internet appliance, or the like. Exemplary networks include a Local Area Network, a Wide Area Network, an organizational intranet, the Internet, or the like. The functionality of an exemplary computer and network are further explained in conjunction with FIG. 5, below.
System balancing is divided into five phases that serve as building blocks on each other starting with the net daily activity received from back-office service provider 102 and concluding with settlement agent 106 reconciliation. By dividing this process into phases it is possible to detect an out-of-balance condition before starting the end of day funds transfer process.
The first phase balances the data received from the broker-dealer back office service provider against the data accepted by the sweep engine. All inbound activity files contain a trailer record that stores the number of records on the file and the total of all debit and credit transactions. During the file processing and parsing process, the three data values referenced are internally computed and stored. When the inbound activity file processing is complete the internally computed record count, aggregated debit and credit transactions are matched to the values stored on the inbound trailer record. These values must be in agreement for processing to continue.
After the inbound activity file is successfully balanced, the sweep engine will begin core processing or allocation of the net daily activity, described below with respect to FIGS. 2-4. A second balancing phase occurs during the allocation and posting process, when the sweep engine internally counts the number of transactions received and accumulates the value of credits and debits received. At the conclusion of the processing, these values are compared against the retained control totals from an internal transmission balancing process. This is done to confirm that all transactions provided to the sweep engine have either been posted to the account or, in the case of an error, duly reported.
As a result of the allocation and posting processing, the sweep engine will create a funds transfer report detailing the allocation of the daily activity among the various depository institutions. As a third balancing phase, the total sum of funds allocated across these depository institutions should balance to the net total of credits and debits processed in the allocation and posting phase.
After the final allocation and posting of daily activity transactions, the settlement agent will receive an electronic transmission of wire instructions from or on behalf of the custodial agent. The wires will be posted to a settlement account pending transmissions to/from the depository institutions. A fourth balancing phase occurs at the conclusion of the day, when the settlement account is reconciled to validate that all transmissions have been completed and that expected funds from the depository institutions were received. The net balance of the settlement account should equal the net total on an expected funds settlement balancing report.
On the day following system processing, the custodial accounts balances and accrued interest from the depository institutions will be obtained for balancing against derived aggregate deposit balances (e.g., as calculated by applying the all-in rate to the individual account balances) stored within the sweep engine. The first three phases of reconciliation described above can be monitored and verified by a series of daily reports. The settlement agent contracts with the custodial agent to perform the fourth level of reconciliation described above utilizing standard reconciliation processes which include daily verification of “zero balances” in all settlement accounts. The fifth phase of reconciliation may be performed by utilizing a reconciliation dashboard, such as disclosed in pending U.S. patent application Ser. No. 11/556,662, incorporated herein by reference in its entirety
As discussed above, in the United States, for example, Regulation D limits transfers from an MMDA account to six per month or other statement cycle. During the allocation and posting processing, sweep engine 104 manages allocation of funds swept into the Individual and Omnibus TAs and MMDAs on a daily and monthly (or other periodic) basis, so that transfers from the Individual and Omnibus MMDAs are limited.
In one embodiment, the allocation and posting processing are incorporated into deposit sweep engine 104. Data registers or data sets are established in an allocation database for storing data representative of the amount of funds deposited in the Omnibus TA and the Omnibus MMDA. Data registers or data sets are also established in the allocation database for each customer for storing data representative of the allocation of funds between the customer's Individual TA and Individual MMDA. The Individual TAs and MMDAs correspond to the Omnibus TA and Omnibus MMDA at each depository institution, such that the sum of the balances recorded in the Individual TAs is equal to the balance of funds deposited in the Omnibus TA and the sum of the balances recorded in the Individual MMDAs is equal to the balance of funds deposited in the Omnibus MMDA. Data registers or data sets are also established for storing data representative of the number of transfers from the individual MMDA and Omnibus MMDA for use in Tracking regulatory compliance. For example, an IMMDA transfer counter and OMMDA transfer counter are established in the deposit sweep engine database for storing data representative of the number of transfers from the IMMDA and OMMDA, respectively.
In one embodiment, to aide in regulatory compliance, at the start of each month, a set percent of the aggregate deposited funds is retained in the Omnibus TA, for example 1%, 5%, or any other percent, may be retained in the Omnibus TA. It is desirable that this set percent, or target OTA percent (TTP), be as small as possible. The TTP may be based on a number of factors, such as transaction history in the individual and/or custodial deposit accounts, or may be set arbitrarily, as would be apparent to one of ordinary skill in the art. Additionally, as would be apparent to one of ordinary skill in the art, the TTP may be optimized so that the minimum amount of funds are kept in the Omnibus TA while still ensuring compliance with transfer limits. For example, the TTP may be managed and altered during the calendar month or other statement cycle, as discussed below,
In one embodiment, the target OTA percent (TTP) can be set lower, but increased during the month or statement cycle each time a transfer is required from the OMMDA. To that end, during each transfer from the OMMDA during the month or statement cycle, sufficient funds are transferred to increase the TTP to a larger percentage based on the number of remaining transfers (as represented by the OMMDA transfer counter). For example, the month or statement cycle may begin with the TTP set to 1% and the OMMDA transfer counter set to 0. When a first transfer from the OMMDA is needed during the month or statement cycle, the OMMDA transfer counter in increased to I and the TTP is raised to 3%. The Individual TA data and the Individual MMDA data are modified for one or more of the plurality of individuals so that the OTA will contain 3% of the total omnibus hinds after settlement of the account. If a second transfer is needed from the OMMDA during the month or statement cycle, the OMMDA transfer counter is incremented from 1 to 2 and the TTP is raised to 4%. If a third transfer is needed during the month or statement cycle, the OMMDA transfer counter is incremented from 2 to 3 and the T′I′P is raised to 5%. If a fourth transfer from the OMMDA is needed during the month or statement cycle, the OMMDA transfer counter is incremented from 3 to 4 and the TTP is raised to 10%. If a fifth transfer is required during the month or statement cycle, the OMMDA transfer counter is incremented from 4 to 5 and the TTP is raised to 20%. Finally, if a sixth transfer is needed (and if six transfers is the transfer limit), the OMMDA transfer counter is incremented from 5 to 6 and the TTP is raised to 100%. In other words, as discussed herein, when the transfer limit is reached, the Individual TA data and the Individual MMDA data are modified so that the entire balance of each Individual MMDA is transferred to its respective Individual TA. The exact percentages for the TTP that correspond to each transfer can be modified as would be apparent to one of skill in the art, to optimize the process. For example, percentages may be set differently depending on how large the depository institution's balances are, since banks with large balances tend to have a lower percentage of outbound transfers.
Further, in another embodiment, the TTP may be reduced at the end of the calendar month or other statement cycle, if the number of transfers from the OMMDA to the OTA during the month were low as compared to the transfer limit. For example, if there are four transfers remaining before reaching a transfer limit of six in a given calendar month or statement cycle (i.e. the OMMDA transfer counter is less than three), but only three days remaining in the calendar month or statement cycle, the TTP can be reduced to 0% for the remainder of the calendar month or statement cycle, since there can be transfers out of the OMMDA each of the remaining days of the month or statement cycle without reaching the transfer limit.
Despite any modifications made to the TTP during the month or statement cycle, the TTP can be reset (e.g., returned to 1%) at the start of the following calendar month or statement cycle as discussed further below with respect to FIG. 4.
On a regular periodic basis, e.g., daily, a deposit sweep engine processor receives customer transaction data from back office service provider 102 representative of a daily deposit and withdrawal information for each customer. In one embodiment, the customer transaction data is a daily net deposit or daily net withdrawal made by each individual. As discussed above, the sweep engine processor optimizes swept balances for FDIC insurance coverage and bank network requirements, in some instances splitting swept balances among a plurality of banks, in amounts that do not exceed the deposit insurance limit for each customer at each depository institution, permitting customer funds to be eligible for insurance coverage in excess of the basic FDIC limit. As would be apparent to one of skill in the art, during the allocation and posting processing, tests are performed relating to each net customer transaction to ascertain whether or not the customer has a sufficient balance to satisfy the desired transfer. Then, for each depository institution, the sweep engine processor determines an aggregate amount of funds to be deposited or withdrawn from the Omnibus TA and Omnibus MMDA to cover the customer activity, based on the net daily transaction data, and allocates funds for each Individual TA and Individual MMDA corresponding to the custodial deposit accounts. Funds needed for satisfaction of transfers out of the individual sweep accounts are satisfied by funds withdrawn in the aggregate from the custodial accounts and funds transferred into the individual sweep accounts are deposited in the aggregate to the custodial accounts.
FIG. 2 is a flow chart providing an example of an allocation process 200 that allocates deposits and withdrawals on the individual account level for both the IMMDA and ITA. The deposit sweep engine processor reads the customer transaction data and first determines whether the customer's net daily transaction is a withdrawal (step 202). If it is not a withdrawal, the processor adds the net daily deposit amount, if any, to the customer's ITA (step 216). The processor then moves to the next customer, if any, and starts over (step 218). If there are no remaining customers, the processor proceeds to step 302, as discussed below with respect to FIG. 3.
Beginning with the first customer, if the customer's net daily transaction is a withdrawal, the deposit sweep engine processor determines whether the customer's net withdrawal is greater than the amount of funds in the customer's ITA (step 204). If the net withdrawal is not greater than the amount of funds in the ITA, the processor subtracts the withdrawal amount from the ITA (step 214). The processor then moves to the next individual, if any, and starts over (step 218). If, however, the net withdrawal is greater than the amount of funds in the ITA, the processor adds 1 to the individual's IMMDA transfer counter (step 206). The processor then determines whether the individual's IMMDA transfer counter is equal to 6 or some other established transfer limit (step 208). If the counter is equal to the transfer limit, the processor transfers the entire balance of funds in the IMMDA to the ITA (step 210). If it is less than the transfer limit, the processor transfers the net withdrawal amount from the IMMDA to the ITA (step 212). In either case, the processor will then subtract the withdrawal amount from the ITA (step 214). The processor then moves to the next individual, if any, and starts over (step 218).
As a result of allocation process 200, the deposit sweep engine processor updates the allocation database for each customer's ITA and IMMDA account based on the allocations described above.
FIG. 3 is a flow chart providing an example of an allocation process 300 that allocates ITA and IMMDA balances on the customer account level to minimize the number of transfers from the OMMDA for a given period. After allocation process 200 has concluded, the deposit sweep engine processor first determines the net balance change for the OMMDA (step 302), based on a comparison of a sum of the data generated for each customer's IMMDA during allocation process 200 against the data received from the depository institution and/or stored in the allocation database representing the current balance of funds in the OMMDA. The deposit sweep engine processor then determines whether the net balance change for the OMMDA is a negative amount greater than the OTA balance (step 304), by comparison to the data received from the depository institution and/or stored in the allocation database representing the current balance of funds in the OTA.
If the net balance change for the OMMDA is a negative amount greater than the OTA balance, the processor adds 1 to the OMMDA transfer counter (step 316). Next, the processor determines whether the OMMDA transfer counter is equal to 6 or some other established transfer limit (step 318). If the OMMDA transfer counter is equal to the transfer limit, then the processor sets the TTP to 100% (step 319) and transfers every individual's entire IMMDA balance to their respective ITA (step 320). If it is not equal to the transfer limit, the processor increases the TTP to a larger percentage based on the number of remaining transfers (step 321) and transfers funds from one or more of the plurality of individual's IMMDA to their respective ITA until the Target OTA balance is reached (step 322).
If the net balance change for the OMMDA is not a negative amount greater than the OTA balance, the processor then determines whether the net balance change is negative (step 306). If the net balance is negative, the processor transfers funds from one or more ITAs to their respective IMMDAs until the net balance change amount is reached (step 314). In one embodiment, the processor determines which, if any, customers hold eligible ITA balances. Eligible customers have IMMDA transfer counters of less than 6 or some other established transfer limit. Then, beginning with eligible customers that hold the largest ITA balances, the processor transfers all or a portion of the ITA balance to the respective IMMDA. When the net balance change amount is reached, the processor stops ITA balance transfer processing. If the net balance change is exceeded with the transfer of funds from a single ITA, the processor transfers only the funds required. The processor repeats this determination-and-transfer process until the OMMDA net balance change is reduced to zero.
If, on the other hand, the net balance change for the OMMDA is not a negative amount greater than the OTA balance and the net balance change is not negative, the processor first determines whether the OMMDA transfer counter is equal to 6 or some other transfer limit (step 308). If the OMMDA transfer counter is equal to the transfer limit, the processor does not transfer any ITA funds to the IMMDA (step 310). If the OMMDA transfer counter is not equal to the transfer limit, the processor transfers funds from one or more ITAs to their respective IMMDAs until the Target OTA balance is reached (step 312).
For example, in one embodiment, in step 312, the processor determines whether the OTA balance is greater than the target OTA balance. The target OTA balance is calculated by multiplying the target OTA percent (TTP), discussed above, by the sum total of the OMMDA and OTA balances. If the OTA balance is greater than the target OTA balance, then the processor transfers funds from the ITAs to the IMMDAs until the target OTA is reached. Beginning with customers that hold the largest ITA balance, the processor transfers funds from the ITAs to the IMMDAs. When the target OTA balance is reached, the processor stops transferring funds from the ITAs. If the target OTA balance is reached with funds from a single ITA, the processor only transfers the funds required from that customer's ITA,
As a result of allocation process 300, the processor updates the database for the Omnibus TA and Omnibus MMDA, as well as each customer's ITA and IMMDA, based on the allocations described above.
The sweep engine processor then creates a funds transfer report for each depository institution detailing the allocation of the daily activity among the OTA and OMMDA, as well as instructions for either a net withdrawal from or net deposit to the custodial deposit accounts, for daily settlement of the OTA and OMMDA accounts (step 324). The settlement agent receives an electronic transmission of wire instructions from or on behalf of the custodial agent and then transmits funds to or from the depository institutions based on those instructions. The sweep engine process also creates a funds allocation report detailing the allocation of the daily activity between each customer's Individual TA and individual MMDA and forwards such instructions to the custodial agent for reconciliation with the custodial agent's books and records for each customer
The allocation processes described with respect to FIGS. 2 and 3 are repeated on a daily basis during the calendar month or other statement cycle. Additionally, at the beginning of each month or other statement cycle, a rebalance process 400 is employed for rebalancing the ITA and IMMDA accounts, as shown in FIG. 4. The processor reviews the data sets representative of the amount of funds allocated to the individual and omnibus accounts as well as the IMMDA transfer counter for the previous month or statement period.
For each customer where the IMMDA transfer counter reached 6 during the previous period, the processor transfers from the ITA to the respective IMMDA an amount of funds equal to the total ITA balance minus the product of the target OTA percent (TTP) and the total ITA balance (step 402). In this manner, only the target OTA percent of the total ITA balance of funds is retained in the ITA with the remainder of the funds allocated to the IMMDA. After such reallocation for each customer where the IMMDA transfer counter reached 6 during the previous period, the processor then determines a modified OTA and OMMDA balance based on the rebalancing in step 402 and determines whether the OTA balance is now greater than the target OTA balance (step 404). As discussed above, the target OTA balance is calculated by multiplying the target OTA percent (TTP) by the sum total of the OMMDA and OTA balances. If the OTA balance is not greater than the target OTA balance, the processor makes no further modification to the allocation of funds in the ITAs and IMMDAs.
If the OTA balance is greater than the target OTA balance, the processor determines the delta or excess percent over the target OTA percent (TTP) (step 406). In particular, the processor determines the delta or excess percent by calculating the percent of funds in the customer ITAs for the customers where the IMMDA transfer counter did not reach 6 during the previous period, as compared to the total balance of funds in both the ITAs and IMMDAs for the customers where the IMMDA transfer counter did not reach 6 during the previous period. The target OTA percent (TTP) is then subtracted from this calculated percent. Next, for each customer where the IMMDA transfer counter did not reach 6 during the previous period, the processor transfers the delta or excess percent from the ITA to the IMMDA, so that the target OTA balance is reached (step 408). For example, if the TTP is set at 1%, but the sum of the funds allocated to the ITAs for the customers where the IMMDA transfer counter did not reach 6 during the previous period, as compared to the total balance of funds in both the ITAs and IMMDAs for the customers where the IMMDA transfer counter did not reach 6 during the previous period is 3%, then 2% of the balance of funds in the ITAs of each customer where the IMMDA transfer counter did not reach 6 during the previous period is transferred to their respective IMMDA. After steps 402 and 408, the OTA balance will be reached.
The processor finishes rebalance process 400 by resetting the IMMDA and OMMDA transfer counters to zero (step 410). One of ordinary skill in the art will appreciate that a more elaborate rebalancing process could also be employed to further optimize the allocation of funds, so that a minimum amount of funds are kept in the Omnibus TA while still ensuring compliance with established transfer limits. For example, whereas in the embodiment described above, the TTP is returned to at a set percent (e.g., 1%) at the beginning of each month or statement cycle, in an alternative embodiment, the TTP could be increased or decreased on a monthly or other periodic basis based on activity in the individual and custodial deposit accounts, as would be apparent to one of ordinary skill in the art, so that a minimum amount of funds are kept in the Omnibus TA while still ensuring compliance with established transfer limits.
As a result of the monthly rebalance process, the deposit sweep engine processor creates a funds transfer report detailing the rebalancing allocation for the OTA and OMMDA accounts. The settlement agent then receives an electronic transmission of wire instructions from or on behalf of the custodial agent and transmits these instructions to the depository institution to reallocate funds in the custodial deposit accounts. Similarly, instructions are provided to the custodial agent to rebalance funds allocated to the Individual TAs and Individual MMDAs on the books and records of the custodial agent.
According to the present invention, a plurality of customers of a custodial agent are provided with FDIC insurance for funds in excess of $100,000 at an agreed-to interest rate. The depository institutions are provided with a stable source of funds with reduced reserve requirements. The custodial agent and the agent or administrator receive fees from the “all in cost of funds” paid by the depository institution for managing allocation of funds at the individual and custodial levels and for facilitating transfers between the individual accounts and the custodial accounts to satisfy daily transactions. Regulatory compliance is managed through allocation of funds in the individual accounts by the deposit sweep engine processor prior to instructing the depository institutions as to the omnibus account, such that a minimum or reduced amount of funds are kept in the Omnibus TA while still limiting transfers.
The present invention (i.e., components of deposit sweep arrangement 100 (e.g., back office service provider 102, deposit sweep engine 104 and its associated database and processor, settlement agent 106), process 200, process 300, process 400 or any parts or functions thereof) may be implemented using hardware, software or a combination thereof and may be implemented in one or more computer systems or other processing systems. However, the manipulations performed by the present invention are often referred to herein in terms, such as comparing or identifying, which are commonly associated with mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein which form part of the present invention. Rather, the operations are machine operations. Useful machines for performing the operation of the present invention include general purpose digital computers or similar devices, such as a computer system 500, as shown in FIG. 5, in which the present invention, or portions thereof, can be implemented as computer-readable code.
Computer system 500 includes one or more processors, such as processor 504. Processor 504 can be a special purpose or a general purpose digital signal processor. Processor 504 is connected to a communications infrastructure 506 (for example, a bus or network). Various software implementations are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the relevant art how to implement the invention using other computer systems and/or computer architectures.
Computer system 500 can include a display interface 502 that forwards graphics, text, and other data from communication infrastructure 506 (or from a frame buffer not shown) for display on a display unit 530.
Computer system 500 also includes a main memory 508, preferably random access memory (RAM), and may also include a secondary memory 510. Secondary memory 510 may include, for example, a hard disk drive 512, a removable storage drive 514, and/or a memory stick or the like. Removable storage drive 514 may comprise a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, or the like. Removable storage drive 514 reads from and/or writes to a removable storage unit 518 in a well known manner. Removable storage unit 518 may comprise a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 514. As will be appreciated by persons skilled in the relevant art(s), removable storage unit 518 includes a computer usable storage medium having stored therein computer software and/or data.
In alternative implementations, secondary memory 510 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 500. Such means may include, for example, a removable storage unit 522 and an interface 520. Examples of such means may include a program cartridge and cartridge interface, a removable memory chip (such as an erasable programmable read only memory (EPROM), programmable read only memory (PROM)) and associated socket, and other removable storage units 522 and interfaces 520 which allow software and data to be transferred from the removable storage unit 522 to computer system 500.
Computer system 500 may also include a communications interface 524. Communications interface 524 allows software and data to be transferred between computer system 500 and external devices. Communications interface 524 may include a modem, a network interface (such as an Ethernet card), a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, wired or wireless systems, or the like. Software and data transferred via communications interface 524 are in the form of signals 528 which may be electronic, electromagnetic, optical or other signals capable of being received by communications interface 524. These signals 528 are provided to communications interface 524 via a communications path 526. Communications path 526 carries signals 528 and may be implemented using wire or cable, fiber optics, a phone line, a cellular link, a radio frequency (RF) link and/or other communications channels.
In this document, the terms “computer program medium,” “computer usable medium” and “computer readable medium” are used to generally refer to media such as removable storage unit 518, removable storage unit 522, and a hard disk installed in hard disk drive 512. Computer program medium and computer usable medium can also refer to memories, such as main memory 508 and secondary memory 510, which can be memory semiconductors (e.g., DRAMs, etc.). These computer program products are means for providing software to computer system 500.
Computer programs (also called computer control logic) are stored in main memory 508 and/or secondary memory 510. Computer programs may also be received via communications interface 524. Such computer programs, when executed, enable the computer system 500 to implement the present invention as discussed herein. In particular, the computer programs, when executed, enable the processor 504 to implement the processes of the present invention, such as the steps illustrated in FIGS. 2-4, discussed above. Accordingly, such computer programs represent controllers of the computer system 500. Where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system 500 using removable storage drive 514, interface 520, hard drive 512 or communications interface 524. The control logic (software), when executed by processor 504, causes processor 504 to perform the functions of the invention as described herein.
In another embodiment, the invention may be implemented primarily in hardware using, for example, hardware components such as an integrated circuit (IC) customized for a particular use, also known as application specific integrated circuits (ASICs). Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art.
In yet another embodiment, the invention is implemented using a combination of both hardware and software.
The invention is also directed to computer program products comprising software stored on any computer useable medium. Such software, when executed in one or more data processing devices, causes the data processing device(s) to operate as described herein. Embodiments of the invention employ any computer useable or readable medium, known now or in the future. Examples of computer useable mediums include, but are not limited to, primary storage devices (e.g., any type of random access memory), secondary storage devices (e.g., hard drives, floppy disks, CD ROMS, DVD ROMS, ZIP disks, tapes, magnetic storage devices, optical storage devices, MEMS, nanotechnological storage device, etc.), and communication mediums (e.g., wired and wireless communications networks, local area networks, wide area networks, intranets, etc.). It is to be appreciated that the embodiments described herein can be implemented using software, hardware, firmware, or combinations thereof.
While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example, and not limitation. It will be apparent to persons skilled in the relevant art(s) that various changes in form and detail can be made therein without departing from the spirit and scope of the present invention. Thus, the present invention should not be limited by any of the above described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
In addition, it should be understood that the figures and screen shots illustrated in the attachments, which highlight the functionality and advantages of the present invention, are presented for example purposes only. The architecture of the present invention is sufficiently flexible and configurable, such that it may be utilized (and navigated) in ways other than that shown in the accompanying figures.
Further, the purpose of the foregoing Abstract is to enable the U.S. Patent and Trademark Office and the public generally, and especially the scientists, engineers and practitioners in the art who are not familiar with patent or legal terms or phraseology, to determine quickly from a cursory inspection the nature and essence of the technical disclosure of the application. The Abstract is not intended to be limiting as to the scope of the present invention in any way.
EXAMPLE
FIGS. 6A-6H provide a table of data representative of data produced by an exemplary deposit sweep engine processor managing custodial deposit accounts according to one embodiment of the present invention. FIG. 6 provides account balance information for an Omnibus TA and Omnibus MMDA and corresponding Individual TAs and Individual MMDAs for the first eight days in a given month for three customers: Andrew, Betty, and Carl.
The first day of data is shown in FIG. 6A. Line 1 shows the respective account balances at the start of the first day. According to one embodiment of the present invention, the TTP is set to 5% and, as such, 5% of the total funds deposited by each customer is allocated to the customer's individual TA and the remaining 95% of the total funds is allocated to the customer's individual MMDA. This allocation provides a cushion for the Omnibus TA of 5%.
Lines 1 a and 1 b show the response of the deposit sweep engine processor to individual daily net account activity for day 1. Specifically, Andrew writes a check for $10, Betty deposits a check for $5, and Carl has no account activity. Line 1 a shows the updated account balances following two allocations performed by the processor: (1) an allocation of funds from Andrew's MMDA to his TA to cover his check; and (2) an allocation of funds to Betty's TA to reflect her deposit. Line 1 b shows the updated account balances following a $10 Withdrawal from Andrew's TA to cover his check.
Based on the individual daily net activity, the processor determines that the daily net activity will result in a negative net balance change in the Omnibus MMDA of $5, caused by the transfer of funds from Andrew's MMDA to his TA to cover his $10 withdrawal. Line 1 c shows the updated account balances following the processor's reallocation of funds in the Individual TAs and MMDAs to offset the negative net balance change. Specifically, the processor allocates funds first from an individual having the highest Individual TA balance to his or her corresponding Individual MMDA in order to offset the negative net balance change. This results in a $5 allocation from Betty's TA to her MMDA. This allocation reduces the cushion for the Omnibus TA to 3.39%.
At the end of the first day, although there was a negative net balance change of $5 resulting from the daily activity, the reallocation of funds in the Individual TAs and MMDAs has eliminated the net transfer from the Omnibus MMDA. The only individual charged with an MMDA transfer (as reflected by the incremented individual transfer counter) is Andrew because he is the only individual having an MMDA transfer from his account.
The second day of data is shown in FIG. 6B. Line 2 shows the updated account balances following the daily settlement of accounts during day 1. Lines 2 a and 2 b show the response of the deposit sweep engine processor to individual daily net account activity for day 2. Specifically, Andrew writes a check for $5 and both Betty and Carl have no account activity. Line 2 a shows the updated account balances following an allocation of funds from Andrew's MMDA to his TA to cover his check. Line 2 b shows the updated individual account balances following a $5 withdrawal from Andrew's TA to cover his check.
Based on the individual daily net activity, the processor determines that the daily net activity will result in a negative net balance change in the Omnibus MMDA of $5, caused by the transfer of funds from Andrew's MMDA to his TA to cover his $5 withdrawal. Line 2 c shows the updated individual account balances following the processor's reallocation of funds in the Individual TAs and MMDAs to offset the negative net balance change. Specifically, the processor allocates funds from Betty's TA to Betty's MMDA because Betty has the highest TA balance among the three individuals. This results in a $5 allocation from Betty's TA to her MMDA. Note that because Carl has an equally high TA balance, the processor could have transferred the $5 from Carl's TA to Carl's MMDA instead. However, regardless of whose account is used, the allocation reduces the cushion for the Omnibus TA to 1.72%.
At the end of the second day, although there was a negative net balance change of $5 resulting from the daily activity, the reallocation of funds in the Individual TAs and Individual MMDAs has eliminated the negative net balance change from the Omnibus MMDA. The only individual charged with an MMDA transfer is Andrew because he is the only individual having an MMDA transfer from his account.
The third day of data is shown in FIG. 6C. Line 3 shows the updated account balance following the daily settlement of accounts during day 2. Line 3 a shows the response of the deposit sweep engine processor to individual daily net account activity for day 3. Specifically, Betty deposits $20 and both Andrew and Carl have no account activity. Line 3 a shows the updated account balances following an allocation of funds to Betty's TA to reflect her deposit.
Based on the individual daily net activity, the processor determines that the daily net activity will not result in negative net balance change from the Omnibus MMDA. The processor determines that the daily net activity increases the Omnibus TA balance above the target Omnibus TA balance. That is, Betty's deposit increases the cushion for the Omnibus TA to 8.86%, which is above the TTP of 5%. Line 3 b shows the updated account balances following a reallocation by the processor to reduce the cushion to the TTP of 5%. Specifically, $9.50 of Betty's $20.00 deposit is allocated to her MMDA, the rest being allocated to her TA.
The fourth day of data is shown in FIG. 6D. Line 4 shows the updated account balance following the daily settlement of accounts during day 3. Lines 4 a and 4 b show the response of the deposit sweep engine processor to individual daily net account activity for day 4. Specifically, Carl writes a check for $20 and both Andrew and Betty have no account activity. Line 4 a shows the updated account balances following an allocation of funds from Carl's MMDA to his TA to cover his check. Line 4 b shows the updated account balances following a $20 withdrawal from Carl's TA to cover his check.
Based on the individual daily net activity, the processor determines that the daily net activity will result in a negative net balance change in the Omnibus MMDA of $15, caused by the transfer of funds from Carl's MMDA to his TA to cover his $20 withdrawal. Unlike the situation in days 1 and 2, however, the negative net balance change is greater than the balance of the Omnibus TA. As a result, the custodial accounts are charged with an Omnibus MMDA transfer (as reflected by the incremented Custodial transfer counter) and the TTP is increased. Here the TTP is increased by 7% for a resulting TTP of 12%. The processor determines that the total amount of funds needed to be transferred from the various Individual MMDAs to their respective TAs to provide for a 12% TTP is equal to $24.30. Because Carl's Individual MMDA transfer counter will be incremented anyway and because he has enough funds to cover the transfer, the processor allocates the $24.30 from Carl's MMDA to his TA. Line 4 c shows the account balances following this allocation. If, however, Carl did not have enough funds to cover the transfer, the processor would allocate funds first from an individual having the highest TA balance. In another embodiment, the processor would rank potential individuals based on their Individual transfer counter and TA balance in order to minimize the number of individuals charged with an MMDA withdrawal while favoring individuals having lower Individual transfer counters.
The fifth day of data is shown in FIG. 6E. Line 5 shows the respective account balances following the daily settlement of accounts during day 4. Lines 5 a and 5 b show the response of the deposit sweep engine processor to individual daily net account activity for day 5. Specifically, Andrew writes a check for $10 and both Betty and Carl have no account activity. Line 5 a shows the updated account balances following an allocation of funds from Andrew's MMDA to his TA to cover his check. Line 5 b shows the updated account balances following a $10 withdrawal from Andrew's TA to cover his check.
Based on the individual daily net activity, the processor determines that the daily net activity will result in a negative net balance change in the Omnibus MMDA of $10, caused by the transfer of funds from Andrew's MMDA to his TA to cover his $10 withdrawal. Line 5 c shows the updated account balances following the processor's reallocation of funds in the Individual TAs and MMDAs to offset the negative net balance change. Specifically, the processor allocates funds from Carl's TA to Carl's MMDA because Carl has the highest TA balance among the three individuals. This results in a $10 allocation from Carl's TA to his MMDA. This allocation reduces the cushion for the Omnibus TA to 8.86%
At the end of the fifth day, although there was a negative net balance change of $10 resulting from the daily activity, the reallocation of funds in the Individual TAs and MMDAs has eliminated the net transfer from the Omnibus MMDA. The only individual charged with an MMDA transfer is Andrew because he is the only individual having an MMDA transfer from his account.
The sixth day of data is shown in FIG. 6F. Line 6 shows the updated account balances following the daily settlement of accounts during day 5. Lines 6 a and 6 b show the response of the deposit sweep engine processor to individual daily net account activity for day 6. Specifically, Andrew writes a check for $45 and both Betty and Carl have no account activity. Line 6 a shows the updated account balances following an allocation of funds from Andrew's MMDA to his TA to cover his check. Line 6 b shows the updated account balances following a $45 withdrawal from Andrew's TA to cover his check.
Based on the individual daily net activity, the processor determines that the daily net activity will result in a negative net balance change in Omnibus MMDA of $45, caused by the transfer of funds from Andrew's MMDA to his TA to cover his $45 withdrawal. Like the situation in day 4, the negative net balance change is greater than the balance of the Omnibus TA. As a result, the custodial accounts are charged with an Omnibus MMDA transfer and the TTP is increased. Here the TTP is increased by 15% for a resulting TTP of 27%. The processor determines the total amount of funds needed to be transferred from the various Individual MMDAs to their respective TAs to provide for a 27% TTP is equal to $38.65. Because Andrew does not have enough funds to cover the transfer, the processor allocates funds first from an individual having the highest MMDA balance. As a result, Betty's MMDA counter is incremented and the $38.65 is moved from her MMDA to her TA. Line 6 c shows the account balances following this allocation.
The seventh day of data is shown in FIG. 6G. Line 7 shows the updated account balances following the daily settlement of accounts during day 6. Line 7 a shows the response of the deposit sweep engine processor to individual daily net account activity for day 6. Specifically, Andrew deposits $100 and both Andrew and Carl have no account activity. Line 7 a shows the updated account balances following an allocation of funds to Andrew's TA to reflect his deposit.
Based on the individual daily net activity, the processor determines that the daily net activity will not result in a negative net balance change in the Omnibus MMDA. The processor determines that the daily net activity increases the Omnibus TA balance above the target Omnibus TA balance. That is, Andrew's deposit increases the cushion for the Omnibus TA to 48.79%, which is above the TTP of 27%. Line 7 b shows the updated account balances following a reallocation by the processor to reduce the cushion to the TTP of 27%. Specifically, $63.00 of Andrew's $100.00 deposit is allocated to his MMDA, the rest being allocated to his TA.
The eighth day of data is shown in FIG. 6H. Line 8 shows the updated account balances following the daily settlement of accounts during day 7. Lines 8 a and 8 b show the response of the deposit sweep engine processor to individual daily net account activity for day 8. Specifically, Andrew writes a check for $110, Carl deposits $5, and Betty has no account activity. Line 8 a shows the updated account balances following two allocations performed by the processor: (1) an allocation of funds from Andrew's MMDA to his TA to cover his check; and (2) an allocation of funds to Carl's TA to reflect his deposit. Line 8 b shows the updated account balances following a $110 withdrawal from Andrew's TA to cover his check.
Based on the individual daily net activity, the processor determines that the daily net activity will result in a negative net balance change in the Omnibus MMDA of $105, caused by the transfer of funds from Andrew's MMDA to his TA to cover his $110 withdrawal. Like the situations in days 4 and 6, the negative net balance change is greater than the balance of the Omnibus TA. As a result, the custodial accounts are charged with an Omnibus MMDA transfer and the TTP is increased. Here the TTP is increased by 20% for a resulting TTP of 47%. The processor determines that the total amount of funds needed to be transferred from the various Individual MMDAs to their respective TAs to provide for a 47% TTP is equal to $39.65. Because Andrew does not have enough funds to cover the transfer, the processor allocates funds first from an individual having the highest MMDA balance. As a result, Betty's MMDA transfer counter is incremented and the $39.65 is moved from her MMDA to her TA. Line 8 c shows the account balances following this allocation.
As would be apparent to one of ordinary skill in the art, the deposit sweep engine processor will continue to manage the custodial deposit accounts, as discussed above, for the remainder of the month or statement cycle, and then rebalance the individual accounts of Andrew, Betty and Carl at the beginning of the following month or statement cycle.
It is to be appreciated that the Detailed Description section, and not the Summary and Abstract sections, is intended to be used to interpret the claims. The Summary and Abstract sections may set forth one or more but not all exemplary embodiments of the present invention as contemplated by the inventor(s), and thus, are not intended to limit the present invention and the appended claims in any way.
The present invention has been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed.
The foregoing description of the specific embodiments will so fully reveal the general nature of the invention that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present invention. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.
The breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims (13)

1. A computer-implemented method for managing, over a period of time, funds held in custodial accounts at a depository institution by a custodial agent on behalf of a plurality of customers, wherein said custodial accounts comprise an omnibus transaction account (“Omnibus TA”) and an omnibus money market deposit account (“Omnibus MMDA”), comprising:
(a) determining a balance of funds in said custodial accounts, wherein said Omnibus TA represents a plurality of individual transaction accounts (“Individual TAs”) of one or more of said plurality of customers and said Omnibus MMDA represents a plurality of individual money market deposit accounts (“Individual MMDAs”) of one or more of said plurality of customers, and wherein said Omnibus TA has a balance of funds in an amount equal to the total aggregate amount of funds in said Individual TAs and said Omnibus MMDA has a balance of funds in an amount equal to the total aggregate amount of funds in said Individual MMDAs;
(b) determining a resulting balance of funds in one or more Individual TAs and one or more Individual MMDAs based on transaction data for one or more of said plurality of customers;
(c) deriving with one or more processors of said computer a derived net balance change for said Omnibus MMDA from transaction data for one or more of said plurality of customers;
(d) comparing with said one or more processors said derived net balance change to the balance of funds in said Omnibus TA;
(e) determining which of said plurality of customers has an eligible Individual TA based on at least a number of prior transfers from each customer's Individual MMDA within said period of time and said resulting balance of funds in said customer's Individual TA; and
(f) allocating funds with said one or more processors from one or more of said eligible Individual TAs to their respective Individual MMDAs in order to offset a negative derived net balance change not greater than the amount of funds in said Omnibus TA and minimize the number of transfers from the Omnibus MMDA.
2. A method according to claim 1, wherein said Omnibus TA and said Omnibus MMDA are interest-bearing accounts.
3. A method according to claim 1, further comprising:
allocating funds with said one or more processors from one or more of said Individual MMDAs to their respective Individual TAs in order to offset a negative derived net balance change in an amount greater than the balance of funds in said Omnibus TA, wherein said allocated funds are in an amount equal to said negative derived net balance change.
4. A method according to claim 1, further comprising:
allocating funds with said one or more processors from one or more of said Individual MMDAs to their respective Individual TAs in order to offset a negative derived net balance change in an amount greater than the balance of funds in said Omnibus TA, wherein said allocated funds are in an amount greater than said negative derived net balance change.
5. A method according to claim 1, further comprising:
when said derived net balance change is a negative derived net balance change in an amount greater than the balance of funds in said Omnibus TA, incrementing an Omnibus MMDA transfer counter by one.
6. A method according to claim 5, further comprising:
when said incremented Omnibus MMDA transfer counter is equal to a predetermined transfer limit for said Omnibus MMDA, allocating with said one or more processors an entire amount of funds from said Individual MMDAs to their respective Individual TAs.
7. A method according to claim 6, wherein said predetermined transfer limit for said Omnibus MMDA is six.
8. A method according to claim 1, wherein said period of time is a month.
9. A method according to claim 1, wherein said period of time is a statement cycle.
10. A method according to claim 1, wherein said Individual TAs and said Individual MMDAs are interest-bearing accounts.
11. A computer-implemented method for managing, over a period of time, funds held in custodial accounts at a depository institution by a custodial agent on behalf of a plurality of customers, wherein said custodial accounts comprise an omnibus transaction account (“Omnibus TA”) and an omnibus money market deposit account (“Omnibus MMDA”), comprising:
(a) determining a balance of funds in said custodial accounts, wherein said Omnibus TA represents a plurality of individual transaction accounts (“Individual TAs”) of one or more of said plurality of customers and said Omnibus MMDA represents a plurality of individual money market deposit accounts (“Individual MMDAs”) of one or more of said plurality of customers, and wherein said Omnibus TA has a balance of funds in an amount equal to the total aggregate amount of funds in said Individual TAs and said Omnibus MMDA has a balance of funds in an amount equal to the total aggregate amount of funds in said Individual MMDAs;
(b) deriving with one or more processors of said computer a derived net balance change for said Omnibus MMDA from transaction data for one or more of said plurality of customers;
(c) comparing with said one or more processors said derived net balance change to the balance of funds in said Omnibus TA;
(d) determining which of said plurality of customers has an eligible Individual TA based on at least a number of prior transfers from each customer's Individual MMDA within said period of time; and
(e) allocating funds with said one or more processors from one or more of said eligible Individual TAs to their respective Individual MMDAs in order to offset a negative derived net balance change not greater than the amount of funds in said Omnibus TA and minimize the number of transfers from the Omnibus MMDA.
12. A method according to claim 11, wherein said Omnibus TA and said Omnibus MMDA are interest-bearing accounts.
13. A method according to claim 11, wherein said Individual TAs and said Individual MMDAs are interest-bearing accounts.
US13/245,538 2009-04-07 2011-09-26 Method, system and computer program product for managing funds in custodial deposit accounts Active US8392304B1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US13/245,538 US8392304B1 (en) 2009-04-07 2011-09-26 Method, system and computer program product for managing funds in custodial deposit accounts
US13/774,239 US8744942B1 (en) 2009-04-07 2013-02-22 Method, system and computer program product for managing funds in custodial deposit accounts

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12/419,691 US8234188B1 (en) 2009-04-07 2009-04-07 Method, system and computer program product for managing funds in custodial deposit accounts
US13/245,538 US8392304B1 (en) 2009-04-07 2011-09-26 Method, system and computer program product for managing funds in custodial deposit accounts

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US12/419,691 Continuation US8234188B1 (en) 2009-04-07 2009-04-07 Method, system and computer program product for managing funds in custodial deposit accounts

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/774,239 Division US8744942B1 (en) 2009-04-07 2013-02-22 Method, system and computer program product for managing funds in custodial deposit accounts

Publications (1)

Publication Number Publication Date
US8392304B1 true US8392304B1 (en) 2013-03-05

Family

ID=46547688

Family Applications (4)

Application Number Title Priority Date Filing Date
US12/419,691 Active 2030-11-04 US8234188B1 (en) 2009-04-07 2009-04-07 Method, system and computer program product for managing funds in custodial deposit accounts
US13/245,538 Active US8392304B1 (en) 2009-04-07 2011-09-26 Method, system and computer program product for managing funds in custodial deposit accounts
US13/560,544 Active US8712881B1 (en) 2009-04-07 2012-07-27 Method, system and computer program product for managing funds in custodial deposit accounts
US13/774,239 Active US8744942B1 (en) 2009-04-07 2013-02-22 Method, system and computer program product for managing funds in custodial deposit accounts

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US12/419,691 Active 2030-11-04 US8234188B1 (en) 2009-04-07 2009-04-07 Method, system and computer program product for managing funds in custodial deposit accounts

Family Applications After (2)

Application Number Title Priority Date Filing Date
US13/560,544 Active US8712881B1 (en) 2009-04-07 2012-07-27 Method, system and computer program product for managing funds in custodial deposit accounts
US13/774,239 Active US8744942B1 (en) 2009-04-07 2013-02-22 Method, system and computer program product for managing funds in custodial deposit accounts

Country Status (1)

Country Link
US (4) US8234188B1 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130007022A1 (en) * 2009-06-27 2013-01-03 Petruzzi Christopher R Auditing custodial accounts
US9374370B1 (en) 2015-01-23 2016-06-21 Island Intellectual Property, Llc Invariant biohash security system and method
US9430798B1 (en) 2009-05-26 2016-08-30 Island Intellectual Propery Llc Method and system for allocating deposits over a plurality of depository institutions
US10068294B1 (en) 2009-11-24 2018-09-04 Island Intellectual Property Llc Method and system for allocating funds over a plurality of time deposit instruments in depository institutions
US10157207B2 (en) 2015-11-17 2018-12-18 Bank Of America Corporation System for supplemental data reporting utilizing data record properties
US10482483B2 (en) 2015-11-17 2019-11-19 Bank Of America Corporation System for aggregating data record attributes for supplemental data reporting
US11610260B1 (en) 2020-01-28 2023-03-21 Island Intellectual Property Llc System, method and program product to transfer, allocate and track ownership interests in aggregated accounts

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8150766B1 (en) 2003-01-27 2012-04-03 Island Intellectual Property Llc System and method for investing public deposits
US8660920B2 (en) * 2005-08-16 2014-02-25 New Affinity Concepts Corp. Managed deposit program
US20100274718A1 (en) * 2009-04-27 2010-10-28 Bank Of America Corporation Financial institute-implemented account management system
US8595102B1 (en) * 2010-09-13 2013-11-26 New Affinity Concepts Corp. Insured deposit note program
US8655689B1 (en) * 2011-10-13 2014-02-18 Island Intellectual Property Llc System, method and program product for modeling fund movements
US10937097B1 (en) * 2012-02-06 2021-03-02 Acorns Grow Incorporated Systems and methods for creating excess funds from retail transactions and apportioning those funds into investments
US8781906B2 (en) 2012-02-06 2014-07-15 Walter Cruttenden Systems and methods for managing consumer transaction-based investments
USD927509S1 (en) 2013-03-14 2021-08-10 Acorns Grow Incorporated Mobile device screen or portion thereof with graphical user interface
USD969818S1 (en) 2013-03-14 2022-11-15 Acorns Grow Inc. Mobile device screen with graphical user interface
US11176614B1 (en) 2013-03-14 2021-11-16 Acorns Grow Incorporated Systems and methods for creating excess funds from retail transactions and apportioning those funds into investments
USD972577S1 (en) 2013-03-14 2022-12-13 Acorns Grow Inc. Mobile device screen with a graphical user interface
USD928190S1 (en) 2013-03-14 2021-08-17 Acorns Grow Incorporated Mobile device screen or portion thereof with an animated graphical user interface
US10074091B2 (en) 2014-10-10 2018-09-11 Paymation, Inc. Dynamic financial management system, method and device
US11100513B2 (en) 2014-10-10 2021-08-24 Paymation, Inc. Dynamic financial management system, method and device
USD792890S1 (en) 2015-05-22 2017-07-25 Acorns Grow Incorporated Display screen or portion therof with a financial data graphical user interface
US10636087B1 (en) * 2017-03-07 2020-04-28 Wells Fargo Bank, N.A. Customized graphical user interface for managing multiple user accounts
USD928799S1 (en) 2018-07-19 2021-08-24 Acorns Grow Incorporated Mobile device screen or portion thereof with graphical user interface
US11567655B2 (en) 2019-02-21 2023-01-31 Acorns Grow Incorporated Secure signature creation on a secondary device
USD927521S1 (en) 2019-12-09 2021-08-10 Acorns Grow Incorporated Mobile device screen or portion thereof with a graphical user interface

Citations (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4774663A (en) * 1980-07-29 1988-09-27 Merrill Lynch, Pierce, Fenner & Smith Incorporated Securities brokerage-cash management system with short term investment proceeds allotted among multiple accounts
US4985833A (en) * 1988-08-24 1991-01-15 First City, Texas- N. A. Extended coverage monetary regulation system
US5893078A (en) * 1997-03-26 1999-04-06 Carreker-Antinori, Inc. System and method for determining optimal sweep threshold parameters for demand deposit accounts
US6026381A (en) * 1996-11-05 2000-02-15 Itx Corporation Financial market classification system
US6374231B1 (en) 1998-10-21 2002-04-16 Bruce Bent Money fund banking system
US20020087454A1 (en) * 2000-12-30 2002-07-04 Bea Calo Global trading system
US20030135437A1 (en) * 2001-07-27 2003-07-17 Promontory Interfinancial Network, Llc Method and apparatus for fully insuring large bank deposits
US20050044038A1 (en) * 2003-08-21 2005-02-24 Finistar, Inc. Methods and systems for facilitating transactions between commercial banks and pooled depositor groups
US20050154662A1 (en) 2003-11-06 2005-07-14 Langenwalter James A. Asset allocation, rebalancing, and investment management system
US20060047593A1 (en) 2004-09-01 2006-03-02 Ubs Financial Services Inc. Method and system for funds management
US20060212378A1 (en) 2005-01-21 2006-09-21 Data Path Corporation Account administration plans and systems
US20060224480A1 (en) 2005-03-29 2006-10-05 Reserve Solutions, Inc. Systems and methods for loan management with variable security arrangements
US20070005493A1 (en) 2005-06-29 2007-01-04 Amy Kandravy Sponsor-manager reconciliation in handling of custodian transactions
US20070043666A1 (en) 2005-08-16 2007-02-22 Burdette William R Managed deposit program
US7302413B1 (en) 2002-03-06 2007-11-27 Reserve Management Corporation Systems and methods for providing loan management from cash or deferred income arrangements
US20070294158A1 (en) * 2005-01-07 2007-12-20 Chicago Mercantile Exchange Asymmetric and volatility margining for risk offset
US20080052215A1 (en) * 2006-05-31 2008-02-28 Tudisco Geoffrey M Online omnibus trading system
US7398245B1 (en) 2002-03-06 2008-07-08 Reserve Solutions, Inc. Systems and methods for providing loan management from cash or deferred income arrangements
US20080288398A1 (en) * 2007-05-16 2008-11-20 The Pnc Financial Services Group, Inc. Cash sweep account platform system and method
US20090048954A1 (en) * 2007-08-13 2009-02-19 Canopy Financial Sub-accounting for an omnibus account
US7509286B1 (en) 1998-10-21 2009-03-24 Reserve Management Corporation Systems and methods for money fund banking with flexible interest allocation
US7519551B2 (en) * 1998-10-21 2009-04-14 Island Intellectual Property Llc Systems and methods for administering return sweep accounts
US20090106161A1 (en) 2003-02-25 2009-04-23 Manuel Alemany Apparatus and method for data interchange
US7536350B1 (en) 1998-10-21 2009-05-19 Island Intellectual Property Llc Systems and methods for providing enhanced account management services for multiple banks
US7574403B2 (en) * 2000-03-20 2009-08-11 Roundit, Inc. Patronage incentive saving system and method for retail businesses
US7640199B1 (en) 2006-11-03 2009-12-29 Promontory Interfinancial Network, Llc Auditing and reconciling custodial accounts
US7668771B1 (en) 2007-02-28 2010-02-23 Island Intellectual Property Llc System and method for allocation to obtain zero activity in a selected aggregated account
US7668772B1 (en) * 1998-10-21 2010-02-23 Island Intellectual Property Llc Systems and methods for money fund banking with flexible interest allocation
US7672886B2 (en) 1998-10-21 2010-03-02 Island Intellectual Property Llc Systems and methods for managing client accounts
US7680734B1 (en) 1998-10-21 2010-03-16 Island Intellectual Property Llc Money fund banking system
US7835976B2 (en) * 2005-03-03 2010-11-16 Mbox Llc Financial management system and related methods
US8032456B1 (en) 2008-02-11 2011-10-04 Island Intellectual Property Llc System, methods and program products for processing for a self clearing broker dealer

Patent Citations (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4774663A (en) * 1980-07-29 1988-09-27 Merrill Lynch, Pierce, Fenner & Smith Incorporated Securities brokerage-cash management system with short term investment proceeds allotted among multiple accounts
US4985833A (en) * 1988-08-24 1991-01-15 First City, Texas- N. A. Extended coverage monetary regulation system
US6026381A (en) * 1996-11-05 2000-02-15 Itx Corporation Financial market classification system
US5893078A (en) * 1997-03-26 1999-04-06 Carreker-Antinori, Inc. System and method for determining optimal sweep threshold parameters for demand deposit accounts
US7536350B1 (en) 1998-10-21 2009-05-19 Island Intellectual Property Llc Systems and methods for providing enhanced account management services for multiple banks
US7809640B1 (en) 1998-10-21 2010-10-05 Island Intellectual Property Llc Money fund banking system
US7716131B2 (en) 1998-10-21 2010-05-11 Island Intellectual Property Llc Money fund banking system with multiple banks and/or rates
US7672886B2 (en) 1998-10-21 2010-03-02 Island Intellectual Property Llc Systems and methods for managing client accounts
US7752129B2 (en) * 1998-10-21 2010-07-06 Island Intellectual Property Llc Systems and methods for managing client accounts
US7668772B1 (en) * 1998-10-21 2010-02-23 Island Intellectual Property Llc Systems and methods for money fund banking with flexible interest allocation
US7769688B1 (en) * 1998-10-21 2010-08-03 Island Intellectual Property Llc Money fund banking system
US7509286B1 (en) 1998-10-21 2009-03-24 Reserve Management Corporation Systems and methods for money fund banking with flexible interest allocation
US6374231B1 (en) 1998-10-21 2002-04-16 Bruce Bent Money fund banking system
USRE43246E1 (en) 1998-10-21 2012-03-13 Island Intellectual Property Llc Money fund bank system
US7680734B1 (en) 1998-10-21 2010-03-16 Island Intellectual Property Llc Money fund banking system
US7933821B1 (en) 1998-10-21 2011-04-26 Island Intellectual Property Llc Systems and methods for administering return sweep accounts
US7519551B2 (en) * 1998-10-21 2009-04-14 Island Intellectual Property Llc Systems and methods for administering return sweep accounts
US8019667B1 (en) 1998-10-21 2011-09-13 Island Intellectual Property Llc Systems and methods for money fund banking with flexible interest allocation
US7574403B2 (en) * 2000-03-20 2009-08-11 Roundit, Inc. Patronage incentive saving system and method for retail businesses
US20020087454A1 (en) * 2000-12-30 2002-07-04 Bea Calo Global trading system
US7376606B2 (en) 2001-07-27 2008-05-20 Promontory Interfinancial Network, Llc Method and apparatus for fully insuring large bank deposits
US20030135437A1 (en) * 2001-07-27 2003-07-17 Promontory Interfinancial Network, Llc Method and apparatus for fully insuring large bank deposits
US7440914B2 (en) 2001-07-27 2008-10-21 Promontory Interfinancial Networks, Llc Method and apparatus for fully insuring large bank deposits
US7596522B1 (en) 2001-07-27 2009-09-29 Promontory Interfinancial Network, Llc Computer program product for fully insuring large bank deposits
US7603307B2 (en) 2001-07-27 2009-10-13 Promontory Interfinancial Network, Llc Computer-implemented method for fully insuring large bank deposits
US7398245B1 (en) 2002-03-06 2008-07-08 Reserve Solutions, Inc. Systems and methods for providing loan management from cash or deferred income arrangements
US7302413B1 (en) 2002-03-06 2007-11-27 Reserve Management Corporation Systems and methods for providing loan management from cash or deferred income arrangements
US20090106161A1 (en) 2003-02-25 2009-04-23 Manuel Alemany Apparatus and method for data interchange
US20070276752A1 (en) * 2003-08-21 2007-11-29 Whiting Richard W Methods and Systems for Facilitating Transactions Between Commercial Banks and Pooled Depositor Groups
US20050044038A1 (en) * 2003-08-21 2005-02-24 Finistar, Inc. Methods and systems for facilitating transactions between commercial banks and pooled depositor groups
US20050154662A1 (en) 2003-11-06 2005-07-14 Langenwalter James A. Asset allocation, rebalancing, and investment management system
US20060047593A1 (en) 2004-09-01 2006-03-02 Ubs Financial Services Inc. Method and system for funds management
US20070294158A1 (en) * 2005-01-07 2007-12-20 Chicago Mercantile Exchange Asymmetric and volatility margining for risk offset
US20060212378A1 (en) 2005-01-21 2006-09-21 Data Path Corporation Account administration plans and systems
US7835976B2 (en) * 2005-03-03 2010-11-16 Mbox Llc Financial management system and related methods
US20060224480A1 (en) 2005-03-29 2006-10-05 Reserve Solutions, Inc. Systems and methods for loan management with variable security arrangements
US20070005493A1 (en) 2005-06-29 2007-01-04 Amy Kandravy Sponsor-manager reconciliation in handling of custodian transactions
US20070043666A1 (en) 2005-08-16 2007-02-22 Burdette William R Managed deposit program
US20080052215A1 (en) * 2006-05-31 2008-02-28 Tudisco Geoffrey M Online omnibus trading system
US7640199B1 (en) 2006-11-03 2009-12-29 Promontory Interfinancial Network, Llc Auditing and reconciling custodial accounts
US8019668B1 (en) 2007-02-28 2011-09-13 Island Intellectual Property Llc System and method for allocation to obtain zero activity in a selected aggregated account with holdback
US7668771B1 (en) 2007-02-28 2010-02-23 Island Intellectual Property Llc System and method for allocation to obtain zero activity in a selected aggregated account
US7672902B1 (en) 2007-02-28 2010-03-02 Island Intellectual Property Llc System and method for pre-funding interest for early termination of client account having funds in one or more aggregated accounts
US7996308B1 (en) 2007-02-28 2011-08-09 Island Intellectual Property Llc System and method for managing aggregated accounts
US7680716B1 (en) 2007-02-28 2010-03-16 Island Intellectual Property Llc System and method for allocating excess funds in aggregated control account
US7752107B1 (en) * 2007-02-28 2010-07-06 Island Intellectual Property Llc System and method for managing aggregated accounts
US7672901B1 (en) * 2007-02-28 2010-03-02 Island Intellectual Property Llc System and method for holdback procedure for after-hours transactions
US20080288398A1 (en) * 2007-05-16 2008-11-20 The Pnc Financial Services Group, Inc. Cash sweep account platform system and method
US20090048954A1 (en) * 2007-08-13 2009-02-19 Canopy Financial Sub-accounting for an omnibus account
US8032456B1 (en) 2008-02-11 2011-10-04 Island Intellectual Property Llc System, methods and program products for processing for a self clearing broker dealer

Non-Patent Citations (12)

* Cited by examiner, † Cited by third party
Title
"First Horizon Bank Health Savings Account Sweep Agreement and Investment Instruction," http://www.firsthorizonmsaver.com/files/mutual-fund-app.pdf; accessed Sep. 17, 2010 (6 pages).
"First Horizon Bank Health Savings Account Sweep Agreement and Investment Instruction," http://www.firsthorizonmsaver.com/files/mutual—fund—app.pdf; accessed Sep. 17, 2010 (6 pages).
Blasio et al. v. Merrill Lynch & Co., No. 07-cv-318 (RJS), electronic case filing (Feb. 5, 2008). *
Bradly, C.M. & Shibut, L. (2006). The liability structure of FDIC-insured institutions. FDIC Banking Review 18(2). *
FDIC Law, Regulations, Related Acts. Part 204-Reserve Requirements of Depository Institutions (Regulation D). *
FDIC Law, Regulations, Related Acts. Part 204—Reserve Requirements of Depository Institutions (Regulation D). *
Finistar documents (no. date). *
King, Amanda Swift, "Untangling the effects of credit cards on money demand: convenience usage vs. borrowing," Quart. J. Bus. Econ. 43 (1/2):57-80, University of Nebraska-Lincoln, United States (2004) (33 pages).
Lloyds TSB Group PLC, Regulatory News Service, Feb. 11, 2000. WRNS, Part 2, pp. 7-42, 8 pages.
Martin, Stephanie (Apr. 22, 2004). Memo from Legal Division of Board of Governors of the Fed. Reserve System, Wash. DC. *
Nair, S. K. et al., "A Specialized Inventory Problem in Banks: Optimizing Retail Sweeps," Prod. Oper. Manag. 17 (3): 285-295, Wiley-Blackwell, United States (2008) (16 pages).
O'Brien, Christine D., et al., "International liquidity management: Solutions for the 21st century," TMA Journal 15(2):28-35 (1995) (7 pages).

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9946997B1 (en) 2009-05-26 2018-04-17 Island Intellectual Property Llc Method and system for allocating deposits over a plurality of depository institutions
US11367138B1 (en) 2009-05-26 2022-06-21 Island Intellectual Property Llc Method and system for allocating deposits over a plurality of depository institutions
US9430798B1 (en) 2009-05-26 2016-08-30 Island Intellectual Propery Llc Method and system for allocating deposits over a plurality of depository institutions
US10552910B1 (en) 2009-05-26 2020-02-04 Island Intellectual Property Llc Method and system for allocating deposits over a plurality of depository institutions
US9607335B1 (en) 2009-05-26 2017-03-28 Island Intellectual Property, Llc Method and system for allocating deposits over a plurality of depository institutions
US9811811B1 (en) 2009-05-26 2017-11-07 Island Intellectual Property Llc Method and system for allocating deposits over a plurality of depository institutions
US9305315B2 (en) * 2009-06-27 2016-04-05 Christopher R. Petruzzi Auditing custodial accounts
US20130007022A1 (en) * 2009-06-27 2013-01-03 Petruzzi Christopher R Auditing custodial accounts
US10068294B1 (en) 2009-11-24 2018-09-04 Island Intellectual Property Llc Method and system for allocating funds over a plurality of time deposit instruments in depository institutions
US9569773B1 (en) 2015-01-23 2017-02-14 Island Intellectual Property, Llc Invariant biohash security system and method
US9904914B1 (en) 2015-01-23 2018-02-27 Island Intellectual Property, Llc Notification system and method
US9965750B1 (en) 2015-01-23 2018-05-08 Island Intellectual Property, Llc Notification system and method
US9805344B1 (en) 2015-01-23 2017-10-31 Island Intellectual Property, Llc Notification system and method
US10134035B1 (en) 2015-01-23 2018-11-20 Island Intellectual Property, Llc Invariant biohash security system and method
US9483762B1 (en) 2015-01-23 2016-11-01 Island Intellectual Property, Llc Invariant biohash security system and method
US10623182B1 (en) 2015-01-23 2020-04-14 Island Intellectual Property, Llc Invariant biohash security system and method
US10832317B1 (en) 2015-01-23 2020-11-10 Island Intellectual Property, Llc Systems, methods, and program products for performing deposit sweep transactions
US9374370B1 (en) 2015-01-23 2016-06-21 Island Intellectual Property, Llc Invariant biohash security system and method
US10157207B2 (en) 2015-11-17 2018-12-18 Bank Of America Corporation System for supplemental data reporting utilizing data record properties
US10482483B2 (en) 2015-11-17 2019-11-19 Bank Of America Corporation System for aggregating data record attributes for supplemental data reporting
US11610260B1 (en) 2020-01-28 2023-03-21 Island Intellectual Property Llc System, method and program product to transfer, allocate and track ownership interests in aggregated accounts

Also Published As

Publication number Publication date
US8744942B1 (en) 2014-06-03
US8234188B1 (en) 2012-07-31
US8712881B1 (en) 2014-04-29

Similar Documents

Publication Publication Date Title
US8392304B1 (en) Method, system and computer program product for managing funds in custodial deposit accounts
US8355985B1 (en) Systems and methods for providing enhanced account management services for multiple banks
Basu et al. The value of risk: measuring the service output of US commercial banks
US8355984B1 (en) Computerized extension of credit to existing demand deposit accounts, prepaid cards and lines of credit based on expected tax refund proceeds, associated systems and computer program products
US5907828A (en) System and method for implementing and administering lender-owned credit life insurance policies
US8738451B2 (en) System, program product, and method for debit card and checking account autodraw
US7792742B1 (en) Risk-based reference pool capital reducing systems and methods
US8260698B2 (en) System and method for processing data related to an annuity using an index-based amount to credit to a contract value
US20050256794A1 (en) Benefit financing arrangement
US8429068B1 (en) Data aggregation for transaction banking partnerships
US8175962B2 (en) Computerized extension of credit to existing demand deposit accounts, prepaid cards and lines of credit based on expected tax refund proceeds, associated systems and computer program products
US20070007335A1 (en) Healthcare Card Closed Loop Network System
US20110119140A1 (en) System, Program Product, and Method for Debit Card and Checking Account Autodraw
US9153076B1 (en) Method for structuring a mortgage servicing right asset efficiently to include a hedging component
US8380546B2 (en) Managing an insurance plan
US20130030971A1 (en) Systems and methods for allocating funds between multiple banking products
US20100030686A1 (en) Retirement paycheck apparatus and methods
US20200051108A1 (en) Paying a reward to a second account based on multiple account qualifications being met by a first account
US20140278580A1 (en) Systems and methods for account processing
US20080046365A1 (en) System and method for providing compensation to loan professionals
US10387851B1 (en) Paying a reward to a second account based on qualifications being met by a first account
US20090276248A1 (en) Apparatus, system, and method for funding insurance premium financing contracts
US20210224764A1 (en) Paying alternate interest rates on interest bearing accounts
Ended Bank of America Reports Fourth-quarter 2014 Net Income of $3.1 Billion, or $0.25 per Diluted Share
Ritzau NC-BANK-OF-AMERICA

Legal Events

Date Code Title Description
STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: MORGAN STANLEY SENIOR FUNDING, INC., AS COLLATERAL

Free format text: PATENT SECURITY AGREEMENT (FIRST LIEN);ASSIGNOR:PROMONTORY INTERFINANCIAL NETWORK, LLC;REEL/FRAME:050978/0104

Effective date: 20191108

AS Assignment

Owner name: MORGAN STANLEY SENIOR FUNDING, INC., AS COLLATERAL

Free format text: PATENT SECURITY AGREEMENT (SECOND LIEN);ASSIGNOR:PROMONTORY INTERFINANCIAL NETWORK, LLC;REEL/FRAME:050988/0969

Effective date: 20191108

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8

AS Assignment

Owner name: PROMONTORY INTERFINANCIAL GROUP, LLC, VIRGINIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:PHILLIPS, DOUGLAS E.;HYLAND, ROBERT N.;CARLINO, ANTHONY R.;REEL/FRAME:054886/0209

Effective date: 20090604

Owner name: INTRAFI NETWORK LLC, VIRGINIA

Free format text: CHANGE OF NAME;ASSIGNOR:PROMONTORY INTERFINANCIAL GROUP, LLC;REEL/FRAME:054961/0887

Effective date: 20201019

AS Assignment

Owner name: INTRAFI NETWORK, LLC (F/K/A PROMONTORY INTERFINANCIAL NETWORK, LLC), VIRGINIA

Free format text: RELEASE (REEL 050988 / FRAME 0969);ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:055264/0335

Effective date: 20210209

AS Assignment

Owner name: NOMURA CORPORATE FUNDING AMERICAS, LLC, AS COLLATERAL AGENT, NEW YORK

Free format text: SECURITY AGREEMENT (2ND LIEN);ASSIGNOR:INTRAFI NETWORK, LLC;REEL/FRAME:058045/0689

Effective date: 20211105

AS Assignment

Owner name: INTRAFI LLC, VIRGINIA

Free format text: CHANGE OF NAME;ASSIGNOR:INTRAFI NETWORK LLC;REEL/FRAME:065548/0104

Effective date: 20231102