Patent Grant
11574359
Many customers look for more from their financial institutions than the maintenance of checking and savings accounts. For example, customers may seek guidance relating to budgeting their funds between various expenses. Unfortunately, it is oftentimes difficult for customers to receive such services. This is especially the case for new customers, who must first register for a new account, await approval, and then identify how to receive any additional services desired from the financial institution either themselves or through contacting the financial institution directly. Thus, it would be beneficial to provide an integrated customer onboarding experience enabling a customer to both register for an account as well as additional services in a convenient manner.
One embodiment relates to a financial institution computing system associated with a financial institution. The financial institution computing system includes a network interface configured to communicate data over a network. The financial institution computing system also includes an accounts database configured to store information regarding a plurality of accounts associated with a plurality of customers of the financial institution. The financial institution computing system also includes an account management circuit configured to receive, by the network interface, a customer request to establish an account at the financial institution. In response to receiving the customer request, the account management circuit is also configured to create first and second checking accounts for the customer, the first checking account having a payment card associated therewith, the second checking account not having any payment cards associated therewith. The account management circuit is also configured to receive, by the network interface, information regarding a funding amount for the first and second payment accounts. The account management circuit is also configured to receive, by the network interface, information regarding a first expense of the customer. The account management circuit is also configured to fund the second account with a first portion of the funding amount based on the information regarding the first expense.
Another embodiment relates to a computer-implemented method. The method includes receiving, by a financial institution computing system associated with a financial institution, a customer request to establish an account at the financial institution. The method also includes creating, by the financial institution computing system, in response to receiving the customer request, first and second checking accounts for the customer, the first checking account having a payment card associated therewith, the second checking account not having any payment cards associated therewith. The method also includes receiving, by the financial institution computing system, information regarding a funding amount for the first and second payment accounts. The method also includes receiving, by the financial institution computing system, information regarding a first expense of the customer. The method also includes funding, by the financial institution computing system, the second account with a first portion of the funding amount based on the information regarding the first expense.
Another embodiment relates to a computer-implemented method. The method includes receiving, by a mobile device, a first input from a customer indicating a spending limit for the customer over a predetermined period. The method also includes receiving, by the mobile device, an indication of a deposit of an amount of funds into a first customer checking account. The method also includes determining, by the mobile device, a first portion of the amount of funds that is to be allocated towards the first checking account of the customer based on the spending limit. The method also includes presenting, by the mobile device, a first graphical user interface to the customer, the graphical user interface including a representation of the first portion and a representation of a second portion of the amount of funds allocated to a second checking account of the customer.
Before turning to the figures, which illustrate example embodiments, it should be understood that this application is not limited to the details or methodology set forth in the following description or illustrated in the figures. It should also be understood that the phraseology and terminology employed herein is for the purpose of description only and should not be regarded as limiting.
Various embodiments discussed herein relate to systems and methods for providing customers with personalized financial accounts. In various embodiments, a customer of a financial institution downloads and installs a native application onto their device (e.g., a smartphone). Upon installation on the customer device, the native application is structured to cause the customer device to present the customer with a series of registration interfaces configured to receive information from the customer and transmit the information to a financial institution computing system associated with a financial institution. Using the information, the financial institution computing system verifies the customer and generates two or more checking accounts for the customer. In an example implementation, the financial institution computing system generates two checking accounts for the customer: a customer spending account and a customer reserve account. In such an implementation, the customer spending account has a payment card associated therewith while the customer reserve account does not have a payment card associated therewith. In various embodiments, the financial institution computing system is configured to receive additional information regarding a funding amount for the spending and reserve accounts as well as expenses of the customer. Based on the expenses of the customer, the financial institution computing system allocates customer funds between the customer spending account and the customer reserve account.
Additionally, the native application on the customer device is configured to make recommendations to the customer based on the allocation of the customer's funds and the customer's financial behaviors. For example, the financial institution computing system may monitor the customer's utilization of funds allocated to the customer's spending account (e.g., an average amount the customer spends per week) to determine that the customer's spending is below a predetermined threshold (e.g., a spending limit previously established by the customer). In response to making such a determination, the financial institution computing system may provide a recommendation that the customer set aside some funds for investment or savings. As such, the systems and methods herein provide personalized recommendations based on the customer's individual spending behaviors.
The embodiments and implementations of the systems and methods disclosed herein propose a novel account registration and activation sequence in which a customer is able to establish multiple checking accounts by providing a single input to a financial institution computing system. Technically and beneficially, such a multi-account structure facilitates the presentation of various graphical user interfaces to the customer enabling the customer to monitor and manage the customer's finances. To illustrate, a graphical user interface may include a first portion including a representation of a current funding level of the customer spending account in relation to a spending limit provided by the customer and a second portion indicating a funding level of the customer reserve account. As such, the customer is made aware of both the customer's current spending level as well as a total amount of funds available in an understandable manner.
Additionally, such a multi-account structure facilitates the financial institution providing guidance to improve the financial health of the customer. In various embodiments, the customer's access to funds placed in the customer reserve account is restricted. For example funds placed in the customer reserve account may only be available for payment of a certain subset of customer expenses (e.g., the customer's utility bills). These restrictions ensure that a consistent amount of customer funds remain available for the payment of such customer expenses. Additionally, such a process facilitates the presentation of expense information to the customer. For example, on a graphical user interface, each customer expense may have a payment envelope associated therewith. Each envelope may include an amount owed by the customer by a certain date as well as an adjustable allocation amount. In various embodiments, the systems and methods disclosed herein provide suggested allocation amounts to the customer and dynamically update the envelopes in accordance with allocation inputs provided by the customer. As such, the systems and methods herein provide a unique platform for customers to micro-manage both incoming funds and expenses.
Referring now to
The customer device 110 is a computing device associated with the customer. In various embodiments, the customer may utilize the customer device 110 to register for accounts at the financial institution and view various graphical user interfaces containing information pertaining to the customer's accounts. Examples of the customer device 110 include, for example, personal computing devices such as a desktop or a laptop computer, and mobile computing devices such as smartphones, tablets, and wearable computing devices such as smartwatches and the like.
In the example shown, the customer device 110 includes a customer network interface 112 configured to communicate data over the network 130, a customer I/O device 114, and a financial institution client application 116. The customer I/O device 114 includes hardware and associated logics configured to enable the customer device 110 to exchange information with a customer (e.g., via a touch display, microphone, camera) and other devices. The customer I/O device 114 may include systems, components, devices, and apparatuses that serve both input and output functions, configured to exchange information with external systems (e.g., merchant point of sale devices, computing devices associated with other individuals). Such systems, components, devices and apparatuses include, for example, radio frequency transceivers (e.g., RF or NFC-based transceivers) and other short range wireless transceivers (e.g., Bluetooth©, laser-based data transmitters, etc.).
The financial institution client application 116 is structured to enable the customer to establish and manage financial accounts. Accordingly, the financial institution client application 116 is communicably coupled via the customer network interface 112 over the network 130 to the financial institution computing system 120. In some embodiments, the financial institution client application 116 includes a circuit embodied within the customer device 110. For example, the financial institution client application 116 may include program logic stored in a system memory of the customer device 110. In such arrangements, the program logic may configure a processor of the customer device 110 present the user with various graphical user interfaces based on information regarding customer accounts. In some embodiments, the financial institution client application 116 is at least partly web-based. As will be understood, the level of functionality that resides on the customer device 110 versus the financial institution computing system 120 will vary depending on the implementation.
In some embodiments, the displays presented to the customer via the financial institution client application 116 are configured to receive information from the customer to establish an account at the financial institution. Examples of such interfaces are described in more detail with respect to
In some embodiments, the financial institution client application 116 includes program logic configured to cause the customer device 110 to process and manipulate customer financial data received from the financial institution computing system 120 over the network 130. For example, in response to funds being deposited into the customer's spending account, the financial institution computing system 120 may transmit updated account balance information to the customer device 110. In response, the customer device 110, via the financial institution client application 116, may manipulate such information using predetermined parameters to determine an allocation of the deposited funds between the customer spending account and the customer reserve account. In some arrangements, the allocation is based on preferences indicated by the customer. In some arrangements, the allocation is a default allocation determined by the financial institution. For example, the customer device 110 may allocate an amount of the deposited funds into the customer spending account that corresponds to a spending limit established by the customer and the remainder of the funds into the customer reserve account.
In some embodiments, the financial institution client application 116 includes an allocation algorithm, process, method, and/or other type of control framework configured to cause the processor of the customer device 110 to allocate customer funds placed into the customer reserve account among various expenses of the customer. For example, the customer device 110 may receive (e.g., from the financial institution computing system 120) information regarding bills (e.g., rent, utility bills, service provider bills) of the customer describing various amounts owed by the customer to recipients by predetermined dates. The allocation algorithm may include a prioritization scheme that designates portions of available funds to each customer bill based on the amount and due date of each payment. Additionally, such an allocation may be used to present the customer with a payment interface configured to present the customer with depictions of upcoming payments owed by the customer and configured to receive inputs from the customer to make such payments in accordance with the allocation.
The financial institution client application 116 may also include monitoring logic configured to track the customer's utilization of accounts and provide recommendations to the customer in response to the detection of certain patterns. For example, such monitoring logic may cause the customer device 110 to compare an amount of customer spending over a predetermined period to a spending limit established by the customer. If the customer's spending level is below the spending limit by more than a first threshold for a predetermined percentage of periods (e.g., weeks, months), for example, the customer may be presented with a suggestion to set aside funds for investment. Alternatively, if the customer's spending level is consistently above the spending limit, the customer may be presented with suggestions on how to reduce spending levels.
In some embodiments, the customer device 110 includes a mobile wallet application (not shown) structured to facilitate and permit payments by interfacing with various accounts held by the customer (e.g., including accounts established via the financial institution client application 116). The mobile wallet client application is structured to permit the customer to engage in transactions via communication with, for example, a merchant point of sale (“POS”) device via an established communication channel (e.g., near field communications) in accordance with any known standard.
The financial institution computing system 120 is a computing system associated with the financial institution configured to establish and maintain customer accounts. In the example shown, the financial institution computing system 120 includes a network interface 122 configured to communicate data over the network 130, an account management circuit 124, and an accounts database 126. The accounts database 126 is structured to retrievably store information pertaining to accounts held by a number of customers at the financial institution. The accounts database 126 may include non-transient data storage mediums (e.g., local disc or flash-based hard drives, local network servers) or remote data storage facilities (e.g., cloud servers). The accounts database 126 may include personal customer information (e.g., names, addresses, phone numbers), identification information (e.g., driver's license numbers, standard biometric data), and customer financial information (e.g., token information, account numbers, account balances, available credit, credit history, transaction histories).
The account management circuit 124 is configured to create, hold or store, and manage the financial accounts of various customers. In some instances, such management includes maintaining and handling transaction processing for various customer accounts. In some embodiments, the financial institution client application 116 is at least partly provided by the account management circuit 124. In this regard, the account management circuit 124 is configured to communicate information utilized by the customer device 110 to render the various interfaces described herein to the customer. Such information may include, for example, customer account balance information, information regarding customer deposits into the accounts, upcoming payments owed by the customer to various entities, and suggested allocations of customer funds. For example, in some embodiments, the account management circuit 124 performs the operations discussed above with respect to the customer device 110 to allocate customer funds between the customer spending and reserve accounts and allocate customer funds among payments owed by the customer.
In various embodiments, the account management circuit 124 is configured to approve the customer for a checking account at the financial institution based on information gathered from the customer via the financial institution client application 116. For example, the account management circuit 124 may communicate with various external computing systems (e.g., credit bureaus, public databases, social media databases) to verify the identity of the customer and determine that the customer is eligible for an account at the financial institution. In response to determining that the customer is eligible, the account management circuit 124 may generate at least two checking accounts (e.g., the customer reserve account and the customer spending account) for the customer.
In this regard, the account management circuit 124 may assign a primary account number and a secondary account number to the customer. For example, the account management circuit 124 may maintain a queue of account numbers that are yet to be assigned to any customers of the financial institution. In response to determining the eligibility of the customer for an account, the account management circuit 124 may designate two such account numbers for the customer. Alternatively, the account management circuit 124 may utilize a random number generator to generate the primary and secondary account numbers for the customer in real time in response to the customer's approval. The primary account number may be associated with the customer reserve account and may be used by the customer to identify an account to which future deposits are to be made. The secondary account number may be associated with the customer spending account. In alternative embodiments, the primary account number (i.e., the account number that the customer uses to deposit funds) may be associated with the customer spending account rather than the customer reserve account. As described herein, the account management circuit 124 may allocate various deposits made by the customer between the customer spending account and the customer reserve account.
In various embodiments, the customer spending account has a payment card (e.g., a debit card, an Automated Teller Machine card) associated therewith. Accordingly, the account management circuit 124 may also generate a card number (e.g., in accordance with the ISO/JEC 7812 standard) for the customer spending account and transmit the card number to a card network computing system to have additional parameters (e.g., the card verification value) associated with the card number. Once all of these parameters are associated with the card number have been generated, the account management circuit 124 may initiate a sequence to generate a physical payment card containing such parameters and send the physical payment card to the customer.
In some embodiments, then, the customer's primary account number is associated with the customer reserve account, while the customer's payment card is associated with the customer spending account. Put differently, the account to which the customer deposits funds is separated from a mechanism (the payment card) through which the customer withdraws funds. Such an arrangement beneficially facilitates limiting the customer's spending. Since the customer's deposits are routed to the customer reserve account, portions of the deposits must then be transferred to the customer spending account to render funds available for everyday customer spending. The requirement of such transfers encourages the customer to establish the customer spending limit as, in some embodiments, the customer spending limit is tied to a periodic transfer between the customer reserve account and the customer spending account. Additionally, these transfers create opportunities to notify the customer about other additional aspects of the customer's finances. As described herein, to transfer funds to the customer spending account, the customer must view graphical user interfaces that display information regarding other payment obligations of the customer. As such, the customer is made aware of the context in which additional spending is taking place.
In some embodiments, the account management circuit 124 is configured to digitally activate the payment card in response to receiving a customer preference/input to activate the account. In some embodiments, the customer may provide such an input upon receiving the physical payment card by, for example, calling or otherwise contacting the financial institution. In some embodiments, the customer may provide such an input by indicating a preference to provision the customer spending account to a mobile wallet of the customer.
In some embodiments, the account management circuit 124 is configured to communicate with various external computing systems regarding transfers of funds into and out of the customer's spending and reserve accounts. For example, the customer may provide information (e.g., via a digital form or the like) regarding the customer spending account to an entity (e.g., an employer) from which the customer is to receive a periodic payment. The entity may electronically (e.g., via an Automated Clearing House transaction) transfer funds into the customer spending account via the network 130. Additionally, in various embodiments, the customer may provide information regarding various expenses of the customer. For example, the customer may provide information regarding various accounts (e.g., billing accounts) held by the customer at external entities (e.g., landlords, utilities, other service providers). In response, the account management circuit 124 may formulate requests to have the external entities (e.g., via associated computing systems) provide digital or e-bills to the financial institution computing system 120. Upon a customer payment becoming due or the customer indicating a preference to make a payment, the financial institution computing system 120 may transfer funds from the customer reserve account to an external entity associated with the payment.
Referring now to
At process 202, a customer input to download the financial institution client application 116 is received. For example, in some embodiments, the customer may utilize a web browser on the customer device 110 to access a website provided by the financial institution computing system 120 and provide an input to download the financial institution client application 116. Alternatively or additionally, the customer may provide such an input via an application (e.g., an application store) on the customer device 110.
At process 204, the financial institution client application 116 is transmitted to the customer device 110. For example, in some embodiments, the account management circuit 124 may transmit the financial institution client application 116 to the customer device 110 in response to the customer providing the input received at process 202 from the financial institution website. Alternatively, an external server (e.g., associated with the application store) may transmit the financial institution client application 116 to the customer device 110, register the customer device (e.g., assign a unique identifier to the customer device), and provide the unique identifier and customer identifying information (e.g., a customer name) to the financial institution computing system 120, which may create an entry for the customer in the accounts database 126 (or another database).
In some embodiments, upon the customer initiating the financial institution client application 116 on the customer device 110, the financial institution client application 116 cause the customer device 110 to present the customer with a number of registration interfaces configured to receive information from the customer needed to establish a checking account. Examples of such interfaces are described with respect to
At process 208, the account management circuit 124 verifies the customer based on the received registration information and approves the customer for an account at the financial institution. In some embodiments, the account management circuit 124 takes various steps to verify the identity of the customer. For example, if an image of a form of customer identification is received, the account management circuit 124 may verify the authenticity of the form of identification by assessing, analyzing, or otherwise determining the image for various authenticity signatures (e.g., logos, markings, coloring schemes) associated with a legitimate form of customer identification. Additionally, the account management circuit may verify the identity of the customer based on a phone number provided by the customer (e.g., via communications with an external service provider maintaining a database of registered phone numbers). Additionally, the account management circuit 124 may query various external databases (e.g., public databases, databases maintained by credit bureaus) to determine the customer's eligibility for an account. As used herein, the term “eligibility,” when used in relation to determining whether to open an account for a customer, refers to a set of qualifications that must be met in order the opening of an account to take place. Such qualifications may be established by the financial institution. For example, one such qualification is that the customer is not on any blacklists of known bad actors, as required by the Customer Identification Program. Another may be that the customer does not have a history of fraud, and/or has a credit score that is above a threshold. Any qualification used in determining whether to open an account for a customer is consistent with this term.
At process 210, in response to determining that the customer is eligible for an account, the account management circuit 124 may establish a number of checking accounts for the customer. In an example implementation, the account management circuit establishes two checking accounts for the customer: a customer reserve account and a customer spending account. In such an implementation, the account management circuit 124 may generate (i) a primary account number to be associated with the customer reserve account, (ii) a secondary account number to be associated with the customer spending account, and (iii) a payment card number for the customer. Additionally, the account management circuit 124 may store the generated account numbers in the accounts database 126 in association with the registration information obtained from the customer.
The generation of multiple checking accounts in response to a single account registration input represents a departure from conventional practices. Typically, account opening procedures only enable the customer to establish a single checking account as well as potentially a savings account. Such an account structure places limitations on the types of services that can be provided for the customer. Financial institutions are generally limited in their ability to restrict access to the customer's funds in traditional checking accounts (e.g., as long as the customer maintains a balance above a limited threshold, the customer may withdraw funds from the checking account at will). This makes it difficult for financial institutions to allocate funds in the customer's checking account, as there is little to no reliability in the account balance information. Additionally, the customer's ability to transfer funds from a typical savings account is heavily restricted (e.g., the bank may limit the customer's ability to withdraw funds). As such, any funds placed into the customer's savings accounts are generally unavailable for use in many types of transactions. Put differently, the customer's access to funds is basically binary: either the customer has total access to funds (when in the checking account), or limited access to funds (when in the savings account). Such a difference in accessibility may lead to the customer over-allocating funds to the customer checking account (so as to render more funds immediately available), which may facilitate negative customer spending habits (e.g., over spending and lack of saving).
Technically and beneficially, the systems and methods disclosed herein, by effectively replacing the savings account with an additional checking account, facilitates the financial institution immediately providing an array of financial services to the customer. For example, the customer may generally have unrestricted access to funds placed in the customer spending account. While access to funds placed in the customer reserve account is generally more restricted than in a traditional checking account, such funds may be used for more purposes than those deposited in savings accounts. For example, in various embodiments, funds in the customer reserve account may only be used for transactions meeting certain rules established by the financial institution. To illustrate, the financial institution may maintain a directory of payees (e.g., service providers) to which funds in customer reserve accounts may be transferred. The presence of this particularized account including funds that may be provided to a designated set of payees encourages the customer to set aside funds into the account, thereby ensuring that customer funds are available for the payment of certain customer expenses.
In various embodiments, to utilize the funds placed in the customer reserve account for purposes other than making payments to the designated set of payees, the customer must transfer funds to the customer spending account from the customer reserve account. However, because funds placed in the customer reserve account are allocated amongst various customer payments (e.g., as described with respect to
At process 212, the account management circuit 124 funds the customer spending account and the customer reserve account. In one embodiment, the registration interfaces described above may request the customer to input information regarding an account to be used by the customer to provide an initial deposit into the customer's new account. Using such information, account management circuit 124 may formulate a transaction request including a deposit amount (e.g., provided by the customer via a registration interface) and the account number provided by the customer and transmit the request to another financial institution via the network 130. The other financial institution may approve the transaction and authorize the financial institution computing system 120 to transfer funds to the customer's new account. Thus, this embodiment describes an electronic money transfer process that is used to fund the customer's account. While this is the preferred embodiment, in another embodiment, a non-electronic transfer may be used. In this implementation, a funding amount of the customer is withdrawn from the customer's existing account. The withdrawn amount may be in the form of a check, cashier's check, cash, and the like. In this instance, the user may have to visit a branch location, upload, or otherwise use these funds to fund the new account. Of course, the financial institution client application 116 may use a check deposit feature (e.g., snap a picture of the check) to alleviate the customer's need to go to the branch location and enable a remote sign-up process.
In some embodiments, as a default, the totality of the initial deposit is placed into the customer spending account. This way, upon the customer activating the payment card associated with the spending account, a substantial amount of the initial deposit (e.g., the amount of the initial deposit less a mandatory minimum balance set by the financial institution) is available for use by the customer. In an alternative embodiment, the totality of the initial deposit is placed into the customer reserve account and all or a portion of the initial deposit is transferred to the customer spending account upon receiving an additional input from the customer (e.g., the customer providing a spending limit). This way, the customer is prevented from utilizing the initial deposit until a spending limit is established, thereby encouraging the customer to establish a spending limit and take full advantage of the financial guidance provided via the financial institution client application 116.
At process 214, the account management circuit 124 receives a customer input to create a spending limit. For example, upon approving the customer for an account at process 208, the financial institution computing system 120 may transmit a notification signal, communication, or message to the customer device 110 (e.g., a text message, an email, a notification generated and provided via the client application, etc.) which, in response, may present account management interfaces to the customer. The account management interfaces may enable the customer to establish a spending limit with respect to the customer's new account. Upon the customer indicating a preferred spending limit over a predetermined period, the account management circuit 124 establishes the spending limit at process 216 by storing the provided limit in association with the customer's account. As described herein, the spending limit may be utilized in determining amounts to be allocated to the customer spending account and the customer reserve account, and to provide recommendations to the customer.
In various embodiments, funds placed in the customer reserve account are generally set aside for a subset of payments (e.g., bills) owed by the customer and/or other financial goals of the customer such as savings funds. As such, payments made by the customer in relation to other transactions (e.g., at a brick-and-mortar or an online merchant) are generally deducted from the customer spending account. Given this difference in the intended use of funds placed in either account, the customer's access to funds placed in the customer reserve account is generally more restricted than the customer's access to funds placed in the customer spending account. For example, in one embodiment, funds placed in the customer reserve account are unavailable for general use unless the balance of the customer spending account is below a predetermined amount (e.g., the amount of a transaction requested received by the financial institution computing system 120). In another embodiment, funds in the customer reserve account are unavailable for use in general transactions unless the customer authorizes a transfer between the customer spending account and the customer reserve account.
Given this difference in availability of customer funds placed in customer spending and reserve accounts, the initial allocation of funds between the spending and reserve accounts determines the immediate availability of the funds. As described herein, this initial allocation may be done in a number of different ways. For example, in one embodiment, the customer may select an option wherein any available customer funds exceeding the customer spending limit are placed into the customer reserve account to facilitate the customer spending below the spending limit. In another embodiment, the customer may select another option that allocates any available customer funds exceeding a total amount of upcoming payments owed by the customer (e.g., received via the method 400 described in relation to
In some embodiments, the account management circuit 124 utilizes the customer spending limit to establish a transaction rule or rule set for the customer's spending account. In some embodiments, the account management circuit 124 utilizes the transaction rule set in the process of approving customer transactions using the customer spending account. For example, in response to receiving a request to deduct funds from the customer spending account (e.g., from a merchant computing system over the network 130), the account management circuit 124 may add an amount in the request to an amount spent by the customer within a predetermined period (e.g., a week). In some embodiments, if the summation of the amounts is above the spending limit, the account management circuit 124 denies the transaction request. In some embodiments, if the summation of the amounts exceeds the spending limit, the account management circuit 124 transmits a notification to the customer device 110 and requests approval from the customer prior to allowing the merchant to deduct the funds.
In some embodiments, the account management interfaces identify other cards that the customer wishes to associate with the new account (hereafter referred to as “companion cards”). For example, the customer may input information regarding a card associated with another customer or another account at the financial institution that the customer wishes to use in concert with the payment card associated with the new account. In response to receiving such information, the account management circuit 124 may determine if the provided account information pertains to an account belonging to another customer. If the customer identifies an account owned or partly owned by another customer, the account management circuit 124 may seek permission from the other customer (e.g., by sending a message via a mobile banking application or e-mail). Upon the other customer providing permission, the account management circuit 124 may crosslink the customer's new account (e.g., the customer spending account) with the account of the other customer.
Through such crosslinking of accounts, financial advising tools (e.g., such as spending alerts) established by the customer with respect to the new account also apply to the crosslinked account. In an example, if, via the methods described herein, the customer establishes a $100 spending limit for the new customer account and identifies another companion card, the spending limit applies to the amount spent using both the customer's new account as well as the companion card. As such, the systems and methods disclosed herein enable related customers to manage combined spending even if one of the accounts was not created via the financial institution client application 116.
Additionally, the account management interfaces may also enable the customer to provide an input to provision the payment card associated with the customer's new account to a digital or mobile wallet. For example, the financial institution client application 116 may include a deep linking feature configured to activate a mobile wallet client application (e.g., a mobile wallet client application provided by the financial institution associated with the financial institution computing system 120, or other external mobile wallet providers such as Apple Pay®, Android Pay®, and/or Samsung Pay®) on the customer device 110 in response to the customer indicating a preference to provision the payment card to the mobile wallet. From within the mobile wallet application the customer may provide information relating to the payment card associated with the customer's new account, thereby causing the mobile wallet provider to tokenize the payment card and provision the payment card to the customer's mobile wallet. Beneficially, this linking enables the customer to engage in transactions using the payment card via the customer device 110. Example account management interfaces are described with respect to
Referring now to
Referring now to
In some embodiments, the digital wallet provisioning button 352 enables the customer to provision the customer spending account to mobile wallets provided by external computing systems. In this regard, in response to the customer selecting the digital wallet provisioning button 352, the account management circuit 124 communicates the card number associated with the customer spending account to such external computing systems, which tokenizes the card number to render the card number usable within other mobile wallet applications on the customer device 110. The spending limit button 354 is configured to receive a customer preference to establish a spending limit. The account action interface 348 also includes a skipping button 356 configured to receive a customer input to not perform any of the additional actions.
Referring now to
Referring now to
Referring now to
Additionally, as described herein, the financial institution computing system 120 or the customer device 110 may track the customer's spending in each of the categories depicted via the icons 370, 372, 374, 376, 378, and 380 to provide insights to the customer as to the customer's level of spending in each category. For example, in some embodiments, the financial institution computing system 120 maintains a directory of merchants that associates a number of different merchants with each of the categories. Upon the customer performing a transaction via the customer spending account, the financial institution computing system 120 accesses the directory and, based on the merchant, categorizes the transaction and updates the customer's transaction history accordingly. This way, the customer may view the transactions conducted in each category.
In some embodiments, the financial institution computing system 120 is configured to deny transaction requests that cause the customer to spend more than a spending limit in a particular category. Alternatively or additionally, in response to receiving such a transaction request, the financial institution computing system 120 may provide a notification to the customer device 110 to seek approval from the customer prior to authorizing such a transaction. This way, not only is the customer potentially prevented from generally spending more than a desired amount, but also prevented from spending more than a desired amount in a particular category.
Referring now to
At process 402, the account management circuit 124 receives information regarding one or more expenses of the customer. In some embodiments such information may be received from the customer device 110. For example, in some embodiments, the financial institution client application 116 causes the customer device 110 to present the customer with a graphical interface configured to receive information regarding the customer's bills or any other expenses, which includes recurring and non-recurring expenses. An example of such a graphical user interface is described with respect to
Using such information, the account management circuit 124 may request information the identified entities. For example, using a customer account number associated with a particular service provider, the account management circuit 124 may request an e-bill from a computing system associated with the service provider. The e-bill may contain information regarding a payment owed by the customer such as an amount and due date. In some embodiments, the account management circuit 124 is configured to extract information regarding a payment owed by the customer from the e-bill and transmit such information to customer device 110 to assist in the rendering of various graphical user interfaces described herein.
At process 404, the account management circuit 124 receives information regarding an amount of funds to be placed into the customer spending account and customer the customer reserve account. In some embodiments such information may be received from the customer device 110. For example, in some embodiments, the financial institution client application 116 causes the customer device 110 to present the customer with a graphical interface configured to receive information regarding a deposit into the customer spending account and the customer reserve account. An example of such a graphical user interface is described with respect to
At process 406, the account management circuit 124 determines if the amount of funds to be deposited in the account is greater than a customer spending limit (e.g., established via the method 200 described with respect to
At processes 408 and 410, if the customer has deposited more than the spending limit, the account management circuit 124 is configured to allocate a first portion of the amount of funds to the customer reserve account based on the expense information and allocate a second portion of the amount of funds to the customer spending account. In some embodiments, the account management circuit 124 is configured to initially allocate an amount corresponding to the customer spending limit into the customer spending account. The account management circuit 124 then compares the amount of the remaining funds to a combined amount of expenses owed by the customer within a predetermined period (e.g., a week, a month). If there are sufficient remaining funds to timely pay the customer's expenses, the account management circuit 124 may deposit an amount corresponding to the customer expenses into the customer payments. As the expenses become due, the account management circuit 124 may transfer funds from the customer reserve account to accounts of entities to which the customer owes payment.
In some embodiments, if there are insufficient remaining funds to timely pay the customer expenses, the account management circuit 124 may transmit an allocation suggestion to the customer device 110. The allocation suggestion may, for example, suggest that the customer reallocate funds from the customer spending account to the customer reserve account to provide the customer reserve account with sufficient funds to timely pay the customer expenses.
At process 412, the account management circuit 124 allocates the funds placed in the customer reserve account to the customer expenses. In an example, if there are sufficient funds available to timely pay all of the customer expenses, the account management circuit 124 divides the funds placed into the customer reserve account between each expense in accordance with the amount of each expense. However, if there are insufficient funds available to timely pay all of the customer expenses, the account management circuit 124 may generate an allocation between the customer expenses. In various embodiments, the account management circuit 124 generates an allocation using a prioritization algorithm that prioritizes the customer expenses based on a due date and amount. Generally speaking, customer expenses having greater amounts and having sooner due dates will receive a greater allocation.
In some embodiments, the account management circuit 124 allocates the available customer funds based on the entities to which the customer owes payments. For example, the financial institution computing system 120 may maintain a database storing information regarding the payment policies of various entities. The payment policies may include information pertaining to fees for late payments. In such an embodiment, the account management circuit 124 may retrieve payment policy information relating to the entities identified by the customer and allocate the available customer funds based on projected late fee amounts.
In various embodiments, once the account management circuit 124 generates an allocation, the allocation may be transmitted to the customer device 110 over the network 130 to render an allocation graphical user interface to the customer. The allocation graphical user interface may include representations of the amounts allocated to the customer spending account and the customer reserve account. The allocation graphical user interface may also include amounts allocated to upcoming payments owed by the customer. An example allocation graphical user interfaces are described with respect to
At process 414, the account management circuit 124 determines if the customer has any remaining funds. For example if the total available amount of funds (e.g., the combination of an initial account balance and a deposit of customer funds into the customer spending account and the customer reserve account) exceeds the total amount of customer expenses by more than the customer spending limit, the account management circuit 124 may determine that there are remaining customer funds.
At process 416, the account management circuit 124 prompts the customer to allocate any remaining funds. In some embodiments, the account management circuit 124 may initially allocate any remaining customer funds to the customer spending account, but indicate to the customer that such remaining funds are unallocated. This way, the remaining funds are available for utilization by the customer in payment card transactions. Alternatively, the account management circuit 124 may initially allocate any remaining customer funds to the customer reserve account, but indicate to the customer that such remaining funds are unallocated. Alternatively, the account management circuit 124 may initially allocate a first portion (e.g., a first half) of the remaining funds to the customer spending account and a second portion of the remaining funds to the customer reserve account (e.g., a second half). This way, the customer has a portion of the remaining funds for payment card transactions, and a portion set aside for future expenses of the customer that may become due.
In some embodiments, the account management circuit 124 facilitates the transmittal of an allocation notification to the customer device 110. The allocation notification may include a push notification (e.g., transmitted via a push notification service) alerting the customer of an unallocated amount, and prompt the customer to sign into the financial institution client application 116 to provide an input to allocate the remaining amount.
Referring now to
As shown, the expense graphical user interface 500 includes a payment addition window 502 and an entity identifying window 506. The payment addition window 502 includes a plurality of classifications of various entities to which the customer may owe payments. Next to each classification is an addition button 504. As indicated by the emboldened addition button 504, upon the customer selecting a particular addition button 504, the customer device 110 may retrieve a listing of entities associated with the selected classification (e.g., from a database maintained at the financial institution computing system 120) and use the retrieved listing to populate the entity identifying window 506. The entity identifying window 506 enables the customer to select an entity from the listing of entities at which the customer has an account.
In some embodiments, upon the customer selecting a particular entity, the customer may be brought to an additional interface enabling the customer to input an account number of the customer at the entity. As described herein, the financial institution computing system 120 may utilize such information to receive information regarding payments owed by the customer from an external computing system and make such payments using funds placed into the customer reserve account. Additionally, the customer may input additional preferences as to making payments to a particular entity. For example, the customer may indicate a preference to have the customer's bills paid automatically.
Referring now to
As shown, the deposit graphical user interface 508 includes a government benefit button 510, a direct deposit button 512, and a skipping button 514. The government benefit button 510 is configured to receive a customer preference to deposit government benefits into the customer's account. In response to the customer selecting the government benefit button 510, the customer may be presented with another interface enabling the customer to identify a government benefit (e.g., from a dropdown menu) and input information (e.g., an account number) associated with the benefit. The financial institution computing system 120 may utilize such information to request that the customer's benefits be deposited into the customer spending and reserve account. The direct deposit button 512 is configured to receive a customer preference to have a paycheck or the like deposited into the customer's spending and reserve accounts. In some embodiments, in response to the customer selecting the direct deposit button 512, the financial institution computing system 120 may send the customer or employer of the customer a form (e.g., via e-mail, the financial institution client application 116, or paper-based mail) to establish the customer account's as a direct deposit account. The skipping button 514 is configured to receive a customer preference to skip adding any deposits to the customer's spending and reserve accounts.
Referring now to
As shown, the account management graphical user interface 516 includes a spending limit portion 518, an account balance portion 520, and a navigation portion 522. The spending limit portion 518 includes a representation of the customer spending limit (e.g., established via the method 200 discussed above). For example, the spending limit portion may include an amount remaining and a predetermined period before reaching the spending limit for the predefined period. The amount remaining may be the customer spending limit less the amounts of any transactions engaged in by the customer since the initiation of a spending limit period. The account balance portion 520 includes a representation of the total amount of customer funds in both the customer spending account and customer reserve account. As such, even though the customer has two separate checking accounts, the financial institution client application 116 provides the appearance that the customer has only a single checking account, thus simplifying the process of managing the account for the customer.
The navigation portion 522 provides the customer with access points to various functionalities described herein. As shown, the navigation portion 522 includes a dynamic icon 524, an advising icon 526, a transaction icon 528, and a navigation dialogue box 530. In some embodiments, the dynamic icon 524 updates depending on various actions taken by the customer within the financial institution client application 116. For example, if the customer is yet to provision the payment card associated with the customer spending account to the customer's digital wallet, the dynamic icon 524 may be configured to receive a customer preference to provision the payment card to the digital wallet. For example, the dynamic icon 524 may provide an input to program logic configured to interface with program logic of a mobile wallet application on the customer device 110, which may enable the customer to provision the payment card to the digital wallet. Alternatively or additionally, the dynamic icon 524 may cause the customer device 110 to transmit a provisioning signal to the financial institution computing system 120, which may (e.g., via the account management circuit 124) perform a process to provision the digital payment card to the customer's digital wallet.
In various embodiments, the dynamic icon 524 updates based on the most recent notification received by the customer from the financial institution computing system 120 within a predetermined period. If no notifications are received within the predetermined period, the account management graphical user interface 516 may not include the dynamic icon 524 (or it may be grayed out, or provided with an indicator that alerts the user to the fact that no notifications were received).
The advising icon 526 is configured to receive a customer input to view various recommendations generated by the customer device 110 and/or financial institution computing system 120 in accordance with the systems and methods disclosed herein. As described herein, program logic of the customer device 110 or the financial institution computing system 120 may be configured to assess account balance information and the customer's transaction history to make various recommendations to the customer. Upon the customer selecting the advising icon 526, the customer may be brought to another interface containing such suggestions.
The transaction icon 528 is configured to receive a customer preference to view upcoming payments owed by the customer (e.g., obtained via the customer entered information into an interface such as the expense graphical user interface 500 discussed with respect to
Referring now to
Referring now to
In some embodiments, the account balance portion 542 is similar to the account balance portion 520 described with respect to
In the example shown, the icons 548 in each transaction entry reflect the type of transaction. The icons may be identical to the icons 370, 372, 374, 376, 378, and 380 described with respect to
In some embodiments, the entries in the transaction portion 546 show up in a predetermined order. For example, in one embodiment, the transactions show up in chronological order. As such, the customer's most recent transaction may show up in the leftmost entry of the transaction portion 546, and the oldest transaction may show up in the rightmost entry. The customer may scroll to the left to view entries associated with older transactions. In some embodiments, the icons 548 are selectable by the customer to bring the customer to an additional graphical user interface containing information regarding the transaction associated with the icon 548. For example, such a graphical user interface may include the specific merchant and timing of the transaction, as well as any receipts stored in association with the transaction.
The navigation portion 552 includes various icons enabling the customer to take various other actions with respect to the customer spending account and the customer reserve account. For example, the navigation portion 552 may include a payment icon enabling the user to make a payment via the customer's mobile wallet (e.g., via a separate mobile wallet client application on the customer device 110 or via a wallet functionality integrated into the financial institution client application 116), a bill payment icon enabling the customer to view upcoming payments, as well as a deposit icon enabling the customer to transfer money to the customer's reserve account. In some embodiments, the navigation portion 552 includes an icon depicting a person-to-person payments functionality enabling the customer to select a person to transfer funds from the customer spending account to. Additionally, the navigation portion 552 includes a navigation dialogue box 530 as described with respect to
Referring now to
Referring now to
The allocation portion 566 includes a plurality of entries 568, 570, and 572. Each of the entries 568, 570, and 572 is associated with an envelope to which the customer may add a portion of the unallocated funds to. As will be appreciated, the allocation graphical user interface 560 may include any number of entries. In the example shown, the entry 568 is associated with a spending re-load envelope. The spending reload envelope depicts to the customer an amount that is scheduled to be transferred to the customer spending account upon the expiration of a period associated with the customer spending limit (e.g., at the beginning of the next week). The entry 570 depicts the current balance of the customer spending account, and the entry 572 depicts an amount currently allocated to an electric bill of the customer. Each entry includes a slide bar depicting a range of amounts that may be associated with each envelope if the customer allocates a portion of the unallocated funds to the envelope. In various embodiments, the customer may select each of the slide bars and allocate a portion of the unallocated funds to each envelope.
Referring now to
In some embodiments, the entries in the commonly used functionality portion 576 are populated based on the customer's history of using the financial institution client application 116. For example, each time the customer accesses a particular feature of the financial institution client application 116, the customer device 110 may add an entry to a customer activity log. To populate the commonly used functionality portion 576, the customer device 110 may access the activity log and identify a predetermined number (e.g., two) of functionalities that have been used the most within a predetermined period (e.g., a month). As such, the commonly used functionality portion 576 may be dynamically updated based on the customer's utilization of the financial institution client application 116. Thus, the navigation dialogue box 530 provides the customer with access to both a specific subset of functionalities (e.g., associated with the term the customer enters) as well as the functionalities most commonly used. This enables the customer to efficiently navigate through the financial institution client application 116.
Referring now to
The financial trends portion 584 includes graphical depiction of the customer's finances. For example, the financial trends portion 584 includes graphs depicting the customer's level of spending, bill payments, and account balance over the course of a number of months. Each graphical depiction includes a target amount as well as an average amount. For example, in one embodiment, the graphical depiction of the customer's level of spending includes the customer's spending limit as well as the average level of customer spending. This way, the customer is able to efficiently view their spending in relation to a target level. As such, the financial summary graphical user interface 580 provides the customer with a broad overview of aspects of the customer's financials.
Referring now to
At process 602, an indication of a deposit to the customer's spending account is received. In some embodiments, the customer may enter information regarding an alternative banking account of the customer and a deposit amount into a funding interface (e.g., similar to the graphical user interface 336 discussed with respect to
At process 604, the deposit to the customer's spending account is allocated to the customer's spending and reserve accounts based on a customer spending limit. For example, the account management circuit 124 may determine a current balance of the customer's spending account and compare the amount to a customer spending limit. If the current balance is below the spending limit, the account management circuit 124 may allocate a portion of the deposit corresponding to the difference to the customer spending account. Alternatively or additionally, the account management circuit 124 may allocate a predetermined amount to the customer spending account. The predetermined amount may be determined based on a deposit schedule (e.g., based on the customer's income and the frequency that the customer receives deposits from an employer). The predetermined amount may be set such that an amount corresponding to the customer spending limit is transferred into the customer spending account each spending limit period (i.e., the period to which the customer spending limit applies, such as a month). In some embodiments, after the initial deposit into the customer's spending account, the remaining funds are allocated to the reserve account.
At process 606, upcoming payments owed by the customer are identified. In some embodiments, the account management circuit 124 retrieves information regarding customer expenses from the accounts database 126 (e.g., information regarding bills or other expenses of the customer), and identifies payments owed by the customer within a predetermined period (e.g., week, month, etc.). In some embodiments, the account management circuit 124 requests information regarding customer expenses from external computing systems and identifies the upcoming customer payments based on information received from such external systems. In some embodiments, the customer device 110 requests such information from the financial institution computing system 120, which may return the information to the customer device 110 for identification of the upcoming payment of the customer.
At process 608, the total amount of the upcoming payments owed by the customer is compared with the current balance of the reserve account balance. If the customer has sufficient finds in the customer reserve account, method 600 moves on to process 616 to transmit funds to recipients of the upcoming customer payments. However, if there are insufficient funds in the customer reserve account to make all of the upcoming payments owed by the customer, additional funds are requested from the customer at process 610. In an embodiment, the account management circuit 124 facilitates a push notification being provided to the customer (or any other type of notification and request to the customer). An example push notification is described with respect to
At process 612, a determination is made whether the customer provided sufficient funds to timely make the upcoming payments owed by the customer. Such a determination may be made by either the customer device 110 or the account management circuit 124 based on a customer response to the message presented to the customer at process 610. If the customer provided sufficient funds to timely make the upcoming payments the method 600 advances to process 616 to transmit funds to the recipients of the customer's upcoming payments. However, if the customer did not provide sufficient funds, the customer's funds in the customer reserve account are allocated between upcoming customer payments at process 614. For example, the account management circuit 124 may generate an allocation using the prioritization algorithm described herein.
At process 616, funds are transferred to recipients of upcoming customer payments. For example, using information provided by the customer during the method 200 described with respect to
Referring now to
Referring now to
In various embodiments, the financial institution client application 116 includes a messaging applet configured to generate messaging graphical user interfaces in response to certain determinations being made regarding the customer's finances. In this regard, the messaging applet may include messaging templates that are retrieved in response to certain triggers (e.g., the customer spending above or below the customer spending limit, the customer having insufficient funds in the customer reserve account to make an upcoming payment, a detected change in the customer's income). Each messaging template may have an associated set of responses that may be presented as options to respond to the messages presented to the customer. Additional message templates may be presented to the customer based on the customer's responses to the messages. As such, rather than presenting the customer with multiple graphical user interfaces to notify the customer and enable the customer to perform a needed action, the financial institution client application 116 efficiently presents all of such information to the customer via a single interface in an interactive manner.
Referring now to
At process 802, the account management circuit 124 monitors the customer's spending habits and activities. For example, the account management circuit 124 may retrieve a transaction history of the customer and determine an amount spent by the customer within various predetermined periods. At process 804, the account management circuit 124 compares the customer's spending levels to the customer's spending limit and determines whether the customer's spending amount differs from the spending limit by more than various thresholds. If not, method 800 advances to process 808 to monitor the customer's expense payments. In some embodiments, the customer device 110 performs such an analysis upon receipt of the customer's transaction history from the financial institution computing system 120.
However, if the customer's spending behavior deviates from the customer's spending limit by more than a threshold amount, the account management circuit 124 provides a spending recommendation to the customer at process 806. For example, if the customer consistently spends more than the customer spending limit (e.g., the customer spends more than the spending limit in more than predetermined percentage of weeks), a recommendation to cut spending may be provided. Such a recommendation may identify particular transactions of the customer that are selected by comparing characteristics of the customer's transactions (e.g., amounts, merchants, timing) with transactions of other customers of the financial institution. If the customer engages in transactions or patterns of transactions avoided by other customers having a similar income as the customer, for example, the recommendation to cut spending may identify the transactions. In some embodiments, the recommendation enables the customer to establish transaction rules for the customer spending account such that, upon the customer attempting to engage in one of the identified transactions, the transaction is either denied or an alert may be provided to the customer.
If the customer consistently spends amounts below the customer spending limit, the account management circuit 124 or customer device 110 may provide advice as to what the customer should do with the extra funds. For example, a recommendation may be provided for the customer to establish a savings or investment account.
At process 808, the account management circuit 124 monitors payments of the customer's expenses. For example, based on customer transaction information stored at the accounts database 126 (e.g., describing amounts owed by the customer to external entities by certain dates and amounts paid by the customer), the account management circuit 124 may determine if the customer consistently makes such payments timely at process 810. If so, the method 800 may end.
However, if the customer does not consistently make such payments, the account management circuit 124 may assess the transaction history of the customer at process 812 to identify negative customer spending habits (e.g., by comparing the customer's spending transactions to transactions of other customers of the financial institution). Based on such habits, the account management circuit 124 may provide recommendations to the customer at process 814. For example, the recommendation may prompt the customer to transfer funds from the customer spending account to the customer reserve account and/or lower the customer's spending limit. The recommendation may also describe transactions that the customer should avoid to accommodate for such changes. Alternatively or additionally, the recommendation may include suggestions as to the customer's expenses. For example, the recommendation may suggest that the customer discontinue receiving a service from a particular service provider (so as to lower the total amount of the customer's bill payments) if the total amount of the customer's bills each month differs from that of other customers having a similar income to the customer.
Upon the customer naming the savings account, the account management circuit 124 may establish a savings account for the customer and periodically transfer the indicated amount of funds (e.g., the average amount the customer spends below the customer spending limit) from the customer's spending account the savings account. Thus, technically and beneficially, the systems and methods herein enable customers to dynamically establish accounts based on the customer's current financial situation.
Referring now to
Referring now to
As shown, the recommendation messaging graphical user interface 922 includes an initial message 924 indicating the identified deposit pattern to the customer, as well as a graphical depiction 926 of recent deposits into the customer's account. As shown, the initial message 924 prompts the customer to confirm whether the customer has received a raise. If the customer responds in the affirmative (as indicated by the customer response message 928), the customer device 110 may generate a response message 930 that indicates that, if the customer's spending limit is maintained, the customer may set aside additional money into savings. In some embodiments, the response message includes a savings forecast (e.g., similar to the savings forecast 920 described with respect to
The embodiments described herein have been described with reference to drawings. The drawings illustrate certain details of specific embodiments that implement the systems, methods, and programs described herein. However, describing the embodiments with drawings should not be construed as imposing on the disclosure any limitations that may be present in the drawings.
It should be understood that no claim element herein is to be construed under the provisions of 35 U.S.C. § 112(f), unless the element is expressly recited using the phrase “means for.”
As used herein, the term “circuit” may include hardware structured to execute the functions described herein. In some embodiments, each respective “circuit” may include machine-readable media for configuring the hardware to execute the functions described herein. The circuit may be embodied as one or more circuitry components including, but not limited to, processing circuitry, network circuits, peripheral devices, input devices, output devices, and sensors. In some embodiments, a circuit may take the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (IC), discrete circuits, system on a chip (SOCs) circuits), telecommunication circuits, hybrid circuits, and any other type of “circuit.” In this regard, the “circuit” may include any type of component for accomplishing or facilitating achievement of the operations described herein. For example, a circuit as described herein may include one or more transistors, logic gates (e.g., NAND, AND, NOR, OR, XOR, NOT, XNOR), resistors, multiplexers, registers, capacitors, inductors, diodes, wiring, and so on).
The “circuit” may also include one or more processors communicatively coupled to one or more memory or memory devices. In this regard, the one or more processors may execute instructions stored in the memory or may execute instructions otherwise accessible to the one or more processors. In some embodiments, the one or more processors may be embodied in various ways. The one or more processors may be constructed in a manner sufficient to perform at least the operations described herein. In some embodiments, the one or more processors may be shared by multiple circuits (e.g., circuit A and circuit B may comprise or otherwise share the same processor which, in some example embodiments, may execute instructions stored, or otherwise accessed, via different areas of memory). Alternatively or additionally, the one or more processors may be structured to perform or otherwise execute certain operations independent of one or more co-processors. In other example embodiments, two or more processors may be coupled via a bus to enable independent, parallel, pipelined, or multi-threaded instruction execution. Each processor may be implemented as one or more general-purpose processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), or other suitable electronic data processing components structured to execute instructions provided by memory. The one or more processors may take the form of a single core processor, multi-core processor (e.g., a dual core processor, triple core processor, quad core processor), microprocessor, etc. In some embodiments, the one or more processors may be external to the apparatus, for example the one or more processors may be a remote processor (e.g., a cloud-based processor). Alternatively or additionally, the one or more processors may be internal and/or local to the apparatus. In this regard, a given circuit or components thereof may be disposed locally (e.g., as part of a local server, a local computing system) or remotely (e.g., as part of a remote server such as a cloud-based server). To that end, a “circuit” as described herein may include components that are distributed across one or more locations.
An exemplary system for implementing the overall system or portions of the embodiments might include general purpose computing devices in the form of computers, including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit. Each memory device may include non-transient volatile storage media, non-volatile storage media, non-transitory storage media (e.g., one or more volatile and/or non-volatile memories), etc. In some embodiments, the non-volatile media may take the form of ROM, flash memory (e.g., flash memory such as NAND, 3D NAND, NOR, 3D NOR), EEPROM, MRAM, magnetic storage, hard discs, optical discs, etc. In other embodiments, the volatile storage media may take the form of RAM, TRAM, ZRAM, etc. Combinations of the above are also included within the scope of machine-readable media. In this regard, machine-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions. Each respective memory device may be operable to maintain or otherwise store information relating to the operations performed by one or more associated circuits, including processor instructions and related data (e.g., database components, object code components, script components, etc.), in accordance with the example embodiments described herein.
It should also be noted that the term “input device,” as described herein, may include any type of input device or input devices including, but not limited to, a keyboard, a keypad, a mouse, joystick, or other input devices capable of performing a similar function. Comparatively, the term “output device,” as described herein, may include any type of output device or output devices including, but not limited to, a computer monitor, printer, facsimile machine, or other output devices capable of performing a similar function.
Any foregoing references to currency or funds are intended to include fiat currencies, non-fiat currencies (e.g., precious metals), and math-based currencies (often referred to as cryptocurrencies). Examples of math-based currencies include Bitcoin, Litecoin, Dogecoin, and the like.
It should be noted that although the diagrams herein may show a specific order and composition of method steps, it is understood that the order of these steps may differ from what is depicted. For example, two or more steps may be performed concurrently or with partial concurrence. Also, some method steps that are performed as discrete steps may be combined, steps being performed as a combined step may be separated into discrete steps, the sequence of certain processes may be reversed or otherwise varied, and the nature or number of discrete processes may be altered or varied. The order or sequence of any element or apparatus may be varied or substituted according to alternative embodiments. Accordingly, all such modifications are intended to be included within the scope of the present disclosure as defined in the appended claims. Such variations will depend on the machine-readable media and hardware systems chosen and on designer choice. It is understood that all such variations are within the scope of the disclosure. Likewise, software and web implementations of the present disclosure could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps, and decision steps.
The foregoing description of embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from this disclosure. The embodiments were chosen and described to explain the principals of the disclosure and its practical application to enable one skilled in the art to utilize the various embodiments and with various modifications as are suited to the particular use contemplated. Other substitutions, modifications, changes, and omissions may be made in the design, operating conditions, and arrangement of the embodiments without departing from the scope of the present disclosure as expressed in the appended claims.
This application claims priority to U.S. Provisional Patent Application No. 62/536,805 entitled “Interactive Banking Using Multiple Checking Accounts,” filed Jul. 25, 2017, and hereby incorporated by reference in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 7478062 | Ansley | Jan 2009 | B2 |
| 7813983 | Wottowa et al. | Oct 2010 | B2 |
| 8306914 | Johns et al. | Nov 2012 | B2 |
| 8630947 | Freund | Jan 2014 | B1 |
| 8738527 | Kalinichenko et al. | May 2014 | B2 |
| 9443268 | Kapczynski et al. | Sep 2016 | B1 |
| 9582830 | Johns et al. | Feb 2017 | B2 |
| 9928549 | Stern et al. | Mar 2018 | B2 |
| 10055727 | Aiglstorfer | Aug 2018 | B2 |
| 10078867 | Chan et al. | Sep 2018 | B1 |
| 10733610 | Martin | Aug 2020 | B2 |
| 20020123949 | Vanleeuwen | Sep 2002 | A1 |
| 20030061162 | Matthews | Mar 2003 | A1 |
| 20070282743 | Lovelett et al. | Dec 2007 | A1 |
| 20080189185 | Matsuo et al. | Aug 2008 | A1 |
| 20080270304 | Brown | Oct 2008 | A1 |
| 20120030043 | Ross et al. | Feb 2012 | A1 |
| 20120179558 | Fischer | Jul 2012 | A1 |
| 20120233015 | Calman et al. | Sep 2012 | A1 |
| 20130041819 | Khasho | Feb 2013 | A1 |
| 20130054436 | Hanson et al. | Feb 2013 | A1 |
| 20140089153 | Pinski | Mar 2014 | A1 |
| 20140122340 | Flitcroft et al. | May 2014 | A1 |
| 20140136381 | Joseph et al. | May 2014 | A1 |
| 20140156536 | Grigg et al. | Jun 2014 | A1 |
| 20140188704 | Grossman et al. | Jul 2014 | A1 |
| 20150100475 | Cummings et al. | Apr 2015 | A1 |
| 20150254648 | Clements et al. | Sep 2015 | A1 |
| 20150269671 | Garrity et al. | Sep 2015 | A1 |
| 20150294297 | Lipshultz | Oct 2015 | A1 |
| 20150302398 | Desai et al. | Oct 2015 | A1 |
| 20150379488 | Ruff | Dec 2015 | A1 |
| 20160132875 | Blanco et al. | May 2016 | A1 |
| 20160140654 | Bhat et al. | May 2016 | A1 |
| 20160247233 | Page | Aug 2016 | A1 |
| 20170004577 | Cunningham | Jan 2017 | A1 |
| 20170024813 | Crouspeyre et al. | Jan 2017 | A1 |
| 20170032353 | Vadivel et al. | Feb 2017 | A1 |
| 20170061535 | Williams | Mar 2017 | A1 |
| 20170109540 | Heiman | Apr 2017 | A1 |
| 20170109817 | Vea et al. | Apr 2017 | A1 |
| 20170301014 | Singer | Oct 2017 | A1 |
| 20180025331 | Dallenbach et al. | Jan 2018 | A1 |
| 20180225756 | Wasser et al. | Aug 2018 | A1 |
| Entry |
|---|
| Envudu Help Center, “How does it work?”, http://help.envudu.com/about-the-envudu-mobile-app/how-does-it-work, downloaded Jul. 13, 2017. 2 pages. |
| Envudu, “Experience the power of weekly based spending”, http://help.envudu.com/envudu-s-key-features-explained/experience-the-power-of-weekly-based-spending, downloaded Jul. 13, 2017. 2 pages. |
| Envudu, “Leverage emotion to eliminate overspending”, https://envudu.com/#/, downloaded Jul. 13, 2017. 11 pages. |
| Envudu, Reservoir smooths out income highs and lows, http://help.envudu.com/envudu-s-key-features-explained/reservoir-smooths-out-income-highs-and-lows, downloaded Jul. 13, 2017. 2 pages. |
| Grant, Kinsey, “Wells Fargo Debuts “Greenhouse” Digital Bank Accounts Without Overdrafts”, The Street, Nov. 2, 2017. 4 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 62536805 | Jul 2017 | US |
