WO2023228195A1 - Aperçus et recommandations basés sur une transaction - Google Patents

Aperçus et recommandations basés sur une transaction Download PDF

Info

Publication number
WO2023228195A1
WO2023228195A1 PCT/IL2023/050543 IL2023050543W WO2023228195A1 WO 2023228195 A1 WO2023228195 A1 WO 2023228195A1 IL 2023050543 W IL2023050543 W IL 2023050543W WO 2023228195 A1 WO2023228195 A1 WO 2023228195A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
recommendation
insight
transactions
account
Prior art date
Application number
PCT/IL2023/050543
Other languages
English (en)
Inventor
Avi BEN YOSSEF
Ilia GUTMAN
Ronen MEIRI
Danny VAROD
Itzik JAN
Yohan BERDUGO
Amichai Yehuda LEVY
Avishay MERON
Original Assignee
One Zero Digital Bank Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by One Zero Digital Bank Ltd filed Critical One Zero Digital Bank Ltd
Publication of WO2023228195A1 publication Critical patent/WO2023228195A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/04—Architecture, e.g. interconnection topology
    • G06N3/044—Recurrent networks, e.g. Hopfield networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/04—Architecture, e.g. interconnection topology
    • G06N3/0464—Convolutional networks [CNN, ConvNet]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0201—Market modelling; Market analysis; Collecting market data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0201—Market modelling; Market analysis; Collecting market data
    • G06Q30/0202—Market predictions or forecasting for commercial activities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/06—Asset management; Financial planning or analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12—Accounting

