Technical Field

[0001] Disclosed herein is a computer- implemented data management system. In particular, the present disclosure relates to a system and method of transferring data between a plurality of computing devices, wherein the computing devices process the data before and/or after transferring, and the processing affects said transfer of data.

Background Art

[0002] Current automated database allocation systems perform evaluations according to rigidly programmed cycles (e.g., perform evaluation every day at midnight, every week, every month, and so forth). As such, events that occur between cycles may be overlooked, ignored, and the like. So long as when the evaluation does take place, the database is in order. For example, if a particular database is required to have more data-in than data-out, then a current database allocation system may check at midnight daily to ensure this is the case. However, throughout the day, the data-in and data-out may fluctuate wildly. Additionally, events that occur during one cycle may not occur in a subsequent cycle. Current database allocation systems are limited because they cannot accommodate such fluctuations.

[0003] In this specification where a document, act or item of knowledge is referred to or discussed, this reference or discussion is not an admission that the document, act or item of knowledge or any combination thereof was at the priority date, publicly available, known to the public, part of common general knowledge; or known to be relevant to an attempt to solve any problem with which this specification is concerned.

Summary

[0004] Disclosed herein is a data management system. The system may comprise a processor; and memory storing instructions that, when executed by the processor, cause the system to: receive first data from a client system, second data from a billing system, and third data from a credit system via a data network, wherein the first data comprises a first identifier, the second data comprises a second identifier, and the third data comprises a third identifier; generate first transfer data in dependence on a comparison of the first identifier and the second identifier; generate second transfer data in dependence on a comparison of the first identifier and the third identifier; and dynamically generate instructions to distribute data between a plurality of accounts in dependence on the first and second transfer data.

[0005] The disclosed system provides flexibility in evaluating automated database allocation systems by accepting user-defined evaluation cycles dependent on numerous factors including, without limitation, frequency of data-in, expected amount of data-in, frequency of data-out, expected amount of data-out, user-defined goals, data excluded from evaluation, and additional factors that will be appreciated upon review of the disclosures herein. As the previously disclosed factors may each vary, the evaluation cycle itself varies, providing more flexibility in the rate of database evaluation. Such flexibility improves database allocation systems by creating more accurate statements that those determined by rigidly programed evaluation cycles.

[0006] In some forms, the memory stores instructions that, when executed by the processor, cause the system to generate first matching data in dependence on the comparison of the first identifier and the second identifier.

[0007] In some forms, the memory stores instructions that, when executed by the processor, cause the system to output a first event to the client system, or dynamically generate the instructions to distribute data between the plurality of accounts in dependence on the generated first matching data.

[0008] In some forms, the memory stores instructions that, when executed by the processor, cause the system to: receive first confirmation data from the client system upon receipt of the first event; and store the first confirmation data for future comparisons between the first identifier and the second identifier.

[0009] In some forms, the memory stores instructions that, when executed by the processor, cause the system to adjust the first data in dependence on the first confirmation data received from the client system.

[0010] In some forms, the memory stores instructions that, when executed by the processor, cause the system to generate second matching data in dependence on the comparison of the first identifier and the third identifier. [0011] In some forms, the memory stores instructions that, when executed by the processor, cause the system to output a second event to the client system, or dynamically generate the instructions to distribute data between the plurality of accounts in dependence on the generated second matching data.

[0012] In some forms, the memory stores instructions that, when executed by the processor, cause the system to: receive second confirmation data from the client system upon receipt of the event; and store the second confirmation data for future comparisons between the first identifier and the third identifier.

[0013] In some forms, the memory stores instructions that, when executed by the processor, cause the system to adjust the first data in dependence on the second confirmation data received from the client system.

[0014] In some forms, the system further comprises one or more management modules stored on the memory, the one or more management modules including instructions that, when executed by the processor, cause the one or more management modules to generate the first and second transfer data; and a distribution engine stored on the memory, the distribution engine including instructions that, when executed by the processor, cause the distribution engine to dynamically generate the instructions to distribute the data between the plurality of accounts.

[0015] In some forms, the one or more management modules comprises: a first module including instructions that, when executed by the processor, cause the first module to: analyse the first and second data; generate the first transfer data in dependence on the first and second data; and dynamically output the first transfer data to the distribution engine; a second module including instructions that, when executed by the processor, cause the second module to: analyse the first and third data; generate the second transfer data in dependence on the first and third data, and dynamically output the second transfer data to the distribution engine; and a third module including instructions that, when executed by the processor, cause the third module to: receive fourth data from the client system; analyse the fourth data to generate third transfer data; and dynamically output the third transfer data to the distribution engine.

[0016] In some forms, the first module comprises a first matching engine, the first matching engine including instructions that, when executed by the processor, cause the first matching engine to generate the first matching data and output the first matching data to the client system and the distribution engine.

[0017] In some forms, the second module comprises a second matching engine, the second matching engine including instructions that, when executed by the processor, cause the second matching engine to generate the second matching data and output the second matching data to the client system and the distribution engine .

[0018] Also disclosed herein is a computer- implemented method of data management, the method comprising the steps of: a) retrieving from non- volatile memory and/or from a client system via a data network a data set including a plurality of data records, each data record comprising first data received from the client system, or second data received from the client system, the first data and the second data comprising a first and second identifier respectively; b) forming event management data in dependence on the first and second data; c) receiving third data from a crediting system and fourth data from a billing system, the third data and the fourth data comprising a third and fourth identifier respectively; d) associating the third data with the first data by comparing the third identifier with the first identifier; e) generating first transfer data in dependence on the comparison between third identifier and the first identifier; f) associating the fourth data the second data by comparing the fourth identifier with the second identifier; g) generating second transfer data in dependence on the comparison between fourth identifier and the second identifier; and h) dynamically generating instructions to distribute data between a plurality of accounts in dependence on the first and second transfer data.

[0019] In some forms, the method further comprises retrieving cycle data from the nonvolatile memory and/or from the client system via the data network, and wherein the step of forming the event management data is performed in dependence on the first data, the second data, the third data, the fourth data and the cycle data.

[0020] In some forms, the method further comprises releasing data from at least one of the plurality of accounts in response to the fourth data received from the billing system.

[0021] In some forms, the method further comprises redistributing data between the plurality of client accounts following the release of data from the account.

[0022] Also disclosed herein is a data management system implemented using computer processing and memory resources accessible by at least one client system via a data network. In some forms, the system may comprise one or more management modules configured to receive data from the at least one of the client system, at least one billing system and at least one credit system via the data network. The first data may comprise first data received from the at least one client system, second data received from at least one billing system and third data received from the at least one credit system, the first, second and third data including at least one first, second or third identifier attribute respectively. In some forms, the one or more management modules may be further configured to compare the at least one first attribute associated with the first data received from the at least one client system with the at least one second identifier associated with the second data received from the at least one billing system and generate first transfer data in dependence on the comparison, and to compare the at least one first identifier attribute associated with the data received from the at least one client system with the at least one third identifier attribute received from the at least one crediting system and generate second transfer data in dependence on the comparison. In some forms, the system may comprise a distribution engine configured to receive the first and second transfer data from the one or more

management modules and dynamically generate instructions to distribute data between a plurality of client accounts in dependence on the first and second transfer data.

[0023] In one embodiment, the system allows a user to dispense with arbitrary spend categories and instead simply enter, via the client system, as a one-time set up exercise, data relating to recurring bills by providing identifier attributes (e.g. an amount payable, the frequency and the next due date) and have the system maintain a schedule of due dates for each bill and calculate the amount to be set aside to cover each bill in time for its due date. [0024] In at least one embodiment, the disclosed system allows for real time transactional data and automatic matching of bill payment transactions to the correct spend category and/or to individual budgeted bills. The disclosed system is also able to perform a reallocation of surplus or deficit funds both in the budget and, with integration to a core banking system, with actual bank transfers. Performing actual bank transfers in a real time response to actual bill payment transactions allows excess funds to be immediately made available for discretionary spending or conversely, if a bill payment was larger than expected, additional funds could be taken from the discretionary spending funds to make up for the shortfall. Immediate redistribution of funds may be able to protect the user from inadvertently spending funds previously thought of as safe to spend but that are now needed to meet a shortfall in bill funding.

[0025] In at least one embodiment, the disclosed system allows a user to add a quarterly, half-yearly or annual bill, provide a 'next due' date and an anticipated amount and the system is able to calculate the amount to be set aside in each of the user defined budget periods to ensure the full amount is available when the bills falls due. In at least one embodiment, the system is able to provide a bill smoothing effect by putting aside a smaller and more consistent amount each budgeting period so as to steadily accumulate the full amount payable by the due date. Bill smoothing may be a highly effective way of preventing the spikes and troughs of household bills from negatively impacting lifestyle.

[0026] In at least one embodiment, the disclosed system allows for income received from credit systems (e.g. salary received from a payer) to be automatically transferred between client accounts as soon as the income has arrived. This may facilitate the ability of the system to provide the user with an indication of what they can safely spend and more importantly, show the user the impact of dipping in to those allocated cash amounts. The system may achieve at least two things; it may compensate for human error and forgetfulness, and it may impose a level of benign discipline to help the user stay on track with a budget.

[0027] In some forms, the one or more management modules comprises a second

