Patent Application
20160247229
In general, embodiments of the invention relate to retirement planning. In particular, embodiments of the invention relate to a framework to provide an assessment of the impact that using certain funds from different financial accounts may have on retirement planning.
Retirement planning, in a financial context, refers to the allocation of savings or revenue for retirement in an attempt to achieve financial independence, so that the need to be gainfully employed is optional rather than a necessity. Most retirement planning models provide a target sum that the user should save before retirement, but fail to consider the impact of using funds from different accounts to be incorporated into retirement planning.
Embodiments of the present invention address the above needs and/or achieve other advantages by providing apparatuses (e.g., a system, computer program product, and/or other device) and methods for a system for assessing an impact of using funds from different accounts to pay for financial events in retirement planning for a user. The system is configured to receive information associated with a group of accounts, electronically monitor the information, initiate presentation of a spend user interface to the user, receive a user selection of a financial event, calculate a financial event cost, determine one or more payment disbursement accounts from the group of accounts, calculate a payment disbursement ratio, and electronically present the payment disbursement ratio to the user. The present invention enables a user to plan for payment of a suspected or hypothetical financial event by determining which accounts owned by the user should be used, and by calculating the amount of funds from each account to be used in payment, so as to optimize the remaining funds for retirement planning. In this regard, the user may be able to select one or more events and customize the event to determine the effect of the one or more events on user's current financial situation. In doing so, the user may keep track of, or test, the payment and retirement scenario specifics in real-time.
In some embodiments of the invention, a system for assessing an impact of using funds from different accounts to pay for financial events in retirement planning for a user is provided. In some embodiments, the system comprises at least one non-transitory storage device, at least one processor, and at least one module stored in said storage device and comprising instruction code that is executable by the at least one processor and configured to cause said at least one processor to receive information associated with a group of accounts, wherein the group of accounts comprises accounts associated with a user, and wherein the information comprises a type of account and an amount of funds in the account. In some embodiments, the module is configured to calculate an amount of spendable funds associated with the user for a time period, wherein the amount of spendable funds is calculated based on the amount of funds in the group of accounts, the amount of outgoing funds, and the amount of incoming funds for the time period. In some embodiments, the module is configured to calculate an estimated amount of time associated with an availability of the amount of funds in the group of accounts based on at least the amount of spendable funds and the amount of funds in the group of accounts. Furthermore, in some embodiments, the module may be configured to initiate presentation of a spend user interface to the user, wherein the spend user interface is provided on a user device and comprises at least selectable financial event options for one or more financial events that could occur for the user. The module also may be configured to receive, via the spend user interface, a user selection of a financial event. Furthermore, the module may be configured to calculate a financial event cost, wherein the financial event cost is a cost associated with the financial event. The module may then be configured to determine one or more payment disbursement accounts from the group of accounts based on the account information, the financial event, and the financial event cost, wherein the payment disbursement accounts comprise one or more accounts to be used to pay the financial event cost. Additionally, the module may be configured to electronically present, via the spend user interface, the one or more payment disbursement accounts to the user. Furthermore, the module may be configured to calculate a new amount of spendable funds or a new estimated amount of time associated with an availability of the amount of funds in the financial institution accounts based on the financial event cost and the one or more payment disbursement accounts to be used to pay the financial event cost. Finally, the module may be configured to initiate presentation of an updated spend user interface to the user, wherein the updated spend user interface is provided on the user device and comprises the new amount of spendable funds or the new estimated amount of time, the one or more payment disbursement accounts used to cover the one or more payment options, and an amount from the one or more payment disbursement accounts.
In some embodiments of the system, the module is further configured to cause a processor to receive from the user, via the spend user interface, an order to execute a payment plan for the financial event cost, according to the selected payment disbursement ratio. In such an embodiment, the module may be further configured to execute the payment plan, wherein executing the payment plan comprises withdrawing funds from the one or more payment disbursement accounts based on the payment disbursement ratio, and applying the withdrawn funds to the financial event cost.
In some embodiments of the system, the module is further configured to cause a processor to electronically present, via the send user interface, an interactive interface, wherein the interactive interface provides the user with options to adjust aspects of the calculation of the payment disbursement ratio. In such an embodiment, the module may be configured to receive from the user, via the send user interface, an adjustment to the calculation of the payment disbursement ratio. Additionally, the module may be configured to calculate a payment disbursement ratio, wherein the payment disbursement ratio comprises the amount of funds from each payment disbursement account to be used to pay the financial event cost. Finally, the module may be configured to electronically present, via the send user interface, an updated calculation of the payment disbursement ratio in real time.
In some embodiments of the system, the module is configured to electronically monitor the information associated with the group of accounts, wherein the module is further configured to electronically monitor the information associated with the group of accounts in real time.
In some embodiments of the system, the module is configured to calculate a payment disbursement ratio, wherein the module is further configured to calculate the payment disbursement ratio with a tax module, wherein the tax module is configured to assess the tax consequences of using funds from each payment disbursement account.
In some embodiments of the system, the module is configured to calculate a payment disbursement ratio, wherein the module is further configured to calculate the payment disbursement ratio with an interest rate module, wherein the interest rate module is configured to assess the interest rate associated with each payment disbursement account.
In some embodiments of the system, the module is configured to calculate a payment disbursement ratio, wherein the module is further configured to calculate the payment disbursement ratio with an income module, wherein the income module is configured to assess an income of the user, in relation to each payment disbursement account.
In some embodiments of the invention, a computer implemented method for assessing an impact of using funds from different accounts to pay for financial events in retirement planning for a user is provided. The computer implemented method may comprise receiving, using a computing device processor, information associated with a group of accounts, wherein the group of accounts comprises accounts associated with a user, and wherein the information comprises a type of account and an amount of funds available in the account. In some embodiments, the computer implemented method may comprise calculating an amount of spendable funds associated with the user for a time period, wherein the amount of spendable funds is calculated based on the amount of funds in the group of accounts, the amount of outgoing funds, and the amount of incoming funds for the time period. Furthermore, the computer implemented method may comprise calculating an estimated amount of time associated with an availability of the amount of funds in the group of accounts based on at least the amount of spendable funds and the amount of funds in the group of accounts. The computer implemented method also may comprise initiating, using a computing device processor, presentation of a spend user interface to the user, wherein the spend user interface is provided on a user device and comprises at least selectable financial event options for one or more financial events that could occur for the user. In some embodiments, the computer implemented method further comprises receiving, using a computing device processor, a user selection of a financial event. The computer implemented method may then be configured for calculating, using a computing device processor, a financial event cost, wherein the financial event cost is a cost associated with the financial event. Furthermore, the computer implemented method may comprise determining, using a computing device processor, one or more payment disbursement accounts from the group of accounts based on the account information, the financial event, and the financial event cost, wherein the payment disbursement accounts comprise one or more accounts to be used to pay the financial event cost. In some embodiments, the computer implemented method comprises electronically presenting, using a computing device processor, the one or more payment disbursement accounts to the user. Additionally, the computer implemented method may comprise calculating, using a computing device processor, a new amount of spendable funds or a new estimated amount of time associated with an availability of the amount of funds in the financial institution accounts based on the financial event cost and the one or more payment disbursement accounts to be used to pay the financial event cost. Finally, the computer implemented method may comprise initiating, using a computing device processor, presentation of an updated spend user interface to the user, wherein the updated spend user interface is provided on the user device and comprises the new amount of spendable funds or the new estimated amount of time, the one or more payment disbursement accounts used to cover the one or more payment options, and an amount from the one or more payment disbursement accounts.
In some embodiments of the computer implemented method, the computer implemented method comprises receiving from the user, using a computing device processor, an order to execute a payment plan for the financial event cost, according to the selected payment disbursement ratio. In such an embodiment, the computer implemented method may further comprise executing, using a computing device processor, the payment plan, wherein executing the payment plan comprises withdrawing funds from the one or more payment disbursement accounts based on the payment disbursement ratio, and applying the withdrawn funds to the financial event cost.
In some embodiments of the computer implemented method, the computer implemented method comprises electronically presenting, using a computing device processor, via an interactive interface, wherein the interactive interface provides the user with options to adjust aspects of the calculation of the payment disbursement ratio. Such a computer implemented method may further comprise receiving from the user, using a computing device processor, an adjustment to the calculation of the payment disbursement ratio. Additionally, the computer implemented method may comprise calculating, using a computing device processor, a payment disbursement ratio, wherein the payment disbursement ratio comprises the amount of funds from each payment disbursement account to be used to pay the financial event cost. Finally, the computer implemented method may comprise electronically presenting, using a computing device processor, an updated calculation of the payment disbursement ratio in real time.
In some embodiments, the computer implemented method comprising electronically monitoring further comprises electronically monitoring, using a computing device processor, the information associated with the group of accounts in real time.
In some embodiments, the computer implemented method comprising calculating the payment disbursement ratio further comprises calculating, using a computing device processor, the payment disbursement ratio with a tax module, wherein the tax module is configured to assess the tax consequences of using funds from each payment disbursement account.
In some embodiments, the computer implemented method comprising calculating the payment disbursement ratio further comprises calculating, using a computing device processor, the payment disbursement ratio with an interest rate module, wherein the interest rate module is configured to assess the interest rate associated with each payment disbursement account.
In some embodiments, the computer implemented method comprising calculating the payment disbursement ratio further comprises calculating, using a computing device processor, the payment disbursement ratio with an income module, wherein the income module is configured to assess the income of the user, in relation to each payment disbursement account.
In some embodiments of the invention, a computer program product for assessing an impact of using funds from different accounts to pay for financial events in retirement planning for a user is provided. The computer program product may comprise a non-transitory computer-readable medium comprising computer readable instructions, the instructions comprising instructions for receiving information associated with a group of accounts, wherein the group of accounts comprises accounts associated with a user, and wherein the information comprises a type of account and an amount of funds in the account. In some embodiments, the computer program product comprises calculating an amount of spendable funds associated with the user for a time period, wherein the amount of spendable funds is calculated based on the amount of funds in the group of accounts, the amount of outgoing funds, and the amount of incoming funds for the time period. In some embodiments, the computer program product may comprise calculating an estimated amount of time associated with an availability of the amount of funds in the group of accounts based on at least the amount of spendable funds and the amount of funds in the group of accounts. Additionally, the computer program product may comprise initiating presentation of a spend user interface to the user, wherein the spend user interface is provided on a user device and comprises at least selectable financial event options for one or more financial events that could occur for the user. In some embodiments, the computer program product may comprise receiving, via the spend user interface, a user selection of a financial event. Furthermore, the computer program product may comprise calculating a financial event cost, wherein the financial event cost is a cost associated with the financial event. Additionally, the computer program product may comprise determining one or more payment disbursement accounts from the group of accounts based on the account information, the financial event, and the financial event cost, wherein the payment disbursement accounts comprise one or more accounts to be used to pay the financial event cost. In some embodiments, the computer program product may comprise electronically present, via the spend user interface, the one or more payment disbursement accounts to the user. Additionally, the computer program product may comprise calculating a new amount of spendable funds or a new estimated amount of time associated with an availability of the amount of funds in the financial institution accounts based on the financial event cost and the one or more payment disbursement accounts to be used to pay the financial event cost. Finally, the computer program product may comprise initiating presentation of an updated spend user interface to the user, wherein the updated spend user interface is provided on the user device and comprises the new amount of spendable funds or the new estimated amount of time, the one or more payment disbursement accounts used to cover the one or more payment options, and an amount from the one or more payment disbursement accounts.
In some embodiments, the computer program product further comprises computer readable instructions for receiving from the user, via the spend user interface, an order to execute a payment plan for the financial event cost, according to the selected payment disbursement ratio. In such an embodiment, the computer program may also comprise computer readable instructions for executing the payment plan, wherein executing the payment plan comprises withdrawing funds from the one or more payment disbursement accounts based on the payment disbursement ratio, and applying the withdrawn funds to the financial event cost.
In some embodiments, the computer program product further comprises computer readable instructions for electronically presenting, via the send user interface, an interactive interface, wherein the interactive interface provides the user with options to adjust aspects of the calculation of the payment disbursement ratio. In such an embodiment, the computer program product may further comprise computer readable instructions for receiving from the user, via the send user interface, an adjustment to the calculation of the payment disbursement ratio. Additionally, the computer program product may also comprise computer readable instructions for calculating a payment disbursement ratio, wherein the payment disbursement ratio comprises the amount of funds from each payment disbursement account to be used to pay the financial event cost. Finally, in some embodiments, the computer program product further comprises computer readable instructions for electronically presenting, via the send user interface, an updated calculation of the payment disbursement ratio in real time.
In some embodiments, the computer readable instructions for electronically monitoring the information associated with the group of accounts further comprises electronically monitoring the information associated with the group of accounts in real time.
In some embodiments, the computer readable instructions for calculating a payment disbursement ratio further comprises calculating the payment disbursement ratio with a tax module, wherein the tax module is configured to assess the tax consequences of using funds from each payment disbursement account.
In some embodiments, the computer readable instructions for calculating a payment disbursement ratio further comprises computer readable instructions for calculating the payment disbursement ratio with an interest rate module, wherein the interest rate module is configured to assess the interest rate associated with each payment disbursement account. In some embodiments, the computer readable instructions may also be configured for calculating the payment disbursement ratio with an income module, wherein the income module is configured to assess an income of the user, in relation to each payment disbursement account.
Having thus described embodiments of the invention in general terms, reference will be made to the accompanying drawings, where:
The following glossary of terms is intended to define the terms solely as they relate to this patent document, and should not be interpreted as definitions of the terms in any other context.
An “account” is the relationship that a user has with an entity, such as a financial institution. Examples of accounts include a deposit account, such as a transactional account (e.g., a banking account), a savings account, an investment account, a money market account, a time deposit, a demand deposit, a pre-paid account, a credit account, a non-monetary user profile that includes information associated with the user, or the like. The account is associated with and/or maintained by the entity.
Age parameter
The “age parameter” refers to an estimated age at which the user will not be able to cover the user's outflows (estimated amount of time associated with the amount of available funds based on the user assets, including the user financial accounts). The age parameter is based on the user's assets, liabilities, estimated inflows, estimated outflows, rates of return and interest on assets and liabilities. Stated another way, the age at which the user's outflows are greater than the user's inflows and the user has no additional assets to cover the difference.
“Assets” include accounts of the user and/or other property owned by the user. The assets may be associated with accounts or may be property that is not associated with a specific account. Examples of assets associated with accounts may be accounts that have cash or cash equivalents, or accounts that are funded with or contain property, such as safety despots box account that jewelry, a trust account that is funded with property, or the like. Examples of assets that may not be associated with accounts may be antiques in a user's home, jewelry in a user's home, or the like.
“Authentication information” is any information that can be used to identify of a user. For example, a system may prompt a user to enter authentication information such as a username, a password, a personal identification number (PIN), a passcode, biometric information (e.g., voice authentication, a fingerprint, and/or a retina scan), an answer to a security question, a unique intrinsic user activity, such as making a predefined motion with a user device. This authentication information may be used to authenticate the identity of the user (e.g., determine that the authentication information is associated with the account) and determine that the user has authority to access an account or system.
“Funds” or “Available Balance” are a balance in an account that can be invested or withdrawn. For example, the funds may refer to a bank ledger balance minus the amount of any monetary checks in the process of collection. Funds may also be referred to as an available balance, a collected balance, good funds, and usable funds.
Available Fund Amount or Amount of spendable funds
The “available fund amount” or “amount of spendable funds” is the amount of money a user can spend above the user's cost of living expenses (e.g., essential or semi-essential expenses) for entertainment, vacations, gifts, or other like non-essential expenses (e.g., fun money, safe to spend amount, or the like) while maintaining enough funds to reach a certain age (e.g., age parameter at which the user's funds will be depleted and will no longer be able to cover the outflows). For example, the amount of funds left over after the difference between the in-flows and out-flows are determined.
A “bank account” is a financial account between a bank customer and a financial institution. Examples of bank accounts include a deposit account, such as a transactional account (e.g., a banking account), a savings account, an investment account, a money market account, a time deposit, a demand deposit, a pre-paid account, a credit account, or the like.
A “checking account” is a deposit account held at a bank or other financial institution for the purpose of securely and quickly providing access to funds on demand, through a variety of different channels.
A “communication interface” or “communication device” is any device for communicating with other devices or with one or more users. For example, a communication interface may include a modem, server, transceiver, and/or a user interface.
A “computer program product” is an article of manufacture that includes any non-transitory computer readable storage medium having data, code, or other information stored thereon. A computer program product typically includes computer-executable instructions (e.g., code) stored on non-volatile memory. When executed by a processor, such computer-executable instructions typically cause the processor to perform one or more functions.
A “computing device” is any device that employs a processor and memory and can perform computing functions, such as a personal computer or a mobile device.
A “database” or “data warehouse” is a computer based storage location composed of data extracted from data processing systems.
A “demand deposit account” is a bank account from which deposited funds can be withdrawn on demand without advance notice to the depository institution, such as, for example, general checking and saving accounts.
A “discount” is the amount by which the price for a product/service is less than its par or face value of the product/service.
An “entity” as used herein may be a financial institution. For the purposes of this invention, a “financial institution” may be defined as any organization, entity, or the like in the business of moving, investing, or lending money, dealing in financial instruments, or providing financial services. This may include commercial banks, thrifts, federal and state savings banks, savings and loan associations, credit unions, investment companies, insurance companies and the like. In some embodiments, the entity may allow a user to establish an account with the entity.
A “financial institution” is any organization, entity, or the like in the business of moving, investing, or lending money, dealing in financial instruments, or providing financial services. This may include commercial banks, thrifts, federal and state savings banks, savings and loan associations, credit unions, investment companies, insurance companies and the like.
A “financial event” or “life event” may be any immediate or future event that causes a change in a user's financial status. A financial event may be a charge, a transaction, and exchange, or the like that may cause the user to lose or gain money and/or assets. Examples of financial events or life events include a medical expense, buying a house, college tuition, rent, and the like.
A “financial transaction” refers to any transaction involving a transfer of money or something of monetary value. For example, a financial transaction may refer to a purchase of goods or services, a return of goods or services, a payment transaction, a credit transaction, a rewards transfer, or an account money transfer or withdrawal.
Inflow of funds, Inflows, Incoming Funds
Refers to funds received from or deposited into the user's assets (e.g., user's accounts, or the like), such as paychecks, 401K disbursements, pension disbursements, rental property, or the like.
“Interest” is the monetary benefit paid by a borrower for the right to use a lender's or a depositor's funds. In one example, interest may be periodically paid over the life of a loan, deposit, security, or the like. In another example, some interest-bearing instruments, such as savings accounts, may not have defined maturities such that interest is not paid periodically over the life of the instrument but instead is paid solely at the end of the loan/deposit/security term.
A “line of credit” is (1) a type of loan that permits a borrower to draw funds, up to a specified maximum, for a defined period of time, or (2) any loan that permits the borrower to borrow funds up to a specified maximum, make repayments in any amount at any time, and obtain any number of advances so long as the maximum is not exceeded. For example, a customer may be issued a revolving line of credit such that the amount borrowed from the line of credit can be paid down and borrowed/advanced again, as the customer's needs change.
“Liabilities” are cash or cash equivalent debt that a user may owe to an entity. Examples of liabilities may include a home mortgage, another type of loan for which the user has to make payments, taxes owed to the government, a legal judgment against the user, or any other situation in which the use owes a debt to another entity or person.
A “memory” or “memory device” is any computer readable medium configured to store data, code, or other information. The memory may include volatile memory, such as volatile Random Access Memory (RAM) including a cache area for the temporary storage of data. The memory may also include non-volatile memory, which can be embedded and/or may be removable. The non-volatile memory can additionally or alternatively include an electrically erasable programmable read-only memory (EEPROM), flash memory or the like.
Mobile device
A “mobile device” is any mobile communication device, such as a cellular telecommunications device (i.e., a cell phone or mobile phone), personal digital assistant (PDA), a mobile Internet accessing device, a tablet computer, a laptop, or other mobile device.
A “money market” is an aggregation of buyers and sellers actively trading money market instruments.
A “money market deposit account” is a bank deposit account that pays interest based on the money markets current interest rates. Generally, money market deposit accounts provide higher rate of interest than might otherwise be earned in checking or savings accounts. As compared with demand deposit accounts, money market deposit accounts typically limit the number of transactions in the account within a given time period.
To “monitor” is to watch, observe, or check something for a special purpose over a period of time. The “monitoring” may occur periodically over the period of time, or the monitoring may occur continuously over the period of time. In some embodiments, a system may actively monitor a database, wherein the system reaches out to the database and watches, observes, or checks the database for changes, updates, and the like. In other embodiments, a system may passively monitor a database, wherein the database provides information to the system and the system then watches, observes, or checks the provided information.
An “online banking account” is an account that is associated with one or more user accounts at a financial institution and that can be accessed by a user over a network (e.g., the Internet) via a computer device, such as a personal computer, laptop, or mobile device (e.g., a smartphone or tablet). For example, the user may have an online banking account that is associated with the user's checking account, savings account, investment account, and/or credit account at a particular financial institution. A user may access an online banking account to view account balances, view transaction history, view statements, transfer funds, and pay bills. More than one user may have access to the same online banking account.
Refers to funds outgoing from the user's assets (e.g., user's accounts, or the like) to cover liabilities, such as payments for housing (e.g., rent or mortgage), bills, health care insurance and other costs, heat, water, food, car, boat, transportation, or like, which illustrates all of the essential (e.g., necessary or semi-necessary to the user) costs that cover what the user currently uses to live.
A “payment” is a monetary amount or item of monetary value transferred from one individual or entity to another individual or entity in return for receipt of good(s) and/or services.
A “processor” or “processing device” refers to a device or combination of devices having circuitry used for implementing the communication and/or logic functions of a particular system. For example, the processor may include a digital signal processor device, a microprocessor device, and various analog to digital converters, digital to analog converters, and/or other support circuits. Control and signal processing functions of the system are allocated between these devices according to their respective capabilities. The processor may also include the functionality to encode and interleave messages and data prior to modulation and transmission.
“Retirement planning” in a financial context may refer to the allocation of funds and decisions made for the use of funds incoming and outgoing in an attempt to achieve financial independence, so that the need to be gainfully employed is optional rather than a necessity. “Retirement planning” may relate to anything that involves determining how the user should utilize assets in order to try to maximize the use of the asset to live. In some embodiments, retirement planning models estimate a user's income immediately prior to retirement and adjust this income downward to reflect an income necessary for the user to maintain a satisfactory lifestyle. In some embodiments, a retirement planning model incorporates the user's current health and medical history and extrapolate the annual living expenses through the years in retirement. In some embodiments, retirement planning may be provided to the user by a financial institution, or other entity.
A “transaction” refers to any communication between a user and the financial institution or other entity monitoring the user's activities. For example, a transaction may refer to a purchase of goods or services, a return of goods or services, a payment transaction, a credit transaction, or other interaction involving a user's account. In the context of a financial institution, a transaction may refer to one or more of: a sale of goods and/or services, initiating an automated teller machine (ATM) or online banking session, an account balance inquiry, a rewards transfer, an account money transfer or withdrawal, opening a bank application on a user's computer or mobile device, a user accessing their e-wallet, or any other interaction involving the user and/or the user's device that is detectable by the financial institution. A transaction may include one or more of the following: renting, selling, and/or leasing goods and/or services (e.g., groceries, stamps, tickets, DVDs, vending machine items, and the like); making payments to creditors (e.g., paying monthly bills; paying federal, state, and/or local taxes; and the like); sending remittances; loading money onto stored value cards (SVCs) and/or prepaid cards; donating to charities; and/or the like.
A “user” may be a financial institution customer (e.g., an account holder or a person who have an account (e.g., banking account, credit account, or the like)). In one aspect, a user may be any financial institution customer involved in retirement planning with the financial institution or any other affiliate entities associated with the financial institution. In some embodiments, the user may be an individual who may be interested in opening an account with the financial institution. In some other embodiments, a user may be any individual who may be interested in enrolling in the retirement plan offered by the financial institution. In some embodiments, a “user” may be a financial institution employee (e.g., an underwriter, a project manager, an IT specialist, a manager, an administrator, an internal operations analyst, bank teller or the like) capable of operating the system described herein. For purposes of this invention, the term “user” and “customer” may be used interchangeably.
A “user interface” is any device or software that allows a user to input information, such as commands or data, into a device, or that allows the device to output information to the user. For example, the user interface include a graphical user interface (GUI) or an interface to input computer-executable instructions that direct a processing device to carry out specific functions. The user interface typically employs certain input and output devices to input data received from a user second user or output data to a user. These input and output devices may include a display, mouse, keyboard, button, touchpad, touch screen, microphone, speaker, LED, light, joystick, switch, buzzer, bell, and/or other user input/output device for communicating with one or more users.
Embodiments of the present invention now may be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all, embodiments of the invention are shown. Indeed, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure may satisfy applicable legal requirements. Like numbers refer to like elements throughout.
Typically, retirement planning models estimate a user's income immediately prior to retirement and adjust this income downward to reflect an income necessary for the user to maintain a satisfactory lifestyle. Most retirement planning models incorporate the user's current health and medical history and extrapolate the annual living expenses through the years in retirement. The present invention provides the functional benefit of incorporating specific, customized financial events (e.g. medical expense, a child move, death of spouse, or the like) to dynamically recalculate the effect of said financial events on the user's retirement plan.
In some embodiments, a “user” may be a financial institution customer (e.g., an account holder or a person who have an account (e.g., banking account, credit account, or the like)). In one aspect, a user may be any financial institution customer involved in retirement planning with the financial institution or any other affiliate entities associated with the financial institution. In some embodiments, the user may be an individual who may be interested in opening an account with the financial institution. In some other embodiments, a user may be any individual who may be interested in enrolling in the retirement plan offered by the financial institution. In some embodiments, a “user” may be a financial institution employee (e.g., an underwriter, a project manager, an IT specialist, a manager, an administrator, an internal operations analyst, bank teller or the like) capable of operating the system described herein. For purposes of this invention, the term “user” and “customer” may be used interchangeably.
In some embodiments, an “entity” as used herein may be a financial institution. For the purposes of this invention, a “financial institution” may be defined as any organization, entity, or the like in the business of moving, investing, or lending money, dealing in financial instruments, or providing financial services. This may include commercial banks, thrifts, federal and state savings banks, savings and loan associations, credit unions, investment companies, insurance companies and the like. In some embodiments, the entity may allow a user to establish an account with the entity. An “account” may be the relationship that the user has with the entity. Examples of accounts include a deposit account, such as a transactional account (e.g. a banking account), a savings account, an investment account, a money market account, a time deposit, a demand deposit, a pre-paid account, a credit account, a non-monetary user profile that includes only personal information associated with the user, or the like. The account is associated with and/or maintained by an entity. In other embodiments, an “entity” may not be a financial institution.
As used herein, a “user interface” may be a graphical user interface. Typically, a graphical user interface (GUI) is a type of interface that allows users to interact with electronic devices such as graphical icons and visual indicators such as secondary notation, as opposed to using only text via the command line. In some embodiments, the graphical user interface may include both graphical elements and text elements.
As illustrated by block 104 in
Block 106 of
As illustrated by block 108 in
As illustrated by block 110 in
Block 112 of
It should be understood that when describing a user throughout this invention, the use of the term user may be replaced by users, which indicates that the invention may also include pulling information from the accounts of one or more users (e.g., customers). The multiple users may include a household of people (e.g., husband and wife, parent and child, multiple family members, or the like), which may determine the available funds amount and/or the age parameter for multiple users, for example a household. In still other embodiments, with respect to the actions that a user may take that are described herein, the user may allow or designate another family member, a financial advisor, an estate planner, a trustee, or the like (e.g., otherwise described as a designee) in order to take an action in place of the user. These designees may use the information available to the user for retirement planning purposes during retirement of the user and/or after the user passes away to help plan the user's retirement and/or distribute the user's assets.
Block 154 illustrates that the user may also have a full-time and/or part time job that provides additional income inflows, such as supplemental employment income inflows, to the user and/or user accounts. The amount of estimated supplemental employment income may be determined based on the hours that the user works, which may be estimated over a period of time, and as such be increased, diminished, or stop based on the age of the user, the number of hours worked over time, increases or decreases in pay over time, and/or other factors that may indicate how long a user may have supplemental income in the future.
As illustrated by block 152 and 154 the inflows from disbursement accounts or other assets, and/or the inflows from supplemental employment income inflow, may be utilized directly to pay for outflows, and thus, be used to calculate the amount of spendable funds illustrated in block 160 described below. In other embodiments of the invention the inflows from disbursement accounts or other assets, and/or the inflows from supplemental employment income inflow may be distributed to liquid or semi-liquid accounts, described in further detail below with respect to block 156.
Block 156 illustrates liquid (e.g., liquid or semi-liquid) assets, such as accounts that may be equivalent to cash or assets that can be converted quickly into cash. For example, the liquid accounts may be checking accounts, savings accounts, self-directed investment accounts, money market accounts, or the like. These liquid accounts may be utilized to pay for the outflows directly as illustrated by block 158 in
As illustrated in block 158 the outflows of the users 9 may include the payments that the user makes in order to live (e.g., necessary or semi-necessary to the user for the living expenses and other liabilities of the user). For example, in some embodiments the outflows may include housing outflows, which may cover the expenses of the user for mortgage payments, taxes, insurance, or the like that the user has to pay in order to maintain a residence. In other examples, the outflows may be related to bills, such as electric, gas, water, or the like. The user's health care cost, such as user's health care premiums and yearly estimated cost may be included. The user may have car payments that are due on a monthly (or other time period) basis. The user may also have insurance payments for the user's car, life, or the like. In addition, there may be other outflows, such as but not limited to child care payments, cell phone payments, internet, and/or other entertainment expenses that may or may not be included in the outflow calculations (e.g., may or not be considered essentials or semi-essentials). The outflows may also include some life event outflows that may be easily predictable, non-repeating outflows, and/or only periodic outflows (e.g., occurs more than the time period for which the outflows are calculated), such as but not limited to paying for a child's college, paying for a wedding, or other like life events that affect the user's outflows. As illustrated by block 152, 154, and 156 some of these outflows may be paid by one or more of the inflows, the supplemental employment income inflow, and/or the liquid assets either directly or indirectly. As such, one or more of the user's assets may have a balance that is depleted over time as the outflows are paid.
Block 160 illustrates the amount of spendable funds per the time period is determined by taking the difference between the inflows and outflows. As such, the amount of spendable funds illustrates the amount of money that a user has to spend above the user's outflows per the time period. For example, the amount of spendable funds may be utilized by the user to spend on trips, electronics, entertainment (e.g., dinners, moves, shows, or the like), to spend on family members, or the like. The amount of spendable funds is the amount of money that the user is safe to spend over the time period, without spending negative amounts of money on the outflows.
As illustrated by block 162, the amount of spendable funds may be utilized, along with the user's assets and liabilities, in order to determine an age parameter at which the user's assets are estimated to be depleted. As such, the age parameter illustrates the age at which the user will not be able to cover the outflows. For example, as the user's inflows from block 152 are depleted, there becomes a point in time when the user's inflows will not cover the user's outflows. At this point in time, the outflows will be covered by the balances of the user's liquid assets (e.g., cash accounts or other like cash accounts). As such, a calculation for an age parameter may be made when the total assets of the user (e.g., inflows from assets and liquid asset accounts) would not cover the outflows for the user's liabilities. In some embodiments the age parameter may be infinity as the user's inflows are so great (e.g., payments received in dividends, interest rates, rental payments received) that they will never be depleted enough to be less than the user's outflows.
Block 164 illustrates that in some embodiments the user may not spend the amount of spendable funds, and as such depending on the how the outflows were paid, the unspent fund amount may be reinvested into the liquid assets (e.g., self-directed accounts, checking accounts, savings accounts, or the like) or back into more illiquid assets, such as purchases of property or other non-liquid assets.
It should be further understood that the determination of the amount of spendable funds over the time period and/or the age parameter may change in real-time or near real-time as the rate of return on the assets change (e.g., stock values change, rental income changes or goes away, assets are depleted, big purchases are made or sold, or the like), and costs of the liabilities change (e.g., damage to property than needs repair, variable interest rate changes, life events occur that deplete assets, loans are taken out or paid off, or the like). As such, the present invention may be constantly in real-time or near real time, or over various intervals, recalculated in order to provide a more accurate amount of spendable funds and/or age parameter to the user, such that the user is better able to plan for retirement. Moreover, as illustrated in further detail later the user may be able to adjust the amount of spendable funds and/or the age parameter in order to determine how changes in spending habits affect the age at which the user's assets are depleted, or vice versa.
In some embodiments, the system may be configured to process the information associated with the financial institution accounts of the user. In this regard, the system may be configured to calculate an amount of spendable funds (e.g., otherwise described herein as an available fund amount) associated with the user based on the amount of funds available in the financial institution accounts, the amount of outgoing funds, and the amount of incoming funds for the time period. In one aspect, the amount of spendable funds may be calculated for a specific time period, as previously discussed herein. For example, the amount of spendable funds may be calculated for every day, every week, every month, or the like. In addition, the system may be configured to calculate an estimated amount of time associated with an availability of the amount of funds available in the financial institution accounts (e.g., an age parameter) based on at least the amount of spendable funds and the amount of funds available in the financial institution accounts, as previously discussed herein. For example, consider a situation where the amount of spendable funds available to the user every month is $2500 and the amount of funds available in the financial institution accounts of the user is $300,000. Based on user's assets, liabilities, estimated inflows, and estimated outflows, the estimated amount of time associated with the availability of the amount of funds may be 120 years, in that, if the user spends $2500 every month, based on factors such as the user's assets, rates associated with return on investments, liabilities, estimated inflows, estimated outflows, or the like, the user may continue to maintain a consistent lifestyle for until the user is, for example, 120 years old before the amount of funds available in the financial institution accounts is depleted. In one aspect, determining the amount of time associated with the availability of the amount of funds is based on at least the current age of the user.
In response, the process flow includes initiating presentation of a spend user interface to the user on a user device, wherein the spend user interface is provided on a user device and comprises at least selectable financial event options for the one or more financial events that could occur for the user, as shown in block 204. In one aspect, the system may be configured to present on the spendable user interface, the amount of spendable funds associated with the user and the estimated amount of time associated with the availability of the amount of funds available in the financial institution accounts.
In some embodiments, the one or more financial events may result in unexpected income and/or unexpected expenditure for the user. In this regard, in one aspect, the one or more financial events may include, but are not limited to a medical expense such as a surgical procedure, a recurring physical exam, or the like, an investment property purchase, an unexpected trip, a child moving back home, or the like. In another aspect, the one or more financial events may include but are not limited to an unexpected income from inheritance, death of spouse, or the like.
As shown in block 206, the process flow includes receiving, via the spend user interface, a user selection of a financial event from the one or more financial events. In response, the system may be configured to initiate presentation of event information user interface to the user, wherein the event information user interface is provided on the user device and comprises at least selectable options associated with the financial event selected by the user and enables the user to input financial event information associated with the financial event selected by the user. In some embodiments, the event information user interface may include information associated with the financial event selected by the user. In one aspect, the event information may include one or more predefined selectable options for the user. For example, if the user selects a financial event related to a medical expense, the event information interface may provide the user with one or more predefined options or questions related to the nature of the medical expense such as a heart bypass, a colonoscopy, an endoscopy, radiation, or the like. In another aspect, the event information may include one or more predefined questions associated with the selected financial event. In this regard, the system may be configured to enable the user to provide information associated with the one or more predefined questions. In another aspect, the event information may enable the user to customize the event information user interface by creating additional options to enter selective information. For example, the user may require a medical procedure not included in the one or more predefined options. In such cases, the system may be configured to enable the user to create a customized event information option to enter selective information. In some embodiments, the system may be configured to analyze the one or more financial events selected by the user and provide tips for preventative care. For example, if the selected financial event is a heart bypass surgery, the system may be configured to provide the user with one or more cardiovascular tips for better health. In some embodiments, the one or more tips provided may include financial advice to enable the user to budget assets effectively to pay for the selected financial event.
As shown in block 208, the process flow includes determining one or more payment options from the financial institution accounts for the financial event selected by the user. In some embodiments, in response to receiving the event information from the user, the system may be configured to initiate presentation of a payment option user interface to the user on the user device, wherein the payment option user interface includes one or more payment options associated with the event information. In one aspect, the system may be configured to access the distributed network of servers to determine the financial event costs based on the financial event information. For example, if the user selects a heart bypass option as the medical expense, the payment option user interface may generate one or more payment options based on factors such as medical insurance, which may be gathered from third-party websites, applications, systems, or the like, internal financial institution stored information, or from other like businesses. In this regard, the system may be configured to generate an estimated medical payment for a heart bypass with medical insurance, estimated medical payment for a heart bypass with Medicaid, and/or estimated medical payment for a heart bypass without insurance. In one aspect, in the event that the user selects the option of estimated medical payment with medical insurance, the system may be configured to receive the user's current medical insurance information. In another aspect, the system may be configured to store the user's health insurance information and use the stored health insurance information prior to estimating the medical payment. In this regard, the system may be configured to confirm with the user that the medical insurance information on file is the user's current medical insurance.
In response, the system may be configured to receive, via the payment option user interface, at least one of the one or more payment options based on at least a user selection of the one or more payment options. As shown in block 210, in response to receiving at least one of the one or more payment options from the user, the process flow includes calculating a new amount of spendable funds (e.g., available fund amount) or a new estimated amount of time associated with an availability of the amount of funds available in the financial institution accounts (e.g., age parameter). In some embodiments, the system may be configured to receive a user input associated with the new amount of spendable funds or the new estimated amount of time and adjust the amounts accordingly. Continuing from the previous example, assuming that the aggregate of the estimated cost of the one or more selected financial events, after all expenses, amounts to $84,000, the system may be configured to calculate a new amount of spendable funds for the amount of available funds (e.g. $1800) in the user's financial institution accounts to be available to the user until the user is 120 years old. The system may be configured to take into account factors such as the user's assets, rates associated with return on investments, liabilities, estimated inflows, estimated outflows, or the like to calculate the new amount of spendable funds. In this scenario, since the amount of spendable funds decreases from $2500 to $1800, the user's lifestyle may be affected significantly. The system may enable the user to adjust the amount of spendable funds in an attempt to maintain similar lifestyle. Consequently, the system may be configured to recalculate the age parameter based on the adjusted amount of spendable funds and factors such as the user's assets, rates associated with return on investments, liabilities, estimated inflows, estimated outflows, or the like. Similarly, the user may decide to improve current lifestyle and increase the amount of spendable funds every month. The system may be configured to enable the user to adjust the estimated amount of time (e.g. age parameter) associated with the amount of available funds in the user's financial institution accounts by reducing the estimated life expectancy of the user. In response, the system may be configured to recalculate a new amount of spendable funds based on the adjusted age parameter and factors such as the user's assets, rates associated with return on investments, liabilities, estimated inflows, estimated outflows, or the like, thereby increasing the amount of spendable funds available to the user. In some embodiments, the amount of spendable funds and the estimated amount of time associated with the availability of funds available in the financial institution accounts have a negatively correlated relationship.
In response to calculating new amount of spendable funds and/or new estimated amount of time, the system may be configured to initiate presentation of an updated spend user interface to the user, wherein the updated spend interface is provided on the user device and comprises the new amount of spendable funds or the new estimated amount of time, one or more of the financial institution accounts used to cover the one or more payment options, and an amount from one or more of the financial institution accounts.
In some embodiments, the system may be configured to establish a payment disbursement plan to enable the user to pay for the one or more financial events. In one aspect, the updated spend user interface may present the payment disbursement plan to the user on the user device, wherein the payment disbursement plan may include a percentage allocation of amounts from each of the one or more financial institution accounts to be applied towards the one or more financial events selected by the user. In response to receiving the payment disbursement plan, the system may be configured to enable the user to execute the plan by distributing the funds from the various accounts into the user's checking account or other account from which the funds will be paid, by scheduling the disbursement for the future point in time when the financial event is likely to occur, or scheduling an alert to remind the user of the fund allocations when the financial event occurs. In some embodiments, the system may be configured to enable the user to adjust the percentage allocation of the amount from the one or more financial institution accounts of the user, wherein adjusting further comprises adjusting a current weight of one or more holdings associated with the one or more financial institution accounts of the user.
In some embodiments, the system may be configured to determine whether the user is ahead of a plan, on plan, or behind a plan based on at least the amount of outgoing funds, the amount of incoming funds, and the amount of spendable funds. In one aspect, the system may be configured to determine that the user is ahead of a plan if the amount of outgoing funds and spendable funds is less than the amount incoming funds. In another aspect, the system may be configured to determine that the user is on plan if the amount of outgoing funds and spendable funds is equal to the amount of incoming funds. In yet another aspect, the system may be configured to determine that the user is behind plan if the amount of outgoing funds and spendable funds is greater than the amount of incoming funds for one or more time periods.
The present invention provides the functional benefit of providing the amount of spendable funds, amount of time associated with the availability of funds available in the financial institution accounts, or the like described above as visual information to the user on an interactive graphical user interface. In this regard, the system is configured to receive user input and dynamically determine updated amounts based on at least retrieving information associated with the one or more financial institution accounts of the user and event information from disparate databases in substantially real-time (e.g., real-time or near real time). In this way, the present invention enables the user to visually recognize the impact of the one or more financial events selected.
In some embodiments, the system may be configured to recommend one or more products and/or services to the user based on the one or more financial events selected by the user. In one aspect, the system may be configured to recommend one or more merchants and/or service provider associated with the selected financial event. In another aspect, the system may be configured to recommend a specific time period for purchase based on existing offers and/or discounts available to the user. In some other embodiments, the system may be configured to recommend one or more offers associated with one or more products and/or services previously purchased by the user for the one or more financial events selected. For example, if the financial event selected by the user is “car purchase”, the system may be configured to recommend a specific car merchant, financing options, discounts/rebates on car accessories, warranties, or the like.
In addition to receiving the user selection of a financial event from the one or more financial events, the process flow includes receiving, via an event scheduling interface, a user selection of a future predetermined date associated with the financial event selected by the user, as shown in block 258. For example, the user may be interested in purchasing a car. In this scenario, the user may select the “car purchase” financial event from the one or more financial events listed on the spend user interface. In addition, the event scheduling interface may enable the user to select a predetermined future date associated with the car purchase. In this regard, in one aspect, the system may be configured to initiate presentation of a calendar on the event scheduling interface to enable the user to select a favorable date. In response, the system may be configured to initiate presentation of event information user interface to the user, wherein the event information user interface is provided on the user device and comprises at least selectable options associated with the financial event selected by the user and enables the user to input financial event information associated with the financial event selected by the user. In some embodiments, the event information user interface may include information associated with the financial event selected by the user. In this example, the event information may include information associated with the car that the user intends on purchasing, such as, model, year, body style, gas mileage, preferred manufacturers, or the like. The user may also input a cost associated with the car, otherwise the financial institution may access third-parties in order to determine a cost of the car through third-party applications, websites, systems, servers, or the like. In other embodiments the costs associated with events may be determine in the same way as described with respect to the car.
In response, the process flow includes determining one or more payment options from the financial institution accounts for the financial event selected by the user at the future predetermined date, as shown in block 260. In some embodiments, the system may be configured to determine one or more payment options for the financial event selected by the user at the time the user selected the financial event on the spend user interface. In some other embodiments, the system may be configured to determine one or more estimated payment options for the financial event selected by the user at the predetermined future date selected by the user. In yet another embodiment, the system may be configured to determine one or more payment options for the financial event selected by the user between the time the user selected the financial event on the spend user interface and the predetermined future date to determine the best payment option for the user based on one or more factors. In one aspect, the one or more factors include, but are not limited to, market information such as a level of market demand, economic trend, demographic, industry standard, government laws and regulations, seasonal price variation, or the like. In other embodiments, the one or more factors may include when it would be best to use one of the financial accounts of the user, such as the user should wait for the financial account until the user can take from an investment account without penalty (e.g., 401K cannot be accessed without penalty until a specific age is reached). In one embodiment for example, the user may select “car purchase” as the financial event from the one or more financial events presented to the user on the spend user interface. In response, the system may be configured to determine that the price of the car requested by the user is currently (e.g., in December) $32,000 and at the predetermined future date selected by the user (e.g., in April) is $35,500. In some embodiments, the system may be configured to determine the estimated price of the car requested by the user between December and April and present the price fluctuation to the user on the user device. In one aspect, the price fluctuation may be presented periodically as a weekly fluctuation, a monthly fluctuation, or the like. Moreover, the financial institution may indicate to the user to wait until a future date (e.g., in February) to make the purchase when the user has access to additional funds (e.g., the user can access his IRA without penalty).
In some embodiments, the one or more payment options for the car purchase may include, but are not limited to, an equated monthly installment option, a one-time payment option, or the like. In this regard, the system may be configured to determine one or more pricing options available from one or more car dealers within a specific geographic radius associated with the location of the user. Other factors included in determining the one or more payment options include a preferred merchant, geographic location of the user, a preferred geographic location, comparable car models, or the like. In some embodiments, the financial institution may indicate to the user to purchase the car with cash, to finance the car, or lease the car based on the user's inflows, outflows, access to financial accounts without penalty, the rate of return for various assets, or the like. For example, the financial institution may suggest to the user to finance the purchase because interest rates are only 1%, and instead of paying cash the user can invest the cash at a higher rate of return. In other examples, the financial institution may indicate that the user should finance the car because accessing the cash to pay for the car outright would result in too many penalties.
In response to receiving payment options, the system may be configured to receive, via the payment option user interface, at least one of the one or more payment options based on at least a user selection of the one or more payment options. In some embodiments, the system may be configured to provide a recommendation to the user based on the selected financial event and the future predetermined date. Continuing from the previous example, the system may be configured to determine that the best time during the year to buy a car is during the month of October, when most showrooms are likely to release the previous year models at relatively cheaper prices to make room for the new yearly car models. In this regard, the system may provide the estimated price of the car requested by the user outside the time period between the time the user selected the financial event on the spend user interface and the predetermined future date.
In response to receiving the user selection of the payment option, the system may be configured to calculate a new amount of spendable funds or a new estimated amount of time associated with an availability of the amount of funds available in the financial institution accounts, as shown in block 262. In some embodiments, the system may be configured to establish a payment disbursement plan to enable the user to pay for the one or more financial events. In one aspect, the updated spend user interface may present the payment disbursement plan to the user on the user device, wherein the payment disbursement plan may include a percentage allocation of amounts from each of the one or more financial institution accounts to be applied towards the one or more financial events selected by the user. In response to receiving the payment disbursement plan, the system may be configured to enable the user to execute the plan.
As shown in
The user input system 340 may include any computerized apparatus that can be configured to perform any one or more of the functions of the user input system 340 described and/or contemplated herein. For example, the user may use the user input system 340 to transmit and/or receive information or commands to and from the system 330. In some embodiments, for example, the user input system 340 may include a personal computer system (e.g. a non-mobile or non-portable computing system, or the like), a mobile computing device, a personal digital assistant, a mobile phone, a tablet computing device, a network device, and/or the like. As illustrated in
Each communication interface described herein, including the communication interface 342, generally includes hardware, and, in some instances, software, that enables the user input system 340, to transport, send, receive, and/or otherwise communicate information to and/or from the communication interface of one or more other systems on the network 310. For example, the communication interface 342 of the user input system 340 may include a wireless transceiver, modem, server, electrical connection, and/or other electronic device that operatively connects the user input system 340 to another system such as the system 330. The wireless transceiver may include a radio circuit to enable wireless transmission and reception of information. Additionally, the user input system 340 may include a positioning system. The positioning system (e.g. a global positioning system (GPS), a network address (IP address) positioning system, a positioning system based on the nearest cell tower location, or the like) may enable at least the user input system 340 or an external server or computing device in communication with the user input system 340 to determine the location (e.g. location coordinates) of the user input system 340.
Each processor described herein, including the processor 344, generally includes circuitry for implementing the audio, visual, and/or logic functions of the user input system 340. For example, the processor may include a digital signal processor device, a microprocessor device, and various analog-to-digital converters, digital-to-analog converters, and other support circuits. Control and signal processing functions of the system in which the processor resides may be allocated between these devices according to their respective capabilities. The processor may also include functionality to operate one or more software programs based at least partially on computer-executable program code portions thereof, which may be stored, for example, in a memory device, such as in the user application 347 of the memory 346 of the user input system 340.
Each memory device described herein, including the memory 346 for storing the user application 347 and other information, may include any computer-readable medium. For example, memory may include volatile memory, such as volatile random access memory (RAM) having a cache area for the temporary storage of information. Memory may also include non-volatile memory, which may be embedded and/or may be removable. The non-volatile memory may additionally or alternatively include an EEPROM, flash memory, and/or the like. The memory may store any one or more of pieces of information and data used by the system in which it resides to implement the functions of that system.
As shown in
Also shown in
It will be understood that the system application 337 may be configured to implement any one or more portions of the various user interfaces and/or process flow described herein. The system application 337 may interact with the user application 347. It will also be understood that, in some embodiments, the memory includes other applications. It will also be understood that, in some embodiments, the system application 337 is configured to communicate with the structured database 338, the user input system 340, or the like.
It will be further understood that, in some embodiments, the system application 337 includes computer-executable program code portions for instructing the processor 334 to perform any one or more of the functions of the system application 337 described and/or contemplated herein. In some embodiments, the system application 337 may include and/or use one or more network and/or system communication protocols.
In addition to the system application 337, the memory 336 also includes the structured database 338. As used herein, the structured database 338 may be one or more distinct and/or remote databases. In some embodiments, the structured database 338 is not located within the system and is instead located remotely from the system. In some embodiments, the structured database 338 stores information or data described herein.
It will be understood that the structured database 338 may include any one or more storage devices, including, but not limited to, datastores, databases, and/or any of the other storage devices typically associated with a computer system. It will also be understood that the structured database 338 may store information in any known way, such as, for example, by using one or more computer codes and/or languages, alphanumeric character strings, data sets, figures, tables, charts, links, documents, and/or the like. Further, in some embodiments, the structured database 338 may include information associated with one or more applications, such as, for example, the system application 337. It will also be understood that, in some embodiments, the structured database 338 provides a substantially real-time representation of the information stored therein, so that, for example, when the processor 334 accesses the structured database 338, the information stored therein is current or substantially current.
It will be understood that the embodiment of the system environment illustrated in
In addition, the various portions of the system environment 300 may be maintained for and/or by the same or separate parties. It will also be understood that the system 330 may include and/or implement any embodiment of the present invention described and/or contemplated herein. For example, in some embodiments, the system 330 is configured to implement any one or more of the embodiments of the process flows described and/or contemplated herein in connection any process flow described herein. Additionally, the system 330 or the user input system 340 is configured to initiate presentation of any of the user interfaces described herein.
In accordance with embodiments of the invention, the term “module” with respect to a system may refer to a hardware component of the system, a software component of the system, or a component of the system that includes both hardware and software. As used herein, a module may include one or more modules, where each module may reside in separate pieces of hardware or software.
In some embodiments of the invention, the user may own more than one account and desire to optimize the user's retirement funds. In such an embodiment, the system may identify the available funds, review the factors that affect the value of a fund over time (e.g., tax, interest, and the like), and calculate an optimized ratio of funds from different accounts or other assets (e.g., property owned by the user, or the like) to be used in the payment of the financial event.
As such,
In reference to the process flow 900 of
In some embodiments, the group of accounts may solely comprise accounts owned by the user. In some embodiments, the group of accounts may comprise accounts owned by the user's spouse, family members, or friends. In some embodiments, the group of accounts may comprise accounts owned jointly by the user and a third party. In some embodiments, the group of accounts may include any combination of such types of account ownership.
As shown in block 904, the process flow may include electronically monitoring the information associated with the group of accounts. In some embodiments, the information associated with the group of accounts may comprise the amount of funds held within each account, the known growth or interest of each account, the expected growth or interest of each account, the known taxes for each account for the taxable year, the expected taxes for each account for the taxable year, the types of financial events that may be paid for by using the funds of each account, and the like. In some embodiments, the system electronically monitors the group of accounts for this information on a periodic basis (e.g., once every hour, once every day, once every week, and the like). In some embodiments, the system electronically monitors the group of accounts in real time, or near real time so that the system maintains the most up-to-date information associated with the group of accounts. In some embodiments, one or more of the accounts within the group of accounts is located within, or maintained by, the entity and as such the system may monitor these accounts through an internal monitoring system. In some embodiments, one or more of the accounts within the group of accounts is located externally to the entity and is maintained by a third party. In such an embodiment, the entity may monitor the account through an external monitoring system that may include requests to the third party, an electronic feed from the third party, and the like.
As shown in block 906, the process flow may include initiating presentation of a spend user interface to the user, wherein the spend user interface is provided on a user device and comprises at least selectable financial event options for one or more financial events that could occur for the user. In some embodiments, the end user interface may encompass any of the embodiments described in
As shown in block 908, the process flow may include receiving, via the spend user interface, a user selection of a financial event. In some embodiments, the user selection of a financial event may include information about the type of financial event selected, the cost for the user of the financial event, the time when the financial event is expected (e.g., immediately, in 1 year, and the like), and the like. In response to receiving the user selection, the system may be configured to initiate presentation of an event information user interface to the user, wherein the event information user interface is provided on the user device and comprises at least selectable options associated with the financial event selected by the user and enables the user to input financial event information associated with the financial event selected by the user. In some embodiments, the event information user interface may include information associated with the financial event selected by the user. In one aspect, the event information may include one or more predefined selectable options for the user. For example, if the user selects a financial event related to a medical expense, the event information interface may provide the user with one or more predefined options related to the nature of the medical expense such as a heart bypass, a colonoscopy, an endoscopy, radiation, or the like. In another aspect, the event information may enable the user to customize the event information user interface by creating additional options to enter selective information. For example, the user may require a medical procedure not included in the one or more predefined options. In such cases, the system may be configured to enable the user to create a customized event information option to enter selective information.
As shown in block 910, the process flow may include calculating a financial event cost, wherein the financial event cost is a cost associated with the financial event. In some embodiments, the financial event cost is provided by the user and therefore the system simply identifies the cost. In some embodiments, the system predicts the financial event cost based on statistics and information stored within the system by the entity. In some embodiments, the financial event cost is unknown and the system estimates the financial event cost based on factors provided by the user as well as statistics and information stored within the system by the entity.
As shown in block 912, the process flow may include determining one or more payment disbursement accounts from the group of accounts based on the account information and the financial event, wherein the payment disbursement accounts comprise one or more accounts to be used to pay the financial event cost. A payment disbursement account may be any account, from the group of accounts, from which the user may draw funds for payment of the financial event cost. For example, a financial event that is occurring in a month may be paid with funds drawn from a user's checking account since there are generally very few, if any, restrictions to checking account funds, making the user's checking account a payment distribution account. However, the user's funds held in a certificate of deposit (CD) that matures in 5 months will be tied up when the financial event occurs, making the CD ineligible to be a payment disbursement account. In some embodiments, funds from every account from the group of accounts may be eligible to pay for the financial event, in which case every account in the group of accounts may be determined to be a payment disbursement account. In other embodiments of the invention, a financial account may have restrictions for accessing the funds early, but this may not disqualify the account as a payment disbursement account because the present invention may take into the account the penalties for accessing the funds into the determination of whether or not to utilize at least some of the funds in the account. For example, the user may only be able to take a portion of the funds from a 401K account without penalty, and as such, the present invention may calculate the amount of funds that could be utilized without penalty and what it would cost utilize additional funds from the account that would result in a penalty. In the event that the life event is related to the user receiving funds, for example through an inheritance, the financial institution may also determine to which of the group of accounts the funds should be distributed (e.g., investment accounts, pay-off a high interest rate loan, or the like).
In some embodiments of the invention, not only may the financial institution determine one or more payment disbursement accounts that the user currently has in order to pay for the life event (or receive any funds from the life event), but the financial institution may provide offers for products or services (e.g., types of accounts, or the like) that the financial institution provides. For example, in order to pay off an estimated medical expense, the financial institution may recommend that the user 9 opens a credit account that has a zero (0) percent annual percentage rate for a period of time, that the user 9 refinances a first or a second mortgage at a lower annual percentage rate, that the user 9 pays for the event using a specific card to earn the most rewards in general or for a specific transactions that the user wants to make, or the like. In another example, when the user 9 receives an inheritance, the financial institution may present specific investment vehicle suggestions to the user to help the user 9 to invest the funds received from an inheritance, or another type of life event.
As shown in block 914, the process flow may include calculating a payment disbursement ratio, wherein the payment disbursement ratio comprises the amount of funds from each payment disbursement account to be used to pay the financial event cost. A payment disbursement ratio may be any ratio of funds from one or more disbursement accounts, optimized to maximize the future value of the user's group of accounts. In some embodiments, the system utilizes a tax module to assess the tax consequences of using funds from each of the payment disbursement accounts and determine the payment disbursement accounts that would have the lowest tax consequences if used to pay the financial event cost. It should be understood that when discussing that funds are received by a user from a life event the funds may also be described as a payment, however, instead of an outgoing payment to another entity for an expense the payment is incoming to the user's own accounts from another entity. For example, the payment disbursement ratio may not only relate to the ratio of funds used from accounts to pay an entity for a service or product, but it may also relate to the ratio of funds received (e.g., inheritance) that should be directed to one of the user's accounts.
In one embodiment, a payment disbursement account with a low tax consequence may be an account with no taxes (e.g., cash, Roth IRAs, and the like), low taxes, an account that may receive the benefit of recording a loss for the taxable year, and the like. The tax module may also calculate the expected tax rates for each account, or an expected trend in the tax rates, and thereby determine whether funds in an account are more valuable if used at the time of the financial event, or at a time after the financial event. For example, if Account A and Account B will have the same tax rate at the time of the financial event, but Account B's tax rate will increase in the following years while Account A's tax rate is fixed, then the system may determine that funds from Account B should be used before the funds in Account A. As such, payments made from or to a particular account may be based off of estimated taxes or other fund assessments for the account (e.g., taxes, yearly management account assessments, early withdrawal assessments, or the like).
In some embodiments the system utilizes an income module to determine the user's expected income for the taxable year based on salaries, investments, dividends, rent payments, and the like, and using the income module to determine the impact of withdrawing funds from or providing funds to one or more accounts. As such, payments made from or to a particular account may be based off of income levels and the accounts to which the income is being directed.
In some embodiments, the system utilizes an interest rate module to determine the interest rate for each account (i.e., the rate at which the funds in the account grow) at the time of the financial event, as well as expected or known changes to the interest rate of the account over time. As such, payments made from (e.g., for a life event expense) or to (e.g., for funds received from a life event) a particular account may be based off of estimated rates of return.
In some embodiments, the system utilizes the tax module, the income module, the interest rate module, the amount of available funds within each payment distribution account, and/or the financial event costs to calculate the optimized payment distribution ratio for each of the payment disbursement accounts. In some embodiments, the financial event cost is payable over a set period of time, and as such, the system may take each periodical payment date into account in calculating the optimal payment distribution ratio.
As shown in block 916, the process flow may include electronically presenting, via the spend user interface, the payment disbursement ratio to the user. An example payment disbursement ratio presentation for a user with payment disbursement accounts “Account A,” “Account B,” “Account C,” and “Account D” may be represented in the following way: payment disbursement ratio=50% Account A, 40% Account B, 10% Account C, and 0% Account D. Of course, this may also be represented in respect to the percentages of the funds originally held in each of the payment disbursement accounts: 100% of funds from Account A, 100% of funds from Account B, 20% of funds from Account C, and 0% from Account D. Finally, the payment disbursement ratio may be represented as the monetary value of the funds withdrawn from each payment distribution account: e.g., $5,000 from Account A, $4,000 from Account B, $1,000 from Account C, and $0 from Account D. In some embodiments, electronically presenting, via the spend user interface, the payment disbursement ratio to the user includes presenting a selectable option to execute a payment plan, wherein the payment plan comprises drawing funds from the one or more payment disbursement accounts according to the payment disbursement ratio, and applying those funds to the financial event cost.
In some embodiments, the spend user interface may comprise an interactive interface that allows the user to adjust certain aspects of the payment disbursement ratio. Examples of these aspects may include the financial accounts analyzed by the system, a maximum amount of funds that may be withdrawn from a financial account, an amount of funds that must be removed from a financial account, and the like.
In some embodiments, the system may automatically take the changes received from the user and use the modified constraints to re-calculate the payment disbursement ratio according to block 914, and then re-presents the payment disbursement ratio to the user according to block 916. In this manner, the system may provide instant feedback to the user. Such instant feedback may allow a user to easily visualize the impacts of the user-implemented adjustments to the constraints in real time, or near real time. Such an embodiment benefits a user by allowing the user to make minor changes to the constraints of the calculation method, while the system handles the complex calculations that go into finding an optimized payment disbursement ratio.
As shown in block 918, the process flow may include receiving from the user, via the spend user interface, an order to execute a payment plan for the financial event cost, according to the selected payment disbursement ratio. For example, the user may select a button on the spend user interface that communicates the order to the system. In some embodiments, the system may present, via the spend user interface, an impact on the user's retirement plan, based on the current calculated payment plan. As such, the system may calculate a new amount of spendable funds (e.g., otherwise described herein as an available fund amount) or the new estimated amount of time (e.g., otherwise described herein as the age parameter) based on how the proposed payment plan will change the users inflows, outflow, assets, and liabilities. As shown in block 920, the process flow may include executing the payment plan, wherein executing the payment plan comprises withdrawing funds from the one or more payment disbursement accounts based on the payment disbursement ratio, and applying the withdrawn funds to the financial event cost. In some embodiments, the system automatically withdraws and applies the funds to the financial event cost. In embodiments where the financial event cost will be due in the future, the system may “freeze” or place a hold on the identified funds so that the user or the system can ensure that the funds are available when the financial event cost is due. In some embodiments, a withdrawal date may be set that is different from the payment date, wherein the withdrawal date is the date in which the funds will be withdrawn according to the payment plan. The withdrawal date may be earlier than the payment date so that the user can be assured that the funds will be available in time to make the payment. In some embodiments, the user may make the payments, and the system may provide forms, or any other documentation available to aid the user in making the payment.
In some embodiments, the system may provide an offer to the user, wherein the offer is based on the newly structured group of accounts owned by the user. Such an offer may be for creating a new account that may help the user recover from making the payment for the financial event. For example, the system may identify an opportunity for the user to take out a second mortgage on the user's house in order to generate some or all of the funds necessary to pay for the financial event. In some embodiments, the second mortgage and its associated funds may be included in the payment disbursement ratio calculations, even before a user has created the second mortgage. Such an embodiment may allow a user to visually identify the effects of the second mortgage, especially with respect to the financial event and the user's retirement planning. The user may then select the second mortgage option, and the system may help the user set up a second mortgage with the entity. Of course, the second mortgage option is exemplary and other investment options may be used, including a loan with the entity, a home refinancing, an education investment account (ESA), a new investment account (e.g., CDs, bonds, and the like), a new savings account, or the like.
Referring to
For example, if the user selects “Financial Event 1,” from the selectable financial events 414, the system may then receive the user selection according to block 908, and then calculate a financial event cost according to block 910. The system may then determine one or more payment disbursement accounts from the group of accounts based on the account information and the financial event, in accordance with block 912. The system may then calculate a payment disbursement ratio according to block 914.
Subsequently, the system may present the payment disbursement ratio, among other things, via the spend user interface 800 from
As illustrated in
In accordance with embodiments of the invention, the term “module” with respect to a system may refer to a hardware component of the system, a software component of the system, or a component of the system that includes both hardware and software. As used herein, a module may include one or more modules, where each module may reside in separate pieces of hardware or software.
Although many embodiments of the present invention have just been described above, the present invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Also, it will be understood that, where possible, any of the advantages, features, functions, devices, and/or operational aspects of any of the embodiments of the present invention described and/or contemplated herein may be included in any of the other embodiments of the present invention described and/or contemplated herein, and/or vice versa. In addition, where possible, any terms expressed in the singular form herein are meant to also include the plural form and/or vice versa, unless explicitly stated otherwise. Accordingly, the terms “a” and/or “an” shall mean “one or more,” even though the phrase “one or more” is also used herein. Like numbers refer to like elements throughout.
As will be appreciated by one of ordinary skill in the art in view of this disclosure, the present invention may include and/or be embodied as an apparatus (including, for example, a system, machine, device, computer program product, and/or the like), as a method (including, for example, a business method, computer-implemented process, and/or the like), or as any combination of the foregoing. Accordingly, embodiments of the present invention may take the form of an entirely business method embodiment, an entirely software embodiment (including firmware, resident software, micro-code, stored procedures in a database, or the like), an entirely hardware embodiment, or an embodiment combining business method, software, and hardware aspects that may generally be referred to herein as a “system.” Furthermore, embodiments of the present invention may take the form of a computer program product that includes a computer-readable storage medium having one or more computer-executable program code portions stored therein. As used herein, a processor, which may include one or more processors, may be “configured to” perform a certain function in a variety of ways, including, for example, by having one or more general-purpose circuits perform the function by executing one or more computer-executable program code portions embodied in a computer-readable medium, and/or by having one or more application-specific circuits perform the function.
It will be understood that any suitable computer-readable medium may be utilized. The computer-readable medium may include, but is not limited to, a non-transitory computer-readable medium, such as a tangible electronic, magnetic, optical, electromagnetic, infrared, and/or semiconductor system, device, and/or other apparatus. For example, in some embodiments, the non-transitory computer-readable medium includes a tangible medium such as a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a compact disc read-only memory (CD-ROM), and/or some other tangible optical and/or magnetic storage device. In other embodiments of the present invention, however, the computer-readable medium may be transitory, such as, for example, a propagation signal including computer-executable program code portions embodied therein.
One or more computer-executable program code portions for carrying out operations of the present invention may include object-oriented, scripted, and/or unscripted programming languages, such as, for example, Java, Perl, Smalltalk, C++, SAS, SQL, Python, Objective C, JavaScript, and/or the like. In some embodiments, the one or more computer-executable program code portions for carrying out operations of embodiments of the present invention are written in conventional procedural programming languages, such as the “C” programming languages and/or similar programming languages. The computer program code may alternatively or additionally be written in one or more multi-paradigm programming languages, such as, for example, F#.
Some embodiments of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of apparatus and/or methods. It will be understood that each block included in the flowchart illustrations and/or block diagrams, and/or combinations of blocks included in the flowchart illustrations and/or block diagrams, may be implemented by one or more computer-executable program code portions. These one or more computer-executable program code portions may be provided to a processor of a general purpose computer, special purpose computer, and/or some other programmable data processing apparatus in order to produce a particular machine, such that the one or more computer-executable program code portions, which execute via the processor of the computer and/or other programmable data processing apparatus, create mechanisms for implementing the steps and/or functions represented by the flowchart(s) and/or block diagram block(s).
The one or more computer-executable program code portions may be stored in a transitory and/or non-transitory computer-readable medium (e.g. a memory) that can direct, instruct, and/or cause a computer and/or other programmable data processing apparatus to function in a particular manner, such that the computer-executable program code portions stored in the computer-readable medium produce an article of manufacture including instruction mechanisms which implement the steps and/or functions specified in the flowchart(s) and/or block diagram block(s).
The one or more computer-executable program code portions may also be loaded onto a computer and/or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer and/or other programmable apparatus. In some embodiments, this produces a computer-implemented process such that the one or more computer-executable program code portions which execute on the computer and/or other programmable apparatus provide operational steps to implement the steps specified in the flowchart(s) and/or the functions specified in the block diagram block(s). Alternatively, computer-implemented steps may be combined with, and/or replaced with, operator- and/or human-implemented steps in order to carry out an embodiment of the present invention.
While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other changes, combinations, omissions, modifications and substitutions, in addition to those set forth in the above paragraphs, are possible. Those skilled in the art will appreciate that various adaptations, modifications, and combinations of the just described embodiments can be configured without departing from the scope and spirit of the invention. Therefore, it is to be understood that, within the scope of the appended claims, the invention may be practiced other than as specifically described herein.
