Patent Application
20200357069
The present invention relates to a financial planning system that automatically selects products and financing in accordance with goals in a financial plan of an individual, and automatically commits to purchases and loans on behalf of the individual.
A financial planner advises his or her client as to how to invest to achieve their financial goals. Computer-based systems exist that automate the calculations and projections typically made by a financial planner.
A solo financial planner may execute software on their personal computer 50, and may use Internet 10 to access client accounts at banks 20 or brokerages 30. The financial planner may use information service 40 to obtain, e.g., quotes for current market valuation of client investments.
Alternatively, a solo financial planner having personal computer 50, with locally stored client information 55, can use a CFP system operative at financial planning server 60. Instead of a personal computer, the financial planner can use a tablet computer or a smartphone. Typically, personal computer 50 uses a public network, such as Internet 10, to communicate with server 60. In one configuration, referred to as software-as-a-service (SaaS), personal computer 50 has an operating system and browser, but lacks special software. In another configuration, referred to as a client-server configuration, personal computer 50 must first download special client software, and must execute this client software to gain access to the program at financial planning server 60.
An employee financial planner typically uses personal computer 70 on the premises of their employer, which operates financial planning server 60. Local area network (LAN) 62 provides the physical connection from personal computer 70 to financial planning server 60. The client information is stored in storage device 75 that is connected to LAN 62. Financial planning server 60 may use the Internet to access client accounts at banks or brokerages.
Alternatively, an employee financial planner can use financial planning server 60 in a SaaS or client-server configuration.
CFP software can be characterized as goal-based (CFP-GB), cash-flow-based (CFP-CF), or hybrid (CFP-HY).
In a goal-based system, the CFP-GB system explicitly allocates certain funds towards achieving a particular goal and then projects whether the goal can be achieved under simulations. Goals are funded separately, and the likelihood of their achievement is evaluated based on a Monte Carlo analysis of investments dedicated towards each goal. In a purely goal based system, there is no accounting of incomes and expenses, but instead there is an assumption about a level of necessary savings needed to achieve the set goals. The household's actual cash flows remain to be determined by the advisor in a separate exercise to see if the savings can be achieved.
The outcome of the CFP-GB system is a goal-based financial plan (FP-GB), which outlines how much ongoing savings in total are required in order to achieve the customer's goals and how these savings should be apportioned across the goals, and what allocation of investment products is recommended for investing these savings towards the goals.
During system set-up (not shown), the financial planning system is configured with tax tables, so that a client's estimated taxes can be automatically computed, and with expected life tables, so that years of retirement can be estimated.
At step 105, the user, either a financial planner acting on behalf of his/her client, or the client him/herself, opens an account for the client, and populates it with the client's age. The system then looks up the client's expected life, subtracts the user's age, and determines the timeframe T for the financial plan, in months, from the present month until the client's expected end of life. The user provides an initial savings balance (ISB) for the client, an expected monthly savings amount for each month, and a set of goal amounts G$[g], g=1 . . . G, and corresponding goal end dates GT[g].
At step 110, the user identifies the client's accounts with third-party systems, such as banks or brokerages, and provides access (read) and/or alteration permission. Most brokerages are set-up to enable a financial advisor to trade a client's account, but not withdraw funds therefrom.
At step 115, the financial planning system populates the client's account with information from the client's third-party accounts.
At step 120, the financial planning system gets initial values for the market environment for the client's account. Typically, this includes current prices for the financial instruments that the users holds, and might wish to hold, and price history for these financial instruments, to derive volatility per instrument. The market environment may also include future forecasts for returns and risk, if the planning system relies on such forecasts.
At step 150, the financial planner identifies the investments INV v=1 . . . V that will be used in the financial plan, and their risk parameters. For example, the investments that will be considered may be INV={bond1, bond2, bond3, equity1, equity2, equity3}, where each investment is a mutual fund or exchange-traded fund. Assume that bond1 and equity1 have low risk, bond2 and equity2 have medium risk, and bond3 and equity3 have high risk.
At step 155, the financial planning system pre-computes a set of Monte Carlo simulations, to create a Scenario Investment Return array SIR[n,t,v] based on the number of scenarios n=1 . . . N, where N is typically chosen as a large number such as 1,000, but any number may be used so long as it is large enough that the statistical distribution across scenarios is realistic, such as N being at least around 100; the time periods t=1 . . . T, where T was computed at step 105 of
The Monte Carlo simulations use random numbers to simulate the behavior of markets. For instance, a low risk investment may be defined to have a monthly return in the range −10% to +10%, a medium risk investment may be defined to have a monthly return in the range −20% to +20%, a high risk investment may be defined to have a monthly return in the range −30% to +30%. The probability distribution for each investment may be defined as Gaussian (bell-shaped), centered at 2% for low risk investments, 6% for medium risk investments, and 12% for high risk investments. For each time period, a pseudo-random number in the range 0 to 1 is generated, with the distribution being equiprobable. Then, the generated number is mapped into a range using the probability distribution appropriate for the type of investment. Other techniques may be used to generate the Scenario Investment Return array SIR[n,t,v], such as a Monte Carlo simulation.
At step 160, the financial planner creates the Goal Accounts, one per goal.
At step 165, the financial planner sets the starting conditions, also referred to as a Trial Financial Plan, by allocating the ISB among the Goal Accounts, setting weights ws[g] for allocating monthly savings S (from step 105 of
At step 170, the financial planning system creates the N scenarios based on the Trial Financial Plan and the Scenario Investment Return SIR[n,t,v] from the Monte Carlo simulation. For each scenario, for each time period, for each goal account, the financial planning system system computes the Goal Account Return GAR[n,t,g]:
GAR[n,t,g]=k=1KSIR[n,t,k]*wI[g,k] (equation 1)
and computes the Goal Account balance GA[n,t,g]:
GA[n,t,h]=(1+GAR[n,t,g])*GA[n,t−1,g]+S[t,g] (equation 2)
The financial planning system rebalances the goal account investments to conform to the weighted allocation in the Trial Financial Plan. If the goal's time limit GT[g] has been reached, the financial planning system closes the goal account for the goal, stores the final value of the Goal Account GAFV[n,g]=GA[n,t=GT[g],g], and allocates the savings that would have been used for the goal to other goals by a suitable method such as proportional reallocation or weighted reallocation. In proportional reallocation, each adjusted savings weight ws_adj[g] is increased by the same amount. Assume goal1 (g=1) has been reached, then for g=2 . . . G
ws_adj[g]=ws[g]+ws[1]/(g−1) (equation 3)
In weighted reallocation, each adjusted savings weight ws_adj[g], g=2 . . . G, is increased so that its share of savings remains constant:
ws_adj[g]=ws[g]+ws[g]/Σg=2G ws[g] (equation 4)
At step 175, the financial planning system determines the goals success likelihood across all scenarios based on the stored GAFV[n,g]. A goal has succeeded when the scenario-wide GAFV[n,g] is at least equal to the goal amount G$[g] specified at step 105 of
Goals_success_likelihood=N−1*Σn=1N1(GAFV[n,g]≥G$[g]) (equation 5)
At step 180, the financial planning system decides whether the Trial Financial Plan is acceptable, that is, whether equation 5 is true for all goals g=1 . . . G. If so, processing continues at step 185. If not, processing returns to step 165, and the financial planner adjusts the Trial Financial Plan.
At step 185, the financial planning system defines the recommended financial plan as the first Trial Financial Plan that was deemed acceptable at step 180.
At step 190, if the customer has given permission, the financial planning system automatically moves funds among accounts, and/or places trades. Fund movement occurs when the ISB is allocated among accounts, when the monthly savings is allocated among accounts, and when accounts are rebalanced to conform to the financial plan.
In a cash-flow-based system, the CFP-CF system is acting more like an accounting system that projects into the future. It computes the planned incomes, expenses, accounts for taxes and other withholdings, and projects a simulated investment portfolio income. The goals in CFP-CF system are also represented as specific cash flow outlays planned for specific times in the future, such as a plan to purchase a second home 5 years from now or a plan to pay for kids' college expenses when they reach 18 years old. The system projects the cash flows and alerts the advisor if there is a deficit or surplus in cash flows under the advisor's financial plan assumptions.
The outcome of the CFP-CF system is a cash-flow-based financial plan (FP-CF), which outlines the parameters of the goals that are achievable given the customer's income and expenses assumptions, as well as the allocation of net savings across investment accounts and across investment products within accounts, recommended in order to achieve the selected goals.
Step 205 is similar to step 105 of
Steps 210, 215 and 220 are similar to steps 110, 115 and 120 of
Steps 250 and 255 are similar to steps 150 and 155 of
At step 260, the financial planner selects k=1 K investments for the client's single account, and sets weights w[k] for the investments in the single portfolio account. All goals are funded from this single account. The selected investments k=1 K, and the weights w[k] comprise the Trial Financial Plan.
At step 270, the financial planner set the initial account balance B[t=0] to be the ISB.
At step 275, the financial planning system creates the N scenarios based on the Trial Financial Plan and the Scenario Investment Return SIR[n,t,v] from the Monte Carlo simulation. For each scenario, for each time period, for the single portfolio account, the financial planning system system computes the Net Savings NS[t], where GCF[t,g] represents the goal cash flow spending for goal g at time t:
NS[t]=INC[t]−EXP[t]−TAXES[t]−Σg=1GGCF[t,g] (equation 6)
then computes the scenario's Portfolio Return PR[n,t]:
PR[n,t]=Σk=1KSIR[n,t,k]*wI[k] (equation 7)
then computes the account balance B[n,t]
B[n,t]=(1+PR[n,t])*B[n,t−1]+NS[t] (equation 8)
The financial planning system rebalances the goal account investments to conform to the weighted allocation in the Trial Financial Plan, as at step 170 of
At step 280, the financial planning system determines the goals success likelihood across all scenarios based on the stored B[n,T]. If B[n,T] is positive, then the scenario is a success.
Goals_success_likelihood=N−1*Σn=1N(B[n,T]>0) (equation 9)
At step 285, the financial planning system decides whether the Trial Financial Plan is acceptable, that is, whether the Success metric is greater than 0. If so, processing continues at step 290. If not, processing returns to step 260, and the financial planner adjusts the Trial Financial Plan.
At step 290, the financial planning system defines the recommended financial plan as the first Trial Financial Plan that was deemed acceptable at step 285.
At step 295, if the customer has given permission, the financial planning system automatically moves funds among accounts, and/or places trades. Fund movement occurs when the ISB is allocated among accounts, when the monthly savings is allocated among accounts, and when accounts are rebalanced to conform to the financial plan.
In a hybrid system, the CFP-HY system is based on goals, like in case of CFP-GB system, however instead of relying on assumption about the level of net savings, it uses a more detailed accounting for cash flows, like in case of CFP-CF system. In a CFP-HY system, all goals are funded together, from the overall net cash flows.
The outcome of the CFP-HY system is a hybrid financial plan (FP-HY), which outlines the recommended levels of net savings (i.e. recommended level of expenses given the customer's income assumptions) together with the parameters of the goals that are achievable given such level of savings, as well as the allocation of net savings across investment accounts and across investment products within accounts, recommended in order to achieve the selected goals.
Steps 350, 355, 360, 365 are similar to steps 150, 155, 160, 165 of
Step 370 is similar to step 170 of
S[t,g]=ws[g]*NS[t] (equation 10)
Steps 375, 380, 385, 380 are similar to steps 175, 180, 185, 190 of
There is room for improvement in financial planning systems.
In accordance with an aspect of this invention, there is provided a method of creating a best financial plan for a user, the financial plan showing how at least one goal is affordable based on the user's income, expenses and investment performance, the financial plan having automatically selected financing for the at least one goal. In a user database, there are stored the at least one goal defined by the user, at least one financing template chosen by the user, acceptability criteria and optimality criteria. In a financing database, there are stored financing offers from financing providers, each financing offer having financing terms.
For each goal, a set of goal-financing scenarios is created, based on the goal, the user financing templates, and the financing offers. A draft financial plan is generated for each goal-financing scenario. Draft financial plans are eliminated according to the acceptability criteria to generate a set of acceptable financial plans. The best financial plan is selected according to the optimality criteria from the acceptable financial plans, and stored in the user database.
In accordance with another aspect of this invention, there is provided a method of creating a best financial strategy for a user, the financial strategy showing how at least one goal is affordable based on the user's income, expenses and investment performance, the financial strategy having automatically selected financing for at least one goal. In a user database, there are stored the at least one goal defined by the user, at least one financing template chosen by the user, periodic criteria and scenario-best criteria. In a financing database, there are stored financing offers from financing providers, each financing offer having financing terms.
For each goal, a set of goal-financing scenarios is created based on the goal, the user financing templates, and the financing offers. For each goal-financing scenario, the effect of financing on user wealth is estimated. Goal-financing scenarios are eliminated by comparing user wealth with the periodic criteria. The best goal-financing scenario is selected according to the scenario-best criteria. The best financial strategy is generated in accordance with the best goal-financing scenario, and stored in the user database.
In accordance with a further aspect of this invention, there is provided a method of creating a best financial plan for a user, the financial plan showing how at least one goal is affordable based on the user's income, expenses and investment performance, the financial plan having an automatically selected product for the at least one goal. In a user database, there are stored the at least one goal defined by the user, a set of chosen product characteristics associated with the goal and chosen by the user, acceptability criteria and optimality criteria. In a products database, there are stored product offers from product providers, each product offer having offered product characteristics.
A set of products is automatically selected from the products database, the offered product characteristics of each selected product satisfying the chosen product characteristics. A draft financial plan is generated for each selected product as the goal. Draft financial plans are eliminated according to the acceptability criteria to generate a set of acceptable financial plans. The best financial plan is selected according to the optimality criteria from the acceptable financial plans, and stored in the user database.
In accordance with a still further aspect of this invention, there is provided a method of creating a best financial strategy for a user, the financial strategy showing how at least one goal is affordable based on the user's income, expenses and investment performance, the financial strategy having an automatically selected product for at least one goal. In a user database, there are stored the at least one goal defined by the user, a set of chosen product characteristics associated with the goal and chosen by the user, periodic criteria and scenario-best criteria. In a products database, there are stored product offers from product providers, each product offer having offered product characteristics.
A set of products is automatically selected from the products database, the offered product characteristics of each selected product satisfying the chosen product characteristics. For each selected product, the effect of purchasing the product on user wealth is estimated. Products are eliminated by comparing user wealth with the periodic criteria. A best product is selected according to the scenario-best criteria. The best financial strategy is generated in accordance with the best product, and stored in the user database.
It is not intended that the invention be summarized here in its entirety. Rather, further features, aspects and advantages of the invention are set forth in or are apparent from the following description and drawings.
A specific goals/financing financial planning system, also referred to as a consumption planning system, enables connection between an individual's financial plan, and real world product and financing offers that are resources for helping the individual achieve his or her goals.
Only the very richest tier of population has enough wealth and income to be able to manage their financial lives and reach their life goals purely based on the results obtained from investments. For the vast majority of people both in the United States and elsewhere in the world, the bigger portion of their financial lives are centered on ongoing consumption of products and services.
Thus, a financial planning system adapted for planning and managing consumption is needed for the rest of the population, so they can understand the implications of their decisions over their lifetimes. A consumption-oriented financial planning system opens the door to aggregating consumption of individuals into a group, obtaining benefits from product and service providers based on the group, and feeding such benefits back to the individuals.
An important aspect of an optimal financial plan is timing. First, it is necessary to model the full cost of consumption, including upfront and periodic costs as well as savings. Second, it is helpful to have consumption priorities so that resources can be optimally allocated. Third, it is helpful to know flexibility in usage and cost.
Optimal wealth management creates more money for consumption. Wealth management comprises properly allocating savings between cash and investments of differing types and differing taxability, and managing risk exposure across different investments.
Optimal consumption management depends on spending limited resources on the things that matter, which is modelled by assigning priorities to goals.
A critical part of a consumption managing system is the ability to choose the best financing for a user. Accordingly, financial planning systems automating the choice of financing will now be discussed.
As shown in Table 1.5, this application presents six configurations of financial planning systems (FPSs), three based on a conventional FPS, and three based on a benchmark FPS. The three configurations are: (a) baseline (without automatically selected products and financing), (b) modified for automatically selected financing, and (c) modified for automatically selected products and financing.
Use cases are presented at the end of this specification.
In other configurations (not shown), an FPS automatically selects products but lacks capability to automatically select financing.′
As used herein, “
The first column of Table 1.5 shows figures relevant to a conventional cash-flow based FPS.
A financial plan (FP) is created by a conventional financial planning system (CFPS), see
A FP is a comprehensive statement of an individual's goals, particularly long-term in goals, and a detailed savings and investing election for achieving those goals. The FP is highly individualized to reflect the individual's personal and family situation, risk tolerance, and future expectations.
The outcome of a FP is a specification of how the individual's savings should be invested to achieve the individual's goals. Goal actions occur when specified by the user, as part of the goals. The conventional FP should be recomputed (updated) to reflect changes in the individual's situation and changes in the investment market.
The second column shows figures relevant to a modified conventional FPS with automatically selected financing. The changes include a system setup flowchart (
The embodiment of
A utility system receives and stores financing offers from financing providers, and makes these offers available to the MCFPS.
Each MCFPS stores user-defined criteria for what makes a FP acceptable to the user, and user-selected financing templates. A conventional FPS does not use acceptability criteria because the user is constantly manually generating new FPs, and deciding when a FP is acceptable.
Based on the providers' financing offers and the user's financing templates, the MCFPS generates financing scenarios, and creates a FP for each financing scenario (“iteration plan”). The MCFPS chooses the iteration plan that best meets the user's acceptability criteria as the user's FP.
On behalf of the user, if authorized by the user, the MCFPS commits to the financing in the FP.
The MCFPS sends an anonymized and compacted (“reduced”) version of the FP to the utility system. As shown in the third use case at the end of this specification, a reduced FP is a subset of a user's FP. Periodically, the utility system reviews the reduced FPs, creates loan demand curves for different financing types, and sends the loan demand curves to the financing providers, to encourage them to provide financing offers suited to the goals of the FP users. The third column shows figures relevant to a modified conventional FPS with automatically selected products and financing. The changes include selecting product characteristics during user setup (
The embodiment of
A utility system receives and stores product offers from product suppliers, and makes these offers available to the MCFPS.
Each MCFPS stores user-defined criteria for what makes a FP acceptable to the user, and user-selected product characteristics.
Based on the suppliers' product offers and the user's product characteristics, the MCFPS generates product scenarios, and creates a FP for each product scenario (“iteration plan”). The MCFPS chooses the iteration plan that best meets the user's acceptability criteria as the user's FP.
On behalf of the user, the MCFPS commits to purchase the product in the FP. The MCFPS sends an anonymized and compacted (“reduced”) version of the FP to the utility system. Periodically, the utility system reviews the reduced FPs, creates product demand curves for different product types, and sends the product demand curves to the product suppliers, to encourage them to provide product offers suited to the goals of the FP users.
The fourth column shows figures relevant to a benchmark FPS.
A financial strategy (FS) is created by a benchmark financial planning system (BFPS), see
The FS can be thought of as a self-updating FP plus periodic advice, where the self-updates occur due to market changes and user actions: updating information or adding new information, see
At explained at
The outcome of a FS is, for each time interval, investment actions and goal actions to take, based on the individual's savings and goals, the individual's previously enacted (or simulated, if in the context of future simulations) investments and goal actions, and changes in the market environment in the previous time interval (see
The FS detects when it needs to be updated to reflect changes in the individual's situation and changes in the investment market, and automatically updates itself (see
The fifth column shows figures relevant to a benchmark FPS with automatically selected financing. The changes include automatic selection of financing (
The embodiment of
A utility program receives and stores financing offers from financing providers, and makes these offers available to the MBFPS.
Each MBFPS stores user-selected financing templates. The MBFPS generates a benchmark curve to indicate when an action advised by a FS is acceptably meeting the user's goals.
Based on the providers' financing offers and the user's financing templates, the MBFPS generates financing scenarios, and estimates the user's wealth for each financing scenario. The MBFPS chooses the financing scenario that meets the benchmark curve and maximizes the user's wealth.
On behalf of the user, the MBFPS commits to the financing in the FP.
The MBFPS sends an anonymized and compacted (“reduced”) version of the FS to the utility program. Periodically, the utility program reviews the reduced FSs, creates loan demand curves for different financing types, and sends the loan demand curves to the financing providers, to encourage them to provide financing offers suited to the goals of the FS users.
The sixth column shows figures relevant to a benchmark FPS with automatically selected products and financing. The changes include selecting product characteristics during user setup (
The embodiment of
A utility program receives and stores product offers from product suppliers, and makes these offers available to the MBFPS.
Each MBFPS stores user-selected product characteristics. The MBFPS generates a benchmark curve to indicate when an action advised by a FS is acceptably meeting the user's goals.
Based on the suppliers' product offers and the user's product characteristics, the MBFPS generates product scenarios, and estimates the user's wealth for each product scenario. The MBFPS chooses the product scenario that meets the benchmark curve and maximizes the user's wealth.
On behalf of the user, the MBFPS commits to purchase the product in the FP. The MBFPS sends an anonymized and compacted (“reduced”) version of the FP to the utility program. Periodically, the utility program reviews the reduced FPs, creates product demand curves for different product types, and sends the product demand curves to the product suppliers, to encourage them to provide product offers suited to the goals of the FS users.
Note that during user setup, there is no selecting of financing characteristics, because it is assumed that the lowest interest rate available for the borrower's characteristics, and minimizing the interest paid are the desired characteristics. However, the invention is not limited to this choice of financing characteristics, and other financing characteristics may be desirable in other embodiments, such as establishing reliable repayment to create a good credit history so that future loans may be available at lower rates.
As used herein and in the claims, a “life action” is an event affecting the user's financial plan; a life action may have a one-time effect or a periodic effect or a combination thereof. Life actions represent the reality of a user's financial life. Examples of life actions include: a salary from a job, an expected inheritance in the future, rent payments to the user's landlord, rental income from the user's properties, and so on.
As used herein and in the claims, a “goal” is an uncommitted life action. Goals represent what the user wants. When a user commits to a goal in her financial plan, the goal becomes a life action. A goal has a cost or range of costs, and has a desired timeframe expressed as a particular start date and a particular duration, or as a range of start dates and a particular duration. Examples of goals include retirement, tuition for the user's child, home purchase, charitable gift or endowment, and so on. A “legacy goal” is a one-time cost that occurs at the user's death, such as leaving an inheritance.
As used herein and in the claims, a “life object” is either a “life action” or a “goal”.
One problem with prior art financial planning systems is that the system tries to fund all goals, which often leads to all goals being unfunded.
An advantage of the present invention is that the financial planning system is able to choose which goals to fund. This is a huge improvement, as it leads to outcomes having at least some successfully funded goals, instead of all goals being unfunded. This advantage ensues from the technique of having a user specify all of his or her goals, with associated priority. Initially, the system regards all goals as “uncommitted”. As the system decides that a goal is affordable, the system changes that goal to “committed”.
A goal is modelled as an initial cost, optionally followed by periodic recurring costs, possibly ending at a particular date. Each goal has a user-specified priority, with higher priority goals being funded before lower priority goals. At least one highest priority goal must be specified. The present system provides templates for modelling goals such as retirement, home purchase (initial, mortage payment, real estate tax payments, resale value or annual increase, percent used for business), vehicle purchase (vehicle cost, vehicle lifetime, initial payment, loan payments, insurance payments, operating cost payments, loan duration, annual decrease, percent used for business), vehicle lease, child's college, child's wedding, and a free-form template; the non-free-form templates automatically check “reasonableness” such as requiring that the start date precede the end date.
In some embodiments, a goal template can specify a relationship between this goal and another life object. For instance, the retirement template may identify a job life object and specify that the job ends when retirement begins.
Another problem with prior art financial planning systems is that all goals are the same priority, which forces the user to manually impose priority, such as by first running the system with highest priority goals, and only after these succeed, can the user move on to other goals. This is inefficient.
Another advantage of the present invention is that the user is able to assign priorities to goals, so the system automatically achieves goals in accordance with the user's priorities, and the user is saved from executing multiple iterations of the system to find out how many goals are achievable. In one embodiment, multiple goals can be specified at the same priority. In another embodiment, only one goal can be specified at each priority, forcing the user put his or her goals into a priority sequence. In some embodiments, temporal or value portions of a goal can be specified with different priority levels; the system then represents these as different goals.
A further problem with prior art financial planning systems is that goals can be specified only for a fixed duration, and for a particular cost. This is extremely inefficient for a user, since the user must manually figure out what is achievable for goals that can vary in time and/or cost, leading the user to multiple executions of the financial planning system.
A further advantage of the present invention is that the user is able to specify goals having a variable timeframe and/or a variable cost, so the system automatically can be lavish or frugal depending on a simulation outcome and/or a user's goal flexibility.
Yet another problem with prior art financial planning systems is that the investment allocation remains constant over the user's lifetime.
Yet another advantage of the present invention is that the investment allocation may change over a user's lifetime. In one embodiment, the desired investment allocation is defined independent of the user's life actions. In another embodiment, the desired investment allocation changes in response to one or more of the user's age, life actions and total wealth.
The present financial planning system calculates priority-level benchmarks, such as “minimum wealth to achieve goals” (MWAG), based on the goals at each priority level. The benchmarks are a family of curves, with one curve for each goal priority level. The lowest value curve corresponds to the highest priority goal spending. The second lowest value curve corresponds to the highest priority curve plus the second highest priority goal spending. The third lowest value curve corresponds to the second lowest level curve plus the third highest priority goal spending, and so on. In this embodiment, the minimum wealth to achieve goals benchmark assumes that, for a goal having a time range, the goal begins at the latest possible time; and assumes that, for a goal having a value range, the minimum value is used.
If a goal has a range of values, the range values are divided into sub-goals, with a minimum wealth to achieve goals curve for each sub-goal.
For each Monte Carlo scenario, corresponding to one possible future scenario of investment returns, the system chooses which goals to fund based on comparison of the current wealth with the minimum wealth to achieve goals: lower-priority goals are funded only when aggregate wealth is sufficient to fund all higher priority goals. Then, the likelihood of success for each goal is summed across all scenarios.
If these scenarios result in an acceptable plan, and if the user has given permission, the financial planning system then acts on this plan, such as by moving funds among accounts or placing securities trades.
If these scenarios do not result in an acceptable plan, then the user must change his or her goals, or income expectations. Advantageously, the user does not consume time running scenarios with re-ordered existing goals, as the system has already done the best that can be done with the existing goals.
The present system can be used for at least three purposes: asset management, money management, and consumption advice.
Asset management is useful for wealthy people, who seek a better investment outcome.
Money management is useful for day-to-day financial planning, indicating which streams of expenses should be adjusted or sequenced. Particularly, as goals are completed, the optimal asset allocation can change.
Consumption advice is useful for buying and selling items having significant financial value to the user, such as a home or vehicle. The present system helps ensure that the user buys something appropriate to their wealth: not too cheap and not too expensive.
Network 10 is any suitable communication network such as the Internet. Financial planning system 500, financial planner 550, financial planning servers 560, 580, bank 20, brokerage 30, information service 40 and user 551 are each coupled to network 10 via a suitable communication channel. Generally, financial planner 550 configures the financial planning system, and then uses the financial planning system on behalf of his client or customer, or enables his client or customer to use the financial planning system directly. User 551 is a client or customer of financial planner 550 that directly uses the financial planning system, as configured by financial planner 550. As used herein, “user” means either financial planner 550 and/or user 551, as will be apparent from context.
First, a solo financial planner may execute planning software 610 on her personal computer 550 having locally stored client information 555, and may use Internet 10 to access client accounts at banks 20 or brokerages 30. The financial planner may use information service 40 to obtain, e.g., quotes for current market valuation of client investments.
Second, in a client-server configuration, a solo financial planner having client planning program 610 (instead of a full planning system) executing on her personal computer 550, with locally stored client information 555, can use financial planning server 500 executing server planning program 520. In a variation, financial planning server 500 enables the financial planner to store her client's information in client information storage 540 coupled to financial planning server 500. Instead of a personal computer, the financial planner can use a tablet computer or a smartphone or other suitable device. Typically, personal computer 550 uses a public network, such as Internet 10, to communicate with server 500.
Life objects library 530 includes goal templates and life action templates. Each template provides fields for financial modelling of that type of goal or life object, including priority, date and cash flow. Examples of life objects include job (periodic salary, periodic bonus, social security earnings), trust fund income, alimony income, expected inheritance, social security payments and life insurance.
In some embodiments, the system suggests financing options such as vehicle loans, mortgage refinancing, good times to buy or sell lower priority life objects such as a second car to achieve higher priority goals.
Third, in a software-as-a-service (SaaS) configuration otherwise similar to the client-server configuration, a solo financial planner uses personal computer 550 has an operating system and browser, but lacks special software; client data can be stored in local storage 555 or in server client storage 540. Instead of a personal computer, the financial planner can use a tablet computer or a smartphone or other suitable device.
Fourth, an employee financial planner uses personal computer 590 on the premises of their employer, which operates financial planning server 580 executing financial planning program 620. Local area network (LAN) 582 provides the physical connection from personal computer 590 to financial planning server 580. The client information is stored in storage device 595 that is connected to LAN 582. Financial planning server 580 may use the Internet to access client accounts at banks or brokerages. Instead of a personal computer, the financial planner can use a tablet computer or a smartphone or other suitable device. Financial planning program 620 operates according to a SaaS configuration; in a variation, financial planning program 620 operates according to a client-server configuration.
In a further variation, the employee financial planner is not on her employer's premises, and uses Internet 10 to communicate with financial planning server 580 executing financial planning program 620.
Fifth, an employee financial planner uses personal computer 570 on the premises of their employer, which operates financial planning server 560. Local area network (LAN) 562 provides the physical connection from personal computer 570 to financial planning server 560. The client information is stored in storage device 575 that is connected to LAN 562. Financial planning server 560 may use the Internet to access client accounts at banks or brokerages. Instead of a personal computer, the financial planner can use a tablet computer or a smartphone or other suitable device.
Financial planning server 560 is essentially a proxy, so that the employee financial planner can use financial planning program 520 executing on financial planning server 500. Financial planning program 520 operates according to a SaaS configuration; in a variation, financial planning program 520 operates according to a client-server configuration, with the client program located at financial planning server 560 or financial planner computing device 570. In a variation, financial planning server 500 enables the financial planner to store her client's information in client information storage 540 coupled to financial planning server 500.
In a further variation, the employee financial planner is not on her employer's premises, and uses Internet 10 to communicate with financial planning server 560.
Each of personal computer 550, 570, 590 and server 500, 560, 580 is a general purpose computer programmed according to the present invention. Connections to Internet 10 may be wireline or wireless.
Each goal has at least a start time, a duration of spending, and an amount spent. The financial planning system has a monthly granulation, that is, the Monte Carlo simulations are performed on a month-by-month basis, so the amount spent per goal can be specified per month of the duration. However, typically the user is interested in a lifetime plan, so the goal spending is specified per year. If the spending needs to change over the duration of the goal, the goal should be defined as two goals at the same priority level, preferably with no other goals at this priority level.
Additionally, the start time of a goal can be specified as a range, and/or the cost of a goal can be specified as a range.
At Priority 1, Goal A, such as college tuition for a child, has a duration of a few years, and a cost specified as a range, corresponding to (a) uncertainty as to future tuition cost and (b) uncertainty as to what percent of tuition that the parent will pay.
Also at Priority 1, Goal B, such as retirement, shows flexibility in start date, with a fixed annual cost.
At Priority 2, Goal C, such as a home downpayment, shows flexibility in start date and in cost, corresponding to the user's desire to own a home but not being picky about when or its type.
Also at Priority 2, Goal D, such as a charitable gift, shows flexibility in start date and in cost, corresponding to the user's desire to gift something appropriate for her future circumstances.
Goals at priorities 3 to (n−1) are not shown.
At Priority (n), Goal E, such as a boat, shows flexibility in start date and in cost. By specifying this as the lowest priority goal, the user indicates that she wants this goal only if she becomes unexpectedly wealthy.
Time variability in a goal will now be discussed.
When a goal has a time range specified for its start date, the benchmark calculation (such as a minimum wealth to achieve goals calculation) assumes that the latest time in the range is the start date of the goal. For each Monte Carlo simulation, time variable goal funding can occur according to different techniques. In one technique, as soon as the user's wealth exceeds the minimum wealth to achieve goals for that goal, it will be funded. In another technique, the latest start date of the goal is always used. A further technique, discussed below, may be used if the goal also has value variability.
Value variability in a goal will now be discussed.
For each Monte Carlo simulation, variable value goal funding can occur according to different techniques. In one technique, as soon as the user's wealth exceeds the minimum wealth to achieve goals for the lowest value sub-goal, it will be funded. If the goal also has time variability, the following technique may be used: at the soonest time that the least value sub-goal can be funded, the financial planning system estimates the benefit of waiting until the latest time of funding, and if the expected benefit exceeds a predetermined threshold then the financial planning system waits until the earlier of (a) when the highest value sub-goal can be funded, and (b) the latest time of funding, to decide at what time and level to fund this goal.
Creation of benchmark curves will now be discussed.
As used herein and in the claims, a benchmark is a value at a particular time that indicates whether an objective is or is not achievable, with an objective being either one goal or a set of goals having the same priority. The present financial planning system uses benchmarks to choose which user goals to fund.
In this embodiment, a “minimum wealth to achieve goals” (MWAG) technique is used to determine the benchmark curves. In other embodiments, other techniques are used to determine the benchmarks.
A second benchmark technique is to assume the most conservative returns on all investments, then project all cash flows, and via trial and error, adjust the initial starting wealth to achieve the goals at the highest priority level. This process is repeated with goals at the highest and next-highest priority level to achieve the initial starting wealth for the next benchmark. This is repeated for all priority levels to achieve all benchmark curves.
A third benchmark technique is to re-run the entire set of Monte Carlo simulations so that the user's wealth at the time of death is zero.
Assume that the user has one priority 1 goal: retirement; one priority 2 goal: tuition for the user's only child; and one priority 3 goal: multi-country ski trip. During retirement, the user's only expenses are retirement expenses. Assume further that the user has income only from a job and investments.
Savings[t,p]=Income[t,p]−Expenses[t,p]−Taxes[t,p]
where t=Present . . . Death
p=priority level (equation 11)
Cumulative_Savings[t,p]=Savings[t,p]=Σt=PresentDeathSaving[t,p] (equation 12)
Invest_Income[t,p]=Invest_return*(ISB+Cumulative_Savings[t−1,p]) (equation 13)
Wealth[t,p]=ISB+Cumulative_Savings[t,p]+Invest_Income[t,p] (equation 14)
The hypothetical wealth includes investment income that assumes a fixed rate of return for the investments for the planning period, as in conventional financial planning systems. This fixed rate of return may represent the sum of the rates of return of several investments with respectively different rates of return.
In another embodiment, instead of a fixed rate of return for the investments, a set of investment rate of return Monte Carlo simulations is generated for the financial planning period, and the average simulated rate of return at each period is used for the investments.
Final Value[p] refers to the user's wealth at the time of death, Wealth[t=Death, p]. In this case, the ISB and Final Value[p=1] of the Wealth P1 are positive. However, in other cases, the ISB and/or Final Value may be negative. The ISB could be negative if the user owes money (e.g., student loans). The Final Value could be negative if the user is destitute or has her wealth in illiquid assets that are not included in Wealth as defined here.
The bisection method bisects an interval, then selects a subinterval for further processing. In this example, the MWAG curve approximately results from sliding the Wealth curve down, so the bisection method begins with the interval defined by ISB of Wealth P1 and zero, and iterates, generating a “Wealth” curve at each iteration until the Final Value of the “Wealth” curve is within a predetermined threshold, such as 2% of the Final Value of Wealth P1, of zero, and then this “Wealth” curve is the MWAG P1 curve.
The Newton method finds successively better approximations based on adjusting an initial guess by subtracting a function of the initial guess divided by the first derivative of the function of the initial guess to yield a second guess, then iterating by adjusting successive guesses until the Final Value of the “Wealth” curve is within a predetermined threshold, such as 2% of the Final Value of Wealth P1, of zero, and then this “Wealth” curve is the MWAG P1 curve.
At step 700, the financial planner manually identifies the available investments v=1 . . . V and their associated risk parameters. This is similar to step 250 of
At step 710, the financial planner defines up to Y strategies. For each strategy y, y=1 . . . Y, the financial planner selects K investments, and sets the initial investment weights, that is, the portion of savings to be allocated to each investment. Each initial investment weight is a fraction between 0 and 1, with the total of the weights summing to 1.0. For example, if K=3, then the initial investment weights might be [0.33 0.33 0.34] for even weighting, or [0.2 0.2 0.6] for uneven weighting.
The present system enables the investment allocation to change over time. Typical strategies favor higher risk investments when the client is younger, and lower risk investments when the client is older. A conventional “target date fund” automatically changes the investment allocation of a portfolio based on the time remaining until the target date of the fund; investors are supposed to choose a target date close to their desired retirement. Prior art financial planning systems accommodate target date funds, if at all, via a bundle of predefined scenarios, such as about 50 scenarios, instead of Monte Carlo simulated scenarios.
The present financial planning system essentially customizes a target date fund to the user, rather than requiring the user to pick a fund closest to her needs. The user's retirement date can be flexible, whereas conventional target date funds lack time variability in the target date.
The present financial planning system accommodates target date funds via Monte Carlo simulated scenarios, such as about 1,000 scenarios, with the portfolio weights of investments varying over time, thereby better modelling risk. For instance, assume that the k=1 investment has high risk, the k=2 investment has medium risk and the k=3 investment has low risk, and that t indicates the year of the financial plan (t=0 is the initial condition). The following system investment strategy y(1) changes from high risk to low risk as the client ages: [t=0, 1.0 0 0], [t=10, 0.8 0.2 0], [t=20, 0.5 0.5 0], [t=30, 0.2 0.5 0.3], [t=40, 0 0.3 0.7]. The following system investment strategy y(2) changes from medium to low risk as the client ages: [t=0, 0.3 0.7 0], [t=10, 0.2 0.7 0.1], [t=20, 0.1 0.5 0.4], [t=30, 0 0.3 0.7], [t=40, 0 0 1.0].
In another embodiment, the desired investment allocation changes in response to one or more of the user's age, life actions (goal completion) and total wealth. For example, after the goal of paying for a child's college tuition is met, the user may be willing to assume more risk with their income that had gone towards tuition.
At step 715, the financial planner defines the life object templates, comprising the life action templates and goal templates, to be available to users. A goal template has a field for priority level. A life action template lacks a priority level. Usually, the financial planner selects from a library of life object templates. The financial planner may also create customized life object templates. The life object templates automatically check “reasonableness” such as requiring that the start date precede the end date.
A liquidatable asset is a type of life action.
Table 2 shows a general life object template; other fields may be added. The life object template has a row for each field. Each row includes a field number, a field status (required or optional), a field name, and a field value supplied by the template creator or by the user. Income fields 8A-8B are comparable to Cash Flow fields 9A-9E, that is, a template that uses Income does not use Cash Flow, while a template that uses Cash Flow does not use Income.
Table 3 shows an expected inheritance life action represented in a life object template. Field 1 was supplied by the financial planner and indicates an expected inheritance of a thing. Field 2 was supplied by the financial planner and indicates the template number in a library, such as life actions library 530. The financial planner selected the other fields for this life action. The user provides the field values. Field 3 shows the user named this life action “Aunt Mary bequest”. Field 4 shows the user described this bequest as “Kahlo painting”. There is no priority level (no field 5), which means this is a life action not a goal. Field 6 shows that the user expects this inheritance to begin between Jan. 1, 2025 and Dec. 31, 2030 (whenever Aunt Mary dies), and field 7 shows that the user expects this inheritance to end on the same day. Field 8A shows that the user expects the inheritance to have a value of $800,000. Field 14 shows that the user expects it will take one year to sell this inheritance. Field 15 indicates that the user is willing to liquidate this asset to achieve goals of priority 1 or 2, but not lower priority goals. The user considers Aunt Mary's Kahlo painting to have some sentimental value, but is willing to liquidate the painting to achieve her high priority goals.
Table 4 shows a tuition goal represented in a life object template. Field 1 was supplied by the financial planner and indicates tuition. Field 2 was supplied by the financial planner and indicates the template number in a library, such as life actions library 530. The financial planner selected the other fields for this life action. The user provides the field values. Field 3 shows the user named this life action “Juliet tuition”. Field 5 shows the user gave this goal a priority of “2”. Field 6 shows that the user expects this goal to begin between Sep. 1, 2024 (Juliet may graduate from high school in three years) and Sep. 1, 2026 (Juliet may graduate from high school in four years then take a year off). Field 7 shows that this goal has a duration of four years. Field 10B shows that this goal has a value range of 30,000 per year to 120,000 per year, corresponding to the user's uncertainty over whether Juliet will live at home and attend a state school, or will attend an elite university and live there, or something in-between. Field 10B also shows that this goal has three tiers, meaning that the user is effectively specifying tutition at 30,000 per year; 75,000 per year (midpoint of lowest and highest values); or 120,000 per year, as priority 2 goals.
Alternatively, the user might specify tuition at 30,000 per year as a priority 2 goal; tuition at 75,000-30,000=45,000 as a priority 3 goal; and tuition at 120,000-75,000=45,000 as a priority 4 goal; this scenario corresponds to the user wanting to pay some tuition as a priority 2 goal, but pay all of the most expensive tuition only if all other goals at priorities 2 and 3 are satisfied. Perhaps Juliet will need student loans or a job, if the user has other goals.
Table 5 shows a student loan life action represented in a life object template.
Table 6 shows a rental property life action represented in a life object template.
At step 720, the user creates an account for herself and populates it with user descriptive information, including the user's present age, initial savings balance ISB (which can be negative if the user has outstanding loans such as student loans and/or a home mortgage). In this embodiment, the financial planning system then looks up the user's expected life from a stored table, and enables the user to adjust her expected life. The financial plan will be for a duration of T months, with T=12*(Expected Life (years)−Current Age (years)).
At step 725, the user specifies her life actions resulting in income, expenses or taxes for the duration of the financial plan, using the life action templates defined at step 715. Life actions are things that the user has already committed to, such as repaying the user's student loans.
At step 730, the user defines her goals using the goal templates defined at step 715. Goals are things that the user would like to commit to if affordable.
At step 735, the user defines her liquidatable assets, using the life action templates defined at step 715. For instance, the user may already own a home, and be willing to liquidate this upon retirement. In some embodiments, steps 725 and 735 are combined.
At step 740, the user selects her core System_Strategy from the strategies defined at step 710, defines her excess threshold ET, and selects her satellite System_Strategy from the stragies defined at step 710. The system uses the core System_Strategy until the user's excess wealth exceeds the excess threshold, at which point the system switches to the satellite System_Strategy. The default is to use the core System_Strategy for wealth up to the excess threshold, and then use the satellite System_Strategy for wealth exceeding the excess threshold; however, in some embodiments, the user may specify that the satellite System_Strategy is used for all wealth.
In some embodiments, the user specifies a first core System_Strategy, and then after ET is reached, specifies a second core System_Strategy in lieu of the first for wealth up to ET, and then a third System_Strategy for wealth exceeding ET. For example, the user may select a first medium risk strategy as her core System_Strategy, such as an equity index investment, and then after excess wealth exceeds ET, switch to a low risk strategy as her core System_Strategy for her wealth up to ET, such as a government bond fund, and a high risk strategy for excess wealth exceeding ET, such as a foreign country small cap equities investment.
In some embodiments, the user can specify multiple excess thresholds ET_1, ET_2, ET_3, . . . with respective System Strategies.
In some embodiments, the financial planning system suggests System Strategies based on the value of the excess threshold. For instance, for an excess wealth threshold of $3 million, the system might suggest a bitcoin investment, or for an excess wealth threshold of $10 million, the system might suggest original artwork or other investment having a relatively unpredictable return.
At step 745, the user defines her scenario acceptability threshold. This pre-defined acceptability enables the financial planning system to automatically decide whether a financial plan is acceptable, whereas conventional financial planning systems leave that decision to the user, expecting the user to iterate for awhile. For example, the user may define acceptability as Acceptability=[p1 80%, p2 60%, p3 40%] meaning a financial plan is acceptable if it has at least an 80% chance of achieving priority 1 goals and at least a 60% chance of achieving priority 2 goals and at least a 40% chance of achieving priority 3 goals.
If the user is concerned with having all of her goals met, then goals success likelihood is defined as at step 280 of
Goal_success_likelihood=N−1*Σn=1N1(B[n,T]>BenchmarkpAccept) (equation 15)
In other embodiments, other techniques for defining acceptability are used.
At step 750, the user identifies the client's accounts with third-party systems, such as banks or brokerages, and provides access (read) and/or alteration permission.
At step 760, the financial planning system populates the client's account with information from the client's third-party accounts.
At step 770, the financial planning system gets initial values for the market environment for the client's account.
Step 810 is similar to step 255 of
At step 820, for each priority level, the benchmark curves are determined. In one embodiment, MWAG curves based on hypothetical wealth, discussed with respect to
At step 910, the investment weights w(k) are selected. The investment weights do not vary with time, and the rate of return of each investment also does not vary with time. Typically, the core System_Strategy from step 740 is used as the Selected Strategy for determining w(k), with the fixed return for each investment being the most conservative expected return.
At step 920, the current priority level is set to “1”.
At step 930, Cumulative Savings is initialized to the ISB from step 720.
At step 940, all of the goals at the current priority level are converted to life actions. If the goal has a time range, the latest start date is used. If the goal has a value range, it is split into sub-goals, so that a MWAG curve will be generated for each sub-goal.
At step 950, the user's wealth (Cumulative_Savings) is calculated for each period of the financial plan, thereby generating a Wealth curve for the current priority level.
At step 960, the financial planning system determines the MWAG curve corresponding to the Wealth curve for the current priority level.
At step 970, the current priority level is incremented by one.
At step 980, the financial planning system checks whether the current priority level exceeds the maximum priority level P defined at step 730. If not, processing returns to step 930. If so, processing is complete, that is, the benchmark curves have been determined.
Returning to
At step 840, the financial planning system sets the initial account balance B[t=0] to be the ISB defined at step 720.
At step 850, the financial planning system creates the N scenarios based on the selected system investment strategy, the benchmark curves, the user's goals and life actions, and the Scenario Investment Return SIR[n,t,v] from the Monte Carlo simulations.
For each scenario n, for each time period t, for each priority level p, and for each subgoal s (if any goal has value variability represented as sub-goals):
N=INC[t]−EXP[t]−TAXES[t] (equation 16)
where
INC[t]=Σk=1KLA_INC[k,t,n] (equation 17)
EXP[t]=Σk=1KLA_EXP[k,t,n] (equation 18)
TAXES[t]=Σk=1KLA_TAX[k,t,n] (equation 19)
PR[n,t]=Σk=1K SIR[n,t,k]*wI[k] (equation 20)
and computes the account balance B[n,t] similar to step 275 of
B[n,t]=(1+PR[n,t])*B[n,t−1]+NS[t] (equation 21)
At step 860, the financial planning system determines the goals success likelihood across all scenarios. As used herein and in the claims, for a goal to be successful, the financial planning system must commit that goal, and successfully fund that goal. Successful funding generally corresponds to the user's wealth remaining above the MWAG curve for the duration of the goal.
An example of determining goals success likelihood will now be discussed with reference to
The sole priority 1 goal in this example is retirement, corresponding to the MWAG P1 curve. At the start of the retirement goal, indicated as a vertical dashed line, four of the five simulation scenarios are above the MWAG P1 curve, so the probability that the retirement goal will be achieved is 4/5=80%.
The sole priority 2 goal in this example is tuition, corresponding to the MWAG P2 curve. At the start of the tuition goal, indicated as a vertical dashed line, two of the five simulation scenarios are above the MWAG P2 curve, so the probability that the tuition goal will be achieved is 2/5=40%.
The sole priority 3 goal in this example is a ski trip, corresponding to the MWAG P3 curve. At the start of the ski trip goal, indicated as a vertical dashed line, four of the five simulation scenarios are above the MWAG P3 curve, so the probability that the ski trip goal will be achieved is 4/5=80%.
Generally, it is desirable that priority 2 goals have a higher success likelihood than priority 3 goals. However, in the scenario of
At step 870, the financial planning system decides whether the Financial Plan is acceptable in accordance with step 745. If so, processing continues at step 890. For example, if the user's acceptability threshold is Acceptability=[p1 80%, p2 60%, p3 40%], then the example of
If the Financial Plan is not acceptable, at step 880, the user revises goals and/or priorities and/or investment allocation strategies and/or acceptability threshold and processing returns to step 820. At step 880, the financial planning system may suggest strategies or investments to the user, with the suggestions based on the user's wealth and goals. Exemplary suggestions made by the financial planning system may be:
At step 890, the financial planning system defines the user's Financial Strategy as the parameters leading to goals success likelihood deemed acceptable at step 870. These parameters include the initial savings balance specified at step 720, the life actions specified at step 725, the goals and priority levels specified at step 730, the liquidatable assets specified at step 735, the System Strategies specified at step 740, the acceptability threshold specified at step 745, and the benchmark curves determined at step 820.
Conventional financial planning systems produce a financial plan, possibly misleading the user into false certainty regarding goal achievement. In contrast, the present financial planning system produces a financial strategy with success likelihoods for the goals, more accurately representing future uncertainty to the user.
At step 895, the financial planning system implements or applies the Financial Strategy deemed acceptable at step 870, as shown in
Turning to
At step 1020, if the customer, also referred to as the user or the client, has given permission, the financial planning system automatically moves funds among accounts, and/or places trades in accordance with the Financial Strategy. Fund movement occurs when the ISB is allocated among accounts, when the monthly savings is allocated among accounts, and when accounts are rebalanced to conform to the financial plan.
At step 1030, for those actions specified by the Financial Strategy that cannot be automatically accomplished, the financial planning system notifies the customer of what actions to take. For instance, if an asset such as a painting is to be liquidated, the customer is notified. At step 1040, the user optionally updates information or adds new information.
Examples of updating information are: changing the parameters of life actions or goals, or deleting life actions or goals. Examples of adding new information are: adding new life actions, adding new goals or financial accounts.
At step 1050, the financial planning system determines that sufficient time has elapsed so that the next period t+1 of the Financial Strategy has arrived. Typically, at step 720, the financial period is defined as a month, but in some cases it may be a week, a bi-week, a quarter-year, a year or other suitable timeframe.
At step 1060, the financial planning system checks whether the user is still alive, or whether another condition at the end of the Financial Strategy has occurred. If so, processing is complete. If not, processing continues to step 1070.
At step 1070, similar to step 770, the financial planning system gets current values for the market environment for the client's account.
At step 1080, the financial planning system determines whether a new financial strategy is needed. Generally, a new financial strategy is needed when at least one of the following events has occurred, as specified by the user, indicating a change to wealth over time:
At step 1090, only the period t+1 of the existing Financial Strategy is computed, reflecting the current market environment from step 1070 and any changes to current position made by the user at step 1040. Processing at step 1090 is similar to processing at step 850, but for only n=reality (instead of one of N simulation scenarios) and only t=t+1 (instead of t=1 to T), and will not be discussed in detail for brevity. Step 1090 comprises implementing the acceptable financial strategy by determining actions period-by-period. Then, processing continues at step 1020.
An advantage of the present financial planning system is that if there have been no material changes in the user's circumstances since the last period, only the current period needs to be computed at step 1090; in contrast, a conventional financial planning system gives only a plan for one period, and needs to be completely re-run at a next period. The present financial planning system needs to be completely re-run only in a period where there have been material changes in the user's circumstances (the “yes” branch from step 1080 to step 820, indicated by AA in a circle).
The effect of financing on an object will now be discussed.
A third-party financing provider defines its financing product by parameters, such as:
An individual can define private financing available to the individual, on a goal-by-goal basis. For instance, the individual's family may volunteer to give the individual a no-interest loan of $15,000 to be repaid over 10 years, for use only on the downpayment for a car. The parameters for private financing are otherwise similar to the parameters for third-party financing, discussed above.
We now turn to the issue of when financing is appropriate.
A very conservative person buys an object only when s/he has saved sufficient funds to afford the object. However, this is not necessarily an optimal strategy when possession of the object would enable improvements in the person's life. For instance, a car enables a person to work further from home, transport food, transport their family to events, and so on. Thus, financing an object may improve a person's life sufficiently to be worth the cost of financing.
A user may accept financing in several ways. One way is on a goal-by-goal basis: the user to designates a goal as finance-able, possibly indicating restrictions in the amount of financing tolerable by percent of value or absolute amount or financing cost or date or financing provider (private or third party). Another way is globally for all goals: the user designates financing of any goal as acceptable, possibly with restrictions as mentioned; possibly also by priority level, e.g., financing of priority 1 and 2 objects is acceptable but not if the priority is lower; and/or possibly by goal value, e.g., goals costing at least $20,000 are financeable. A further way is by whether the goal has an asset that can be used as collateral. Yet another way is by the type of financing, e.g., private financing as defined by the user is acceptable, but third party financing is not acceptable. Other acceptance strategies for financing can be accommodated.
An example of a financing strategy is: for object=car, financing is acceptable if year is 2021 or later and interest rate is under 5%. This strategy causes the present system to select all loan provider offerings that meet this criteria, then see if the borrower meets the financing provider's criteria.
At step 1115, a financing database is created comprising offers to provide financing according to various terms, for borrowers who meet the lenders' criteria. Financing providers specify whether they will automatically agree to make loans automatically selected by the FPS.
During user setup, a user's willingness to accept financing is specified. In one embodiment, financing is assumed to be acceptable, and the user can override this globally or by goal. In another embodiment, the user must “opt in” to financing, either globally or by goal. The user also specifies whether s/he wishes to automatically accept financing selected by the FPS. Otherwise, steps 1120 and 1125 of user set-up are similar to steps 1100 and 1105 of
During user operation, at step 1130, generally similar to step 1110 of
In some embodiments, there is a “system operation” phase, typically at periodic intervals such as weekly or monthly, wherein at step 1160, the FPS creates financing demand curves (discussed below) based on the users' FPs or FSs and sends these curves to the financing providers. Then at step 1170, the FPS receives the financing providers' responses, if any: either changes to existing loan offers, such as changes to borrower criteria, or entirely new loan offers. The FPS updates the financing database with these updated or new financing offers. The FPS also notifies relevant users of these updated or new financing offers. Generally, a relevant user is one who has financing in their FP or FS, and for whom the updated or new financing offers might result in a better outcome. At step 1140, each user then determines whether or not to accept the updated or new financing offer, thereby possibly refinancing their loan.
Users following a FP or a FS are more likely to repay their loans, so better loan terms may be available from financing providers for such users.
Financing demand curves will now be discussed.
Lenders are concerned with loans to users of different creditworthiness. A user's creditworthiness is conventionally represented by a credit score, showing how a user has managed their use of credit in the past. A FPS permits consideration of how a user will manage their credit in future via a new metric: predicted default rate. A family of curves showing the number of FPs or FSs at different PDRs can be constructed, to show lenders the market size as the lenders change their creditworthiness requirements.
Predicted default rates (PDRs) will now be discussed.
For a conventional FPS, a default is defined narrowly as having zero in all cash and investment accounts, i.e., expenses cannot be paid without asset liquidation. A conventional FPS is usually unable to automate asset liquidation decisions, so this is an appropriately narrow definition.
For a benchmark FPS, a default is defined more broadly as the user's net wealth dropping below zero, meaning that assets can be liquidated to pay expenses. The benchmark FPS automates asset liquidation decisions, so this is an appropriately broad definition.
Conventionally, financing providers base their decision to lend mainly on the potential borrower's income and assets, and on the “credit history” of a potential borrower, that shows how timely an individual has repaid other of their debts to prior lenders such as banks, credit card companies, collection agencies, and governments. Many financing providers use risk-based pricing, their loan rates depend on the borrower's credit history.
An advantage of a FP or FS is that it shows the likelihood of a borrower being able to repay in future, which is arguably more/ant than the borrower's credit history, particularly for younger individuals that have not taken out any or few loans. A FP or FS can be thought of as a future credit history. Thus, a FP or FS is valuable information to a financing provider, as it illuminates the personal risk of a borrower, while the Monte Carlo (MC) simulations used in the FP or FS simulate default risk along with exogenous market risk effects.
For a FP, the predicted default rate, PDR, is defined as in equation 22:
PDR=(no. simulations where user defaults)/total no. simulations (equation 22)
For a FP, the PDR gives the likelihood of default over the lifetime of the financial plan, which is better than no informationabout the future, but does not inform a financing provider as to when the default might occur. Generally, a financing provider is concerned about borrower default only if it occurs during the term of the loan provided by the financing provider.
A FS is “date aware”, i.e., the times of the defaults based on the MC simulations are easily visible. Thus, a FS permits computation of a date-aware PDR, i.e., a PDR for a given time period t1 to t2 of the FS, as in equation 23:
The date-aware PDR is exactly what a risk-based lender wants to know: what is the likelihood of the borrower defaulting during the loan repayment period.
Thus,
Thus,
As is conventional in patent drawings, when only one instance of an item is shown for brevity, it will be understood that many instances of that item are possible and operate similarly.
Section 1. Modified Conventional Financial Planning System with Financing
Financial planning servers 1260, 1270 and financial planner 1250 respectively execute modified conventional financial planning system software 1262, 1272, 1252. The modifications are as described below, including an application programming interface (API) to program 1276 executed by utility system 1275. Generally, financial planner 1250 is a solo or small entity, server 1260 is a large entity, and system 1270 is associated with a sophisticated small entity, a mid-size entity or a large size entity.
Financial planner 1266 is a remote user of financial planning server 1260 or 1270.
Reduced client database 1277 contains reduced (anonymized) financial plans and associated information—such as hypothetical offer acceptances (discussed below)—created by financial planning servers 1260, 1270 and financial planner 1250, sufficient for creation of financing demand curves, for updating of the reduced financial plans by their creators and for sending new and updated loan offers to the owners of the reduced financial plans.
Financing database 1278 contains registration profiles for lenders 1280. Financing database 1278 contains offers to provide financing for various goals according to various terms, for borrowers who meet the lenders' criteria. For instance, if the product is tangible, the lender may be willing to provide a cheaper rate if the lender has a security interest in the product. The lender also indicates whether they are willing to commit to future financing for an individual based on the individual's current circumstances and financial plan. For instance, an individual who has followed their plan for several years may be considered a lower risk; such that the individual's performance, as verified by a financial planner, can be relied upon in addition to a third party credit score.
In financing database 1278, financing providers 1280 specify whether they will automatically agree to make loans automatically selected by the FPS, such as by selecting from
Financing database 1278 also contains financing demand curves created by program 1276.
Financing database 1278 also includes a library of predefined financing strategies, discussed below, that borrowers can indicate their willingness to use.
Financing provider 1280 is a third-party provider of loans, i.e., a lender. Lender 1280 indicates types of loans it is willing to provide along with parameters describing acceptable loans and characteristics of acceptable borrowers.
Utility system 1275 executes program 1276 that stores the descriptions of loans from third-party lenders 1280 in its financing database 1278. It is a single storage point for loan offers from lenders 1280. Via the API supported by program 1276:
Supplemental database 1265 is similar to financing database 1278, except that supplemental database includes loan offers available only to customers of financial planning server 1260. These supplemental loan offers may include proprietary loans offered by the owner of server 1260, exclusive loans offered by business partners of the owner of server 1260, and curated loans offered by third parties to customers of the owner of server 1260.
Supplemental financing provider 1267 represents the owner of server 1260, business partners of the owner of server 1260, and third parties offering financing to customers of the owner of server 1260.
For instance, if the owner of server 1260 is Bank of Atlantis, then supplemental database 1265 may include loan offers to customers of Bank of Atlantis at better rates than the loan offers for non-customers in financing database 1278 provided by Bank of Atlantis, acting as a lender 1280.
After the conventional setup activities occur, as shown by the vertical dotted line, at step 1310, financing database 1278 is defined.
At step 1312, a system administrator (not shown) at utility 1275 defines the types of financing. Table 7 shows a sample list of financing types.
At step 1314, the system administrator of utility 1275 defines the primary features of each of the financing types, such as description, characteristics, and lifetime in months. Then, lenders 1280 populate financing database 1278 with loan offers, see
For example, for financing type 01 Secured Loan, Property, there may be instances as shown in Table 8.
In some embodiments, the system administrator defines general instances of a financing type, such as “01-10 15 year fixed mortgage, FHA, stand-alone home”. Then, lender 1280 works with the product supplier to define specific instances corresponding to the supplier's products, such as “01-10-01 Bank of America 15 year fixed mortgage, FHA, stand-alone home”, “01-10-02 Citibank 15 year fixed mortgage, FHA, stand-alone home”, “01-10-03 Wells Fargo Bank 15 year fixed mortgage, FHA, stand-alone home”.
At step 1320, the owner of each financial planning server 1260 populates supplemental financing database 1265, in similar manner as financing database 1278 is populated. The financing offers in supplemental database 1265 may include hypothetical offers, discussed below.
At step 1330, the system administrator of utility server 1275 and/or lenders 1280 populate financing database 1278 with hypothetical financing offers, similar to step S120 of
A hypothetical financing offer is a way of testing market acceptance of a new loan product. A hypothetical loan offer can be defined by a system administrator (not shown) of utility system 1275, or by a financing provider. Generally, a hypothetical loan offer is the same as a non-hypothetical loan offer, except that the hypothetical loan offer includes a field showing it is hypothetical. As explained below, if the FPS would have selected the hypothetical loan offer, this event is recorded, then the hypothetical loan offer is marked as temporarily ineligible, forcing the FPS to choose a non-hypothetical loan offer for the financial plan. The event of selecting the hypothetical loan offer is stored in reduced database 1277, so that when financing demand curves are created, the demand for the hypothetical loan can be assessed.
At step 1340, the system administrator of utility server 1275 defines available financing templates. For example, the predefined financing templates may All Cash, Major Purchases, Specified Goal, Private Only and Private Supplemental, as shown in Table 9. Generally, the financing templates specify when a type of financing is acceptable to the user. As explained below, since some types of financing can be combined, as a convenience to the user, the FPS first combines the templates to determine the general financing scenarios, and then selects specific financing offers to create the set of financing scenarios to evaluate for the user.
At step 1350, the system administrator of utility server 1275 defines available financial plan acceptability criteria so that FPS 1252, 1262, 1272 will present a financial plan for manual review by the user. In a conventional FPS, success is usually considered to be achieving goals while remaining solvent. For instance, financial plan success can be defined as the financial plan's PDR being less than PDR-Threshold, where PDR-Threshold is a value defined by the user such as 10%.
At step 1360, the system administrator of utility server 1275 defines available lifetime acceptability criteria, also referred to as “financial plan optimality criteria”, so that FPS 1252, 1262, 1272 can model what is important to a user.
For instance, some users may want to maximize the amount of financial wealth (cash and investments) they have at the end of their lives, corresponding to a criteria of “maximize wealth at end of life” even if the user has debt at end of life.
Other users may wish to maximize the value of the goals they achieve during their life, corresponding to criteria of “Maximize Value of Goals Achieved” regardless of debt at end of life.
Other users may wish to achieve only the goals they can afford, corresponding to a criteria of “maximize goals subject to minimizing debt at end of life”.
Other acceptability criteria are possible.
Note that availability of financing can change how many goals are achievable, and can change the value of goals achieved. Examples of lifetime acceptability criteria are shown in Table 10.
For instance, if a user specifies GoalNo-Threshold=3 at step 1440 of
Note that financial plan acceptability criteria of PDR<PDR-Threshold defines a ceiling on the acceptable PDR, thereby defining which financial plans are eligible, while optimality criteria of Minimize PDR results in choosing the eligible financial plan with the lowest PDR.
For convenience, the following description refers to “software 1252, 1262, 1272” in the sense that each of software 1252, 1262, 1272 is capable of executing the functions as described, but only the one of software 1252, 1262, 1272 associated with the user actually executes the functions as described.
At step 1401, software 1252, 1262, 1272 assigns a unique ID tag to the user, intended to be unique across
After conventional steps 1405, 1410, 1415, at step 1425, the user defines private financing available to that user, and the order of selecting financing. Private financing represents gifts or loans that friends and family members, and possibly employers, are willing to provide to a user. Usually, the terms of private financing, such as rate and repayment flexibility, are much better for a user than the terms of third-party financing, so it is preferable to use private financing before third party financing. Private financing is defined similarly to the parameterized descriptions of loans of each financing provider 1280 defined at step 1310 of
The default order of selecting financing for software 1252, 1262, 1272, assuming that all other characteristics of the financing are equal, in order of preference, is: private, supplemental, hypothetical, third-party. The user can change this ordering.
At step 1430, the user selects acceptable financing templates from the financing templates defined at step 1340 of
At step 1435, the user selects financial plan acceptability criteria from the available criteria defined at step 1350 of
At step 1445, the user decides whether to opt into automatic loan approval. Software 1252, 1262, 1272 has a default of no automatic loan approval, which can be changed by the user.
Step 1450, providing a general research interface, is shown with dotted lines to indicate that it is optional, and is performed by utility program 1276, with software 1252, 1262, 1272 merely routing traffic between the user and utility program 1276.
The general research interface is typically a graphical user interface (GUI) that presents a start page with a menu such as in Table 11.
The user can access the General Research GUI after s/he has sufficiently provided registration information. The General Research GUI is a user-friendly way to browse the contents of financing database 1278. The user positions his/her cursor over an item on the start page and clicks on it, to get to another page. The menu items function as follows:
Conventional FPS often provide an interactive interface for the user including the ability to query additional set-up information and view the set-up information provided by the user, but these interfaces vary among FPS and are outside the scope of this invention. The API for utility system 1275 accommodates receiving queries directly from a user of FPS 1250, 1260, 1270, and receiving queries from FPS 1250, 1260, 1270 so that FPS 1250, 1260, 1270 can provide an integrated GUI to the user, if the maker of FPS 1250, 1260, 1270 so desires.
After the SIR[n,t,v] values are generated at step 1520, at step 1530, software 1252, 1262, 1272 determines the acceptable financing scenarios based on the user's selections of acceptable financing templates at step 1430 of
One financing template may correspond to several suitable financing offers. So, software 1252, 1262, 1272 combines the templates as appropriate to create different structures for financing scenarios. Cash-only financing is always evaluated as the first financing scenario. This step is necessary because the user is permitted to select multiple financing templates. In embodiments where the user is permitted to select only one financing template, this step is not needed, but the set of eligible financing templates is much larger.
Then, software 1252, 1262, 1272 evaluates specific financing offers according to the structures of the financing scenarios. The borrower criteria for each financing offer are examined, and the financing offer is discarded if the borrower does not meet the borrower criteria; retention of only financing offers that the borrower is eligible for is akin to “credit pre-approval”. The acceptable financing scenarios are the user-eligible financing offers that satisfy the user's financing templates.
In some embodiments, software 1252, 1262, 1272 adjusts the user's financial plan acceptability threshold, PDR-Threshold define at step 1435 of
Step 1535 causes an iteration of software 1252, 1262, 1272 for each financing scenario to create an Iteration Plan, also referred to as a “draft financial plan” (draft FP), then selects the Iteration Plan in accordance with the lifetime (optimality) criteria selected by the user at step 1440 in
As an example of the first technique of scenario evaluation, when there are five financing templates as above, the first All Cash template results in the first Iteration Plan being substantially the same as the financial plan resulting from the conventional financial planning system; differences may occur from setting I[k] and wI[k] automatically instead of manually, i.e., the financing strategy can affect the investment strategy.
For the second template, Major Purchases, assume that the user specified the THRESHOLD parameter for major purchases as $20,000, and that the only user goals exceeding $20,000 are a house and a car. Software 1252, 1262, 1272 searches for the best (lowest rate) third party financing for the house, then searches for the best (lowest rate) third-party financing for a car. Software 1252, 1262, 1272 then adjusts the user's goals to reduce Goal Value G$[g,f] by the financed amount, and increase Goal cash flow per month GCF[t,g,f] by the loan repayment amounts. Then, with the adjusted goals, the best financial plan is determined in the conventional way as the second Iteration Plan.
In some embodiments, instead of selecting the best financing as simply the lowest rate, software 1252, 1262, 1272 first selects the different loan terms, then selects the best financing for each loan term, then creates additional strategies such as Major Purchases with 5 year loan, Major Purchases with 10 year loan, Major Purchases with 30 year loan. This illustrates how a financing strategy gives rise to multiple financing scenarios.
In some embodiments, software 1252, 1262, 1272 considers the best overall financing, for instance, if a user has a car loan, the user may not qualify for a mortgage.
For the third template, Private Only, software 1252, 1262, 1272 determines which goals have private financing available, and adjusts their G$[g,f] and GCF[t,g,f] parameters as above. Then, with the adjusted goals, the best financial plan is determined in the conventional way as the third Iteration Plan.
For the fourth template, Third-Party with Private Additional, software 1252, 1262, 1272 first adjusts the goal values and cash flow to reflect private financing, as above, then searches for the best third party financing for the house, then searches for the best third-party financing for a car, and again adjusts the goal values and cash flow to additionally reflect third-party financing. Then, with the fully adjusted goals, the best financial plan is determined in the conventional way as the fourth Iteration Plan.
For the fifth template, Supplemental with Private Additional, only software 1262 can execute this, because only software 1262 has access to supplemental financing 1265. Software 1262 first adjust the goal values and cash flow to reflect private financing, as above, then searches for the best supplemental financing for the house, then searches for the best supplemental financing for a car, and again adjusts the goal values and cash flow to reflect supplemental financing. Then, with the fully adjusted goals, the best financial plan is determined in the conventional way as the fifth Iteration Plan.
At the end of step 1535, software 1252, 1262, 1272 compares the five Iteration Plans and selects the best according to the user's lifetime (optimality) criteria.
If the second technique of scenario evaluation was used, the first financing scenario (all cash) translates to one financing scenario, while the other financing scenarios can each translate to multiple scenarios depending on the number of suitable stored financing offers.
In another embodiment, instead of comparing all Iteration Plans, software 1252, 1262, 1272 determines the first Iteration Plan and sets that to be the best Iteration Plan. After determining each subsequent Iteration Plan, software 1252, 1262, 1272 sets that to be the best Iteration Plan only if the new Iteration Plan is an improvement over the existing best Iteration Plan.
The modified conventional financial planning system described above operates in a generally iterative manner.
At step 1540, software 1252, 1262, 1272 presents the financial plan, i.e., the selected Iteration Plan, to the user for a manual determination of acceptability as at step 285 of
If the Iteration Plan is not acceptable, or if there was no acceptable Iteration Plan, at step 1545, the user manually revises his/her goals, financing strategy and/or acceptability criteria, and processing returns to step 1530.
Steps 1550 and 1560 operate conventionally, corresponding to steps 290 and 295 of
At step 1570, software 1252, 1262, 1272 determines whether to automatically commit to a loan, as shown in detail in
At step 1580, software 1252, 1262, 1272 updates the individual's financial plan, if needed, and stores it in client database 1253, 1263, 1273, respectively.
At step 1585, software 1252, 1262, 1272 stores a reduced (anonymized) form of the financial plan in reduced client database 1277 with the unique ID tag assigned at step 1401 of
At step 1600, software 1252, 1262, 1272 receives and stores manually set investments I[k] and investment weights wI[k] as a trial financial plan, corresponding to step 260 of
At step 1605, software 1252, 1262, 1272 selects the first financing scenario determined at step 1530 of
At step 1610, software 1252, 1262, 1272 adjusts the user's goals to reflect the financing, if any. For financing scenario f=1, all cash, no adjustment occurs.
Typically, the MCFPS determines an interest rate at the start of the financing, and uses that same rate throughout the term of the financing. In contrast, the MBFPS, discussed below, automatically determines a variable interest rate at the proper time in each simulation.
Step 1615 corresponds to step 270 of
Step 1620 corresponds to step 275 of
Step 1625 corresponds to step 280 of
At step 1630, software 1252, 1262, 1272 evaluates the draft FP using the acceptability criteria selected by the user at step 1435 of
If the Iteration Plan was not minimally acceptable, at step 1635, software 1252, 1262, 1272 determines whether the investment weights wI[k] can be adjusted. Generally, adjustment can occur at the first execution of step 1635, but after repeated executions, adjustment may not be possible. If adjustment is not possible, processing proceeds to step 1645.
At step 1640, software 1252, 1262, 1272 uses a suitable adjustment technique such as varying investment weights wI[k] between 0 and 1 using an optimization procedure as taught in Chapter 10 of Numerical Recipes: The Art of Scientific Computing, 3rd edition, Press et al., Cambridge University Press, 2007, pages 487-562. Generally, software 1252, 1262, 1272 does not automatically vary the investments I[k] selected in step 1600, but in some embodiments, the software can automatically vary the investments if there are similar risk-level other investments I[k] available. Processing returns to step 1615.
At step 1645, software 1252, 1262, 1272 determines that no draft FP can be created for this financing scenario, and processing proceeds to step 1655.
At step 1650, software 1252, 1262, 1272 stores the investments I[k], the investment weights wI[k], the ending wealth B[n,T,f] for n=1 . . . N, the goals success likelihood (GSL) and the PDR as the Iteration Plan for this financing scenario.
At step 1655, software 1252, 1262, 1272 checks whether this financing scenario is the last financing scenario F. If so, processing proceeds to step 1670.
If this was not the last financing scenario F, at step 1660, software 1252, 1262, 1272 increments to the next financing scenario f.
At step 1665, software 1252, 1262, 1272 resets to the Trial Financial Plan specified at step 1600, and processing continues at step 1610.
At step 1670, software 1252, 1262, 1272 selects the financial plan from among the eligible Iteration Plans based on the lifetime (optimality) criteria specified at step 1440 of
At step 1675, software 1252, 1262, 1272 checks whether the selected Iteration Plan includes hypothetical financing. If not, processing is complete, and the selected Iteration Plan is deemed to be the chosen financial plan.
If the selected Iteration Plan includes hypothetical financing, then at step 1680, software 1252, 1262, 1272 stores the event that hypothetical financing was selected in reduced client database 1277. This event is valuable information, it shows that the hypothetical financing offer would be useful to this individual. The event of selecting a hypothetical offer is akin to an automated focus group approval. It will be appreciated that hypothetical offers are a quick and inexpensive way to get reliable sales projections for the hypothetical financing.
At step 1685, software 1252, 1262, 1272 marks this Iteration Plan as ineligible because it contains an ineligible (hypothetical) financing offer, and processing returns to step 1670 to select the next-best among the eligible Iteration Plans.
In a variation, instead of returning directly to step 1670, processing flags the hypothetical financing as ineligible, recalculates the financing scenario based on other available financing, if any, and returns to step 1670 with a different Iteration Plan for financing scenario f.
At step 1710, software 1252, 1262, 1272 checks whether the user and the lender have both authorized automatic loan commitment. If no, processing continues at step 1725.
If the user and lender have authorized automated loan commitment, at step 1720, software 1252, 1262, 1272 sends loan commitments to the appropriate lenders (see
In some embodiments, a loan commitment specifies how binding it is, depending on the preferences of the lender and borrower. Loan commitment “binding-ness” is one of the financing characteristics, see step 1314 of
If the lender has authorized automated loan commitment, but the user has not authorized automated loan commitment, at step 1725, software 1252, 1262, 1272 asks the user if s/he wishes to commit to a selected loan, and receives the user's response.
At step 1730, software 1252, 1262, 1272 checks whether the user has approved committing to the loan. If not, processing is complete. If the user has approved, processing proceeds to step 1720.
At step 1810, utility program 1276 checks whether it is time to create loan demand curves, such as by comparing a timer of the current elapsed time t elapsed to a threshold T_threshold. If it is not yet time, utility program keeps checking while utility program 1276 keeps incrementing t elapsed as time passes. Eventually, it will be time, and processing proceeds to step 1815.
At step 1815, for each type of loan, as defined at step 1314 of
At step 1830, utility program 1276 then constructs a loan demand curve, as in
At step 1835, utility program 1276 sends the various types of loan demand curves to those of lenders 1280 that either offer this type of loan, or have indicated interest in offering this type of loan, see
If an entity offering supplemental financing, such as the owner of FPS 1260, wishes to see the loan demand curves for third-party loans, it must register as an instance of lender 1280 and indicate interest in offering this type of loan.
At step 1855, utility program 1276 receives the revised and new loan products, if any, see
At step 1860, utility program 1276 updates financing database 1278 with the revised or new loan products.
At step 1865, utility program 1276 notifies the software, selected from software 1253, 1263, 1273, associated with the relevant financial plans, i.e., the financial plans retrieved at step 1820, of the revised or new loan terms.
At step 1870, utility program 1276 sets the timer t elapsed to zero, and processing returns to step 1810.
In some embodiments, software 1262 executes steps 1810, 1815, 1845, 1860, 1865, 1870 for the financial plans in client database 1263, to produce supplemental loan demand curves for its customers. These supplemental loan demand curves are proprietary to the owner of FPS 1260.
At step S100, lender 1280 opens an account with utility system 1275, provides contact information and demonstrates its authorization to act as a lender (if needed), along with optional information such as the total amount and/or number of loans it is willing to make via system 1275, the total daily amount and/or number of loans it is willing to make via system 1275.
At step S110, lender 1280 provides user-visible marketing information, such as address, customer service telephone number, and why a user should feel comfortable getting a loan from lender 1280. Lender 1280 can also designate some or all of the information it provides at step S120 as being user-visible.
At step S130, for each financing instance (loan offer), lender 1280 defines its features, such as description, product (goal) applicability and required customer characteristics. Customer characteristics are selected from:
In embodiments where the FPS permits identification of its user via the API with utility system 1275, system 1275 can obtain this third-party information on behalf of lender 1280.
At step S130, lender 1280 can optionally opt into automatic loan approval for loans where borrowers meet all its criteria, and the loans are within the daily and lifetime limits, if any, defined at step S100. In some embodiments, automatic loan approval can be conditioned on additional information, such as different thresholds for customer characteristics. For example, a lender may be willing to lend to someone with an income of at least $30,000, and be willing to automatically lend to someone having (income—other loan payments) of at least $100,000.
At step S210, lender 2180 can modify the information it provided at step S100 of
At step S210, lender 2180 can modify the information it provided at step S110 of
At step S230, lender 2180 can add a new loan product. When this occurs, system 1275 automatically distributes (not shown) information about this new loan product to users whose financial plans include a similar type of loan, similar to step 1865 of
At step S240, lender 2180 can amend the terms of an existing loan product or delete the loan product entirely. When this occurs, system 1275 automatically distributes (not shown) information about this new loan product to users whose financial plans include this loan product, similar to step 1865 of
At step S250, if lender 1280 has opted into automatic loan approval at step S130 of
At step S260, the appropriate ones of lender 1280 receive the loan demand curve from utility program 1276 at step 1835 of
At step S270, each lender 1280 decides whether to offer revised or new loan products based on the loan demand curve. Usually, a loan manager employed by lender 1280 reviews the loan demand curve, and decides how to respond.
At step 1850, if lender 1280 has decided to offer a revised or new loan product, lender 1280 sends the loan product terms to utility program 1276 at step 1855 of
U.S. Pat. No. 7,366,694 (Lazerson) discloses a computer system that receives a borrower's personal and financial information, and reasons for wanting a loan, and also receives and stores loan package data from lenders. Lazerson calculates a borrower credit grading distinct from a credit score, and presents a spreadsheet-like display of suitable loans, and possibly products and services relevant to the purpose of the loan. Telling the borrower of his/her credit grading reduces the chances that the borrower will be taken advantage of by a predatory lender.
Lazerson was invalidated as reciting patent-ineligible claims in Mortgage Grader, Inc. v. First Choice Loan Services Inc., 811 F.3d 1314, 117 USPQ.2d 1693 (Fed. Cir. 2016). The Court held that the claims were directed to the abstract idea of “anonymous loan shopping”, and recited steps that could be performed entirely in the human mind, thus reciting a basic tool of technological work that cannot be reserved exclusively via a patent claim. The Court said that the claims lacked an “inventive concept”, merely reciting generic computer components such as an “interface”.
The invention of
The invention of
The embodiment of
The invention of
Section 2. Modified Benchmark Financial Planning System with Financing
User 2001 is an individual who uses FPS 2020 directly, such as via a smartphone or computer.
Financing provider 2005 is similar to financing provider 1280 of
Financing library 2027 is similar to financing library 1278 of
Reduced client database 2025 is similar to reduced client database 1277 of
Supplemental financing provider 2086 is similar to supplemental financing provider 1267 of
Supplemental financing database 2085 is similar to supplemental financing database 1265 of
Modified conventional financial planning system 2015 represents financial planning systems 1250, 1260, 1270 of
FPS 2020 includes the functions of system 500 of
Benchmark FPS program 2021 is used by user 2010, and provides a modified benchmark financial planning system thereto.
Benchmark utility program 2022 is used by FPS 2050, 2060, 2080 in similar manner as utility program 1276 of
Conventional utility program 2023 is used by modified conventional financial planning systems 2015, and corresponds to utility program 1276 of
In other embodiments, the utility functions of system 2020 operate in a separate system than the benchmark FPS functions of system 2020.
At step 2100, a system administrator of system 2020 selects the time period that system 2500 will use for simulation, usually monthly, but weekly, biweekly, quarterly, semi-annually and annually are also possible.
Steps 2105, 2110, 2115 are similar to steps 700, 710, 715 of
Steps 2118, 2120, 2130, 2140 are similar to steps 1310, 1320, 1330, 1340 of
At step 2118, the financing offers may be based on the future market rates simulated at step 2310 of
Note that there is no need for a step corresponding to step 1350 of
At step 2150, the system administrator of FPS 2020 (not shown) defines available FS periodic acceptability criteria for the period defined at step 2100, to assist in modeling what is important to a user. The FS periodic acceptability criteria are similar to the FP acceptability criteria of
For instance, if a user selects (liquidity cushion, m=12), system 2020 will require that the user's FS has at least 12 months of expenses available as cash.
At step 2160, a system administrator of system 2020 defines different criteria that are available to select a FS financing scenario af* as the best of several acceptable scenarios. This step is akin to step 1360 of
At step 2201, FPS 2021 assigns a unique ID tag to the user, for use in the reduced FS.
At step 2245, the user selects FS acceptability criteria: a success of financial strategy threshold (SFS-TH), and success weights SWeightp for each priority level p=1 P, used to automatically determine whether a FS is acceptable. The success weights must sum to 1.0. For example, if the user has only high and low priority goals, then SWeight_high+SWeight low=1. At
Steps 2250-2270 of
Steps 2275, 2280 are similar to steps 1425, 1430 of
At step 2285, the user selects from among the available FS periodic acceptability criteria defined at step 2150 of
At step 2290, the user selects from among the available FS scenario-best criteria defined at step 2160 of
Step 2295 is similar to step 1445 of
At step 2297, the user selects whether s/he wants to be advised of loan prepayment opportunities, and if so, selects a threshold PPAY-TH. See
Step 2299 is performed by benchmark utility program 2022 or modified conventional utility program 2023, and is similar to step 1450 of
Step 2310 corresponds to step 810 of
Step 2320, determining the benchmark, is shown in
Step 2345, determine available financing scenarios, uses the financing templates selected at step 2280 of
At step 2350, evaluation of a sub-goal in the (n, t, p, s) innermost loop is shown in
At step 2360, the goal success likelihood GSL_pfor each goal priority level p is determined, and the date-aware PDR is determined according to Equation 23. Consistent with
At step 2370, FPS 2021 determines whether the FS is acceptable by comparing the success of a financial strategy (SFS) metric with the threshold SFS-TH defined at step 2245 of
In the BFPS described above, FS acceptability requires a specified acceptability likelihood at each priority level, that is, the user specifies a vector of FS acceptability thresholds Acceptability p, p=1 . . . P. In this MBPFS, instead of a vector of FS acceptability thresholds, the user specifies one FS success threshold SF S-TH and goal success likelihood weights for each priority level, SWeight_p, p=1 . . . P. In other embodiments, FS acceptability is determined differently. Step 2370 is a test that automatically determines acceptability of the FS. If the FS is not acceptable, processing continues at step 2375. If the FS is acceptable, processing continues at step 2380.
General acceptability can be defined as a grand function of all information generated during the simulation, a “general utility function” GU(*). SFS is a particular embodiment of GU. Other possible embodiments include for example value-weighted SFS, which also incorporates the value of the goals and not only their success likelihoods GSL (an example of which is shown later in the Wellness Score discussion). Yet another embodiment may be related to a notion of expected path-wise utility PU(n) set equal to aggregate consumption achieved along a given simulation path, averaged over all Monte Carlo paths.
Step 2372, occurring after the FS is determined, for providing a personal research interface, is similar to step 2299 of
The personal research interface is typically an interactive graphical user interface (GUI) that presents a start page with a menu such as in Table 13.
Other than the first five menu items that function as described with respect to step 1450 of
In some embodiments, the “More data structure” and “Your financial strategy set-up information” is also available in the General Research GUI of step 2299 of
In embodiments of
Dual Goal Sensitivity Analysis will now be discussed.
A dual goal sensitivity analysis report is a chart that shows the likelihood of achieving two goals, as one variable for each of the goals is varied. For instance, one goal may be retirement, with the varied value being the age of the individual at which retirement begins, and the other goal may be a product purchase, with the varied value being the cost of the purchase given a particular purchase date, as shown in
Table 14 shows metacode for generating a dual goal sensitivity analysis report. This metacode is repeatedly executed, once for each sensitivity analysis report that the user desires.
At lines 1-3, the user specifies the goal that the user wishes to see plotted on the x-axis of the sensitivity analysis report, along with the goal parameter that is to be varied and the range of variation, XP1 to XPN, and possibly the units (e.g., calendar year or age of user), and then specifies fixed parameters for the goal. Typically, the specification is done via drop-down menus populated based on the user's profile.
At lines 4-6, the user specifies the goal that the user wishes to see plotted on the y-axis of the sensitivity analysis report, the parameter that is to be varied and the range of variation, YP1 to YPN, and possibly the units (e.g., calendar year or age of user), and then specifies fixed parameters for the goal. Typically, the specification is done via drop-down menus populated based on the user's profile.
At line 7, the benchmark FPS displays a chart showing the axes as specified by the user with the ranges set forth, but with no values in the cells defined by the ranges.
At lines 8-11, for each cell, that is for the abscissa goal XG_i=XP1 to XPN and for the ordinate goal YG_i=YP1 to YPN, the financial planning system executes steps 2320-2360 of
At line 12, the benchmark FPS saves the calculated cell value: the likelihood of achieving the goals at the parameter values XG_i and YG_i.
At line 13, the benchmark FPS uses the saved likelihoods to make the requested sensitivity analysis report.
The user then can save this chart, and if desired, create another chart.
In some embodiments, FPS 2021 automatically selects the best goals to tweak and prepares sensitivity analyses for these goals. The actual goal adjustment is done by the user at step 2375.
To automatically adjust goals that are “underachieving” and “overachieving” relative to acceptability of a financial scenario, a goal-value-weighted metric called a “Wellness Score” is defined. The components of the Wellness Score, by goal, are examined to see which are below average (underachieving) and which are above average (overachieving). By reducing the value of the overachieving goal, and increasing the value of the underachieving goal, the Wellness Score is improved.
First, define the Wellness Score, WScore, and the Wellness Score Contribution, WScoreC_i. Let
the Wellness Score Contribution, WScoreC_i, of the ith goal, g_i, i=1 . . . G, is defined as in Equation 26:
Next, for each priority level, average the WScoreC_i for that priority level to give the Wellness Level Average, WScoreLA_p, p=1 P, where P is the number of priority levels for which the user has defined goals, as in Equation 27:
The Wellness Difference, WDiff_i, deficiency or surplus, between the Wellness Score Contribution of the goal and the average for the priority level is WDiff_i=WScoreC_i=WScoreLA_p. If WDiff_i is negative, the value of the goal should be reduced, and if WDiff_i is positive, the value of the goal should be increased, to result in an improved Wellness Score.
Adjusting the goal values is easiest to understand if the sum of the goal values at a priority level remains constant.
Table 15 shows an example of Wellness Score computation, for a user with nine goals, three at each priority level. The Wellness Score is initially 0.666, but after adjusting goal values as below, the Wellness Score becomes 0.693, see Table 16, an improvement of 0.027.
For priority level “High”, the first goal is underachieving (WScoreC_i 0.10<WScoreLA_p 0.17) while the third goal is the most overachieving (WScoreC_i 0.22>WScoreLA_p 0.17). The Wellness Score will improve if the value of the overachieving third goal is reduced, and the underachieving first goal is increased. For this example, change the high priority goal values ($000) from (100 200 300) to (300 200 100).
For priority level “Medium”, the fifth goal is underachieving (WScoreC_i 0.02<WScoreLA_p 0.04) while the fourth goal is overachieving (WScoreC_i 0.05>WScoreLA_p 0.04). The Wellness Score will improve if the value of the overachieving fourth goal is reduced, and the underachieving fifth goal is increased. For this example, change the medium priority goal values ($000) from (100 50 100) to (50 100 100).
For priority level “Low”, the ninth goal is underachieving while the eighth goal is the overachieving. The Wellness Score will improve if the value of the overachieving eighth goal is reduced, and the underachieving ninth goal is increased. For this example, change the low priority goal values ($000) from (200 300 100) to (200 100 300).
The goals success likelihood Prob(g_k) usually changes when the goal value is changed. However, for this example, assume the goals success likelihood is unchanged. With the changes above, the new Wellness Score amounts are shown in Table 16.
Other metrics can be devised.
Single Goal Sensitivity Analysis will now be discussed.
A single goal sensitivity analysis is simply showing how the goal varies as one of its parameters is varied. When using single goal sensitivity, the objective is usually to improve the given goal's likelihood of achievement, and the sensitivity analysis allows pinpointing the goal parameter that makes this possible.
At step 2380, FPS 2021 checks whether any of the financing offers chosen for the FS have acceptance time constraints, indicated as “Loan(t)” to distinguish from a loan lacking an acceptance time constraint. For instance, a lender may offer a loan at a special rate if the borrower pays something by a first date to lock in the special rate, then uses the loan by a second date. This helps lenders forecast loan demand. If not, processing continues at step 2390, since if no loan has an acceptance time constraint, then loans may be in the user's FS, and loan commitments will occur when the loans are needed.
If a selected loan has an acceptance time constraint, then at step 2382, FPS 2021 prepares information as to how not accepting (committing to) this loan affects the user's FS, specifically, (i) whether there are similar loans but slightly more expensive and devoid of acceptance time constraints that can be easily substituted with no other changes to the user's FS, (ii) whether paying cash instead of accepting financing would affect the user's goal achievement, and (iii) whether not accepting the financing with a time constraint would block the user from achieving a goal
At step 2384, loan commitment processing as shown in
At step 2390, the user's FS has been determined. FPS 2021 stores the FS in one of client database 2024, 2064, 2083.
At step 2392, FPS 2021 stores a reduced (anonymized) form of the FS in reduced database 2025.
Step 2395, applying the financial strategy, is shown in
At step 2515, for each financing scenario af, af=1 . . . AF, determined at
B[n,t,af]=B[n,t−1,af]+INC[t,af]−EXP[t,af]+(1+SUM_k w[n,t−1,k]*SIR[n,t,k])*B[t−1] (equation 28)
Often, loan repayments depend on an interest rate that depends on a market rate, and this market rate is simulated at
At step 2520, FPS 2021 eliminates the scenarios among 1 AF that violate the FS periodic acceptability criteria selected at step 2285 of
At step 2522, FPS 2021 checks whether there are any eligible scenarios. If not, processing continues at step 2570. If so, processing continues at step 2525.
At step 2525, FPS 2021 stores the eligible scenarios
At step 2530, from among the eligible scenarios, FPS 2021 selects the financing scenario, designated as af*,in accordance with the FS scenario-best criteria selected at step 2285 of
At step 2535, FPS 2021 checks whether current estimated wealth B[n,t,af*] exceeds Benchmark_p_s, similar to step 850 of
In this embodiment, the test of “best-ness” (optimality) occurs at step 2530, then the test of minimum acceptability of goal achievement occurs at step 2535. In other embodiments, the sequence of tests is swapped, i.e., the test of minimum acceptability occurs first, then the test of “best-ness” (optimality) occurs second.
At step 2540, FPS 2021 checks whether the selected financing scenario af* corresponds to hypothetical financing. If not, processing continues at step 2560.
If the selected financing scenario af* corresponds to hypothetical financing, at step 2545, FPS 2021 stores the event of hypothetical financing being selected in reduced database 2025, similar to step 1680 of
At step 2550, FPS 2021 reverses any provisional asset liquidation and wealth adjustment made at steps 2575 and 2580.
At step 2555, FPS 2021 picks the next best of the eligible financing scenarios stored at step 2525, and sets af′ to correspond with the next best eligible scenario. Processing continues at step 2535.
At step 2560, FPS 2021 appropriately adjusts the goal, income INC[t], expenses EXP[t] and assets to reflect af*, that is, includes the financing for scenario af* in the user's FS. If an unreversed provisional liquidation occurred, it becomes an actual liquidation at this point.
At step 2565, FPS 2021 marks the financed goal as being committed in the FS, and processing returns to step 2350 of
Note that goal commitment means that the goal has been achieved, whereas loan commitment means merely a bilateral “binding-ness” agreement has occurred.
At step 2570, FPS 2021 has determined that even with the best eligible financing scenario af*, the goal is unattainable. So, FPS 2021 checks whether liquidating assets, as described above with respect to step 850 of
In this embodiment, the FPS attempts to get financing before considering asset liquidation. In other embodiments, the sequence is reversed. In still other embodiments, the user can select the sequence of financing and asset liquidation, sometimes by goal priority.
If no such scenario af** exists, that is, there are no more assets to liquidate, at step 2572 FPS 2021 reverses any provisional liquidation that may have occurred at step 2575 and reverses any wealth adjustment that may have occurred at step 2580, sub-goal evaluation is complete, processing returns to step 2350 of
If a suitable scenario af** exists, that is, there are assets to liquidate, then at step 2575, FPS 2021 provisionally adjusts its data to reflect the corresponding asset liquidation. The liquidation must be provisional, so that in case the financing is hypothetical, the liquidation can be reversed at step 2550.
At step 2580, FPS 2021 adjusts B[n,t−1] to reflect that the asset was liquidated, and processing returns to step 2515. Re-checking the best financing is necessary because the asset liquidation may alter which financing the user qualifies for, that is, at step 2910, there may be more, fewer, or the same number of financing alternatives as in the first iteration of step 2910.
At step 2630, based on the FS and market conditions, FPS 2021 may suggest actions such as rebalancing an investment portfolio, liquidating assets, taking out a loan to finance a goal, making a loan payment, or prepaying a loan. FPS 2021 automatically checks whether loan prepayment is feasible. If a user's income has increased, such as via inheritance, job promotion or investment performance, or expenses have decreased, so that B[n,t−1]—Benchmark>PPAY-TH, where PPAY-TH is defined at
At step 2635, FPS 2021 determines whether to automatically commit to a loan, as shown in
At step 2690, evaluation of a sub-goal in the (p, s) innermost loop is shown in
If a new loan is available, as a result of loan demand curves (see
At step 2705, FPS 2021 checks whether there is financing in the FS. If not, processing is complete. If there is financing, processing proceeds to step 2710.
At step 2830, the loan demand curve from a modified benchmark FPS is superior to the loan demand curve from a modified conventional FPS because more potential customers are included for higher PDR. A modified conventional FPS can detect only existing borrowers as potential customers for a revised or new loan product because of the deterministic nature of a conventional FPS, see
At step 2865, benchmark utility software 2022 provides notification of revised or new financing only to users served by a modified benchmark FPS. These users include already identified borrowers and relevant non-borrowers. The notification is received at step 2395 of
Software 2023 executes only step 2865, for users—only already identified borrowers-served by a modified conventional planning system.
At step S320, lender 2005 can choose a customer creditworthiness characteristic determined by FPS 2021 that changes during the lifetime of the FS, as the user's simulated incomes, expenses, assets, liabilities and wealth change. In this case, the FPS 2021 performs an initial calibration procedure to determine the parameters of the model for predicting changes in creditworthiness and for predicting associated changes in user-specific rate adjustments. This calibration can be done by estimating the current creditworthiness of multiple users and comparing it with lender-estimated user-specific rates adjustments for such users, in a cross-sectional model fitting procedure. After the calibration step is completed, the parameters of the creditworthiness model are saved and used for future estimates and simulations.
The embodiment of
The embodiment of
As used herein and in the claims, “products” means products, services or combinations of products and services, as appropriate.
Step 3000, creating a financing database, is similar to step 1115 of
At step 3005, an administrator for the financial planning system creates a product database identifying different products and their characteristics, such as initial cost, lifetime and annual cost, and manufacturer financing terms. A product can be defined generally, such as “luxury sportscar” or specifically, such as “Ferrari 488 GTB sportscar”. Specifically defined products can experience price improvement through the present financial planning system, as discussed below.
At step 3010, an individual profile is created, similar to step 1120 of
At step 3015, general object goals are defined, similar to step 1125 of
At step 3020, specific product goals are defined using the specific products in the product database, along with the individual's willingness to accept manufacturer and/or third-party financing, in embodiments wherein the user can have a general financing strategy but override it for specific goals. In other embodiments, all goals are subject to the user's general financing strategy.
During operation, at step 3030, a FP or FS is created for the individual based on their profile, general goals, specific goals and related profiles, similar to step 1130 of
At step 3040, the individual may be offered the opportunity to commit to a specific goal with or without a financing commitment, such as via pre-payment or a down-payment. In some embodiments, during set-up, an individual may consent to automatic agreement to products that fit the user's goal criteria. At step 3045, the individual may automatically commit to financing. If the individual commits to product purchase and/or financing, at step 3050, the financial planning system transfers funds and updates the individual's FP or FS. The user, by “pre-purchasing”, helps the purveyor to properly forecast demand for its products. Steps 3045 and 3050 are similar to steps 1140 and 1150 of
When a user creates a FP or FS, it contains information about major purchases the user intends to make, and how much the user intends to spend. The financial planning system can aggregate this information to create a demand curve for its users, and negotiate with purveyors to provide advantages, such as lower prices or additional services, thereby benefitting the users and improving their financial future.
At step 3055, executed periodically, the financial planning system surveys the collection of individual FPs or FSs, and creates product demand curves for different types of products that individuals have in their FPs or FSs. The product demand curves include how many general products are in FPs or FSs, and how many specific products. For example, as shown in
The product demand curves are similar to the loan demand curves in that modified conventional FPSs generate deterministic plans, whereas modified benchmark FPSs generate probabilistic plans, as discussed with respect to
Then, at step 3060, the financial planning system makes the product demand curves available to relevant product providers, so that the product providers can choose to offer better terms to individuals served by the financial planning system. Better terms may mean lower prices, a most favorable price guarantee, cheaper financing, fulfillment priority, or custom versions of a product. The product database, created at step 3005, is then updated, and relevant individuals are notified of the updated product, so at step 3040, they may make or update their purchase commitments.
Real-world effects of the present invention include obtaining price improvement in products and/or financing for system users based on the actions of other system users, and a system that automatically purchases, or makes a pre-payment for, a product and/or a type of financing.
Advantages of the present FPS with automatic product and financing selection—both MCFPS and MBFPS—relative to a conventional financial planning system include the benefits discussed above for financing, plus:
Section 3. Modified Conventional Financial Planning System with Products and Financing
Reduced client database 3177 is similar to reduced client database 1277 of
FPS software 3152, 3162, 3172 is respectively similar to FPS software 1252, 1262, 1272 of
FPS software 3161 also functions to populate supplemental products database 3167 with products offered by supplemental product provider 3168.
Utility program 3176 is similar to utility program 1276 of
Third party product supplier 3190 is a provider, e.g., manufacturer or distributor, of goods. Supplier 3190 indicates products it provides via their characteristics and/or brand names for inclusion in products database 3179. Some suppliers 3190 are willing to provide financing to buyers of their products, and such financing is also indicated by supplier 3190 along with parameters describing acceptable loans and characteristics of acceptable borrowers. Supplier 3190 authorizes FPS software 3152, 3162, 3172 to commit to product loans satisfying its parameterized loans, similar to how lenders 1280 in
Products database 3179 includes registration profiles for suppliers 3190, similar to client profiles, along with the supplier's parameterized descriptions of its offered products and any loans that the supplier is willing to provide to borrowers who meet its lending criteria, as discussed above with respect to third-party financing providers. Via utility program 3176, FPS software 3152, 3162, 3172 uses products database 3179. As used herein and in the claims, a “product” refers to a tangible product or a service from multiple service providers that is sold in similar manner. For example, a home companion service agency may sell four hours daily of companionship for an elderly or injured person as its product.
Supplemental product supplier 3166 is similar to third party product supplier 3190, except that it makes product offers only to customers of FPS software 3161.
Supplemental products database 3167 is similar to products database 3179, except that it is only for storing information from supplemental products suppliers 3166.
Steps 3210-3260 are similar to steps 1310-1360 of
At step 3270, products database 3179 is defined via steps 3272-3278.
At step 3272, a system administrator (not shown) for utility program 3176 defines the product types. Products include investment products, insurance products, banking products, financial services (planning for activity and taxes, management), education services, training services, medical services, child care services, annual child costs, durable goods, vehicle purchases or leases, residences (primary, secondary, investment), high value capital items (furniture), leisure travel and so on. Table 17 shows a sample list of products.
At step 3274, the system administrator for utility program 3176 defines product characteristics, such as description, lifetime in months, and cash flow by month, and also defines relevant reliable ratings databases for the product. The product characteristics are usually drawn from industry schema.
Product characteristics also include complaints about the product/supplier from other users of the present FPS. Typically, the system administrator for utility program 3176 configures the present FPS to produce a complaint alert for the system administrator when complaints exceed a complaints threshold, so the system administrator can decide whether to intervene and/or restrict access of the product/supplier to the present FPS.
In some embodiments, if complaints for a product exceed a threshold, such as more than 6% of buyers file a complaint, the FPS automatically increases the periodic cost (as opposed to initial cost) of the product to reflect poor post-sale performance, akin to a “handyman special” indicating a product appropriate for a user who can do most of their own post-sale support.
In some embodiments, if complaints for a supplier exceed a threshold, the FPS automatically adds a penalty cost to products from that supplier, encouraging buyers to select a competing supplier, and encouraging suppliers to resolve complaints.
As another example of a characteristic, the annual increase (or decrease) in the product's cost may be specified, along with the annual increase (or decrease) in resale value for a purchased product. In one embodiment, as a default, if the resale value is not specified, then the product's value is amortized over the product's lifetime. In some cases, a tax lifetime that differs from an expected lifetime may be specified. Product suppliers 3190 then define specific product instances at step S720 of
For example, for product type 01 Personal Road Vehicle, there may be instances as shown in Table 18. Product instances are associated with product sellers, see
The system administrator for utility program 3176 defines general instances of a product type, such as “01-05 Luxury Sportscar”.
Each product type has parameters. In many industries, there are already standardized data schemes for defining product characteristics, such as Financial Information Exchange (FIX) for financial instruments, www.fixtrading.org. Utility program 3176 uses standardized data schemes for product characteristics where possible.
Relevant reliable ratings databases are instances of third-party information services 40, shown in
It will be appreciated that a product demand curve, see step 3948 of
At step 3275, the system administrator for utility program 3176 defines product financing templates, if any, in addition to the financing templates defined at step 3240. For example, if the financing templates from step 3240 are:
At step 3280, supplemental product supplier 3168 defines supplemental products for supplemental products database 3167, in similar manner as third party products suppliers at step 3270 (specifically, steps 3276 and 3278). The definition of product types and characteristics from step 3270 is used at step 3280.
At step 3290, the system administrator for utility program 3176 and/or product supplier 3190 defines hypothetical products for products database 3179.
A hypothetical product is a way of testing market acceptance of a new product. Generally, a hypothetical product offer is the same as a non-hypothetical product offer, except that the hypothetical product offer includes a field showing it is hypothetical. As explained below, if the FPS would have selected the hypothetical product offer, this event is recorded, then the hypothetical product offer is marked as temporarily ineligible, forcing the FPS to choose a non-hypothetical product offer for the financial plan. The event of selecting the hypothetical product offer is stored in reduced database 3177, so that when product demand curves are created, the demand for the hypothetical product can be assessed.
At step 3307, the user selects product characteristics, as shown in detail in
At step 3308, if the user has purchased a product via the present FPS and has an unresolved problem, the user can file a complaint about the product, visible to other users at step 3350 and possibly to the system administrator at
At step 3350, the general research interface also provides a user-friendly way to browse the contents of product database 3179, as shown in Table 19.
Other than the first five menu items that function as described with respect to step 1450 of
At step 3405, FPS software 3152, 3162, 3172 begins with the first goal defined by the user at step 3305 of
At step 3407, FPS software 3152, 3162, 3172 asks the user if the goal is for a product (or service) in products database 3179. If not, At step 3425, FPS software 3152, 3162, 3172
At step 3410, the user associates goal g with a product type PTi selected from products database 3179.
At step 3415, the user specifies product characteristics for the product type selected at step 3410. There are usually multiple ways of specifying product characteristics, e.g., via a menu, via choosing a product offered in products database 3179 so that its characteristics are used as the specified characteristics, or via a combination thereof. A brand name can be a product characteristic. As mentioned above, product characteristics are usually defined by industry data schema. At this step, the user can:
At step 3420, based on the user-specified characteristics from step 3415, FPS software 3152, 3162, 3172 selects all products in products database 3179 that meet the user's characteristics. The user can edit the set of products, such as by removing or adding products. The user finds products outside of his/her specified characteristics using a General Research interactive interface, discussed at step 3350 of
At step 3425, FPS software 3152, 3162, 3172 checks whether there are any products in the set of selected products. For example, the user may dislike the specific product offers in products database 3179, and prefer to retain only a generic goal g. If there are no products, processing continues at step 3455.
At step 3430, FPS software 3152, 3162, 3172 stores the product scenarios for this goal. The product scenarios are the set of products remaining after step 3420. The generic goal is retained if its value differs from the product values.
At step 3435, if the user wishes to augment the financing templates selected at step 3330 of
At step 3440, the user specifies whether s/he opts into automatic purchase approval, on a goal-by-goal basis or for all goals.
At step 3445, the user specifies whether s/he opts into automatic new product replacement, for existing products and/or end-of-life products.
Automatic product replacement can change an existing product. As product suppliers 3190 offer upgraded and new products that satisfy the goal product characteristics specified by the user, FPS software 3152, 3162, 3172 can be pre-authorized to automatically decide what to do with such offers. If a user has committed to purchase a product, and then changes their mind, the product supplier may charge a cancellation fee, such as 20% of the product's cost. Automatic product replacement can replace a product at the end of its life. The original goal is automatically re-instated after the product's end-of-life, at t=PTi_LIFE+1 (see step 3274 of
At step 3455, FPS software 3152, 3162, 3172 increments g, to choose the next goal defined by the user at step 3305 of
At step 3460, FPS software 3152, 3162, 3172 checks whether the new value of g exceeds the number of user goals defined at step 3305 of
At step 3530, FPS software 3152, 3162, 3172 determines all the possible combinations of goals-products and financing relevant to this user by searching products database 3179. This is similar to step 1530 of
At step 3535, FPS software 3152, 3162, 3172 determines an Iteration Plan, as shown in
Step 3540 is a test that manually determines acceptability.
At step 3545, if no acceptable financial plan has been found, one of the things that the user can revise is his/her specification of product characteristics.
When there is a new loan offer or a new product offer, as indicated by the AA and BB circles (see
At step 3560, FPS software 3152, 3162, 3172 determines whether to commit to a purchase, as shown in
At step 3580, FPS software 3152, 3162, 3172 determines whether to commit to a loan, as shown in
At step 3605, FPS software 3152, 3162, 3172 begins cycling through combination goal-product/financing scenarios, not merely financing scenarios as in
Step 3630 is a test that automatically determines whether an iteration plan corresponding to a goal-product financing scenario is minimally acceptable.
Step 3670 is a test that automatically determines which iteration plan, corresponding to a respective goal-product financing scenario, is best.
At step 3675, FPS software 3152, 3162, 3172 checks whether the selected eligible Iteration Plan includes either a hypothetical product or a hypothetical loan. If so, processing continues at step 3680.
At step 3710, software 3152, 3162, 3172 checks whether the user has authorized automatic product purchase commitment for a financial plan being prepared, or has authorized automatic product replacement for a revised or new product offer. If no, processing continues at step 3725.
If the user has authorized automated product purchase commitment for a financial plan being prepared, or has authorized automatic product replacement for a revised or new product offer, at step 3720, software 3152, 3162, 3172 sends product purchase commitments to the appropriate product suppliers, send cancellations for automatically replaced products, and processing is complete.
If the user has not authorized automated product purchase commitment, at step 1325, software 3152, 3162, 3172 asks the user if s/he wishes to commit to a selected product purchase, and receives the user's response.
At step 3730, software 1252, 1262, 1272 checks whether the user has approved committing to the product purchase. If not, processing is complete. If the user has approved, processing proceeds to step 3720.
At step 3820, it will be appreciated that the lender may be a product supplier offering financing for their product.
At step 3944, for each type of product, as defined at step 3272 of
At step 3950, utility program 3176 sends the various types of product demand curves to those of product suppliers 3190 that either offer this type of loan, or have indicated interest in offering this type of loan.
If an entity offering supplemental products wishes to see the product demand curves for third-party products, it must register as an instance of product supplier 3190 and indicate interest in offering this type of product.
At step 3952, the appropriate ones of product supplier 3190 receive the product demand curve.
At step 3954, each product supplier 3190 decides whether to offer revised or new products based on the product demand curve.
At step 3956, if product supplier 3190 has decided to offer a revised or new product, product supplier 3190 sends the product terms to utility program 3176.
At step 3958, utility program 3176 receives the revised and new products, if any.
At step 3960, utility program 3176 updates products database 3178 with the revised or new products.
At step 3962, utility program 3176 notifies the software, selected from software 3152, 3162, 3172, associated with the relevant financial plans, i.e., the financial plans retrieved at step 3944, of the revised or new product terms.
At step 1870, utility program 3176 sets the timer t elapsed to zero, and processing returns to step 3910.
In some embodiments, software 3162 executes steps 3910, 3944, 3954, 3960, 3962, 3970 for the financial plans in client database 3163, to produce supplemental product demand curves for its customers. These supplemental product demand curves are proprietary to the owner of FPS 3160.
At step S700, product supplier 3190 provides account set-up information appropriate for a product supplier.
At step S720, product supplier 3190 populates products database 3179 with instances of products that it wishes to offer to financial plan users. As mentioned, product characteristics usually comply with an industry standard data scheme for the product.
Also at step S720, supplier 3190 defines the cashflow for its product, such as costs of an annual maintenance contract and/or cost of consumables.
At step S720, if there are any timing restrictions for this product offer, they are defined, such as “purchase by date-1, accept delivery by date-2”.
Further at step S720, supplier defines any financing it is willing to offer only to purchasers of this product, in similar manner as loan offers are defined at step S120 of
Section 4. Modified Benchmark Financial Planning System with Products and Financing
Reduced client database 4025 is similar to reduced client database 2025 of
Products database 4028 is similar to products database 3179 of
The objects in objects database 4026 represent general goals, such as “luxury sports car”, while the products in products database 4028 represent specific goals—products and services—instances of objects, such as “Ferrari 488 GTB sports car”.
Third party product supplier 4015 is similar to third party product supplier 3190 of
Supplemental product supplier 4088 is similar to supplemental product supplier 3166 of
Supplemental products database 4087 is similar to supplemental products database 3167 of
Financial planning systems 4050, 4060, 4080 and benchmark program 4021 are respectively similar to financial planning systems 2050, 2060, 2080 and benchmark program 2021 of
FPS software 4081 also functions to populate supplemental products database 4087 with products offered by supplemental product provider 4088.
Utility program 4023 is similar to utility program 2023 of
Step 4140, define products database, is similar to step 3270 of
Step 4150, define available product financing templates, is similar to step 3275 of
At step 4150, product financing acceptability criteria are defined by the system administrator for utility program 3176, such as:
Step 4155, define available scenario-best criteria, is similar to step 2150 of
Step 4160, define supplemental product, is similar to step 3280 of
Step 4180, define hypothetical product, is similar to step 3290 of
Step 4232, user selects product characteristics, is shown in
Step 4233, user files product complaint, is similar to
Step 4299 is similar to step 2499 of
At step 4315, one of the characteristics that the user can specify is whether the FS should evaluate the product at its present cost or its future cost. If a product's cost seems to increase as prices increase generally, then future value is a good choice. However, if a product's price does not increase over time, or possibly drops over time, then present value is a good choice.
At step 4330, the product scenarios for this goal are the selected products from step 4320, and the ones of the sub-goals (if any), defined at step 4230 of
At step 4420, the benchmark is determined as shown in
At step 4445, FPS 4050, 4060, 4080 or benchmark FPS program 4021 (collectively, “FPS 4021”) determines the goal-product financing scenarios based on the product scenarios created at step 4330 of
At step 4455, the sub-goals are evaluated as shown in
Step 4465 is a test that manually or automatically determines acceptability.
Step 4470, occurring after the financial strategy is tentatively determined (before it is tested for acceptability at step 4465), for providing a personal research interface, is similar to step 2372 of
The personal research interface is typically a graphical user interface (GUI) that presents a start page with a menu such as in Table 20.
Other than the first five menu items that function as described with respect to step 1450 of
In embodiments of
A first example of a product financing comparison report is now presented. Assume the product is a car. Table 21 shows a report comparing various forms of purchase financing, such as cash purchase (no financing needed), lease instead of buy with low or high down payment, purchase financed by longer term asset backed loan with low or high down payment, and finally, an option to take out a home equity loan (HELOC) and use it for payment for the car purchase.
A second example of a product financing comparison report is now presented. Assume the product is a college education for the user's child. Table 22 shows a report comparing various forms of purchase financing, including the parent taking a personal unsecured loan, the parent taking a home equity loan, and a child participating by taking a student loan.
At step 4480, FPS 4021 checks whether any of the product offers or any of the financing offers chosen for the FS have acceptance time constraints, indicated as “Purchase(t)” and “Loan(t)”. For instance, a product supplier may offer a product at a special price if the purchaser pays something by a first date to lock in the special price, then pays the remainder by a second date. This helps product suppliers forecast product demand. If not, processing continues at step 4490.
If a selected product or a selected loan has an acceptance time constraint, then at step 4482, the benchmark FPS prepares alternative information, so that the user can see the effect on his/her FS of not immediately committing to the product or loan with time constraints.
At step 4484, purchase commitment processing as shown in
Since purchasing a product or accepting a loan changes the user's situation, at step 4486, the FS is updated. If a product or loan commitment does not occur at step 4484, then step 4486 is skipped.
At step 4490, the user's FS is determined.
If a relevant new product offer or loan offer occurs, see
At step 4495, the financial strategy is applied as shown in
Step 4630 is a test that automatically determines which goal-product financing scenario is best.
Step 4635 is a test that automatically determines whether a goal-product financing scenario is minimally acceptable.
At step 4640, the benchmark FPS checks whether the product or the financing is hypothetical.
At step 4705, the benchmark FPS checks whether there is a product offer that can be committed to, in the FS, and whether the product supplier has opted into automatic purchase approval. If yes, processing proceeds to step 4710. If no, processing is complete, as there is nothing to commit to.
At step 4830, the actions that the benchmark FPS suggest to the user may include purchasing a product and/or taking out a loan.
At step 4832, FPS 4021 determines whether to automatically commit to a purchase, as shown in
At step 4835, the benchmark FPS determines whether to automatically commit to a loan, as shown in
At step 2690, evaluation of a sub-goal in the (p, s) innermost loop is shown in
Step S044 is performed for each product type PTi defined at step 4140 of
At step S046, all reduced FSs with the product type are retrieved from reduced client database 4025.
At step S048, the product demand curve is created based on the information retrieved at step S046.
An actual financial plan is typically about 50 pages long, and is thus too voluminous to provide as a use case. For brevity, the following use cases are greatly abridged. All of the use cases assume two similar starting goals, so that the FPS results can be readily compared.
Assume that, at step 205 of
Based on the user's assets, income and simulations of investment performance, the FPS creates a FP to achieve the user's goals, as shown in
Assume that, at step 730 of
Based on the user's assets, income and simulated investment performance, as shown in
Compared to the FP of Table 24, the FS of Table 27 includes liquidatable assets, priority levels, acceptability thresholds by priority levels, goal priority levels, a goal (retirement) start date expressed as a range, a goal (car) value expressed as a range, subgoals for goal parameters with ranges, goals success likelihood by subgoal, benchmark curves by priority levels, and the ability to have multiple investment strategies (only one strategy is shown in this FS).
An excerpt of an exemplary benchmark financial strategy report is shown in Table 28, and an example of periodic advice is shown in Table 29. The periodic advice is generated at
Comparing goal results between the Conventional FPS and the Benchmark FPS, it is seen that the Benchmark FPS results are more helpful because, when the user has flexibility in the timing and cost of a goal, the BFPS can show the user the value of such flexibility with respect to achieving their goals. Given the range of success likelihoods shown by a BFPS, the user is likely to better understand that their actions impact their financial futures, and so be more motivated to act responsibly over the long term.
Turning to the MCFPS of
Also assume that information provided during user set-up is as in Tables 31 and 32.
For lines 6 and 7 of Table 28, it will be understood that the user provides actual values for her expected future income and expenses at each time period, but for brevity of this use case, the values are indicated as INC[t] and EXP[t].
At the start of operation, see
At
At
First, based on the user's selected financing templates (see Table 28, line 10), software 1262 determines there are at least five financing scenarios involving cash only (always evaluated) and private financing:
At this point, all the financing offers in Table 27 are available for consideration. In practice, many more financing offers are available. Since there is one instance of private financing (Aunt Agatha), one instance of supplemental financing (Atlantis Bank) and two instances of third party financing (Yoyo Bank and Zebra Bank), software 1262 determines that there are seven financing scenarios:
Next, for each financing offer, software 1262 checks whether the user meets the lender's criteria.
Private lender Aunt Agatha merely requires acceptance by Mar. 21, 2022. This is before the user wants to buy the car, but since Agatha does not require a security interest, the user can accept Agatha's offer and just use Agatha's money as an investment until it is needed for the car. So, if the user accepts Agatha's maximum offer of $10,000, as of the first planning period t=1=3/1/2021, there will be immediate income INC[t=1]=10,000, no interest payments, and a balloon principal payment in ten years EXP[t=120]=10,000.
Supplemental lender Atlantis Bank requires a security interest, so the loan must occur as of when the car is purchased in three years. Assuming use of the maximum offer for its maximum duration of 5 years, there will be income INC[t=36]=20,000, EXP[t=36 . . . 96]=20,000*(Prime+1%), and a balloon payment EXP[t=96]=20,000. Atlantis will lend up to 80% of the car's value (Table 27, line 8); since the car's value is $50,000, and 20,000<0.8*50,000, the maximum loan amount is eligible.
However, Atlantis requires a maximum PDR of 5% (Table 27 line 16). The user has specified PDR-Threshold=12% (see Table 28, line 11). So that the user meets Atlantis's criteria, software 1262 changes PDR-Threshold to 5% when supplemental financing from Atlantis is used. This is an example of a user's risk tolerance being affected by a lender.
Third party lender Yoyo Bank requires a security interest, so the loan must occur as of when the car is purchased in three years and is willing to lend for 5 years (Table 27, line 10). Yoyo is willing to lend up to $50,000 (Table 27, line 6) but no more than 80% of the item's value (Table 27, line 8)=0.8*$50,000=$40,000. When the user uses Yoyo's offer, the user is getting money from Agatha ($10,000) and possibly Atlantis ($20,000), so the user will rely on Yoyo for $40,000 (car value−Agatha loan) or $20,000 (car value—Agatha loan—Atlantis loan). The user will have income from Yoyo in month 36, and amortize the loan amount over 60 payments using an interest rate of Prime+4%.
Yoyo requires that its repayments not exceed 30% of the borrower's income. At this point, software 1262 can estimate whether the Yoyo payments will exceed the user's expected income INC[t], such as from salary, and investment income during t=36 . . . 96. Checking again after the draft FP has estimated investment income via simulations is prudent.
Yoyo requires a maximum PDR of 10% (Table 27 line 16). The user has specified PDR-Threshold=12% (see Table 28, line 11). So that the user meets Yoyo's criteria, software 1262 changes PDR-Threshold to 10% when third party financing from Yoyo is used. If supplemental financing from Atlantis is being used, then software 1262 will have changed PDR-Threshold to 5%, and that is well within Yoyo's criteria.
Similar analysis applies for Zebra Bank's loan offer.
At this point, software 1262 lacks reason to eliminate any of the seven financing scenarios, so it maintains all of them.
At
Turning to
In some embodiments, software 1262 automatically provides default investment weights that weight investments equally, i.e., for K investments, each w1[k]=1/K. The user can manually override the defaults. Usually, software 1262 automatically requires that SUM(wI[k])=1, k=1 . . . K.
At step 1610, before evaluating each of the financing scenarios at step 1620, software 1262 adjusts the goals to reflect financing in that scenario. In accordance with the above discussion, Table 33 shows the goal adjustments for the financing scenarios.
For example, Table 33 shows that for the seventh financing scenario FS 7, using private financing from Aunt Agatha, supplemental financing from Atlantis Bank, and third party financing from Zebra Bank, the adjusted goal of the car corresponds to income of $10,000 at t=1 when Aunt Agatha's loan is accepted, and spending of $10,000 at t=36 when the car is purchased. So, the user does not have to dig into her savings to buy the $50,000 car at t=36.
However, during t=36 . . . 96, the user has monthly expenses of $1,000 for the car plus AA=$20,000*(monthly Prime+1%) for paying interest-only on the Atlantis loan plus EE=amortization of $20,000 from Zebra Bank at (monthly Prime+3%) interest over 84 months.
At t=96, the user must make a balloon payment to Atlantis Bank of $20,000.
During t=97 . . . 120, the user has monthly expenses of $1,000 for the car plus EE amortization payments to Zebra Bank.
At t=120, the user must make a balloon payment to Aunt Agatha of $10,000.
During t=121 . . . 156, the user has no monthly car loan payments, and just has monthly car expenses of $1,000. At t=156, the car is at the end of its life and must be replaced, or the user must use public and/or private transportation services and forego the convenience of having her own car.
Finally, because supplemental financing from Atlantis Bank is being used in the seventh financing scenario, the user is forced into a maximum PDR-Threshold of 5%.
Prior to creating a draft FP, software 1262 converts the parameter-based expressions to actual values, such as by estimating the monthly Prime rate at the start of financing, or perhaps using the current monthly Prime rate as an estimation. Then, software 1262 estimates whether the maximum percent of borrower monthly income criteria for Yoyo Bank and Zebra Bank (see Table 29 line 15) are met based on the user's expected income and its estimate of investment performance. Assume that these criteria are met.
At
At
At
In the third financing scenario, the supplemental financing from Atlantis helps, but still results in a high PDR.
The draft FPs for the fourth to seventh financing scenarios each include sufficient financing so that the user does not have to dig into her meagre savings to buy the $50,000 car at t=36, resulting in PDRs under 10%.
But, the draft FPs for the sixth and seventh financing scenarios, relying on financing from Atlantis Bank, flunk the financial plan acceptability criteria, because the simulated PDR is greater than the acceptable PDR of 5%. In other words, to use the Atlantis financing, the user cannot take sufficient investment risk to achieve her retirement goal.
At
Returning to
At
Comparing the first and third use cases, it will be seen that that goal success likelihood for retirement has slightly dropped from 88% to 86%, but the goal success likelihood for the car purchase has increased from 65% to a whopping 99%, showing that FPs with higher success in achieving near-term goals result from automatically considering financing.
Turning to the MBFPS of
Since the financing templates chosen in Table 37 are the same as those in Table 31, the same seven financing scenarios are present at
Table 38 shows an excerpt of the MBFPS FS Report for the FS determined at
Turning now to the MCFPS of
Further, assume that two third-party financing providers, Yoyo Bank and Zebra Bank, have offered to lend purchase money for a car, along with the two financing offers from Aleph Car Co. for its Scoop car. Also assume that the user's Aunt Agatha has offered, to the user, a ten year zero interest loan of $10,000 with no payments until a balloon payment at the end of the loan, for anything that s/he wishes to buy, and that Aunt Agatha wants to user to accept or decline Agatha's loan offer by Mar. 21, 2022. These five financing offers are shown in Table 41.
Assume user goals are as specified in the first use case. Also assume that the user has specified certain parameters for automated product and financing selection as shown in Table 42.
At
At step 3530 of
At
At step 3670 of
If the user lacked sufficient cash for the car purchase, the difference of $30,000 between the car cost of $40,000 and Aunt Agatha's $10,000 loan, then the MCFPS would have selected the best combined financing (lowest lifetime interest payments), TPFOffer-1 and UFOffer-1, in the iteration plan for 17th goal-product financing scenario. In particular, TPFOffer-1 includes interest payments of Prime+4% for 60 months, versus TPFOffer-2 includes interest payments of Prime+3% for 84 months, so TPFOffer-1 likely provides for lowest lifetime interest payments (depends on what Prime interest rate turns out to be during the loan term).
Table 44 is an excerpt of a financial plan for this use case.
Assume the same product and financing offers as in the fifth use case above.
Assume user goals are as specified in the second use case. Also assume that the user has specified certain parameters for automated product and financing selection as shown in Table 46. The acceptability threshold for goals success likelihood, SFS-TH and SWeightpriority, is discussed at step 2245 of
Constructing a FS begins at
At step 4420 of
At step 4430 of
At step 4440 of
At step 4445 of
In this example, as in the third use case, there are three products that meet the user's requirements: Ultex, Scoop and Ohm cars, determined at step 4320 of
Assume financing offers as in the third use case: a private financing offer from Aunt Agatha, defined at step 4275 of
In a realistic situation, available products would not correspond so precisely to subgoals, so the MBFPS would maintain the original sub-goal for a scenario, and also evaluate the available products in separate scenarios. For instance, if the suitable financing offers in the financing database were for a $25,000 Acmi car and a $35,000 Luxura car, then the MBFPS would create five scenarios for:
The result is the goal-product financing scenarios shown in the third use case above.
At
At step 4620, the scenario is eliminated if it violates the user's periodic criteria. In this example, the periodic criteria are that the user wants to save at least $1,000 per month. Committing to a sub-goal that interferes with savings is not permitted.
Assume that the three all cash (no financing) product financing scenarios block the user from saving at least $1,000 per month. The MBFPS eliminates scenarios 1, 2, 3 at step 4620.
Also assume that the only scenario that permits saving $1,000 monthly when relying only on Aunt Agatha's financing is for the cheapest Ultex car. The MBFPS eliminates the scenarios for Scoop with only Aunt Agatha financing, and for Ohm with only Aunt Agatha financing at step 4620.
At step 4622, the remaining eligible scenarios are stored in client database 4024, 4055, 4064, 4083 when the MBFPS is FPS 4020, 4050, 4060, 4080, respectively.
At step 4630, according to the scenario-best criteria chosen by the user, the MBFPS picks the scenario with the highest B[n,t,af] as the af* scenario (see step 2530 of
At step 4635, the MBFPS checks whether the user's estimated wealth for month 36, assuming the af′ scenario, exceeds the benchmark curve for month 36. Assume so in all cases.
At step 4660, the MBFPS adjusts parameters for this scenario, and at step 4665 commits to this sub-goal.
Returning to
At step 4465, the MBFPS automatically evaluates the success of the FS and determines if it is acceptable according to the acceptability threshold for goals success likelihood provided by the user. Here, SFS=(SWeight_high*(success likelihood of car purchase))+(SWeight medium*(success likelihood of retirement))=(0.6*0.99)+(0.4*0.97)=0.594+0.388=0.982=98.2%. The user specified SFS-Th=90%. Since SFS 98.2%>SFS-Th 90%, this FS is acceptable.
At step 4480, the MBFPS determines that Aunt Agatha's loan has an accept-by timing restriction, so at step 4484, the user commits to Aunt Agatha's loan. At step 4486, the MBFPS updates the FS to show the user has an additional $10,000 in cash, and also has an obligation to make a payment of $10,000 to Aunt Agatha in 120 months. The $10,000 is automatically invested until it is needed for purchasing the Ultex car.
At step 4490, the MBFPS stores the FS in the appropriate one of client databases 4024, 4055, 4064, 4083, and the MBFPS converts the FS to a reduced (anonymized) FS and sends it to benchmark utility program 4022 for storage in reduced database 4025.
At step 4495, the MBFPS applies the FS, so that when the user has approved automatic purchases and there have been no changes in the market environment or user's situation, at month 36, an Ultex car will be automatically purchased by the MBFPS on behalf of the user, using Aunt Agatha's $10,000 loan, a $17,000 loan from Zebra Bank and $3,000 from sale of appropriate quantity of the user's investments.
Based on this FS, an exemplary goals results report is shown in Table 47. Note that the PDR during the term of each loan is presented separately from the lifetime PDR. This report is available at step 4470 of
Although illustrative embodiments of the present invention, and various modifications thereof, have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to these precise embodiments and the described modifications, and that various changes and further modifications may be effected therein by one skilled in the art without departing from the scope or spirit of the invention as defined in the appended claims.
This application is a continuation in part of U.S. patent application Ser. No. 15/960,637, filed Apr. 24, 2018, and claims priority to U.S. provisional patent application Ser. No. 62/878,782, filed Jul. 26, 2019, having common inventors herewith, and a common assignee herewith, the disclosure of which is hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62878782 | Jul 2019 | US | |
| 62547786 | Aug 2017 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15960637 | Apr 2018 | US |
| Child | 16731021 | US |