management module configured to analyse the first data received from the at least one client system and the third data received from the at least one credit system, generate the second transfer data in dependence on the analysed first and third data, and output the second transfer data to the distribution engine. In some forms, the second management module may be in the form of a credit management module. In some forms, the first data received from the client system may be in the form of data relating to expected credits (e.g. an income) that a user expects to receive from a crediting system (e.g. an employer). In some forms, the third data received from the credit system may be in the form of data related to actual credits (e.g. an income) received from the credit system (e.g. directly, or via a core banking system). In some forms, the one or more management modules comprises a first management module configured to analyse the first data received from the at least one client system and the second data received from the at least one billing system, generate the first transfer data in dependence on the analysed first and second data, and output the second transfer data to the distribution engine. In some forms, the first management module may be in the form of a debit management module. In some forms, the first received from the client system may be in the form of data relating to expected debits (e.g. bills) that a user expects to pay to a billing system (e.g. a service provider). In some forms, the second data received from the billing system may be in the form of data related to actual debits (e.g. bills) received from the billing system (e.g. directly, or via a core banking system). In some forms, the debit management module may be configured generate first transfer data without the receipt of data from a billing system (e.g. if a user configures the system to automatically transfer funds to another user's account).

[0028] In some forms, the one or more management modules further comprises a third management module configured to receive fourth data from the at least one client system, analyse the fourth data, and output the analysed fourth data to the distribution engine. In some forms, the third management module is a savings management module and the fourth data relates to a savings goal (e.g. an amount of funds required at a set date to purchase a car).

[0029] In some forms, the plurality of client accounts comprises three accounts, each account being configured to receive funds in response to the instructions generated by the distribution engine. The three accounts may be in the form of a pay account, a spendings account and a savings account. The accounts may be held on the system, or linked to the system via a core banking system that is able to communicate with the system via the data network.

[0030] In some forms, the first module comprises a first matching engine, the first matching engine being configured to compare the at least one first identifier attribute associated with the first data received from the at least one client system with the at least one second identifier associated with the second data received from the at least one billing system, and generate matching event data in dependence on the comparison. In some forms, the at least one first identifier attribute associated with the first data received from the at least one client system may be in the form of information relating to an expected bill (e.g. the identity of the billing system). In some forms, the matching event data may be in the form of data confirming or denying a match between the compared identifier attributes.

[0031] In some forms, the first matching engine is configured to output the generated first matching event data to the at least on client system to notify a user that the first matching engine is unable to match the at least one first identifier attribute associated with the first data received from the at least one client system with the at least one second identifier associated with the second data received from the at least billing system, or output the generated first matching event data to the distribution module for the release of data from one of the plurality of client accounts to the at least one billing system.

[0032] In some forms, the distribution module is configured to analyse the first data received from the at least one client system and the first matching event data received from the first matching engine, and generate instructions to distribute data between the plurality of client accounts in dependence on the analysis. For example, the distribution module may compare the input data (e.g. the first data received from the client system) with the first matching event data (e.g. data confirming that a match has been made), determine a difference in funds (e.g. a match may have been made despite the bill amount being more or less than the bill amount expected by the user) and then generate instructions to distribute difference in funds between the client accounts (e.g. if the bill is less than expected, the distribution module may move the surplus funds previously held in a pay account to a spendings account).

[0033] In some forms, the at least one client system is configured to receive first

confirmation data from the user upon receipt of the matching data from the first matching engine, and output the first confirmation data to the first matching engine to manually confirm a match between the first data received from the at least one client system and the second data received from the at least one billing system, and in response to receipt of the first confirmation data, the debit matching engine is configured to store the first confirmation data such that the first matching engine learns to recognise similar matching event data and output the matching event data to the funds transfer module in lieu of outputting the matching event data to the at least one client system for future matching events. This may provide the system with a level of artificial intelligence, in that the system learns the billing habits of a user over time, such that the percentage of matched events increases with use and less user intervention is required (e.g. the level of automation of the system increases over time).

[0034] In some forms, the first matching engine is configured to adjust the at least one first identifier associated with the first transaction data received from the at least one client system in dependence on the first confirmation data received from the at least one client system, and store the adjusted second identifier attribute such that the first matching engine learns to recognise similar unmatched data events and output matching data events to the distribution module in lieu of outputting the matching event data to the at least one client system for future matching events. For example, the first matching engine may adjust the identifier attribute(s) associated with a particular billing event set by a user and store the adjusted identifier attribute(s) (e.g. a range of attributes may be set) such that the system learns the billing habits of a user over time.

[0035] In some forms, the second module comprises a second matching engine, the second matching engine being configured to compare the at least one first identifier associated with the first data received from the at least one client system with the at least one third identifier associated with the third data received from the at least one credit system, and generate second matching event data in dependence on the comparison. In some forms, the at least one first identifier attribute associated with the first data received from the at least one client system may be in the form of information relating to an expected income (e.g. identity of an employer). In some forms, the matching event data may be in the form of data confirming or denying a match between the compared identifier attributes.

[0036] In some forms, the second matching engine is configured to output the generated second matching event data to the at least one client system to notify a user that the second matching engine is unable to match the at least one first identifier attribute associated with the first data received from the at least one client system with the at least one third identifier received from the at least one credit system, or output the second matching event data to the distribution module for distribution of data between the plurality of client accounts.

[0037] In some forms, the distribution module is configured to analyse the first data received from the at least one client system and the third data received from the at least one credit system, and generate instructions to distribute data between the plurality of client accounts in

dependence on the analysis. For example, the distribution module may compare the input data (e.g. the first data received from the client system) with the second matching event data (e.g. data confirming that a match has been made), determine a difference in funds (e.g. a match may have been made despite the income amount being more or less than the income amount expected by the user) and then generate instructions to distribute the difference in funds between the client accounts (e.g. if the income is more than expected, the distribution module may distribute the surplus funds between the spendings and savings accounts).

[0038] In some forms, the at least one client system is configured to receive second confirmation data from the user upon receipt of the second matching event data from the second matching engine, and output the second confirmation data to the second matching engine to manually confirm a match between the first data received from the at least one client system and the third data received from the at least one crediting system, and in response to receipt of the second confirmation data, the second matching engine is configured to store the second confirmation data such that the second matching engine learns to recognise similar matching events and output the second matching event data to the distribution module in lieu of outputting the second matching event data to the at least one client system for future matching events. This may provide the system with a level of artificial intelligence, in that the system learns the income habits of a user over time, such that the percentage of matched events increases with use and less user intervention is required (e.g. the level of automation of the system increases over time).

[0039] In some forms, the second matching engine is configured to adjust the at least one first identifier attribute associated with the first data received from the at least one client system in dependence on the second confirmation data received from the at least one client system, and store the adjusted first identifier such that the second matching engine learns to recognise similar matching events and output the second matching event data to the distribution module in lieu of outputting the second matching event data to the at least one client system for future matching events. For example, the second matching engine may adjust the identifier attribute(s) associated with a particular income event set by a user and store the adjusted identifier attribute(s) (e.g. a range of attributes may be set) such that the system learns the income habits of a user over time.

[0040] In some forms, the distribution engine is configured to output the generated instructions to a core banking system for the execution of the distribution of funds between the plurality of client accounts. [0041] In some forms, the at least one management module is further configured to receive data from the core banking system via the data network.

[0042] In some forms, the system further comprises the core banking system having the plurality of client accounts, and wherein the at least one client system is in the form of a computer processing device having a display for displaying information associated with the plurality of client accounts.

[0043] Also disclosed herein is a computer-implemented method of data management. In some forms, the method may be in the form of an automated data management method. The method may comprise the steps of: a) retrieving from non-volatile memory and/or from at least one client system via a data network a financial data set including a plurality of transaction data records, each transaction data record comprising credit transaction data received from the at least one client system, or debit transaction data received from the at least one client system, the credit transaction data and the debit transaction data including at least one credit and debit identifier attribute respectively; b) forming the financial budget in dependence on the credit and debit transaction data; c) receiving further credit transaction data from at least one crediting system and further debit transaction data from at least one billing system; d) associating the credit transaction data received from the at least one crediting system with the credit transaction data retrieved from the at least one client system by comparing the at least one credit identifier attribute of the credit transaction data received from the at least one crediting system with the at least one credit identifier attribute of the credit transaction data retrieved from the at least one client system; e) generating credit fund transfer data in dependence on the comparison between the at least one credit identifier attribute of the credit transaction data received from the at least one crediting system with the at least one credit identifier attribute of the credit transaction data retrieved from the at least one client system; f) associating debit transaction data received from the at least one billing system with the debit transaction data retrieved from the at least one client system by comparing the at least one debit identifier attribute of the debit transaction data received from the at least one billing system with the at least one debit identifier attribute of the debit transaction data retrieved from the at least one client system; g) generating debit fund transfer data in dependence on the comparison between the at least one debit identifier attribute of the debit transaction data received from the at least one debiting system with the at least one debit identifier attribute of the debit transaction data retrieved from the at least one client system; and h) transferring funds between a plurality of client accounts in dependence on the generated credit and debit fund transfer data.

[0044] In some forms, the method further comprises retrieving budget cycle data from the non- volatile memory and/or from the at least one client system via the data network, and wherein the step of forming the financial budget is performed in dependence on the credit transaction, debit transaction data and the budget cycle data.

[0045] In some forms, the method further comprises releasing funds from at least one of the plurality of client accounts in response to the further debit transaction data received from the at least one billing system.

[0046] In some forms, the method further comprises redistributing funds between the plurality of client accounts following the release of funds from the at least one client account.

[0047] In at least one embodiment, the system allows the user to define their own budget cycle; both its periodicity and its start date. Enabling a user to define their budgeting period may make the budget more familiar to the user, easier to understand and easier to comply with. In some embodiments, it may be possible to offer a user a choice of budget periods; weekly, fortnightly or monthly and should also be possible to align the start date of the budget period with the arrival of income.

[0048] In at least one embodiment, the system employs a user defined budget cycle upon which to operate the cyclical nature of a household budget but would also use a daily level schedule to ensure that events within the budget period are considered in their order of occurrence. In some forms, the system also uses the user inputted frequency and next due date of each bill to build a schedule of bill due dates upon which reminder messages could be sent to the user to pay the bill.

[0049] In one embodiment, there is provided a computer implemented integrated financial system. The system may comprise a budgeting system that may comprise a personal financial management layer integrated with a group of two or more (typically 3) bank accounts having and uses processing logic and internal rules to build a prospective budget that is executed and maintained via direct instruction to the underlying trio of bank accounts, automated transaction matching and optional user input. [0050] In at least one embodiment, the system may have the option to interact with the system using a graphical user interface (GUI). For example, this may enable user inputs pertaining to income streams, bills and saving goals.

[0051] In at least one embodiment, the GUI may comprise a major user interface to correspond to each of the two or more underlying bank accounts. For example, the GUI may comprise: a pay screen corresponds to the pay account - a transactional account with a moderate interest rate that receives income and from which bills are paid; a save screen corresponds to the save account - a savings account with a higher interest rate which receives save goal contributions paid from the pay account; and a spend screen corresponds to the spend account - a transactional account earning no interest and holds the cash that is available for discretionary spending.

[0052] In at least one embodiment, the system may also have the option for interest on any credit amounts to be offset against the interest accruing on a user's loan.

[0053] The system also comprises a system of engagement or SOE which in turn may comprise a datastore and processing logic. The datastore may contain records for each bill, income stream and save goal entered by the user, plus budget cycle details, transaction details and additional data for each of these items as derived by the processing logic. The system may comprise an API gateway for authentication of the user, data flow control and other security measures.

[0054] The SOE may be integrated with a core banking system via a web services layer. The web services layer may be able to co-ordinate and orchestrate web service requests and responses between the software run on a remote processing device (e.g. an application on a mobile smartphone) and the core banking system. The core banking system may comprise the bank datastore which may hold all customer and account related data, a customer banking service through which the customer can directly instruct the core banking system, and a transaction Service through which the SOE can instruct the core banking system. The core banking system may also provide a near real time transaction feed which may pass all transactions relating to client accounts to the SOE.