Definitions

  • the present invention generally relates to the fields of financial transaction analysis and insight generation, and in particular to methods and systems for generating and providing actionable insights and recommendations relating to financial records and transactions.
  • a computer-implemented method for proactively providing financial insights and recommendations includes the steps of: collecting financial transaction data from a plurality of financial data sources, and processing the collected data, and applying at least one machine learning process to a training dataset of financial transaction data to generate at least one transaction analysis model during a training phase, and applying the transaction analysis model to a customer dataset of financial transaction data during a modelling phase to generate at least one prediction of a next transaction in a series.
  • the method further includes the steps of: generating at least one insight in accordance with at least one generated prediction, generating at least one recommendation in accordance with at least one generated insight, and selectively reporting a generated insight or recommendation.
  • the generated prediction may include: a next transaction amount of a next transaction in a series; a next transaction timing of a next transaction in a series; and/or a total number of transactions in a series over a selected time period.
  • the next transaction amount may include: an approximate value; an expected range of values of the next transaction in a series, and/or a mathematical transform thereof.
  • the next transaction timing may include: a date of the next transaction in a series; a timestamp of the next transaction in a series; a period between transactions in a series; and/or a frequency of transactions in a series.
  • the total number of transactions in a series over a selected time period may include: a total number of transactions during a calendar month ; and/or a total number of transactions until an end of a month.
  • the generated prediction may include a plurality of predictions divided into a plurality of prediction categories, each of the prediction categories established based on requirements of at least one generated insight or generated recommendation.
  • the transaction analysis model may be adapted to optimize at least one error function relating to at least one generated prediction or generated insight.
  • the transaction analysis model may include at least one target variable, representing at least one value required for at least one insight, or a mathematical transform thereof, where the error function relates to the target variable.
  • the insight may include at least one of: a deviation of a next transaction from an expected behavior; a deviation of a next transaction amount from an expected amount; an indication of transaction amount being as expected; an indication of transaction amount being greater than expected; an indication of transaction amount being lower than expected; a deviation of a next transaction timing from an expected timing; an indication of transaction timing being as expected; an indication of transaction timing being earlier than expected; an indication of transaction timing being later than expected; a deviation of a total number of transactions over a selected time period from an expected amount; and/or a missing transaction.
  • the insight may be determined according to an empirical distribution function, by selecting a confidence interval representing a normal range for at least one of an amount and a timing of a next transaction, determining at least one probability of observing at least one of an amount and a timing of a next transaction, based on an empirical distribution function of a set of predictions for at least one of the amount and the timing, comparing the probability to confidence interval boundaries of the selected confidence interval, and determining a respective transaction as anomalous if the probability is beyond the confidence interval boundaries.
  • Generating a missing transaction insight may include: examining predictions of transactions generated over an earlier time period to identify a group of recurring transactions having a prediction with respect to a next transaction in a series; removing transactions that occurred from the group; determining from remaining transactions in the group if a minimum selected period elapsed from a date derived from a next transaction timing prediction, in a selected percentile of all next transaction timing predictions; and establishing a transaction as missing if the actual duration, with the minimum selected time period subtracted, is greater than the selected percentile of duration predictions.
  • a missing transaction insight may be determined based on detecting a recurring transaction pattern with a time-base variable distribution comprising a distribution of statistically possible occurrences of a transaction over time.
  • the insight may include a determination of a late or early status of a transaction based on a tail distribution, by calculating leading or trailing edges of expected transactions and defining gaps between sequential transactions, where a transaction received in the gaps is considered as late, and a transaction received in the leading edge of a subsequent expected transaction is attributed to the subsequent expected transaction with a prior transaction considered as missed.
  • the method may further include the step of assigning a confidence score to a respective insight, based on confidence levels of at least one prediction associated with the insight and based on a type of the insight, where a respective recommendation is determined in accordance with the confidence score assigned to a respective insight.
  • the recommendation may be subject to approval or rejection in accordance with at least one factor, such as: at least one confidence score associated with at least one insight on which the recommendation is based; an insight type of at least one insight on which the recommendation is based; an insight category of at least one insight on which the recommendation is based; at least one previous recommendation; whether the recommendation should deactivate or replace at least one previous recommendation that has not expired or been deactivated; and/or a confidence score of the recommendation.
  • the recommendation may include a plurality of recommendations, each respective recommendation assigned to a recommendation category based on an associated recommendation confidence score, where each respective recommendation category is treated in a selected manner.
  • Recommendations in a first recommendation category reflective of a low confidence score may be discarded, recommendations in a second recommendation category reflective of a high confidence score may be sent to a customer, and recommendations in a third recommendation category reflective of an intermediate confidence score may be sent to an operator for further review on a recommendation approval interface.
  • the recommendation may be directed to optimize at least one factor such as: avoiding a negative balance in at least one account or portfolio; maintaining a minimum excess balance amount in at least one account or portfolio; investing excess balance above a threshold in at least one account or portfolio; minimizing a risk level in at least one investment account; maximizing a potential gain in at least one investment account; maintaining a budget; balancing at least one account; balancing a plurality of investment accounts in accordance with at least one objective; a predefined objective; a user defined objective; and a plurality of factors differentially weighted in accordance with a respective degree of importance.
  • the insight may include a determination that at least one account of a plurality of accounts of a customer portfolio, is expected to violate a constraint limitation associated with the respective account, based on a predicted future state of the respective account determined in accordance with at least one identified transaction pattern, where the recommendation includes at least one rebalancing recommendation directed to reallocate resource between a plurality of accounts to avoid the constraint limitation.
  • the insight may include an expectation of an impending failure of at least one account, of a plurality of accounts of a customer portfolio, to meet at least one customer objective relating to the respective account, and a determination of at least one prospective transaction relating to the plurality of accounts that is capable of averting the impending failure without violating at least one rule associated with the respective account, where the recommendation includes an indication of the impending failure to meet the customer objective, and a recommendation to implement the prospective transaction.
  • the insight may include an expectation of future expense transactions in at least one spending category, determined based on transaction patterns and customer behavior relating to the respective spending category, where the recommendation includes at least one spending restriction relating to the respective spending category, directed to meet at least one budgeting or expense minimizing condition.
  • the insight may include a determination that a projected trend in at least one spending category, of a plurality of accounts of a customer portfolio, is approaching an abnormal level, the projected trend determined based on a classification of transactions of a plurality of accounts by spending category and time period, where the recommendation includes at least one recommended action relating to future transactions in at least one of the accounts, directed to abate the projected trend.
  • the insight may include a determination that a prospective future transaction violates at least one rule associated with at least one account of a customer, determined based on a simulation of the prospective future transaction and a predicted future balance in the respective account, derived from transaction patterns and customer behavior patterns in a plurality of accounts of the customer, where the recommendation includes at least one of: an indication of whether the prospective future transaction violates the rule; an indication of whether a prospective purchase is affordable; and a recommendation to change at least one other future transaction or customer behavior such that a prospective purchase will be affordable.
  • the rule may include: ensuring that an aggregate balance across a plurality of accounts of a customer portfolio is maintained above a threshold; and/or ensuring that at least one selected balance in a respective one of the accounts is maintained above a threshold.
  • the collected financial transaction data may include a plurality of data structures, and the processing may include aggregating the data and mapping the data structures into a common format using at least one machine learning process.
  • the collected financial transaction data relating to a first account, of a plurality of accounts of a customer portfolio may include a different data structure or at least one limitation with respect to the collected financial transaction data relating to at least a second account of the customer portfolio, and the generated insight may include an insight relating to the first account, based on at least one generated prediction or generated insight relating to the second account.
  • a computer-implemented system for proactively providing financial insights and recommendations.
  • the system includes a data gathering module, operating on a server computing device communicatively coupled to a computer network, the data gathering module configured to collect financial transaction data from a plurality of financial data sources.
  • the system further includes a data analysis module, operating on a server computing device communicatively coupled to the computer network, the data analysis module configured to process the collected data, and to apply at least one machine learning process to a training dataset of financial transaction data to generate at least one transaction analysis model during a training phase, and to apply the transaction analysis model to a customer dataset of financial transaction data during a modelling phase to generate at least one prediction of a next transaction in a series.
  • the system further includes an insight generator, operating on a server computing device communicatively coupled to the computer network, the insight generator configured to generate at least one insight in accordance with at least one generated prediction.
  • the system further includes a recommendation generator, operating on a server computing device communicatively coupled to the computer network, the recommendation generator configured to generate at least one recommendation in accordance with at least one generated insight.
  • the system further includes a reporting module, executing on a client computing device coupled to the computer network, the reporting module configured to selectively report the generated insight or the generated recommendation.
  • the generated prediction may include: a next transaction amount of a next transaction in a series; a next transaction timing of a next transaction in a series; and/or a total number of transactions in a series over a selected time period.
  • the next transaction amount may include: an approximate value; an expected range of values of the next transaction in a series, and/or a mathematical transform thereof.
  • the next transaction timing may include: a date of the next transaction in a series; a timestamp of the next transaction in a series; a period between transactions in a series; and/or a frequency of transactions in a series.
  • the total number of transactions in a series over a selected time period may include: a total number of transactions during a calendar month; and/or a total number of transactions until an end of a month.
  • the generated prediction may include a plurality of predictions divided into a plurality of prediction categories, each of the prediction categories established based on requirements of at least one generated insight or generated recommendation.
  • the transaction analysis model may be adapted to optimize at least one error function relating to at least one generated prediction or generated insight.
  • the transaction analysis model may include at least one target variable, representing at least one value required for at least one insight, or a mathematical transform thereof, where the error function relates to the target variable.
  • the insight may include at least one of: a deviation of a next transaction from an expected behavior; a deviation of a next transaction amount from an expected amount; an indication of transaction amount being as expected; an indication of transaction amount being greater than expected; an indication of transaction amount being lower than expected; a deviation of a next transaction timing from an expected timing; an indication of transaction timing being as expected; an indication of transaction timing being earlier than expected; an indication of transaction timing being later than expected; a deviation of a total number of transactions over a selected time period from an expected amount; and/or a missing transaction.
  • the insight may be determined according to an empirical distribution function, by selecting a confidence interval representing a normal range for at least one of an amount and a timing of a next transaction, determining at least one probability of observing at least one of an amount and a timing of a next transaction, based on an empirical distribution function of a set of predictions for at least one of the amount and the timing, comparing the probability to confidence interval boundaries of the selected confidence interval, and determining a respective transaction as anomalous if the probability is beyond the confidence interval boundaries.
  • Generating a missing transaction insight may include: examining predictions of transactions generated over an earlier time period to identify a group of recurring transactions having a prediction with respect to a next transaction in a series; removing transactions that occurred from the group; determining from remaining transactions in the group if a minimum selected period elapsed from a date derived from a next transaction timing prediction, in a selected percentile of all next transaction timing predictions; and establishing a transaction as missing if the actual duration, with the minimum selected time period subtracted, is greater than the selected percentile of duration predictions.
  • a missing transaction insight may be determined based on detecting a recurring transaction pattern with a time-base variable distribution comprising a distribution of statistically possible occurrences of a transaction over time.
  • the insight may include a determination of a late or early status of a transaction based on a tail distribution, by calculating leading or trailing edges of expected transactions and defining gaps between sequential transactions, where a transaction received in the gaps is considered as late, and a transaction received in the leading edge of a subsequent expected transaction is attributed to the subsequent expected transaction with a prior transaction considered as missed.
  • the insight generator may be further configured to assign a confidence score to a respective insight, based on confidence levels of at least one prediction associated with the insight and based on a type of the insight, where a respective recommendation is determined in accordance with the confidence score assigned to a respective insight.
  • the recommendation may be subject to approval or rejection in accordance with at least one factor, such as: at least one confidence score associated with at least one insight on which the recommendation is based; an insight type of at least one insight on which the recommendation is based; an insight category of at least one insight on which the recommendation is based; at least one previous recommendation; whether the recommendation should deactivate or replace at least one previous recommendation that has not expired or been deactivated; and/or a confidence score of the recommendation.
  • the recommendation may include a plurality of recommendations, each respective recommendation assigned to a recommendation category based on an associated recommendation confidence score, where each respective recommendation category is treated in a selected manner.
  • Recommendations in a first recommendation category reflective of a low confidence score may be discarded, recommendations in a second recommendation category reflective of a high confidence score may be sent to a customer, and recommendations in a third recommendation category reflective of an intermediate confidence score may be sent to an operator for further review on a recommendation approval interface.
  • the recommendation may be directed to optimize at least one factor such as: avoiding a negative balance in at least one account or portfolio; maintaining a minimum excess balance amount in at least one account or portfolio; investing excess balance above a threshold in at least one account or portfolio; minimizing a risk level in at least one investment account; maximizing a potential gain in at least one investment account; maintaining a budget; balancing at least one account; balancing a plurality of investment accounts in accordance with at least one objective; a predefined objective; a user defined objective; and a plurality of factors differentially weighted in accordance with a respective degree of importance.
  • the insight may include a determination that at least one account of a plurality of accounts of a customer portfolio, is expected to violate a constraint limitation associated with the respective account, based on a predicted future state of the respective account determined in accordance with at least one identified transaction pattern, where the recommendation includes at least one rebalancing recommendation directed to reallocate resource between a plurality of accounts to avoid the constraint limitation.
  • the insight may include an expectation of an impending failure of at least one account, of a plurality of accounts of a customer portfolio, to meet at least one customer objective relating to the respective account, and a determination of at least one prospective transaction relating to the plurality of accounts that is capable of averting the impending failure without violating at least one rule associated with the respective account, where the recommendation includes an indication of the impending failure to meet the customer objective, and a recommendation to implement the prospective transaction.
  • the insight may include an expectation of future expense transactions in at least one spending category, determined based on transaction patterns and customer behavior relating to the respective spending category, where the recommendation includes at least one spending restriction relating to the respective spending category, directed to meet at least one budgeting or expense minimizing condition.
  • the insight may include a determination that a projected trend in at least one spending category, of a plurality of accounts of a customer portfolio, is approaching an abnormal level, the projected trend determined based on a classification of transactions of a plurality of accounts by spending category and time period, where the recommendation includes at least one recommended action relating to future transactions in at least one of the accounts, directed to abate the projected trend.
  • the insight may include a determination that a prospective future transaction violates at least one rule associated with at least one account of a customer, determined based on a simulation of the prospective future transaction and a predicted future balance in the respective account, derived from transaction patterns and customer behavior patterns in a plurality of accounts of the customer, where the recommendation includes at least one of: an indication of whether the prospective future transaction violates the rule; an indication of whether a prospective purchase is affordable; and a recommendation to change at least one other future transaction or customer behavior such that a prospective purchase will be affordable.
  • the rule may include: ensuring that an aggregate balance across a plurality of accounts of a customer portfolio is maintained above a threshold; and/or ensuring that at least one selected balance in a respective one of the accounts is maintained above a threshold.
  • the collected financial transaction data may include a plurality of data structures, and the processing may include aggregating the data and mapping the data structures into a common format using at least one machine learning process.
  • the collected financial transaction data relating to a first account, of a plurality of accounts of a customer portfolio may include a different data structure or at least one limitation with respect to the collected financial transaction data relating to at least a second account of the customer portfolio, and the generated insight may include an insight relating to the first account, based on at least one generated prediction or generated insight relating to the second account.
  • Figure 1 is a schematic illustration of a network environment supporting a computer-implemented system for generating at least one insight or recommendation relating to financial transactions, constructed and operative in accordance with embodiments of the present invention
  • Figure 2 is a flow diagram of a computer-implemented method for generating at least one insight or recommendations relating to financial transactions, operative in accordance with embodiments of the present invention
  • Figure 3 is a graph illustrating an example training of a transaction amount dataset by a median, operative in accordance with an embodiment of the present invention
  • Figure 4A is an exemplary sequence illustrating a missing transaction insight modified to a late arrival transaction insight with amount as expected, operative in accordance with an embodiment of the present invention
  • Figure 4B is an exemplary sequence illustrating a transaction on time with amount higher than expected insight, operative in accordance with an embodiment of the present invention
  • Figure 4C is an exemplary sequence illustrating a transaction is early with amount higher than expected insight, operative in accordance with an embodiment of the present invention
  • Figure 5A is an example first screen of a recommendation approval interface, operative in accordance with an embodiment of the present invention
  • Figure 5B is an example second screen of a recommendation approval interface, operative in accordance with an embodiment of the present invention.
  • Figure 5C is an example screen of a recommendation approval interface provided on a mobile phone, operative in accordance with an embodiment of the present invention
  • Figure 6A illustrates a first example of a rebalancing portfolio recommendation, operative in accordance with an embodiment of the present invention
  • Figure 6B illustrates a second example of a rebalancing portfolio recommendation, operative in accordance with an embodiment of the present invention
  • Figure 6C illustrates a third example of a rebalancing portfolio recommendation, operative in accordance with an embodiment of the present invention
  • Figure 6D illustrates a fourth example of a rebalancing portfolio recommendation, operative in accordance with an embodiment of the present invention.
  • Figure 7 is a flow chart illustration of a data and machine learning pipeline process, operative in accordance with an embodiment of the present invention.
  • the present invention overcomes the disadvantages of the prior art by providing a novel system and method for analysis of financial data to generate predictions of future events and provide customized insights and recommendations.
  • the insights can be utilized by users (e.g., customers) or assigned personnel (e.g., bankers) to apply targeted financial behavior and decisions in a proactive manner, before a significant financial event occurs rather than reacting afterwards.
  • the insights and recommendations may be generated using machine learning processes.
  • Various types of insights may be created, each of which may be linked to a confidence score, and automatically checked against configured rules and routed according to the confidence score, such as directly to the customer, for review by assigned personnel, or discarded.
  • the disclosed system and method may provide insights and recommended actions based on behaviors and transactions of a customer having multiple accounts or portfolios, such as multiple retail and investment portfolios at multiple banks or financial institutions.
  • Financial transaction data obtained from various sources may be analyzed to generate targeted recommendations to assist users with monitoring and managing their accounts and portfolios.
  • the insights and recommendations may be focused on particular attributes and behaviors of a user, and may be optimized in accordance with predefined criteria, for example to maintain a minimum level of cash available for use, to invest extra cashflow, to avoid a negative balance, to minimize investment risk, or to maximize potential investment gains.
  • method refers to manners, means, techniques and procedures for accomplishing a given task including, but not limited to, those manners, means, techniques and procedures either known to, or readily developed from known manners, means, techniques and procedures.
  • the term “user” herein refers to any individual, group or entity for whom embodiments of the disclosed systems or methods may be operated upon, such as a customer having one or more accounts and/or portfolios for which financial information is analyzed and insights or recommendations provided.
  • the terms “customer”, “client” and “user” are used interchangeably herein.
  • account generally refers to a financial balance, characterized by a series of changes or financial transactions (e.g., debits or credits), generally referred to herein as “transactions”, which may be maintained and recorded by a bank or financial institution, and which may fall under one or more categories (e.g., a checking account; a savings account; a deposit account; a foreign currency account; a loan or mortgage; a debit card; a credit card; a pension; an investment; a security or other financial instrument; a position in a stock or market; and the like).
  • portfolio generally refers to a collection of accounts belonging to a joint set of customers (such as an individual customer, or a group of customers with shared finances, e.g., a married couple). In certain contexts of the disclosed embodiments, the terms “account” and “portfolio” may be used interchangeably.
  • “at least one processor” may constitute any physical device or group of devices having electric circuitry that performs a logic operation on an input or inputs.
  • the at least one processor may include one or more integrated circuits (IC), including application-specific integrated circuit (ASIC), microchips, microcontrollers, microprocessors, all or part of a central processing unit (CPU), graphics processing unit (GPU), digital signal processor (DSP), field-programmable gate array (FPGA), server, virtual server, or other circuits suitable for executing instructions or performing logic operations.
  • the instructions executed by at least one processor may, for example, be pre-loaded into a memory integrated with or embedded into the controller or may be stored in a separate memory.
  • the memory may include: a Random Access Memory (RAM); a Read-Only Memory (ROM); a hard disk; an optical disk; a magnetic medium; a flash memory; other permanent, fixed, or volatile memory; or any other mechanism capable of storing instructions.
  • the at least one processor may include more than one processor.
  • Each processor may have a similar construction or the processors may be of differing constructions that are electrically connected or disconnected from each other.
  • the processors may be separate circuits or integrated in a single circuit.
  • the processors may be configured to operate independently or collaboratively, and may be co-located or located remotely from each other.
  • the processors may be coupled electrically, magnetically, optically, acoustically, mechanically or by other means that permit them to interact.
  • machine learning algorithms may be trained using training examples.
  • Some non-limiting examples of such machine learning algorithms may include classification algorithms, data regressions algorithms, image segmentation algorithms, visual detection algorithms (such as object detectors, face detectors, person detectors, motion detectors, edge detectors, etc.), visual recognition algorithms (such as face recognition, person recognition, object recognition, etc.), speech recognition algorithms, mathematical embedding algorithms, natural language processing algorithms, support vector machines, random forests, nearest neighbors algorithms, deep learning algorithms, artificial neural network algorithms, convolutional neural network algorithms, recursive neural network algorithms, linear machine learning models, non-linear machine learning models, ensemble algorithms, and so forth.
  • a trained machine learning algorithm may include an inference model, such as a predictive model, a classification model, a regression model, a clustering model, a segmentation model, an artificial neural network (such as a deep neural network, a convolutional neural network, a recursive neural network, etc.), a random forest, a support vector machine, and so forth.
  • the training examples may include example inputs together with the desired outputs corresponding to the example inputs.
  • training machine learning algorithms using the training examples may generate a trained machine learning algorithm, and the trained machine learning algorithm may be used to estimate outputs for inputs not included in the training examples.
  • engineers, scientists, processes and machines that train machine learning algorithms may further use validation examples and/or test examples.
  • validation examples and/or test examples may include example inputs together with the desired outputs corresponding to the example inputs, a trained machine learning algorithm and/or an intermediately trained machine learning algorithm may be used to estimate outputs for the example inputs of the validation examples and/or test examples, the estimated outputs may be compared to the corresponding desired outputs, and the trained machine learning algorithm and/or the intermediately trained machine learning algorithm may be evaluated based on a result of the comparison.
  • a machine learning algorithm may have parameters and hyper parameters, where the hyper parameters are set manually by a person or automatically by a process external to the machine learning algorithm (such as a hyper parameter search algorithm), and the parameters of the machine learning algorithm are set by the machine learning algorithm according to the training examples.
  • the hyper-parameters are set according to the training examples and the validation examples, and the parameters are set according to the training examples and the selected hyper-parameters.
  • a trained machine learning algorithm may be used as an inference model that when provided with an input generates an inferred output.
  • a trained machine learning algorithm may include a classification algorithm, the input may include a sample, and the inferred output may include a classification of the sample (such as an inferred label, an inferred tag, and so forth).
  • a trained machine learning algorithm may include a regression model, the input may include a sample, and the inferred output may include an inferred value for the sample.
  • a trained machine learning algorithm may include a clustering model, the input may include a sample, and the inferred output may include an assignment of the sample to at least one cluster.
  • a trained machine learning algorithm may include a classification algorithm, the input may include an image, and the inferred output may include a classification of an item depicted in the image.
  • a trained machine learning algorithm may include a regression model, the input may include an image, and the inferred output may include an inferred value for an item depicted in the image (such as an estimated property of the item, such as size, volume, age of a person depicted in the image, cost of a product depicted in the image, and so forth).
  • a trained machine learning algorithm may include an image segmentation model, the input may include an image, and the inferred output may include a segmentation of the image.
  • a trained machine learning algorithm may include an object detector, the input may include an image, and the inferred output may include one or more detected objects in the image and/or one or more locations of objects within the image.
  • the trained machine learning algorithm may include one or more formulas and/or one or more functions and/or one or more rules and/or one or more procedures, the input may be used as input to the formulas and/or functions and/or rules and/or procedures, and the inferred output may be based on the outputs of the formulas and/or functions and/or rules and/or procedures (for example, selecting one of the outputs of the formulas and/or functions and/or rules and/or procedures, using a statistical measure of the outputs of the formulas and/or functions and/or rules and/or procedures, and so forth).
  • artificial neural networks may be configured to analyze inputs and generate corresponding outputs.
  • Some non-limiting examples of such artificial neural networks may include shallow artificial neural networks, deep artificial neural networks, feedback artificial neural networks, feed forward artificial neural networks, autoencoder artificial neural networks, probabilistic artificial neural networks, time delay artificial neural networks, convolutional artificial neural networks, recurrent artificial neural networks, long/short term memory artificial neural networks, and so forth.
  • an artificial neural network may be configured manually. For example, a structure of the artificial neural network may be selected manually, a type of an artificial neuron of the artificial neural network may be selected manually, a parameter of the artificial neural network (such as a parameter of an artificial neuron of the artificial neural network) may be selected manually, and so forth.
  • an artificial neural network may be configured using a machine learning algorithm. For example, a user may select hyper-parameters for the artificial neural network and/or the machine learning algorithm, and the machine learning algorithm may use the hyper-parameters and training examples to determine the parameters of the artificial neural network, for example using back propagation, using gradient descent, using stochastic gradient descent, using minibatch gradient descent, and so forth.
  • an artificial neural network may be created from two or more other artificial neural networks by combining the two or more other artificial neural networks into a single artificial neural network.
  • a non-transitory computer-readable storage medium refers to any type of physical memory on which information or data readable by at least one processor can be stored.
  • the terms “memory” and “computer-readable storage medium” may refer to multiple structures, such as a plurality of memories or computer-readable storage mediums located within an input unit or at a remote location. Additionally, one or more computer-readable storage mediums can be utilized in implementing a computer- implemented method. Accordingly, the term computer-readable storage medium should be understood to include tangible items and exclude carrier waves and transient signals.
  • FIG. 1 is a schematic illustration of a network environment, generally referenced 100, supporting a computer-implemented system, generally referenced 150, for generating at least one insight or recommendation relating to financial transactions, constructed and operative in accordance with embodiments of the present invention.
  • Environment 100 includes a server device 110, at least one user computing device 120, and one or more financial data sources 130.
  • System 150 includes a database 108, a data gathering module 152, a data analysis module 154, an insight generator 156, a recommendation generator 157, and a reporting module 158.
  • Server device 110 includes at least a processor 112.
  • User device 120 includes at least a processor 122 and a user interface 124.
  • System modules 152, 154, 156, 157 operate on server processor 112 and system module 158 operates on user interface 124, although it is appreciated that the functionality of any of the system modules may operate on either one or both of server 1 10 or user device 120.
  • User device 120 may be embodied by any type of electronic device with computing and network communication capabilities, including but not limited to: a mobile computer; a desktop computer; a smartphone; a laptop computer; a netbook computer; a tablet computer; or any combination of the above.
  • Network environment 100 may generally include a plurality of user devices operated by multiple respective customers, although a single user device 120 is depicted for exemplary purposes.
  • Server 110 is communicatively coupled with database 108, with user computing device 120, and with financial data sources 130. Accordingly, information may be conveyed between the components of system 150, such as between database 108, server 1 10, and user device 120, as well as to/from other networks communicatively coupled thereto, over any suitable data communication channel or network, using any type of channel or network model and any data transmission protocol (e.g., wired, wireless, radio, WiFi, Bluetooth, and the like). For example, system 150 may store, manage and process data using a cloud computing model, and the components of system 150 may communicate with one another and be remotely monitored and controlled over the Internet.
  • any data communication channel or network using any type of channel or network model and any data transmission protocol (e.g., wired, wireless, radio, WiFi, Bluetooth, and the like).
  • system 150 may store, manage and process data using a cloud computing model, and the components of system 150 may communicate with one another and be remotely monitored and controlled over the Internet.
  • Processor 1 12 generally performs data processing required by server 110.
  • data analysis module 154 processes and analyzes information obtained from financial sources 130 by data gathering module 152, and insight generator 156 and recommendation generator 157 provide insights 162 or recommendations 163 based on the processed information, as will be discussed further hereinbelow.
  • Processor 112 may also receive instructions or data from other components of system 150 or network environment 100, such as from user device 120.
  • processor 122 performs data processing required by user device 120, and may receive instructions or data from other components of system 150 or network environment 100, such as from server 1 10.
  • User interface 124 allows a user to control parameters or settings of user device 120.
  • user interface 124 allows a user to provide instructions or information to a system module of system 150, such as to browse through or select a recommended operation or action in relation to a user account or portfolio (e.g., associated with relative confident levels, as will be discussed further hereinbelow.
  • User interface 124 may include a cursor or touch-screen menu interface, such as a graphical user interface, configured to enable the operator to manually enter instructions or data.
  • User interface 124 may also be used to communicate with external sources.
  • Database 108 stores relevant information to be retrieved and processed by server 1 10 and by user device 120.
  • database 108 may store financial information relating to user accounts and/or portfolios, such as historical data (e.g., previous transactions) and future states (e.g., timing and amounts of predicted future transactions), data effecting risk level and financial goals, derived data such as financial forecasts and financial behaviors, and associated insights and recommendations, as will be discussed further hereinbelow.
  • the components and devices of system 150 may be based in hardware, software, or combinations thereof. It is appreciated that the functionality associated with each of the devices or components of network environment 100 or system 150 may be distributed among multiple devices or components, which may reside at a single location or at multiple locations. For example, the functionality associated with processor 1 12 or processor 122 may be integrated or distributed between multiple processing units, and the functionality of database 108 may be integrated or distributed between multiple databases (and database types), such as using a cloud computing platform. Similarly, at least part of the functionality associated with the modules of system 150 may reside externally to server 110 or user computer 120. System 150 may optionally include and/or be associated with additional components or modules not shown in the Figures, for enabling implementation of the disclosed subject matter.
  • System 150 is configured to generate at least one insight or recommendation relating to financial data in one or more accounts or portfolios of at least one user.
  • the term “insight” herein generally refers to financial information of an account or portfolio, as determined according to a disclosed embodiment, such as information relating to predicted future transactions (e.g., date, time, period, frequency, duration or amount of a future transaction), or possible actions in relation to future transactions.
  • the term “recommendation” herein generally refers to a possible action or operation that may be implemented in relation to an account or portfolio, as determined according to a disclosed embodiment, such as pertaining to an insight considered in view of further information, such as confidence levels and/or recommendation history of a particular customer, and meeting approval criteria for sending to a customer.
  • network environment 100 may include a plurality of users monitored by system 150 (i.e., concurrently or at different times), although a single user is depicted for exemplary purposes.
  • system 150 provides hybrid recommendations based on machine learning analysis, where a first group of recommendations classified with a higher confidence level may be sent directly to a user (account holders), while a second group of recommendations classified with a lower confidence level may be routed through an interface displaying predictive metrics to enable a determination (e.g., by one or more operators, such as a certified financial analysist) of whether a recommendation in the second group should be sent to the user.
  • system 150 provides at least one rebalancing recommendation of at least one portfolio based on predicted future states.
  • a customer may have multiple portfolios (e.g., retail or investment) in multiple financial institutions, and system 150 may provide a recommendation based on behaviors of all (or selected ones of) customer portfolios so as to optimize at least one predefined condition or criteria.
  • Such criteria may include: to maintain a minimal level of cashflow available for expenditure; to invest all spare cashflow (e.g., beyond minimum amount required to meet recurring base expenses); to avoid a negative balance; and the like, where each condition may be assigned a selected importance weighting (e.g., based on user feedback).
  • system 150 provides at least one recommendation for behavioral changes (e.g., spending recommendations) in multiple expenditure categories (i.e., types of spending) for maintaining a budget, based on past behaviors and possible changes in each category. For example, an analysis of multiple expenditure categories that are recurring for a particular customer (e.g., in which the customer spends beyond a threshold amount and/or a threshold frequency of expenditures over a minimum period), may provide an indication of selected categories for spending to be reduced. System 150 may identify past customer behavior in each selected expenditure category, deduct possible changes in each category, and suggest future spending limits in each category with recommended amounts. The category-based behavioral/spending recommendation may be based on aggregated data from multiple user accounts.
  • behavioral changes e.g., spending recommendations
  • multiple expenditure categories i.e., types of spending
  • an analysis of multiple expenditure categories that are recurring for a particular customer e.g., in which the customer spends beyond a threshold amount and/or a threshold frequency of expenditures over a minimum period
  • System 150 may identify past customer behavior
  • system 150 provides a data and machine learning pipeline, with an abstraction layer-based nomenclature mapping and borrowing data from unrelated accounts. System 150 may use multiple data sources and map them into a unified data structure, to enable a common processing and machine learning analysis, and/or to transfer conclusions from training on one source to another.
  • FIG. 1 is a flow diagram of a computer-implemented method for generating at least one insight or recommendation relating to financial transactions, operative in accordance with embodiments of the present invention.
  • data gathering module 152 extracts financial data 161 , including previous transactions and other information pertaining to at least one account belonging to a respective user, from financial data sources 130, such as bank account and credit card statements.
  • a subsequent procedure 173 includes data preparation and preprocessing, as will be elaborated upon further below.
  • Data preparation and preprocessing is specific to the type of data source (e.g., data from different sources may require different preparations), and the type of usage (i.e., for each insight, the data needs to be prepared to match the insight or the process used to generate the insight).
  • Transactional data may be volatile, and it may be challenging to model an entire transaction type or transaction category in a single model.
  • the volatile nature of transaction data may increase uncertainty of the model and may result in a poor (inaccurate) prediction.
  • Pre-selecting transactions may help direct the modeling to useful transaction types, such as transactions having business value and greater stability. Selecting transaction categories for a model may attempt to balance volatility and business requirements. Examples of technical transaction rules are provided and discussed in detail hereinbelow.
  • volatility is not trivial and there may not be a single definition that will satisfy all scenarios.
  • One definition for volatility is Standard Deviation (STD) of the transaction amount by category.
  • STD Standard Deviation
  • this definition does not take into consideration variations of the average transaction amount by category. For example, the STD for two transaction categories may be $100, where category (C a ) has an average of $200 per transaction and category (Ct>) has an average of $20,000 per transaction. From a business standpoint, C a and Cb behave completely different, although the STD is the same.
  • One modification is to apply a ratio between the STD and the average (AVR), by defining a Relative STD (RSD) as follows [equation 1 ]: where STD(x,y) is a standard deviation of a statistical population “x” (“x” representing a transaction amount or transaction timing), in a transaction category “y”, and where AVR(x,y) is an arithmetic average of a statistical population x in transaction category y.
  • RSD Relative STD
  • a Ratio Function (rf) represents a ratio of the change between two consecutive transactions of the same sequence “s” for a customer [equation 2]:
  • the ratio function is not symmetric where positive changes are weighted in the scale as more than negative changes. This may be overcome by calculating an aggregation on the ratio on and defining a set of thresholds indicating a “degree of variation” of a current transaction relative to a previous transaction.
  • the set of thresholds may be defined as follows [equation 3A]: and equivalently a set of thresholds for negative (decrease) changes is as follows [equation 3B]:
  • Volatility may then be calculated according to the following steps. For each sequence of transactions, the number of times the transaction amount change is beyond the threshold ranges (i.e., above the set of , or below the set of , and the number of times the transaction amount is within the threshold ranges, is measured.
  • Table 1 presents a sample of an exemplary volatility analysis result:
  • Table 1 represents threshold sums and ratios for the following sets of thresholds above.
  • Transaction category (y) are sums of transactions that are within range for thresholds 1 to 4; are sums of transactions that are out of range for thresholds 1 to 4; and are the related volatility ratios.
  • the shading represents the stability of the category, where dark shading represents low volatility category (high predictability).
  • a set of categories that meets certain criteria may be selected. Examples of such criteria may include: most interesting from a business standpoint; has enough transactions to produce stable results; volatility not high; and transaction amount large enough to be significant.
  • Volatility generally depends on various features. Examples of features that may be used to select a set of transactions for analysis may include: transaction date range (i.e., to balance between maximizing the number of transaction in the dataset while limiting the dataset to a relevant time period); transaction count (i.e., having a certain number, such as at least 3, transactions in a series); minimum history (i.e., having a transaction history of a minimal period, such as at least 1 month, in a series); average transaction (i.e., the average transaction must be larger than a minimum amount over a previous number of transactions, e.g., at least ILS 20 over the past 3 transactions); transaction sign (i.e., income and expenses are analyzed separately); transaction timing limitation (i.e., the duration between the last transaction in a series (t) and the previous transaction (t-1 ) should be limited to a certain period, e.g., 1 week, 1 month, or 2 months); and target variable (i.e., the dataset must contain a target that is the next transaction
  • Aggregated filtering is a process that calculates aggregated data on transactions or a transaction history to filter out noisy transactions.
  • a series of transactions may have one or more transactions with an amount exceeding an expected standard range.
  • the following provides exemplary protocols for defining a “standard” range and for how to filter out “nonstandard” transactions.
  • a standard transaction in a series of transactions may be defined if the transaction amount is in a range as follows [equation 5]: where “M” is a median of a historical data series; “T” is a transaction amount; and “a” is a value indicating a width of the range (i.e., a lower value of a corresponds to a narrower width defining the standard transaction range, and vice-versa).
  • FIG. 3 is a graph illustrating an example of training a transaction amount dataset by a median, operative in accordance with an embodiment of the present invention.
  • the graph of Figure 3 depicts a plot of log 10 ( T / M ), as a percentage of the data. Specifically, the graph of Figure 3 displays the values of the ratios log 10 ( T / M ), from the lowest value on the left to the highest value on the right, as a percentage of the total training dataset. It can be seen that for almost the entire range, transactions are close (if not equal) to the median, i.e., Iog 10 ( T / M ) ⁇ 0.
  • the median is a good indicator of future values, as the median is approximately the same size as most samples (except for outliers). Accordingly, the median can be a useful metric for machine learning models in determining insights, as well as a benchmark for comparing model performances.
  • Some of the transaction features include the history of transaction amounts for a previous number of transactions (e.g., previous 10 transactions).
  • a standard transaction in a training set and/or a testing set, may be defined as a transaction for which the target amount value is standard and there are less than a number (e.g., 2) of historic transaction amounts that are nonstandard.
  • a machine learningbased transaction analysis model is generated from a training dataset.
  • the model is generated by applying at least one machine learning process to a collection of training samples of reference data during a preliminary “model training phase”.
  • a training dataset of transactional data associated with a plurality of reference users may be processed using a machine learning process to implicitly identify different patterns and categories and create models for facilitating predictions of different transactions according to selected criteria.
  • the machine learning process may apply machine learning techniques to analyze the training data, in order to produce mapping functions that can be used for classifying additional instances of new datasets according to relevant classification criteria.
  • the data analysis may utilize any suitable machine learning or supervised learning process or algorithm, including but not limited to: an artificial neural network (ANN) process, such as a convolutional neural network, recurrent neural network (RNN), or a deep learning algorithm; a classification or regression analysis, such as a linear regression model; a logistic regression model, or a support-vector machine (SVM) model; a decision tree learning approach, such as a random forest classifier; and/or any combination thereof.
  • ANN artificial neural network
  • RNN recurrent neural network
  • SVM support-vector machine
  • the data analysis may utilize any suitable tool or platform, such as publicly available opensource machine learning or supervised learning tools.
  • Statistical parameters may not necessarily provide an adequate reflection of the quality or accuracy of a model, as such metrics tend to focus on how the model improved in the training phase.
  • a particular model may be optimized to significantly reduce the Root Mean Square Error (RMSE), or to optimize an alternative error function that is related to the determined insights (procedure 180).
  • RMSE Root Mean Square Error
  • a model should perform at least as well or better than a panel of human experts in predicting the amount and the timing of a next transaction in a series.
  • a human (non-machine generated) prediction typically involves examining a latest transaction and extrapolating an average and/or a trend. Accordingly, one model approach is to utilize a decaying average over the recent transaction history.
  • the machine-learning based transaction analysis model may include two separate models: one for predicting a next transaction amount, and another for predicting a next transaction timing.
  • Each model has one or more outputs or target variables, which should reflect certain aspects relating to the predictions.
  • the target variable may represent a value required for a particular insight, such as an amount, or a mathematical transform thereof, and the error function should take into account the target variable and/or transform. For example, when predicting a next transaction amount, an error of $100 may be considered minor for a transaction of $100,000, but the same error would be considerable for a transaction of $150.
  • One approach for addressing this issue is to apply a logarithmic scale, in which an error (E) has the same proportion in the amount scale regardless of the value of the amount.
  • a Iog10(x) can be applied to all amount features and targets, and Mean Squared Error (MSE) can be applied as a loss function for evaluating the model.
  • MSE Mean Squared Error
  • error functions such as mean absolute error (MAE), mean squared error (MSE), or root-mean-squared error (RMSE)
  • MSE mean absolute error
  • MSE mean squared error
  • RMSE root-mean-squared error
  • the error should be measured over a suitable timespan, such as a period of days, which may represent the target variable.
  • Considerations for developing the timing prediction model may include the following: noisy data (i.e., although some categories may have low volatility, transaction data is generally volatile); insufficient data (e.g., newer financial institutions may have scarce available historical data available); conditions for issuing alerts or notifications relating to the predictions (i.e., identifying suspicious events, such that an alert is issued when the predicted transaction amount or duration is beyond an expected range); and asymmetrical distribution of target values about the mean or median.
  • noisy data i.e., although some categories may have low volatility, transaction data is generally volatile
  • insufficient data e.g., newer financial institutions may have scarce available historical data available
  • conditions for issuing alerts or notifications relating to the predictions i.e., identifying suspicious events, such that an alert is issued when the predicted transaction amount or duration is beyond an expected range
  • asymmetrical distribution of target values about the mean or median e.g., asymmetrical distribution of target values about the mean or median.
  • An alternative approach is to define and predict an “irregular” event, by defining a threshold range beyond which a transaction amount or duration is too large or too small.
  • a threshold may be defined statistically as rejecting a null hypothesis (H o ) or asserting no statistical difference between an actual transaction amount and a predicted amount.
  • Setting such thresholds (or a confidence interval for rejecting the null hypothesis) may be defined as identifying percentiles for which a selected percentage (p%) of a target value with be above or below the threshold.
  • Yet another approach may utilize a bagging long short-term memory (LSTM) neural network.
  • LSTM long short-term memory
  • an acceptable range of model predictions in the ensemble is defined as follows [equation 6]: where “y pred " represents a model prediction, and “a” represents a constant value (set as default to 2.5). Models in the ensemble that are outside the accepted range are retrained and the process is repeated until all models for predicting a next log(amount) and predicting a next duration, are within the acceptable prediction range.
  • An ensemble of a large number of models may enable determination of aggregated parameters, such as: model predictions calculated as an average of the model prediction, and percentiles by calculating a percentile threshold on the ensemble model population.
  • Another option that can be used is to retrain several times, discard models that do not converge, then either use the best converging model, or an ensemble of converging models as described.
  • next procedure 176 predictions of next transactions in a transaction series are generated.
  • data analysis module 154 applies one or more transaction analysis models (generated during the model training step 174) to collected user financial data 161 (having undergone data preparation and preprocessing if applicable), to obtain a set of predictions relating to future transactions.
  • the transaction model applies machine learning processes to a dataset of financial transaction information for a respective user, to obtain predictions regarding future transactions.
  • a first group of predictions may include: a next transaction amount 177 and a next transaction timing 178 of a next transaction in a sequence or series.
  • a “next transaction amount” refers to a magnitude of a next transaction, such as an approximate value and/or an expected range of values.
  • a “next transaction timing” refers to an indication of when the next transaction will occur, which may include a date and/or timestamp, as well as a period or frequency of a series of next transactions.
  • a series of transactions may have a period of “1M” (i.e. , one month between transactions); “2M” (i.e., two months between transactions); or “0.5M” (i.e., half a month between transactions), or a frequency of “1/M” (i.e., occurring once per month); “2/M” (i.e., occurring twice per month); or “0.5/M” (i.e., occurring half a month on average).
  • a second group of predictions may include the total number of transactions over a selected period (referenced 179).
  • a set of predictions may be divided into categories, such as by determining a separate group of predictions for income and for expenses, or according to the source or target of selected funds, where the categories may be established based on particular requirements of an insight and/or recommendation.
  • a next procedure 180 relates to generating insights.
  • insight generator 156 is configured to generate one or more insights 162 relating to financial transactions of a customer, in accordance with predicted information relating to the next transactions in a series.
  • the insights may be generated according to collected financial data 161 and generated predictions, such as a next transaction amount 177, a next transaction timing 178, and/or total transactions over a selected period 179 of future transactions in a series.
  • the generated insights may be provided to a customer to assist with tracking and managing his/her accounts and portfolios.
  • the customer may receive an alert relating to an insight, such as when a recurring transaction deviates (or is predicted to deviate) from an expected behavior. More specifically, an insight may initiate an alert when the amount and/or timing of a recurring transaction is deemed anomalous.
  • a first exemplary group of generated insights relates to how an expectation (or prediction) for a next transaction compares to the reality.
  • the amount of a transaction may be below an expected level, above an expected level, or at/within an expected level.
  • the timing of a transaction may be earlier than expected, later than expected, or within the expected timing (e.g., date, period or frequency).
  • a respective next transaction may be categorized as follows: i. transaction amount as expected and arrived on time; ii. transaction amount as expected and arrived early; iii. transaction amount as expected and arrived late; iv. transaction amount greater than expected and arrived on time; v. transaction amount greater than expected and arrived early; vi. transaction amount greater than expected and arrived late; vii. transaction amount lower than expected and arrived on time; viii. transaction amount lower than expected and arrived early; ix. transaction amount lower than expected and arrived late; and x. transaction is missing.
  • a series of “n” predictions is generated for both the expected log(amount) of the next transaction and the expected duration (e.g., number of days) until the next transaction for each transaction received.
  • the transaction amount can be compared to the n log(amount) predictions to determine whether the amount is within expectation. The same can be done for the transaction timing by considering the number of days between the date of the new transaction and the date of the previous transaction in the series (i.e., when the prediction was generated).
  • the transaction analysis models may generate multiple predictions for expected timing (e.g., number of days until a next transaction in the series), and for expected log(amount) of a next transaction.
  • expected timing e.g., number of days until a next transaction in the series
  • expected log(amount) e.g., number of days until a next transaction in the series
  • a distribution of possible values may be obtained for each of the target variables. Since the distribution of predictions may potentially change over time, it should not be assumed that the predictions are distributed in a known probability distribution, such as a normal distribution. To ensure that the distribution function used is valid regardless of the underlying data, the distribution may be estimated non-parametrically using an empirical cumulative distribution function (eCDF) that may be calculated as follows [equation 7]: for each prediction “i” produced by every model in the ensemble.
  • eCDF empirical cumulative distribution function
  • the probability of observing the amount of a newly arrived transaction in a recurring series can be calculated as follows [equation 8]: where “x” represents the log(amount) of the new transaction.
  • the probability of observing the number of days between the date of a newly arrived transaction in a recurring series, and the date of its previous occurrence may be calculated as follows [equation 9]: where “t” represents the actual number of next days observed when a new transaction arrives that is calculated by taking the number of days between the new transaction and its previous occurrence.
  • the probability of observing a transaction with an arrived amount or date may be determined by calculating a probability density function as follows [equation 10]:
  • the above probability density function may ensure that certain key properties of a probability are maintained given 1.
  • the upper bound is set as “1” and the lower bound is set as “0”.
  • This probability measure was designed to account for an aspect of the disclosed embodiments in which insights below a certain confidence threshold value are directed to an internal validation process prior to (optionally) being sent to a client (as will be discussed further hereinbelow with reference to procedure 183). This aspect may help to substantially reduce the number of “false positive” alerts that are sent to a client.
  • both the amount and the timing of a newly arrived transaction in a recurring series can assume three states.
  • Amounts can be either: (i) as expected; (ii) above the expectation; or (iii) below the expectation.
  • Dates can be either: (i) as expected; (ii) later than the expectation; or (iii) earlier than the expectation.
  • an empirical distribution function can be utilized. First, a confidence interval is selected in which the values are considered to be within a normal range.
  • a probability of observing a log(amount) and a date (timing) of a new transaction is determined, based on an empirical cumulative distribution function (eCDF) of the set of predictions for log(amount) and timing.
  • eCDF empirical cumulative distribution function
  • the probabilities of observing the new transaction amount and timing is compared to the boundaries of the confidence interval selected earlier. If the probabilities are outside of the confidence interval boundaries, then the transaction is considered an anomalous transaction and an alert may be generated accordingly.
  • Insights relating to a transaction amount prediction may be categorized as follows:
  • Insights relating to a transaction timing prediction may be categorized as follows:
  • a confidence interval of 95% is selected for a variable “x”, such as a next transaction log(amount)
  • a confidence interval of 95% is selected for a variable “x”, such as a next transaction log(amount)
  • all values of “x” that fall between 0.025 ⁇ F(x) ⁇ 0.975 are considered to be normal. All values of “x” resulting in F(x) > 0.975 are considered to be above the expected amount, and all values of “x” resulting in F(x) ⁇ 0.025 are considered to be below the expected amount.
  • reaction amount insight and “transaction timing insight” may be aggregated into a single combined insight for each relevant transaction.
  • Another type of insight relates to a “missing transaction”, which alerts a user of a transaction that was supposed to occur but did not.
  • the aforementioned nine transaction insight categories relate to transactions that had a prediction (of amount and timing) based on previous transactions in a series, as well as the most recent transaction in a series that is compared to what was predicted. For example, each day (or over some selected time period), all of the transactions of a client (i.e., received from one or more financial institutions) are compared to predictions that were based on earlier transactions, where the collection of transactions form a series. However, there may be cases in which an expectation with respect to a future transaction in a series does not arrive within an expected range of time. In such cases, an insight may be generated that an expected (predicted) transaction is missing, and the client may be alerted accordingly.
  • a missing transaction type of insight type may be generated as follows. Each day (or other selected period), insight generator 156 examines the predictions of transactions that were generated over some earlier period (e.g., during the past 3 months), to identify (e.g., quarterly) recurring transactions that have a prediction with respect to a next transaction. Of these predictions, insight generator 156 checks which of the transactions actually occurred and removes them from the group. The remaining predictions in the group are those that implied a matching transaction would arrive but never did. Insight generator 156 examines if a minimum selected time period (e.g., at least 3 days) has elapsed from the date that is derived from the duration prediction, in a selected percentile (e.g., 95 th percentile) of all duration predictions.
  • a minimum selected time period e.g., at least 3 days
  • the transaction is considered as “missing” and an associated alert may be sent to the client. If a transaction arrives at a later stage, after already designated as missing, then it is modified to a “late” status.
  • the selected percentile of duration predictions e.g., actual duration - 3 days > 95 th percentile of duration predictions
  • non-missing transaction insights i.e., first 9 transaction insight categories described hereinabove
  • process that generates non-missing transaction insights is generally implemented prior to the process that identifies missing transaction, such as each day, so as to ensure that all the arrived transactions are properly accounted for and there are no false positive missing transactions alerts.
  • Another special case may occur if the definition of an early transaction or a late transaction is ambiguous. For example, a transaction arrived on March 3 rd and a prediction was generated that the next transaction in the series will occur on April 3 rd . However, the next transaction only appears on April 27 th . It may be unclear whether this represents a late appearance of the expected April transaction, or an early appearance of the expected May transaction where the April transaction is simply missing.
  • One approach is to apply an implicit date/time (e.g., day of month) expectation based on the model generated transaction duration prediction.
  • a missed transaction may also be determined based on detecting a recurring transaction pattern with a time-base variable distribution.
  • a time-base variable distribution may include a distribution of statistically possible occurrences of a transaction over time.
  • a time-base variable distribution may be accounted for to determine when a transaction is “missed”. For example, a transaction usually occurs on the 7 th day of a month, but sometimes can occur instead on the 8 th or the 9 th day for all kinds of reasons.
  • Insight generator 156 may establish a range of possible time frames during which a selected transaction may take place, and may generate a “missed transaction” alert only if the transaction occurs beyond the established range. Each transaction may have its own behavior in terms of time-base variable distribution.
  • Figure 4A is an exemplary sequence illustrating a missing transaction insight modified to a late arrival transaction insight with amount as expected, operative in accordance with an embodiment of the present invention.
  • a first date (10 April 2021 )
  • a set of predictions of log(amount) and duration until the next transaction is generated.
  • the predictions determine that the expected amount is in the range of 2000-2300 (in some currency) and the transaction will reoccur every 28-32 days.
  • a second date 15 May 2021
  • it is determined that 32 + 3 days have elapsed since the last generated prediction i.e., the upper bound of the predicted duration (32 days) plus the minimum time period for establishing a missing transaction insight (3 days).
  • a “missing insight” is generated.
  • a transaction arrives with the amount 2000, representing 38 days after the previous transaction in the series, and thus the missing insight is modified to “transaction amount as expected and arrived late”.
  • Figure 4B is an exemplary sequence illustrating a transaction on time with amount higher than expected insight, operative in accordance with an embodiment of the present invention.
  • a recurring transaction arrives.
  • a set of predictions of log(amount) and duration until next transaction is generated.
  • the predictions determine that the expected amount is in the range of 2000-2300 (in some currency) and the transaction will reoccur every 28-32 days.
  • a second date (10 May 2021 )
  • a subsequent recurring transaction arrives with the amount 3000.
  • the amount exceeds the upper bound threshold of the log(amount) prediction range (2000-2300), while the time of arrival is within the duration prediction range (28-32 days), and thus a “transaction amount greater than expected and arrived on time” insight is generated.
  • Figure 4C is an exemplary sequence illustrating a transaction is early with amount higher than expected insight, operative in accordance with an embodiment of the present invention.
  • a recurring transaction arrives.
  • a set of predictions of log(amount) and duration until next transaction is generated.
  • the predictions determine that the expected amount is in the range of 2000-2300 (in some currency) and the transaction will reoccur every 28-32 days.
  • a second date (4 May 2021 )
  • a subsequent recurring transaction arrives with the amount 3000.
  • the amount exceeds the upper bound threshold of the log(amount) prediction range (2000-2300), while the time of arrival is before the lower bound of the duration prediction range (28-32 days), and thus a “transaction amount greater than expected and arrived early” insight is generated.
  • Insight generator 156 may provide certain advanced insights, which build on the previously described basic insight categories.
  • One such example is a tax return insight, which may be generated after identifying selected trigger events that could result in a tax return.
  • trigger events may include the discontinuation of a salary payment, or a salary payment including some form of wage-replacement benefits, such as unemployment or disability compensation.
  • a discontinuation of a salary payment event may rely on a “missing transaction insight” trigger for a transaction category relating to a “salary” of the customer. Further filtering may be applied to narrow down the group of events to a subset that may merit further investigation before issuing an insight or alert of a potential tax return.
  • One category of insights may include a determination of a late or early status of a transaction based on a tail distribution. For example, when payments are late, financial institutions may have difficulty determining whether the late payment is attributable to a prior or subsequent due date. This may be addressed by calculating leading or trailing edges of expected transactions and defining gaps between sequential transactions. Payments received in the gaps are treated as late, while payments received in the leading edge of the subsequent expected transaction are attributed to the subsequent expected transaction with a prior payment treated as having been missed.
  • Available data relating to a first account may be insufficient to generate predictions and insights, such as whether a new datapoint (e.g., a selected transaction) is part of a broader pattern. Accordingly, data from unrelated similar accounts may be considered and used to determine if the new datapoint in the first account is part of the pattern.
  • a new datapoint e.g., a selected transaction
  • confidence scores are assigned to respective insights.
  • Each insight may be assigned a confidence score or weighting, in accordance with confidence levels of the utilized predictions and according to the type of insight.
  • Each insight can be based on different data and may use different calculations or processes to generate predictions and confidence levels of the predictions.
  • the confidence scores may be provided by the transaction analysis models (as an output), or calculated based on selected criteria, such as variations per account/customer or statistics of a general population of accounts/customers. The higher the confidence score, the higher the likelihood that the insight will be correct after the fact.
  • a first insight relating to a transaction amount prediction may be assigned a relatively high weighting (e.g., a 0.85 factor on a 0 to 1 scale), whereas a second insight relating to a transaction duration prediction may be assigned a relatively low rating (e.g., a 0.15 weighting factor on a 0 to 1 scale), based on a calculated confidence level of each prediction.
  • Confidence scores may be established using suitable data processing and/or machine learning techniques known in the art. For example, a confidence interval may be calculated using a maximum likelihood estimator (e.g., assuming a distribution and fitting parameters accordingly).
  • An insight may be based on other insights, in which case its confidence score may be based on those of the underlying insights and/or additional statistics. The assignment of a confidence score may be implemented as part of the insight generation (and integrated into step 180).
  • a next procedure 182 relates to generating recommendations.
  • recommendation generator 157 is configured to generate one or more recommendations 163 relating to financial transactions of a customer, in accordance with the generated insights and predicted information.
  • the recommendations may be determined according to one or more generated insights (stage 180), accounting for additional factors, such as confidence level of insights (stage 181 ), validity of financial data, and past recommendations.
  • recommendations may be determined based on insights, then validated, and then approved or rejected based on certain criteria, such as confidence scores and a configuration per insight type, group of types (categories) and/or default conditions.
  • the recommendation may further be compared to previous recommendations that have not yet expired and have not been deactivated, to determine if the recommendation should be sent or not, and whether or not it should deactivate or replace previous recommendations.
  • Each recommendation may also be assigned a confidence score.
  • a recommendation confidence score may correspond to the confidence score of the insight or insights on which the recommendation is predicated, the type of recommendation, and/or additional statistics.
  • a recommendation may include one or more actions for possible implementation.
  • the recommendations may be provided to a customer, who may decide if or which recommendations to implement, and to what extent.
  • the provided recommendations may be directed to optimize one or more criteria relating to at least one account or portfolio of the customer.
  • the confidence score of a recommendation may determine how and/or where the recommendation is directed and in what manner, and effecting how the recommendation is processed and considered.
  • Recommendation generator 157 may analyze the transaction insights, such as insights relating to amount and timing of next transactions and/or missing transactions, and may apply further machine learning analysis to an applicable dataset, to generate a plurality of recommendations.
  • a recommendation may be based on one or more basic insights or advanced insights.
  • insight generator 156 may generate an “excess balance insight” that one or more user accounts has an expected account balance that exceeds a minimum amount, based on predicted amounts and timings of expected future transactions relating to the accounts.
  • Recommendation generator 157 may then generate a recommendation accordingly that the user direct a selected amount of the excess balance into one or more investment options.
  • a recommendation may be directed to optimize one or more criteria, which may be predefined or updated in real-time by a user.
  • criteria may include: avoiding a negative balance in one or more accounts/portfolios; maintaining a minimum excess balance amount in one or more accounts/portfolios; and minimizing level of risk or maximizing potential gains in one or more investment options.
  • Further examples of recommendation objectives may include: helping customers to maintain a budget; balancing accounts; and balancing multiple investment options to meet long-term goals, while addressing short term risks.
  • the recommendations may also be differentially weighted in accordance with a respective degree of importance assigned to different criteria (e.g., based on user feedback). For example, a user may rank different criteria according to level of importance (e.g., in descending order), or assign an importance rating to each criterion (e.g., on a numeric scale).
  • recommendation generator 157 provides recommendations in a hybrid format, where different recommendations are selectively handled in accordance with their associated confidence scores.
  • a respective recommendation may be assigned to a respective category based on selected criteria, such as the recommendation confidence score, and each category may be managed or routed in a certain way.
  • recommendation generator 157 may establish a confidence threshold value (e.g., 0.5), where recommendations having a confidence score below the threshold (e.g., below 0.5) are categorized as “low confidence recommendations”, and those having a confidence score above the threshold (e.g., above 0.5) are categorized as “high confidence recommendations”.
  • Recommendations may alternatively be assigned into more than two categories.
  • a low category may be designated for confidence scores below a first threshold (e.g., below 0.3), a high category designated for confidence scores above a second threshold (e.g., above 0.7), and an intermediate category designated for confidence scores in the range between the two thresholds (e.g., 0.3 to 0.7).
  • Each respective recommendation category may be handled in a customized manner. For example, recommendations in a “low confidence category” may be rejected and discarded; recommendations in an “intermediate confidence category” may be directed to a designated financial analyst for review and approval; and recommendations in a “high confidence category” may be sent directly to the customer.
  • the aforementioned 3 categories may be reduced to 1 or 2 categories by modifying the thresholds (e.g., the low range can be eliminated by modifying the bottom threshold to “0”; the high range can be eliminated by modifying the upper threshold to “1”; and the intermediate range can be eliminated by equalizing the bottom threshold to the upper threshold). Additional ranges can also be added to provide additional (e.g., more than three) options.
  • recommendations in a high confidence category are sent directly to the customer (such as by providing a notification via reporting module 158), recommendations in a low confidence category are discarded, and recommendations in an intermediate confidence category are sent to a third party (e.g., a financial analyst) for further review.
  • the intermediate category recommendations may be presented on a dedicated recommendation approval interface, which may operate using an application programming interface (API) and may include a graphical user interface for displaying and accessing information relating to one or more accounts and/or portfolios of multiple customers. The information may be presented, for example, as part of a website, portal, web application, mobile application, or other components or interfaces known in the art.
  • API application programming interface
  • the recommendation approval interface may provide interactive communication and commands or prompts for receiving instructions or input, such as in order to validate, select, approve, or reject a recommendation.
  • the interface may display predictive metrics and supplementary information relating to a recommendation, to facilitate a determination by the operator for whether a received recommendation for review (e.g., assigned to an intermediate confidence category) should be rejected, or approved for sending to the customer.
  • the operator may also decide to modify or update a selected recommendation before sending to a customer, or may send a recommendation together with customized remarks and/or in a manner so as to provide additional information (e.g., estimated likelihoods of certain outcomes; potential advantages or drawbacks, and the like).
  • recommendations in a low or intermediate confidence category may be directed to an operator, such as a financial analyst, for further review, to decide whether to discard the recommendation or to present it to the customer.
  • the operator may apply human judgement and experience to decide whether the recommendation should be discarded or whether it should be modified or presented to the user as is.
  • Figure 5A is an example first screen of a recommendation approval interface, operative in accordance with an embodiment of the present invention.
  • a first window displays a list of insights for selection, where each insight may be associated with a respective customer.
  • a second window displays the selected insight, in this example relating to an expected excess balance of 5,200 in a user account, as determined based on historical information (including previous income and expenses transactions).
  • the interface may further present a recommendation associated with the insight, which in this example is a recommendation to invest 3,000 of the available excess balance. It is noted that a recommendation may include an action or a list of actions to choose from, or simply information without an associated action.
  • Figure 5B shows an example second screen of a recommendation approval interface, following the first screen of Figure 5A. After approving an initial recommendation to invest the excess balance, the interface presents a following recommendation with a list of recommended investment options. Each option may be associated with a respective weight or rating, reflecting how suitable the option is for the customer, based on selected optimization criteria (e.g., customer objectives, risk level, preferences, and past behavior).
  • selected optimization criteria e.g., customer objectives, risk level, preferences, and past behavior.
  • a first option is to invest the balance in a savings account (rating 4.8); a second option is to invest in a security portfolio (rating 4.2); and a third option is to purchase cryptocurrency (rating 2.8).
  • the customer may be prompted to reject or approve the recommendation options (and possible subsequent continuation recommendations).
  • the sequence of recommendations may be presented in an alternate format, such as a series of text messages on an interactive chat or instant messaging application.
  • Figure 5C shows an example screen of a recommendation approval interface provided on a mobile phone, in relation to the examples of Figures 5A and 5B, where the user receives and selects recommendations in a text messaging format.
  • the recommendation validation interface may further depict predicted metrics relating to a presented insight or recommendation.
  • metrics may include, for example, a risk level of a selected option, or an expected fee to be incurred when implemented a certain action over a selected interval, or an expected change in an account balance (e.g., depicted in a graph format).
  • the predicted metric may also include a forecast that an account is likely to have a negative balance over a selected time interval.
  • recommendation generator 157 may provide “rebalancing recommendations” relating to multiple portfolios of a customer, to facilitate holistic cross-portfolio management and decision making.
  • a customer may have at least one portfolio (e.g., personal, family, and/or business) in at least one financial institution, where each portfolio may have multiple accounts (e.g., checking, debit, savings, investment).
  • Recommendation generator 157 may provide insights and recommendations based on the history and behavior of all the portfolios, in order to optimize predefined conditions. Optimizing conditions may include: to maintain a minimum balance of funds available for use (e.g., in one or multiple selected accounts), to invest all excess funds; to avoid negative balances, or any combination of the above.
  • a future state of a first account may be predicted (e.g., an expectation of an overdrawn account or negative balance), and a recommendation may be provided to rebalance the accounts (e.g., by transferring funds from a different account) to avoid the predicted state.
  • the conditions may be differentially weighted in accordance with a respective degree of importance, such as based on user ratings, which may be predefined or dynamically updated.
  • Disclosed embodiments may take a holistic view of a customer portfolio and predict a future state of one account (e.g., a likely future overdrawn position) and preemptively rebalance accounts to avoid the predicted adverse future state.
  • Data analysis module 154 may analyze a plurality of accounts of a customer and may identify transaction patterns associated with each account. Data analysis module 154 may predict a future state of each of the accounts, and determine based on the predicted future states that at least one of the accounts is expected to violate a constraint limitation associated with the respective account.
  • Recommendation generator 157 may determine and send a rebalancing recommendation that reallocates resources between accounts to avoid the constraint limitation.
  • System 150 may be configured to process the structures, such as by implementing an abstraction layer containing a mapping scheme of a universal client account to the different user accounts.
  • the abstraction layer may be configured to identify common meaning between the different nomenclatures.
  • System 150 may be configured to predict a future state in one or more accounts at periodic or non-periodic intervals, and to provide rebalancing recommendations accordingly at each periodic or non-periodic interval.
  • Figure 6A illustrates a first example of a rebalancing portfolio recommendation, operative in accordance with an embodiment of the present invention.
  • recommendation generator 157 provides a rebalancing recommendation directed to optimizing a condition of avoiding a negative balance.
  • a first retail portfolio in a first bank is determined to have an expected positive cashflow and an expected positive balance
  • a second retail portfolio in a second bank is determined to have an expected positive cashflow and an expected negative balance (i.e., based on generated predictions and insights).
  • recommendation generator 157 provides the customer with a rebalancing recommendation to transfer funds from the first portfolio to the second portfolio.
  • Figure 6B illustrates a second example of a rebalancing portfolio recommendation, operative in accordance with an embodiment of the present invention.
  • recommendation generator 157 provides a rebalancing recommendation directed to optimizing a condition of increasing investments.
  • a retail portfolio in a first bank is determined to have an expected positive cashflow and an expected positive balance (i.e., based on generated predictions and insights).
  • Recommendation generator 157 provides a rebalancing recommendation to transfer funds from the retail portfolio to an investment portfolio in a second bank.
  • Figure 6C illustrates a third example of a rebalancing portfolio recommendation, operative in accordance with an embodiment of the present invention.
  • recommendation generator 157 provides a rebalancing recommendation directed to optimizing a condition of modifying an investment risk profile based on retail portfolios behavior.
  • a retail portfolio in a first bank is determined to have an expected negative cashflow and an expected negative balance (i.e., based on generated predictions and insights).
  • Recommendation generator 157 provides a rebalancing recommendation to transfer funds from the retail portfolio to an investment portfolio in a second bank.
  • a rebalancing recommendation may also be related to a single portfolio of a customer across multiple accounts.
  • a customer may have a portfolio containing multiple accounts (e.g., savings, investment and/or retirement) in multiple institutions, and recommendation generator 157 may provide insights and recommendations based on the history and behavior of the portfolio, in order to optimize predefined conditions.
  • Such conditions may include: to reschedule dates of charge in an account; to freeze or temporarily reduce savings in one or more account so as to avoid a negative balance; or to change a date of a recurring expense (e.g., a credit card charge) to avoid a negative balance.
  • FIG. 6D illustrates a fourth example of a rebalancing portfolio recommendation, operative in accordance with an embodiment of the present invention.
  • recommendation generator 157 provides a rebalancing recommendation directed to optimizing a condition of avoiding a negative balance over a duration of 8 days for a period of several months.
  • a customer has a recurring expense of a monthly credit card charge of 5,000 scheduled for April 2 nd and a recurring income of a salary deposit of 10,000 scheduled for April 10.
  • the initial balance of the customer account is determined to be 2,000 prior to April 2 nd , such that the credit card charge would place the account in a negative balance (until the salary deposit occurs).
  • recommendation generator 157 provides a rebalancing recommendation to postpone the credit card charge until after the salary deposit (to April 15 th ), such that the account will have a positive balance prior to and following the postponed charge.
  • Disclosed embodiments may include using a high-level view of a portfolio of accounts held by differing institutions to monitor an entire portfolio, determine an impending failure to meet an objective in a particular account, and to automatically initiate transactions in multiple accounts within the portfolio to avoid the impending failure without putting the other accounts at risk of failing their own objectives.
  • Data analysis module 154 may analyze a plurality of accounts associated with a portfolio of a customer, may receive at least one customer objective relating to the accounts, and may project an impending failure to meet the customer objective.
  • Data analysis module 154 may analyze data from the accounts to determine at least one prospective transaction relating to a plurality of accounts that is capable of averting the impending failure without violating at least one rule associated with the respective account.
  • Recommendation generator 157 may provide an indication of the impending failure to meet the customer objective, and at least one recommendation to implement the prospective transaction.
  • recommendation generator 157 may provide “budget recommendations” relating to multiple spending categories of a customer, to facilitate maintaining a budget.
  • Data analysis module 154 may identify and analyze different categories of expenditures or “spending categories” (e.g., housing, utilities, transportation, clothing, food, entertainment, travel) of a customer, and detect categories in which recurring expenses can be minimized. Customer behavior in each spending category may be analyzed, to provide expectations of future transactions (amount and timing) in each category.
  • a set of recommendations may be directed to generally minimize overall expenses in view of overall income, and particularly to minimize expenses for different spending categories.
  • recommendation generator 157 may suggest spending limits or restrictions for one or more spending categories over a selected period of time (e.g., a month or a year).
  • the restrictions may relate to reducing the total number of expenses, reducing the amount of individual expenses, reducing the frequency of recurring expenses, and/or modifying the timing of (e.g., postponing) an expense, in different spending categories.
  • Further suggestions may be to reduce (or entirely eliminate) expenditures in selected spending categories, such as those considered unnecessary luxuries (e.g., entertainment, travel).
  • the budget recommendations may take into account variations in previous expenses and associated factors, such as the likelihood of the customer to reduce expenses in certain categories, to help establish recommended restrictions for each spending category.
  • the customer may also be provided with alerts relating to category spending limits (e.g., when approaching or exceeding the limit).
  • the limits may be dynamically updated or modified based on new conditions or in accordance with user feedback, such that different categories may be selectively weighted in accordance with an assigned importance ranking.
  • Spending categories may be identified across a plurality of accounts, and behavioral change recommendations (e.g., spending recommendations) may be provided on a category level based on aggregated data from multiple accounts. For example, account data associated with an individual credit card may not reveal abnormalities in a first spending category (e.g., entertainment spending), but red flags may be identified when all credit card accounts are examined in the aggregate.
  • Data analysis module 154 may analyze data from a plurality of accounts to identify transactions in a plurality of spending categories, group transactions across accounts by category and time period, and analyze groups of transactions for each category across a plurality of time periods to predict a trend for each spending category. The trend may be compared to a normal level, such as based on an average or a standard deviation. If a selected spending category is determined to be trending toward an abnormal level, then recommendations may be generated to abate the trend, in relation to future transactions in at least one of the customer accounts.
  • a recommendation of a prospective purchase may further be directed to optimize selected conditions (e.g., avoiding a minimum account balance, or maintaining a minimum savings level), or to account for an importance level of the prospective purchase (e.g., based on predefined or dynamic user feedback).
  • Disclosed embodiments may include helping customers determine whether they can afford prospective purchases. Specifically, by analyzing a prospective purchase in view of insights gained from past customer financial behavior, recommendations can be provided to enable customers to make desired purchases. Disclosed embodiments may include presenting not just one, but a menu of options to avoid a future undesired financial situation based on a predicted impact of a change in behavioral patterns across a plurality of user accounts. Data analysis module 154 may determine whether a prospective future transaction of a customer violates at least one rule or condition associated with at least one account of the customer.
  • Data analysis module 154 may analyze behavioral patterns derived from previous transactions to predict future balances in a plurality of accounts, and may simulate the prospective transaction in the context of the predicted future balance to determine if the prospective future transaction violates a rule or condition.
  • Recommendation generator 157 may generate at least one recommendation based on the simulation, such as whether the prospective purchase can be afforded, and/or a suggestion to change at least one future transaction or behavior in order to afford the prospective purchases (e.g., to liquid a security, or restructure a credit).
  • the rule may be to ensure that the aggregate balance across all accounts of the customer portfolio is maintained above a threshold, or that selected balances in selected accounts are maintained above a threshold.
  • reporting module 158 reports one or more generated insights 162 and/or recommendations 163 to the customer.
  • the customer may provide instructions or feedback relating to the insights or recommendations, such as to approve or to reject a selected recommended action.
  • a further aspect of the disclosed embodiments relates to a data and machine learning pipeline, where multiple data sources may be mapped into a unified structure to enable unified processing and analysis. For example, predictions and insights can be performed on a first account, based on machine-learning training and modeling implemented on other accounts, such as accounts for which greater historical data is available, regardless of whether the first account is from the same data source as the other accounts.
  • FIG. 7 is a flow chart illustration of a data and machine learning pipeline process, operative in accordance with an embodiment of the present invention.
  • the data and machine learning pipeline may involve several steps. For example, raw data may be normalized into a workable structure, enriched using additional data sources and algorithms, and converted into a common format. The data may be aggregated based on selected criteria, such as by period, by source or target of funds, by category, and the like. The data may be normalized into a structure usable by machine learning models (e.g., by modifying range of parameters, converting parameter types, encoding parameters). A machine learning process may be applied in a training stage, and then to generate predictions based on the training.
  • machine learning models e.g., by modifying range of parameters, converting parameter types, encoding parameters
  • the training may enable a transfer of understanding of behavior from an available general population to a specific case (e.g., a specific account or customer).
  • a specific case e.g., a specific account or customer
  • the aforementioned process may enable determining information (insight or recommendations) for a new customer lacking detailed historical data, based on patterns identified in the general population.
  • Disclosed embodiments may include using an abstraction layer that understands different terminology for different financial institutions and allows real-time transactions based on a mapping infrastructure between the financial institutions. Disclosed embodiments may further include using an abstraction layer to communicate with different accounts, aggregate data from the different accounts, and unify the data to continuously update the data in a data lake to generate an insight and notification when data in one account may affect data in another account.
  • An insight may include an actionable message that may be delivered to a client via a mobile application.
  • An insight may utilize models that account for cross-account behaviors. For example, the message “you overpaid for transaction x” may account for cross-account transactions to determine what “overpaid” means.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • Economics (AREA)
  • Data Mining & Analysis (AREA)
  • Entrepreneurship & Innovation (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Software Systems (AREA)
  • Technology Law (AREA)
  • Evolutionary Computation (AREA)
  • Artificial Intelligence (AREA)
  • Game Theory and Decision Science (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computational Linguistics (AREA)
  • Biomedical Technology (AREA)
  • Health & Medical Sciences (AREA)
  • Biophysics (AREA)
  • General Health & Medical Sciences (AREA)
  • Molecular Biology (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Medical Informatics (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)

Abstract

La présente invention concerne un système et un procédé pour fournir de manière proactive des aperçus et des recommandations financiers. Des données de transaction sont collectées à partir de sources de données financières et traitées. Un processus d'apprentissage machine est appliqué à un ensemble de données d'entraînement pour générer un modèle d'analyse de transaction pendant la phase d'entraînement. Le modèle d'analyse de transaction est appliqué à un ensemble de données de client pendant la phase de modélisation pour générer des prédictions sur les prochaines transactions dans une série. Des aperçus sont générés conformément aux prédictions et des recommandations sont générées conformément aux aperçus. Les aperçus et les recommandations peuvent être catégorisés et associés à des scores de confiance sur la base des conditions d'optimisation sélectionnées. Les prédictions peuvent comprendre le montant ou le moment d'une prochaine transaction dans une série ou le total des transactions dans des séries sur une période sélectionnée. Les recommandations peuvent concerner le rééquilibrage des portefeuilles des clients, les recommandations sélectivement routées selon les scores de confiance, et les recommandations budgétaires pour plusieurs catégories de dépenses. Le mappage de plusieurs sources de données en une structure unifiée permet un traitement commun et le transfert des conclusions de l'entraînement sur une source à une autre.
PCT/IL2023/050543 2022-05-26 2023-05-24 Aperçus et recommandations basés sur une transaction WO2023228195A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202263346132P 2022-05-26 2022-05-26
US63/346,132 2022-05-26

Publications (1)

Publication Number Publication Date
WO2023228195A1 true WO2023228195A1 (fr) 2023-11-30

Family

ID=88918725

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IL2023/050543 WO2023228195A1 (fr) 2022-05-26 2023-05-24 Aperçus et recommandations basés sur une transaction

Country Status (1)

Country Link
WO (1) WO2023228195A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190073669A1 (en) * 2017-09-06 2019-03-07 Visa International Service Association System, Method, and Computer Program Product for Predicting Payment Transactions Using a Machine Learning Technique Based on Merchant Categories and Transaction Time Data
US20190180255A1 (en) * 2017-12-12 2019-06-13 Capital One Services, Llc Utilizing machine learning to generate recommendations for a transaction based on loyalty credits and stored-value cards
US11170433B2 (en) * 2018-01-09 2021-11-09 Intuit Inc. Method and system for using machine learning techniques to make highly relevant and de-duplicated offer recommendations
US20220083995A1 (en) * 2016-05-05 2022-03-17 State Farm Mutual Automobile Insurance Company Using cognitive computing to provide a personalized banking experience

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220083995A1 (en) * 2016-05-05 2022-03-17 State Farm Mutual Automobile Insurance Company Using cognitive computing to provide a personalized banking experience
US20190073669A1 (en) * 2017-09-06 2019-03-07 Visa International Service Association System, Method, and Computer Program Product for Predicting Payment Transactions Using a Machine Learning Technique Based on Merchant Categories and Transaction Time Data
US20190180255A1 (en) * 2017-12-12 2019-06-13 Capital One Services, Llc Utilizing machine learning to generate recommendations for a transaction based on loyalty credits and stored-value cards
US11170433B2 (en) * 2018-01-09 2021-11-09 Intuit Inc. Method and system for using machine learning techniques to make highly relevant and de-duplicated offer recommendations

Similar Documents

Publication Publication Date Title
US11423365B2 (en) Transaction card system having overdraft capability
US20240211967A1 (en) Adaptive transaction processing system
CN110599336B (zh) 一种金融产品购买预测方法及系统
US20150142713A1 (en) Real-Time Adaptive Decision System And Method Using Predictive Modeling
CA3060678A1 (fr) Systemes et procedes pour determiner la capacite financiere d`un emprunteur
US20230351396A1 (en) Systems and methods for outlier detection of transactions
US20050125434A1 (en) System and method for scalable cost-sensitive learning
US20230013086A1 (en) Systems and Methods for Using Machine Learning Models to Automatically Identify and Compensate for Recurring Charges
US20220207420A1 (en) Utilizing machine learning models to characterize a relationship between a user and an entity
US20220005042A1 (en) Orchestration techniques for adaptive transaction processing
CN113610521A (zh) 用于检测行为数据的异常的方法和设备
CN112862182A (zh) 一种投资预测方法、装置、电子设备及存储介质
WO2019194696A1 (fr) Système automatisé d'élaboration et de commande de modèles de notation
KR20110114181A (ko) 예측 정확성이 향상된 대출 심사 방법
Naik Predicting credit risk for unsecured lending: A machine learning approach
dos Reis Evaluating classical and artificial intelligence methods for credit risk analysis
Alfonso-Sánchez et al. Optimizing credit limit adjustments under adversarial goals using reinforcement learning
WO2023228195A1 (fr) Aperçus et recommandations basés sur une transaction
Lee et al. Application of machine learning in credit risk scorecard
Sembina Building a Scoring Model Using the Adaboost Ensemble Model
US12014430B2 (en) Time-based input and output monitoring and analysis to predict future inputs and outputs
KR102571889B1 (ko) 딥러닝 기반의 비금융활동을 통한 신용 평가 방법 및 이를 수행하는 서버
US20240127251A1 (en) Systems and methods for predicting cash flow
US20240064054A1 (en) Alerting networked devices of signal divergence by georegion
US20230401417A1 (en) Leveraging multiple disparate machine learning model data outputs to generate recommendations for the next best action

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23811323

Country of ref document: EP

Kind code of ref document: A1