[0055] The SOE may also provide data to a customer analytics system which may generate and manage events based on a client data. For example, where data shows a customer's Save account is near to achieving a save goal named 'house deposit' a marketing event to promote a home loan may be generated for that customer.

[0056] The system may utilise all budgetary information provided by the user, transactional information provided by the core banking system, and internal processing logic to (a) construct the budget, (b) determine in real time the balance required in the Pay account to cover the budget, (c) instruct the core banking system in real time to execute the internal transfers required to maintain that balance, (d) instruct the core banking system to execute bill payment transactions and save contribution transactions, and (e) update the budget in response to each budgetary event that occurs.

[0057] All user inputs may create, update or delete budget events or other parameters such as the budget cycle and this data may be stored within the datastore within the SOE. Every change to a budget record may trigger the processing logic to perform the distribution calculation. The resultant necessary transfer instructions may be passed to the core banking system via web services.

[0058] Transactions occurring within the core banking system that involve the pay account may be passed to the SOE via a transaction feed web service in near real time. The transaction matching rules within the processing logic may be applied to each of those transactions to determine if they are the execution of a planned budget event such as the receipt of an income or payment of a bill. Where the transaction was not the execution of a planned budget event, or the amount of the transaction was different to the planned amount the system recognises that the budget has been disrupted and the distribution calculation may be triggered so that the balance of the pay account can be restored to the correct value through a transfer of funds between the pay and spend accounts.

[0059] The value of a budgeting system is its ability to help a user to initiate and sustain positive changes in spending behaviour. While it is the intention of most existing budgeting systems to bring about a behavioural change, most fail because they: require too much ongoing effort by the user to maintain to keep up to date or they are not kept up to date at all; don't enable a sufficient level of granularity so as to be recognisable to users; don't enable users to test out new behaviours easily by adjusting to user initiated changes to the budget; are too rigid to be able to accommodate the real life every day events that challenge a budget; don't reward positive behaviours; and don't make users aware of the impacts of not so positive behaviours in a timely manner.

[0060] In contrast, in at least one embodiment, the system disclosed herein may enable behaviour change because it meets one or more of those needs not only through its immediate response to changes but also, in some embodiments, by offering the following features (e.g. in built rewards & benign discipline).

[0061] In order to encourage a user to actively complete their initial set up of their budget the system may have in built rewards. For example, the rewards could be: when a user has at least $2,000 per month deposited and matched to an income in the Pay account and has at least one active save goal then the Save account receives an interest bonus for the month (currently 1.5%); for an offset account, when a user has at least $2,000 per month deposited and matched to an income in the Pay account then any ATM Direct Charges are rebated to the Spend account; and/or 1% cash back is paid on any bills paid via Direct Debit or BPAY up to a value of $1,000 per month.

[0062] The system may not only actively encourage good behaviours but also assist to protect users from themselves by creating disincentives to perform actions that would have a negative impact on their budget.

[0063] The system may make it easy to know what is safe to spend and makes it easy to spend it by issuing a debit card against the Spend account. Conversely, because the money in the Pay account may be allocated to cover planned bills the system may make it harder to spend money from the Pay account. The user may need to specifically request a debit card for the Pay account and, in order to protect those funds set aside for planned bills, the user may need to set up a Pay debit card allowance.

[0064] Withdrawing funds from the Pay account for unplanned spending immediately may cause the Pay account to display as 'Uncovered' and the bills that are now not covered because of the shortfall are highlighted in red. The combination of the 'Uncovered' message, the red bills and the 'Pay account is off track' notification may have a profound effect and users may perform a corrective action to restore balance.

[0065] Further, unplanned spending directly from the Pay account may result in a distribution transfer being executed where an equivalent amount to that just spent from Pay is pulled from the Spend account. In this way, if the user has accidentally spent the money from the Pay account they can be protected from the error by the system.

[0066] Money can be moved from the Pay account to the Spend account via a quick top up feature. This allows for a very deliberate activity on the part of the user and they may immediately made aware of the impact because the Pay account will appear as 'Uncovered'.

[0067] This combination of messaging, display updates and system behaviours may form a level of benign discipline that guides the user toward positive changes in spending behaviour.

[0068] Also disclosed herein is a financial management system implemented using computer processing and memory resources accessible by at least one client system via a data network. The system may comprise one or more account management modules configured to analyse transaction data received from the at least one of the client system, at least one billing system and at least one credit system via the data network. In some forms the transaction data may comprise credit transaction data received from the at least one client system and the at least one credit system, and debit transaction data received from the at least one client system and the at least one billing system, the credit transaction data and the expense transaction data including at least one credit and expense identifier attribute respectively. In some forms, the system further comprises a funds distribution engine configured to receive the analysed transaction data from the one or more account management modules and generate instructions to distribute funds between a plurality of client accounts in dependence on the analysed transaction data.

Brief Description of Drawings

[0069] Various embodiments/aspects of the invention will now be described with reference to the following drawings in which,

[0070] Fig. 1 illustrates a data management system in accordance with an embodiment of the present invention;

[0071] Fig. 2 illustrates a block diagram of the data management system in accordance with an embodiment of the present invention;

[0072] Fig. 3 shows a screen shot of the user interface where the user can provide the details of a regular income stream; [0073] Fig. 4 illustrates a block diagram of the second module;

[0074] Fig. 5 illustrates a screenshot of the series action screen accessible on the client interface;

[0075] Fig. 6 illustrates a screenshot of an interface where the user selects the bill payment method;

[0076] Fig. 7 illustrates a screenshot of an interface for the input of bills that are paid via EFT or BPAY;

[0077] Fig. 8 illustrates a screenshot of an interface for the input of bills that are paid via a direct debit;

[0078] Fig. 9 illustrates a screenshot of an interface for bills where the user has not yet decided on a payment method;

[0079] Fig. 10 illustrates a block diagram of the debit module;

[0080] Fig. 11 illustrates a screenshot of an interface bills paid via EFT or BPAY;

[0081] Fig. 12 illustrates a screenshot of an interface for the users cash flow position;

[0082] Fig. 13 illustrates a screenshot of an interface for the creation of an 'Achieve a Goal' save goal;

[0083] Fig. 14 illustrates a screenshot of an interface for the creation of a 'Rainy Day' save goal.

[0084] Fig. 15 illustrates a screenshot of an interface of the Your Goals Tab;

[0085] Fig. 16 illustrates a screenshot of the Spend interface;

[0086] Fig. 17 illustrates a screenshot of the transfer to save interface;

[0087] Fig. 18 illustrates a screenshot the Quick top-up interface

[0088] Fig. 19 illustrates a screenshot of the user interface for setting up the allowance;

[0089] Fig. 20 illustrates a screenshot of the user interface for the pay screen; [0090] Fig. 21 illustrates another screenshot of the user interface for the pay screen;

[0091] Fig. 22 illustrates a block diagram of the data management system in accordance with an embodiment of the invention;

[0092] Fig. 23 illustrates a block diagram of the processing logic detailed in Table 1; [0093] Fig. 24 illustrates a block diagram of the processing logic detailed in Table 2; [0094] Fig. 25 illustrates a block diagram of the processing logic detailed in Table 3; [0095] Fig. 26 illustrates a block diagram of the processing logic detailed in Table 4; [0096] Fig. 27 illustrates a scenario detailed in Table 4; [0097] Fig. 28 illustrates another scenario detailed in Table 4; [0098] Fig. 29 illustrates another block diagram of the debit matching engine; and [0099] Fig. 30 illustrates a flow diagram of the automatic matching logic. Detailed Description

[00100] An embodiment of the data management system, in the form of a budget management system, will now be detailed below with respect to Figs. 1 to 30. The modern world has afforded the typical consumer the opportunity to employ and benefit from a multitude of products and services that had previously not existed or, where they had existed, were enjoyed in lesser numbers. For example today's average household has 2 or more vehicles, consumes several utility services (e.g. gas, electricity, water, landline, internet), may subscribe to multiple personal and household services (e.g. cable TV, magazine subscriptions, club memberships, cleaners, gardeners), has multiple insurance covers (e.g. home & contents, private health, life insurance, pet insurance, salary continuance), etc. But the complex and enriched lifestyle afforded by modern first world economies comes with a large number of attendant bills and vastly increased complexity in the management of personal and household budgets and cash flow.

[00101] It is incumbent upon each individual and / or household to effectively manage their finances so that they can meet all of their financial obligations. Poor money management can have dire consequences for individuals, families and businesses. For example, disappointing lifestyle impacts may be experienced. But when personal finances really get out of control the consequences can be catastrophic: bill default, mortgage default, cessation of services, negative credit rating impact, repossessions, eviction, and bankruptcy.

[00102] In response to this increased complexity a plethora of personal financial management, budgeting and cash flow management systems have been developed to help individuals understand how they have spent their money and to plan for better spending in the future.

[00103] Despite the wide range of systems available, most people still fail to benefit from an effective budget. Either the existing budget systems are too simplistic, lacking the features necessary to manage all the variability of real life financial situations, or the systems require too much ongoing maintenance by the user. Currently available systems lack the features that convert the good intentions of a budget to actual positive changes in money management behaviours. Many are simply a planning tool, a means for recording an intended plan for managing money. They stop short of bringing about actual execution of the budget through the level of helpful discipline tacitly wanted by individuals who seek out the assistance of a budgeting system.

[00104] The currently existing systems typically focus on: an analysis of past spending through transaction categorisation (historic spend categorisation); and/or building a prospective budget for the user to implement (budgeting tools).

[00105] Those of the first type focus on providing the user with a breakdown of their recent spending based on expense type categorisation of a transaction history from a single financial institution (e.g. Budget Tracker in Suncorp) or from aggregated transactional histories obtained from multiple financial institutions (e.g. Money Brilliant). These tools provide their users with insights into their past spending habits by displaying total dollars spent in the various categories.

[00106] While these tools provide great historical information which could be used to make positive changes in spending behaviour, they usually fail to trigger behaviour change because they don't provide the necessary incentives or discipline to help the user to overcome their own inertia, temptation and resistance to change through a perceived loss of control.

[00107] Additionally, often systems of this type require the user to manually allocate each of their transactions to one of the pre-set spending categories. This is a task which in itself requires a large degree of effort and commitment. Those systems that seek to automatically allocate transactions to the appropriate spending categories will sometimes do so incorrectly, requiring the user to correct the allocation if possible.

[00108] A major concern with this type of system that obtains transactional data from the user's bank is the need for the user to share the internet login credentials for each of their financial institutions with the system. In many cases this is a direct breach of the terms and conditions of usage of the internet services offered by the various institutions.

[00109] Systems that help the user to build a forward looking budget would appear to have a greater potential to bring about behavioural change as the user endeavours to honour the commitment they have made to themselves in creating the budget. These systems vary in their level of sophistication but generally involve the user having to allocate an amount of their income to different categories of spending similar to old school 'envelope budgeting' . The user allocates estimated amounts to various categories of spending such as housing, utilities, food, clothing, transport etc. Additional 'envelopes' may be created for savings and a specific amount (or simply the remainder) allocated for discretionary spending. The system may provide the user with totals for these categories and it is then up to the user to ensure that money is held in the bank account to cover each of these categories. To keep the amounts clearly segregated the user may need to maintain several separate bank accounts.

[00110] A limitation with systems based on old school envelope budgeting is that it is up to the user to determine the amount that needs to be set aside into each category per month. In this exercise the customer's own inaccuracy can limit the effectiveness of the budget. These tools also frequently have a limit to the number of categories or 'envelopes' available for budgeting which doesn't support the complexity of modern household finances. Allocating lump sums to spending categories doesn't allow the user to achieve the level of granularity required to differentiate between bills within a category. Further, individual bills may appear to belong in more than one category resulting in the user not knowing which category to allocate it to, or, once having allocated it, later forgetting which category was used. Some categories may be too broad and end up having so many individual bills that the high total amount appears unrealistic to the user who then reduces the amount set aside (think 'Insurance').

[00111] With the currently available methods it is also up to the user to regularly update the system with actual transaction amounts in each category. The accuracy and usefulness of the budget is entirely dependent on a high level of ongoing effort by the user. Such systems often fail because the level of effort becomes onerous. With respect to the methods for inputting transactional data into the budget system, some require the user to manually input daily transactions against the appropriate category either by keying in transaction details or by scanning receipts. A limitation here is that not all transactions will result in a receipt and more significantly, the accuracy of the system is entirely dependent on the diligence and accuracy of the user's input. As an alternative method the tool may use transaction feeds from the customer's various financial institutions which, depending on the tool, matches the transactions or requires the user to manually match the transactions to the various spend categories to retrospectively show the user how they have spent their money. Systems that utilise

transactional data feeds from the user's various bank accounts go part way to simplifying the matching of transactions but again, systems that require the user to breach the T&Cs of their bank's online usage in order to make that information available are problematic.

[00112] Most budgeting systems appear to work with a calendar month budgeting cycle. This causes a number of issues. A monthly budget may not suit the mental model that the user holds, particularly those who are paid weekly or fortnightly. Systems that offer only a calendar month budgeting period require the user to think of their budget in an unfamiliar time frame that contradicts their mental model. The resulting 'uncomfortableness' can impair the user's experience of and therefore compliance with their own budget. Additionally, as is discussed later, the currently available budgeting systems work best if all of the income that is to be received in the budget period is actually available from the first day of the budget period. This obviously won't be the case for a weekly paid worker enforced to use a monthly budget.

[00113] Existing budgeting systems allocate funds to envelopes on a monthly basis. This works well if all bills occurred monthly or more frequently. In such systems for quarterly, half yearly or annual bills either the user is going to incur an extra-large bill in some months which is likely cause the total bills for that month to exceed the total income, or the user is left to do the math to work out how much to set aside each month to prepare for each of these bills to ensure sufficient funds to cover them when they arrive. Such an exercise would be difficult without using a PC based spreadsheet which begins to defeat the purpose of having a separate budgeting app. [00114] Existing systems typically treat the budget period as a single time point with no consideration given to the relative timing of the receipt of income and the payment of bills. For example, in a month where the total income due is $1,000 and the total of bills due that month is $750, the user takes the remaining $250 as cash for discretionary spending as it would appear that there is no budgetary issue. However, when the income comprises 2 payments; $500 due on the 1st and $500 due on the 15th and on the 1st the user has taken the $250 and spends it. If the first bill for $400 is due on the 10th there is going to be an issue with cash flow as the cash-at- hand is now only $250.

[00115] The effectiveness of budgeting systems is limited by the user's discipline and motivation to actually implement and stick to them. The user can dutifully input the details of their income, bills and savings goals and in return the budgeting system can crunch the numbers and tell the user that they need to set aside $1,000 to cover bills, $200 for savings leaving them $300 to spend that month. But existing systems leave it up to the user to implement their budget by transferring the bills and savings money to separate accounts and to monitor their spending. A disciplined user may transfer the money as required but current budgeting systems do little to discourage users from 'stealing' money back from allocated bill and savings funds.

[00116] In one embodiment, the data management system is in the form of a budget management system that is able to automatically manage the distribution of funds for a user. Referring firstly to Fig. 1, a data management system 100 implemented using computer processing 102 and memory resources 104 accessible by at least one client system 106 via a data network 108 is shown. The client system is in the form of a processing device 110 (e.g. a PC, tablet, smartphone, etc) that enables the client (e.g. customer) to access the network 108. The system is configured to receive first data 112. In one embodiment, the first data 112 may comprise credit transaction data (e.g. income received from an employer), debit transaction data (e.g. bills payable), savings transaction data (e.g. savings goals) and budget cycle data (e.g. a timeframe). The first data 112 includes records each having at least one first identifier (e.g. an attribute associated with the debit transaction, such as an amount payable, the frequency, the next due date, the company name, etc). In one embodiment, the first identifier may comprise at least one credit identifier (e.g. an attribute associated with an income, such as details of the payer, the amount to be paid, the frequency, the due date, etc). A user is able to input data 112 into the client system (e.g. by entering data into a website or app). The input data is transferred to the system memory 104 for analysis by one or more management modules 118. [00117] In the detailed embodiment, the system is accessible by billing systems 114 (e.g. a service provider that issues bills) and crediting systems 116 (e.g. an employer that provides an income, a financial institution that provides interest payments). The system 100 is configured to receive third data 130 from the crediting systems 116. In one embodiment, the third data 130 may comprise credit transaction data. The system is also configured to receive second data 113 from the debiting systems 114. In one embodiment, the second data 113 may comprise debit transaction data. Similar to the first data 112 received via the client systems, the second 144 and third 130 data received from the billing 114 and crediting 116 systems include records having at least one second and third identifier (e.g. an attribute associated with the debit/bill or

credit/income) respectively.

[00118] The system includes a management module 118 that is configured to compare the first identifier associated with the first data received from the at least one client system 106 with the at least one second identifier associated with the second data received from the at least one billing system 114. The management module 118 generates first transfer data (e.g. data that confirms a match between the identifiers or data that confirms that no match was performed between the identifier) in dependence on the comparison. In one embodiment, the first transfer data comprises debit fund transfer data.

[00119] The management module 118 is configured to compare the at least one first identifier associated with the first data received from the at least one client system 106 with the at least one third identifier received from the at least one crediting system 116. The management module 118 generates second transfer data (e.g. data that confirms a match between the identifiers or data that confirms that no match was performed between the identifier attributes) in dependence on the comparison. In one embodiment, the second transfer data comprises credit fund transfer data.

[00120] The system also includes a distribution engine 120 that is configured to receive the first and second transfer data from the management module 118 and dynamically generate instructions to distribute data between a plurality of client accounts 122 in dependence on the first and second fund transfer data. In one embodiment, the distribution engine 120 comprises a funds distribution engine. In one embodiment, the data distributed by the distribution engine comprises data related to funds. [00121] Fig. 2 shows a high level flow diagram of the system 100. In the detailed embodiment, the management module comprises a first, second and third management module. As will be evident to the skilled addressee, the management module may be split into any number of separate modules for processing. In the detailed embodiment, the system comprises a second management module 124 that is configured to analyse the first data 112 received from the client interface 110 and the third data 130 received from the crediting system, and output the second transfer data to the distribution engine 120.

[00122] In the detailed embodiment, the second module 124 is accessible via a Pay screen on the client's processing device 110 and provides an interface for a user to input first data (e.g. the details of one or more recurring or one off sources of income that are deposited into the underlying Pay account). In the detailed form, the required details for the first data are; a name for the income stream, the frequency at which it is expected, the amount that is expected, and the date that the income is next expected to be received. The system comprises a processing logic (e.g. the second module includes instructions executable by a processor of the system) that uses the user inputs received by the second module and internal rules to create a schedule of incomes that are expected to be received into the Pay account.

[00123] In the detailed embodiment, a Pay screen provides an interface for a user to define their desired budget cycle. The user is able to enter details relating to a budget cycle's periodicity and start date. The user is also able to define a budget cycle while inputting the details of a weekly, fortnightly, or monthly income by electing to align the budget cycle to the income cycle. Should the user not define a budget cycle, the system may use calendar month as a default.

[00124] In the detailed embodiment, the system also comprises a first module 126 configured to analyse the first data 112 received from the client interface 110 and second data 144 received from the billing system, and generate first transfer data in dependence on the analysed first and third data. In one embodiment, the first module 126 may comprise a debit module.

[00125] The first module 126 is accessible via the Pay screen on the client's processing device 110. The Pay screen also provides an interface for a user to input the details of one or more recurring or one off bills that are to be paid from the underlying Pay account. The required details in the detailed embodiment are; the payment method by which the bill is to be paid, a name for the bill, the frequency at which it is expected, the expected amount payable, and the date that the bill is next expected to be payable. The system comprises a processing logic that uses the user inputs and internal rules to create a schedule of bills that are expected to be paid from the Pay account. Further, the Pay screen comprises of a header sections and two tabs for display purposes. In one embodiment, the pay screen includes the following display features: A Pay account header (providing information related to BSB, Account Number and applicable interest rate; available balance; whether the Pay account is On track', i.e. whether the available balance is sufficient to meet the bill payments due in the current budget cycle), and a "Your cycles tab" (e.g. a display of all budget events, both planned and actioned, that are due to occur or have occurred within the current cycle or due to occur in the next 2 budget cycles. Budget events may include income events, expected income payments, received income payments. Bill events may include planned bill payments, paid bill payments, pro-rated savings toward bill payments due in future budget cycles (Bill apportionments). Savings events may include planned contributions to savings goals and paid contributions to savings goals

[00126] Budget events are listed in chronological order. Overdue events that were not actioned in previous cycles, limited to the previous 3 months, are carried forward and displayed at the top of the current cycle. Planned events can be actioned on a date before, on or after the due date and their display is subsequently updated with the 'actioned' date.

[00127] Various user actions are available by tapping on the displayed budget events.

Available actions may be applied to the entire series of that budget event, e.g. changing the payable amount of a recurring bill, or may apply to only the current occurrence of the budget event, e.g. paying a bill. The specific actions permitted depend on the current status of the budget event (paid or unpaid, received or outstanding etc.) and whether the specific occurrence is the most recently actioned occurrence of the budget event.

[00128] The Pay screen also includes a transaction history tab. The second tab, named 'Transaction history' is a standard bank account transaction history. The transaction history also includes 'internal transfers' which are the automated rebalancing transfers executed by the core banking system as instructed by the processing logic. As these transactions can be numerous a user interface is provided to enable the user to set a filter to exclude internal transfers from the view. [00129] The system also includes a savings module 128 configured to receive savings data from the client interface 110 and output the analysed savings data to the funds distribution engine 120.

[00130] The savings module is accessible via a save screen that provides an interface for a user to input the details of one or more saving goals. Saving goals can be defined by the user to achieve a specific amount by a specific date for which the processing logic will calculate the required contribution per cycle necessary to achieve the goal, or the saving goal could be to simply contribute a set amount per cycle with no target amount or end date.

[00131] The Save screen comprises a header and two tabs for display purposes. The Save account header may provide the following information: BSB, Account Number and applicable interest rate and available balance.

[00132] The first tab, named 'Your goals' is a display of all of a user's savings goals. Save goals are listed in a chronological order based on their target dates or, for goals without a target date, listed in alphabetical order. This tab also includes a capability to allocate and re-allocate funds to and from individual goals and between goals. Various user actions are available by tapping on the displayed save goals. The available actions are dependent on the current status of the save goal. The second tab, named 'Transaction history' displays a standard bank account transaction history.

[00133] The system also includes a Spend screen in the detailed embodiment that provides an interface for the user to perform the following actions: Transfer to Save - this provides an interface where the user can transfer funds from the Spend account to the Save account to boost their savings; Quick top-up - this provides an interface where the user can transfer funds from the Pay or Save account into their Spend account when their Spend account has insufficient funds to meet day to day living needs; and Payment and transfers - enables the user to access the standard transactional capabilities of the financial institutions' mobile app. The Spend screen comprises a header and 2 tabs for display purposes. The Spend account header provides the following information: BSB, Account Number and applicable interest rate, available balance, number of days remaining in the current cycle

[00134] The first tab, named 'Current cycle' is a display of all of all transactions that have occurred in the current cycle. The second tab, named 'Transaction history' displays a standard bank account transaction history. This also has a filter to remove internal transfers from the view.

[00135] Fig. 3 shows a screen shot of the user interface where the user can provide the details of a regular income stream. The required fields are; amount, a name to help the user identify the income, the frequency at which it is received, and the next date it is expected to be received. The user is able to select from the following frequencies; once, weekly, fortnightly, monthly, quarterly, half-yearly, yearly. For income streams that are weekly, fortnightly, or monthly the user can also select to have their budget cycle aligned to the income stream. It is also possible for the user to nominate an end date for an income stream to account for income sources that are finite such as seasonal work.

[00136] The user is able to define their budget cycle in the same action as adding a new income by requesting that the budget cycle be aligned to the income cycle. Because our research has found that for most people aligning their budget cycle to their income cycle matches their 'mental model' of their budget, the system will as a default, check the option to match the budget cycle to the cycle of the first income added. This can of course, be overwritten by the user.

[00137] Because it is possible that an income transaction has already been received a user is also able to add a new income by first selecting the income transaction itself. Some of the details of the existing income transaction are pre-populated into the user interface.

[00138] Once an income stream has been defined the processing logic will use the frequency and next payment date provided to create a schedule of expected income receipts. This then informs the system of what income amounts can be expected and when they should be received.

[00139] The second module 124 will now be described in further detail with respect to Fig. 4. The second module 124 is configured to receive third data 130 from at least one crediting system 116 and analyse the received third data 130 to generate second transfer data 132. When data from crediting systems is received by the data management system, the system applies matching rules from within the processing logic to incoming data (e.g. the third data) to determine if it is a match with user inputted data (e.g. the first data).

[00140] The second module comprises a second matching engine 134 (e.g. a credit matching engine) that is configured to compare the at least one credit identifier attribute associated with the first data 112 received via the client interface 110 with the at least one credit identifier associated with the third data 130 received from the crediting system 116 and generate unmatched data 136 or matched data 138 in dependence on the comparison.

[00141] The second matching engine 134 is configured to output the generated unmatched credit data 136 to the at least on client system 110 to notify a user that the second matching engine 134 is unable to match the first identifier associated with the first data 112 received from client interface 110 with the second identifier associated with the third data 130 received from crediting system 116, or output the generated matched data 138 to the distribution module 120 for further processing and distribution of data between the plurality of client accounts 122.

[00142] If after the matching rules have been applied and no match was found then the credit transaction is left displayed as an unmatched transaction for the user to match manually. An interface is provided for the user to match the credit transaction to the correct occurrence of the pre-defined income stream. Once the user has manually made the match, the transaction details are stored as matching criteria for future matching requirements; i.e. the system 'learns' how to match the transaction for the next matching event.

[00143] The client interface 110 is configured to receive confirmation data (e.g. credit confirmation data in the form of user intervention) from the user upon receipt of the unmatched data 136 from the second matching engine, and output the confirmation data 140 to the second matching engine 134 to manually confirm a match between the first data originally received from the client system 106 and the third data 130 received from the crediting system 116. In response to receipt of the confirmation data 140, the second matching engine 134 is configured to store the credit confirmation data (e.g. on the non-volatile memory 104 - see Fig. 1) such that the second matching engine 134 learns to recognise similar unmatched data events and output matched data 138 to the distribution module 120 in lieu of unmatched data 136 to the client interface following a similar comparison outcome in the future.

[00144] When a match is established the system updates to acknowledge receipt of the income and this event triggers a redistribution where the processing logic determines on the basis of the new information, namely, the receipt of the income, what the balance of the Pay account should now be and instructs the core banking system to perform the required transfers between the Pay and Spend account. For example, if the amount of income received is in excess of the funds required to cover the budget events in the current cycle then the distribution engine 120 may redistribute excess funds to a Spend account.

[00145] It should be noted that transaction amount is typically not used (i.e. is not used as an identifier attribute) in the detailed embodiment as a transaction matching criteria as the system is designed to be able to accommodate the variability that occurs in real-life.

[00146] One of the key limitations of existing budgeting systems is the amount of user effort required to keep them up-to-date as things change day to day. Many systems also fail to accommodate for 'real life' events that challenge a rigid budget. Through customer resonance testing we identified the user needs that the system design needed to accommodate.

[00147] Because an 'income' can be thought of as a series of income payments or as a single payment occurring on a specific date there was a need to provide user actions that affect the whole series of future income payments (Series actions) and actions that affect only a single occurrence (Occurrence actions).

[00148] Fig. 5 shows a screenshot of the series action screen accessible on the client interface. The system provides an interface for users to perform the following actions; Edit - a user is able to edit: Frequency - e.g. employer changes from a weekly to fortnightly pay cycle; Amount - to reflect ongoing changes in amount paid; Next payment date - e.g. employer changes from paying on a Monday to a Friday; Name of income stream; Delete - a user can delete an income stream that they will no longer receive such as after leaving a job or selling an income producing asset (all previously actioned occurrences will continue to be displayed to provide a history); Pause / Resume - a user can pause or resume an income stream that is seasonal e.g. income from a holiday house (the processing logic will exclude paused income streams when determining what funds sources will be available to service the budget).

[00149] The system provides an interface for users to perform the following actions:

• Match to an existing transaction - where the transaction matching rules have failed to match a credit transaction to an expected income occurrence the user is able to perform the match manually via the income occurrence displayed on the Pay screen. It is also possible to effect the match via the unmatched credit transaction. Un-match - where the user or (less likely) the system has incorrectly matched a transaction to an income occurrence, the user is able to un-match the transaction from the income occurrence

• Skip / un-skip - where the user knows that a future income occurrence will not be received they are able to 'skip' the income occurrence. The system will accordingly recalculate the required balance in the Pay account now knowing that the skipped income occurrence will not be received.

• Each of these actions will result in a change to the balance that is required in the Pay account. The system responds to these actions by executing the distribution calculation and transferring funds between the Pay and Spend accounts as required.

[00150] Existing budget systems do not closely integrate with bank accounts in order to execute bill payments. They simply provide a record of the bills that need to be paid and it is up to the user to physically pay the bill by the due date. There is a need for a budgeting system that is cognisant of the various bill payment methods that may affect a user's budget. Further, there is a need for a budgeting system that, when provided with the details needed to effect payment of a bill, is able to execute that payment automatically. The present system provides a budgeting capability that is tightly coupled with the user's bank account and so, for bills that are paid via a customer initiated transaction i.e. via external or internal transfer or BPAY the system can instruct the core banking system to execute payment of each occurrence of a bill series with no further effort from the user after the initial input of the bill.

[00151] When bills are input into the system, the system requires details of the payment method and payment recipient so that it has the information it needs to instruct the core banking system to execute the bill payment transaction. Fig. 6 shows the interface where the user selects the bill payment method. There are 3 choices, including; electronic funds transfer or BPAY - user initiated payment; direct Debit - biller / vendor initiated payment; and set money aside - where a payment method is not specified. After selecting the bill payment method the following details are required: a name for the bill; the amount to be paid; the frequency at which the bill occurs (the system allows once, weekly, fortnightly, monthly, quarterly, half-yearly, yearly); and the next due date. Once a bill has been defined the processing logic will use the frequency and next payment date provided to create a schedule of expected bill occurrences. Each entry of a bill triggers the distribution calculation where the system's processing logic determines the required balance of the Pay account based on all budget events in the current budget cycle. Refer to 'Funds distribution' section for details of the calculation.

[00152] Fig. 7 shows the user interface for the input of bills that are paid via EFT or BPAY. In some forms, the system includes the core banking system. The system is able to interrogate the core banking system to determine if the client has any existing accounts within the core banking system (see for example, pre-population module 165 in Fig. 2). The system (e.g. the pre- population module 165, which includes instructions executable by a processor to perform the following actions) can perform this step by comparing a client identifier attribute (e.g. a client's name, tax file number, etc.) and with existing accounts that form part of the core banking system. If a match is made (i.e. the client has an existing account with the core banking system), the system then further interrogates the client's account to determine if the client has any already existing BPAY billers, pre-existing automatic transfers or continuous credits or debits (e.g. a regular phone bill, a regular income). If this information is identified, the system is able to pre- populate debit or credit data records with attributes identified on the core banking system. In this way, the initial set-up of the credit and debit transaction data may be automated. The client is then able to access the pre-populated transaction data records to amend or delete the records if required. Further, any new external accounts or BPAY billers can be securely added while inputting the bill details. In another embodiment, the system is able to connect with external core banking systems (e.g. when security access is provided) to interrogate the external system and automatically pre-populate the credit and debit transaction data records for the user.

[00153] The ability to automate the pre-population of transaction data on behalf of the client makes transitioning to the fund management system easy for existing customers of a core banking system (i.e. by not requiring the client to effectively repeat the creation of all of those existing scheduled payments by entering them as bills manually). Further, system allows a client to 'convert' an existing transactional account (e.g. existing account on the core banking system) to be an account managed by the funds management system. Upon activation of the account the system is able interrogate the core banking system for any previously existing scheduled payments that debit the Pay account and then automatically create bills in the Pay account that are linked to those scheduled payments to ensure that funds are available to cover them. Bills produced in this way are fully editable by the customer and become the way that the customer maintains those scheduled payments going forward. [00154] In some forms, the system facilitates the ability of clients from external banks (e.g. external core banking systems) to use the funds management system. The system applies data aggregation methods to access an external clients customer's transactional data from their externally held bank accounts and leverage the existing transaction matching rules in order to identify recurring payments that are likely to be bills. The system is then able to create bills in the Pay account which the customer could choose to accept or reject.

[00155] In some forms, the system is able to leverage electronic methods of receiving bills such as email, BPAY View, Australia Post Digital Mailbox to automatically create and update bills in the Pay account by importing the relevant details from the electronic bill in order to populate the required fields for the bill in the Pay account. This feature allows clients to set a bill to be paid automatically even if the amount payable is variable because the system updates the forecast amount when the actual amount is received in the electronically delivered bill.

[00156] In some forms, the system is able to store multiple sets of bill details for a single bill series assigned to specific occurrence dates to allow a client to set different amounts for different occurrences of the same bill. For example, if a client knows that their next mobile phone bill is likely to be closer to $150 due to excess data usage while on holiday, the client can edit the amount of only the next occurrence (i.e. edit an identifier attribute associated with the particular debit transaction data record) to $150 while leaving all subsequent occurrences at the usual $90. This allows a client to set different transaction amounts for bills that experience seasonal variation (e.g. electricity and gas).

[00157] Fig. 8 shows the user interface for the input of bills that are paid via a direct debit where the biller 'pulls' the funds from the user's bank account. Often a user will not know the exact amount of a bill that is paid via direct debit. The system allows the user to provide an estimate of the bill amount and, should the user's estimate be too high, once the bill payment transaction has been matched to the bill, excess funds are distributed to the Spend account. Should the estimate be too low, the system will allow the total payment amount to be drawn but will then transfer the shortfall of funds from the Spend account.

[00158] Fig. 9 shows the interface for bills where the user has not yet decided on a payment method. This allows for real life situations such as, for example, a user knows that they will need to pay a large sum for car insurance in 10 months' time but they may plan to shop around and therefore don't yet know who the biller will be. [00159] As with the input of incomes it is possible that a user has already paid a bill from the Pay account before they have added the bill as a budget event. In this case the user is able to input the bill by tapping on the transaction which will cause some of the bill details to pre- populate.

[00160] The first module 126 will now be described in further detail with respect to Fig. 10. The first module 126 comprises a first matching engine 142 configured to compare the at least one first identifier associated with the first data 112 received from the client interface 110 with the at least one second identifier associated with the second data 144 received from the billing system 114. In one embodiment, the first matching engine my comprise a debit matching engine. The first matching engine 142 is able to generate unmatched data 146 (e.g. no match was able to be made in relation to a request for funds made by a billing system) or matched data 148 (e.g. a match was able to be made in relation to a request for funds made by a billing system) in dependence on the comparison.

[00161] The first matching engine is configured to output the generated unmatched debit data 146 to the client interface 110 to notify a user that the first matching engine 142 is unable to match the at least one first identifier associated with the first data 112 received from the client interface 110 (i.e. during the initial set-up of the system by the user) with the second identifier associated with the second data 144 received from the billing system 114, or output the generated matched data 148 to the distribution module 120 that is configured to instruct the release of funds from a debiting account (i.e. the account used to pay bills, also referred to as a pay account) to the billing system 114.

[00162] The distribution module 120 is configured to compare the at least one first identifier associated with the first data received from the client interface 110 with the second identifier associated with the second data received from the at least one billing system and generate instructions to distribute funds between the plurality of client accounts in dependence on the comparison.

[00163] The client interface 110 is configured to receive confirmation data from the user upon receipt of the unmatched data 146 from the first matching engine, and output the confirmation data 150 to the first matching engine to manually confirm a match between the first data originally received from the client system and the second data 144 received from the billing system. In response to receipt of the confirmation data 150, the first matching engine 142 is configured to store the confirmation data 150 such that the first matching engine learns to recognise similar unmatched data events and output matched data to the transfer module in lieu of unmatched data to the client interface 110 following a similar comparison outcome in the.

[00164] The system provides a transaction feed in near real time of all transactions that debit or credit a Pay account. As they are received into the system the transaction matching rules are applied to each transaction to find the budget event that it can be matched to. When a debit transaction has been successfully matched to a bill occurrence the budget is updated and a distribution is triggered. The budget is updated to indicate the bill has been paid and so funds no longer need to be held for it. The distribution will mean that any difference between the planned bill payment amount and the amount of the transaction is transferred between the Pay and Spend accounts as appropriate.

[00165] If a debit transaction cannot be matched to a bill occurrence it is displayed as an unmatched transaction and a user interface is provided for the user to manually match the transaction to the correct bill occurrence. Once this match is established the transaction details are stored as matching criteria for future matching requirements.

[00166] As previously detailed, the system is able to interrogate the core banking system to determine if the client has any existing accounts within the core banking system or within an external core banking system. By applying similar methodology, the system is able to automatically create debit transaction data records to cover mortgage repayments by detecting the presence of a home loan account held with the core banking system or with an external core banking system (e.g. if security access to the external core banking system is provided) for which a repayment schedule has been set up by the administrator of the core or external banking system. In dependence on the interrogation of the core/external banking system, the system is able to generate pre -populated debit transaction data records to ensure that funds are available in the Pay account to meet mortgage repayments when they fall due. It is possible for the system to prioritise mortgage repayment bills above other bills due to the consequences of default on mortgage repayments being potentially more distressing for customers. These bills may not editable by users (other than bill name). Instead the application updates the bills in response to changes in the repayment schedule in the core banking system. These changes include events such as: changes in the repayment frequency; changes in the repayment amount due to:

customer request; interest rate changes; changes in loan terms e.g. when a loan rolls from Interest Only to Principal and Interest, or from Fixed Rate to Variable Interest Rate; and increased borrowings.

[00167] In some forms, the client is able to create a Save goal that is linked to the Home Loan and the mortgage repayment. This allows the client to define a goal to repay their home loan by a specific date. The system uses the loan information stored in the core banking system such as current balance, interest rate, contractual term, and the standard repayment to create an additional loan payment bill that will see the home loan paid off by the client's target date. An event feed informs the system of any changes to the customer's home loan account such as interest rate changes and redrawing of funds, and will actively adjust the additional loan payment bill accordingly.

[00168] Referring to Fig. 11, for bills paid via EFT or BPAY a user is able to select that the system should pay the bill automatically. When selected, this system will instruct the core banking system to execute the bill payment transaction as per the schedule of bill occurrences. Users can also select to pay bills manually which affords the user the opportunity to update the bill amount if they have become aware of a change in the payable amount since they first input the bill. For bills that are to be paid manually by the user a notification is sent as a reminder.

[00169] As discussed with respect to incomes, one of the key limitations of existing budgeting systems is the amount of user effort required to keep them up-to-date as things change day to day. Many systems also fail to accommodate for 'real life' events that challenge a rigid budget. There is a need for a system that allows a user to make changes to both a series of bill occurrences and to single occurrences in response to real life events. Through customer resonance testing we identified the user needs that the system design needed to accommodate.

[00170] Because an 'bill' can be thought of as a series of recurring bill payments or as a single payment occurring on a specific date there was a need to provide user actions that affect the whole series of future bill payments (Series actions) and actions that affect only a single occurrence (Occurrence actions).

[00171] The system provides an interface for users to perform the following actions: edit - a user is able to edit: name of the bill; amount to be paid; frequency of bill occurrence; next payment date; automatic / manual bill payment; pause / resume - a user can pause a bill that they won't need to pay for a period of time (e.g. an envisaged scenario was the pausing of a weekly gym membership bill while the user recovered from an injury); and delete - a user can delete a bill that is no longer required. All previously actioned occurrences will continue to be displayed to provide a history.

[00172] The system provides an interface for users to perform the following actions:

• Pay Now - this action is available on all bills. The system allows a user to manually pay a bill even if it is one that they have previously set for automatic payment. This design accommodates situations where the customer may need to pay a bill earlier than expected.

• Match to an existing transaction - where the matching rules have been unable to

match a bill occurrence to a debit transaction the user is able to do so manually. It is also possible to initiate the match from the unmatched transaction to the bill occurrence.

• Un-match - where a bill occurrence has been incorrectly matched to a debit

transaction the user is able to un-match it.

• Skip / un-skip - where the user knows that a future bill occurrence will not be payable they are able to 'skip' the bill occurrence. For example, weekly tutoring fees may be budgeted but the user can skip those occurrences that fall within a period that the family will be away on holidays.

[00173] Each of these actions will result in a change to the balance that is required in the Pay account. The system responds to these actions by executing the distribution calculation and transferring funds between the Pay and Spend accounts as required.

[00174] Fig. 12 shows a screen shot of display for the users cash flow position. Existing budgeting systems that are not updated in real time leave the user unsure of whether they are in a good cash flow position on a day to day, hour to hour basis. There is a need for a budgeting system that provides a user with an accurate status of their cash flow position on demand. This system provides the user with a displayed indicator of On track' when the balance of the Pay account is sufficient to meet the budget events of the current budget cycle and 'Uncovered' when it is not. [00175] The system provides input screens that allow the user to create one or more Save Goals. Once the Save Goal is created, the system automatically adjusts the user's budget and immediately moves the amount required to cover the Save Goal Contribution from the Spend Account to the Pay Account.

[00176] The system allows for two types of Save Goals - Achieve a Goal and Rainy Day. The 'Achieve a Goal' type allows the user to save a specific amount by a specified date. Fig. 13 shows the input screen for the creation of an 'Achieve a Goal' save goal. Once the user inputs the Amount and Target Date, the system calculates the Save Contribution required each budgeting period to achieve that goal. The user has the opportunity to accept that Save

Contribution Amount or enter a different amount. The 'Rainy Day' type allows the user to save a set amount each budget cycle without specifying a specific target amount or date. Fig. 14 shows the input screen for the creation of a 'Rainy Day' save goal.

[00177] The system tracks the progress of an 'Achieve a Goal' type and changes the status to 'Achieved' when the target amount has been reached. Once the Save Goal has been achieved, the system automatically stops contributions to that Save Goal thus keeping the user's budget up to date in real time. When the User decides to take the money from a Save Goal, they are able to 'purchase' the goal. The system stops the contributions for that Save Goal and updates the budget accordingly. All funds accumulated for that Save Goal are automatically moved to the Spend Account ready for the User to spend as required.

[00178] The system provides the ability for a user to pause a Save Goal at any time.

Contributions for that Save Goal are automatically stopped and the budget is updated accordingly. Funds accumulated for that Save Goal remain allocated to that Goal. The User can then resume the Save Goal at any time. When an 'Achieve a Target' Save Goal is resumed, the system automatically calculates the Save Contribution per period required to achieve the Goal and resumes the contributions and updates the budget accordingly.

[00179] The system provides the ability for a user to edit details of a Save Goal at any time. The changes are immediately reflected in the User's Budget and money is moved between the Pay and Spend accounts to reflect that change.

[00180] The system provides the ability for a user to delete a Save Goal at any time.

Contributions for that Save Goal are automatically stopped and the budget is updated accordingly. The user has the ability to redirect any funds accumulated in that Save Goal to another Save Goal or to transfer it to the Spend Account.

[00181] The Save screen comprises of 3 display elements: Header: The header area includes account information and the available balance of the Save account. The available balance is the cumulative balance of all of the save goals. Your goals tab. A screen shot of this tab is shown in Fig. 15.

[00182] The 'Your goals' tab lists the user's saving goals in chronological order of target achievement date or, where the goals have no target date they are listed in alphabetical order. In the case of goals that have a target amount and target achievement date the system also displays the user's progress toward achieving the goal by way of a progress meter. The 'Transaction history' tab provides a standard bank account transaction history

[00183] The system provides a user interface which allows the user to transfer money between Save Goals or to the Spend Account at any time. These transfers do not have any effect on the User's budget. When the reallocation is completed, the system automatically determines if the movement results in one of the Save Goals becoming off track (unlikely to meet the Target Amount by the Target Date) and the affected Save Goal(s) is highlighted as being 'off track' on the Save screen.

[00184] As has been discussed previously, existing budget systems frequently consider the budget period as a single point in time and do not address the timing of budget events. It is often left to the user to determine when there is sufficient available cash to be able to lock away savings while still leaving sufficient cash to cover bills when they fall due and in relation to when expected incomes would be received. There is a need for a budgeting system that can manage the relative timing of these events in order to determine the earliest opportunity at which save goal contributions can be moved to the higher interest rate earning saving account.

[00185] In this system, save contributions for each save goal are automatically transferred from the Pay account to the Save account once per budget cycle. They are transferred as part of the distribution calculations as soon as there are sufficient funds (or based on expected incomes within the cycle there will be sufficient funds) to cover all save contributions as well as all bills due to be paid within the current cycle. The system prioritises payment of bills over the payment of save contributions. Where the conditions for transferring the full save contribution are not met during the cycle, the save contribution may be transferred to the Save account on the last day of the budget cycle: If there are insufficient funds available on the last day of the budget cycle to cover the full contribution amount for the unpaid save goals, a partial contribution (equal to the amount available) is transferred.

[00186] With existing budget systems it can be difficult for a user to know from day to day, hour to hour, how much of the available cash at bank is actually safe to spend. Given a typical system that is not being kept up to date in real time, $1000 may have been set aside to cover 8 bills due in the current cycle of which $150 remains. But which bills have already been paid? Were all the actual amounts paid the same as the planned amounts? How much of the $150 is really safe to spend?

[00187] There is a need for a system that can accurately and in real time tell the user exactly how much is safe to spend at a point in time. Because this system updates in real time after every budget event action in order to keep the balance in the Pay account at the amount required to cover the budget events occurring in the current cycle then any funds that are in the Spend account are safe to spend.

[00188] Fig. 16 is a screen shot of the Spend screen. The relevant information for the user is the available balance which is the amount of cash that is safe to spend on discretionary items, and the number of days remaining in the cycle which is the number of days that that balance is available for.

[00189] Existing budgeting systems lack the flexibility to cope with the variability of everyday life. A real budget needs to be able to flex with increasing and decreasing budgetary demands and facilitate the quick responsive decisions that the user may want make. There is a need for a budgeting system that is able to accommodate and adjust for ad hoc events and decisions by the user.

[00190] This system allows the following actions on the Spend account. When a user finds that their safe to spend balance in their Spend account is in excess of their immediate needs or if the user simply wants to boost one of their savings goals along, the system provides an interface whereby the user can transfer funds from the Spend account to the Save account more quickly than by using a standard transfer screen. As shown in Fig. 17 the 'from' account and 'to' account are already pre-populated as is the transaction description. [00191] From time to time unexpected situations may arise that find the short of cash in the Spend account. The system provides an interface through which the user can quickly and easily 'top-up' the balance of their Spend account by taking funds from the Save or Pay accounts. Clearly, taking funds from the Save account will mean that one or more of the user's save goals are affected but the user is in control of which goal(s) the funds should be taken from. Taking funds from the Pay account will of course place the Pay account into an 'Uncovered' status as the balance is now less than that required to cover all planned budget events due in the current cycle. To prevent those from being immediately pulled back into the Pay account the

distribution calculation is temporarily suspended until triggered to recommence. These triggers are; the receipt of income into the Pay account or a withdrawal from the Spend account (which should be the withdrawal initiated by the customer to access those needed funds). Fig. 18 shows the Quick top-up interface.

[00192] In addition to providing users with the ability to choose their own budget cycle the system is also able to accommodate a user's change of mind regarding their budget cycle. If, after having added their incomes, bills and save goals the user decides to try a different budget cycle, the system will instantly perform the distribution calculation according to the new parameters and perform the necessary transfers.

[00193] This immediate responsiveness to user and external actions highlights how the system meets the currently unmet need of not only updating the budget in real time to provide an always accurate cash flow position but by also executing the required transactions to keep the budget and the underlying bank accounts aligned. This responsiveness also provides the user with the opportunity to test out various 'what if scenarios. For example, a user could experiment with adding additional home loan repayments as bills to see the impact on their budget and determine if it would be sustainable to pay extra. Additional savings goals could be edited or contributions to existing save goals could be increased to achieve them faster. With each edit or addition the system will update the budget and the displays will enable the user to visualise the new budget over 3 cycles and determine if it can be sustained longer term.

[00194] The system provides the user with alerts and notifications which help them to keep the Bett3r account accurate and stay in control of their finances. Typically these notifications let the user know when action is required by them. Some examples of these notifications include alerting the user when: an expected income payment has arrived; a bill that the user has elected to pay manually is due within 3 working days; there is insufficient money available to pay the bills that are due within the current budget cycle; the user is not On track' to cover save contributions or the amount to be set aside to pay future bills; and there is left over money in the Spend Account at the end of the budgeting period which may be put towards savings.

[00195] A user can request a Debit Card linked to the Pay account which allows them to pay bills and make ad hoc purchases such as groceries, lunches or coffees from the Pay account using a card. To ensure that there is enough money in the Pay Account to cover ad hoc spending using the Debit Card, the System provides the ability for the User to set up a Debit Card Allowance. Fig. 19 shows the user interface for setting up the allowance. When a Debit Card Allowance is set by the User, the system automatically updates the budget and sets aside that amount in the Pay Account. Any purchases made using the Debit Card that do not have a corresponding Budget Item are offset against the Debit Card Allowance amount.

[00196] The Pay Screen provides a visual display of the amount used for the current Budget Cycle (refer to Fig 20). The system also provides a detailed list of all transactions made against the Debit Card allowance for the current Budget Cycle (refer to Fig 21).

[00197] The system provides the ability for the User to update or delete the Debit Card Allowance at any time. These updates are immediately reflected in the User's Budget and money is automatically transferred between the Pay and Spend accounts to reflect these changes.

[00198] A representation of the system is shown in Fig. 22. The system comprises a system of engagement (SOE) 201 which in turn comprises a datastore 203 and processing logic 205. The datastore 203 contains records for each bill, income stream and save goal entered by the user, plus budget cycle details, transaction details and additional data for each of these items as derived by the processing logic 205. The system comprise an API gateway 207 for

authentication of the user 209, data flow control and other security measures.

[00199] The SOE 201 is integrated with a Core Banking System 211 via a web services layer 213. The web services layer is able to co-ordinate and orchestrate web service requests and responses between the software run on a remote processing device 209 (e.g. an application on a mobile smartphone) and the core banking system 211. The core banking system 211 comprises a Bank Datastore 215 holds all customer and account related data, a Customer Banking Service 217 through which the customer can directly instruct the core banking system 211, and a Transaction Service 219 through which the SOE 201 can instruct the core banking system 211. The core banking system 211 also provides a near real time transaction feed 221 which passes all transactions relating to client accounts to the SOE 201.

[00200] The SOE 201 also provides data to a Customer Analytics System 223 which generates and manage events based on client data. For example, where data shows a customer's Save account is near to achieving a Save Goal named 'House Deposit' a marketing event to promote a Home Loan may be generated for that customer.

[00201] The following series of tables describes the processes executed by the application's processing logic in order to create, execute and update the budget and cash flow in real time response to triggering events.

[00202] In order to determine the balance required in the Pay account at a point in time the application must first identify all income payments expected in the current Budget Cycle.

[00203] In order to determine the balance required in the Pay account at a point in time the application will; (1) identify the amount required to be set aside for the Debit Card Allowance (if one exists), (2) identify and quantify all bills due to be paid in the current Budget Cycle and (3) identify and quantify the amount to be set aside to cover save goal contribution and (4) identify and quantify amount to be set aside for bills due in the next Budget Cycle but before the first income in that cycle.

[00204] Table 2 (below) and Fig. 24 details how the system identifies and allocates funds for debit card allowance and bills due in the current cycle

[00205] Table 3 (below) and Fig. 25 detail how the system identifies and allocates funds for save goals.

[00206] Table 4 (below) and Figs. 26-28 detail how the system identifies and allocates funds for bills due in a future cycle.

[00207] Table 5 (below) details the funds distribution calculation. After determining all the budget events that will impact the Pay account within the current cycle, the application calculates what the balance of the Pay account should be. This calculation can be triggered at any point in time and these triggers are explained in the Funds Distribution section of this document. The near real-time provision of data concerning trigger events and the immediacy of the application's response is what gives the user a budget that is updated in near real-time. [00208] Table 6 (below) details a funds distribution scenario.

[00209] Table 7 (below) details a funds coverage calculation.

[00210] As details in relation to the account management modules, the system provides the ability to automatically match credit and debit transactions. This allow for the system to provide a sophisticated and robust method for maintaining the budget's currency and accuracy. This is achieved by 'marking off as actioned each budget event by automatically matching that budget event to the appropriate transaction fed from the core banking system to the application in near real time.

[00211] Automatic transaction matching means that the user is not obliged to regularly log in to the application to perform these maintenance tasks. However, the user is able to manually match and un-match transactions should it be necessary. Fig. 29 illustrates a flow diagram showing the automatic matching of debit transaction data.

[00212] In order to match banking transactions to the appropriate bill or income occurrence, each bill and income has attributes stored against it as matching criteria. For a newly added bill (e.g. debit transaction data record 150) the first matching engine 142 will derive and store a set of probable matching criteria as per the table below. A similar processing step occurs for income transaction data records. For bills the matching criteria used is dependent on the payment method used. In the vast majority of cases the derived matching criteria will be confirmed as correct by the first matching. However, once a bill or income has been matched to a transaction, the attributes of the matching transaction replace the derived values and are stored against the bill or income as matching criteria for future matching events. This 'refreshing' of the matching criteria with the details of the most recently matched transaction allows the system to learn as the customer's purchasing behaviours change. This is particularly useful where a customer may have a bill for 'Groceries' to which transactions from a particular grocery store have been matched multiple times. If the customer moves to a new residence and begins shopping at a new grocery store, once the first transaction at the new store is matched to the Grocery bill the system will save the matching criteria applicable to the new store.

[00213] Transaction description is an attribute that is used as a matching criterion and it requires some special treatment. The quality of a match based in part on transaction description is determined by the percentage of characters in the stored description that match the description in the transaction. Because transaction descriptions usually do contain long strings of characters that are common to all transactions e.g. 'scheduled payment external transfer', these strings of common characters are removed so as to prevent an artificially high correlation. Table 8 (below) shows the bill/income type, the associated identifier attribute used for matching and the rationale behind the use of the identifier attribute.

[00214] Banking transactions that debit or credit the Pay account are sent to the system via the near real-time transaction feed from the core banking system. The system applies the matching rules to each transaction as soon as it is received. Transactions that are successfully matched to a bill or income occurrence are not displayed on the Pay screen; the evidence of them having been received is apparent in the fact that the bill or income occurrence is marked off as having been actioned. Where the system has been unable to match a transaction to a bill or income occurrence the un-matched transaction is displayed on the Pay screen so that the user can manually match the transaction to the correct bill or income occurrence at which point the transaction attributes will be stored as matching criteria to enable a match next time. This interaction allows a client to 'teach' the system about the matching criteria to use for that bill to enable a successful automatic match the next time that transaction is received. If an un-matched transaction does not belong to an existing bill or income the user is able to 'ignore' the transaction (by tapping ignore) or the user can use the transaction as a basis upon which to add a new bill or income.

[00215] Where a user has deliberately un-matched a transaction from a bill or income occurrence, the system assumes that the user is correcting an incorrect match and so will not apply the matching rules to that transaction again because reapplying the rules will produce the same result. The system waits for the user to manually action the transaction and, if the user matches it to another bill or income occurrence (e.g. provides debit confirmation data 150) then the transaction attributes are stored against the new bill or income (e.g. the debit identifier attributes of the particular debit data record are updated). In this way the system learns and the rate of transactions matched automatically increases.

[00216] The matching rules are applied in a logical sequence. Firstly, bills are only matched to transactions that debit the Pay account and incomes are only matched to transactions that credit the Pay account. The matching rules are not applied to bills and incomes that have been 'paused' or 'deleted' or to bill and income occurrences that have been 'skipped' or already 'matched' .

[00217] A transaction will not be matched to a bill or income occurrence if the date of the transaction is earlier than the original due date of last matched occurrence of that bill or income. See the table below for an example.

[00218] A transaction dated 17th Nov will not be automatically matched to the Rent bill due on 28th Nov because the transaction date is earlier than the original due date of the last matched occurrence which is 21st Nov even though it was matched to an earlier transaction dated 15th Nov.

[00219] Because an income, and even more commonly bills, can have multiple occurrences even within one budget cycle, it is important that transactions are matched to the correct occurrence of a bill or income. The system applies date based rules to determine whether to allow a match when the transaction date differs from the expected date for the bill or income. In this exercise the system has closely reflected human behaviour by varying the allowable date deviation based on the original frequency of the bill or income. For example, it is foreseeable that a user may pay an annual insurance bill up to 8 weeks in advance of the due date provided to the application when they first entered the bill, but it would be unlikely for a user to pay a weekly bill more than 5 days in advance of the due date provided. The table below details the allowable differences in transaction date and bill or income expected date. Note that where the user has nominated to have a bill paid automatically by the system then date variations are unlikely to occur and especially, bills will not be paid earlier than the expected date. It is of course foreseeable that due to some external issue that automatic bill payments are delayed. For this reason the matching rules will not match a transaction to an automatically paid bill that has a due date later than today but will allow matching back to an earlier date.

Table 9 (below) shows an example of determining the allowable timeframe for

[00221] Two scenarios exist where payment of a bill can result in a 'pending transaction' which is followed by a settlement transaction up to five days later; (1) when a payment to an external account or a BPAY biller is made outside of the Bank's normal hours the available balance of the Pay account is reduced by the pending transaction amount but the current balance is left unchanged until the settlement transaction is processed and (2) when a bill is paid with a scheme debit card using the 'Credit' functionality where a pending transaction or 'hold' is created to reserve funds from the available balance until the settlement transaction is processed. In both of these cases the system applies the matching rules to the pending transactions so that the bill can be marked off as paid. When the settlement transaction arrives the matching rules are applied and the match to the pending transaction is transferred to the settlement transaction.

[00222] If after applying the matching rules to a transaction no matching bill or income occurrence is found, the transaction is displayed in the Pay screen as an un-matched transaction. If only one bill or income occurrence meets the matching criteria then the match is made at that point. If more than one bill or income occurrence meets the matching criteria then additional rules are applied to determine a 'Matching Factor' for each of those occurrences.

• Calculate the difference between the transaction amount and the occurrence amount =

$DIFF

• Calculate the difference between the transaction date and the due date of the oldest unmatched occurrence of the bill or income = DateDIFF

• Calculate the occurrence's MatchingFactor as follows: MatchingFactor = (IDateDIFFI

+ 1) X (l$DIFFI + 1)

The transaction is then matched to the bill or income occurrence that produced the smallest Matching Factor.

[00223] An example of the system logic for the automatic matching of credit and debit transaction data is shown in Tables 10 & 11 (below). At step 1 (see Table 10), the system identifies all credit (e.g. income) and debit (e.g. bills) that could potentially match the transaction data received from with a crediting or debiting system

Table 10

[00224] At step 2 (see Table 11), for each identified transaction data record, the system identifies a correct occurrence for match purposes.

Table 11

[00225] Referring now to Fig. 30, the automatic matching logic will be further described. The system initially checks if transaction date is after last matched date - Bills and Incomes that have a matched occurrence with a due date after the transaction date are discarded from the possible set of matches to ensure that old transactions are not matched to future occurrences. At step 301, the system checks the Base Account and determines if the transaction involves the Pay account. Auto matching is only triggered for transactions to or from the Pay account. At step 303, the system determines the direction of funds; debit or credit. If transaction debits the Pay account, the system the moves to step 304, and determines if Other Account' details exist (e.g. EFT). If Yes, at step 305, the system keeps all bills that match exactly on BSB, Account Number, and Description. If No, at step 307, the system moves to step 309. At step 309, the system determines if BPAY details exist. If Yes and CRN is persistent, at step 311, the system keeps all bills that match exactly on Biller Code, CRN and Description. If Yes and CRN is variable, at step 313, the system keeps all bills that match exactly on Biller Code and

Description. If No, the system moves to step 315. At step 315, for debit transactions that are not EFT or BPAY, the system performs a fuzzy match on Description and keeps all bills that pass fuzzy match. If transaction credits the Pay account, the system performs fuzzy match on Description and keeps all incomes that pass fuzzy match. If one or more bill or income occurrences remain after applying the above rules then the system moves on to step 317. At step 317, the system performs occurrence matching.

[00226] The embodiment of the system detailed above applies a 'Spender' persona, where the goal is to hold the minimum amount required to cover bills in the Pay account, make regular contributions to Save goals, and transfer all remaining funds to the Spend account to maximise the amount of cash available for discretionary spending. Any shortfalls or excesses in the Pay are resolved via automated transfers between the Pay and Spend accounts. In an alternative embodiment, the system can respond to the different 'money management personas' that may exist. In at least one embodiment, the Saver persona may prefer to allocate to themselves a fixed spending allowance to be transferred to the Spend account and have all excess funds transferred to the Save account in order to maximise their savings. In this embodiment, shortfalls and excesses in the Pay account can be resolved through automated transfers between the Pay and Save accounts.

[00227] In another form, the system provides customer level settings allowing users to define rules of operation that apply to their account. User definable rules may include:

Operate for Saver or Spender persona;

Interactive messages that seek permission before pulling funds from the Spend account;

Assigning relative priorities to individual Save Goals and Bills; Types of notifications that the customer wants to receive;

Choice of bill payment amount below which apportionment is not done for future bills. E.g. a customer can choose not to apportion over the year for low value annual bills; and Set default choice of automatic or manual bill payment.

[00228] The terms 'module' and 'engine' as used in the summary, description and claims refer to one or more sequences of coded software (e.g. software components) comprising instructions to be executed by a processor. In some forms, the referenced module or engine includes all of the instructions necessary to accomplish the referenced function. In some forms, the modules may overlap and together accomplish the referenced function. In some forms, the module or engine may include further sub-categories of modules or engines configured to accomplish certain functions.

[00229] The word 'comprising' and forms of the word 'comprising' as used in this description and in the claims does not limit the invention claimed to exclude any variants or additions.

[00230] Modifications and improvements to the invention will be readily apparent to those skilled in the art. Such modifications and improvements are intended to be within the scope of this invention.