Modeling users for fraud detection and analysis

RELATED APPLICATION

0001This application claims the benefit of United States (US) Patent Application number <patcit id="pcit0001" dnum="US61061092B"><text>61/061,092, filed June 12, 2008</text></patcit>.

0002This application claims the benefit of <patcit id="pcit0002" dnum="US61061095B"><text>US Patent Application number 61/061,095, filed June 12, 2008</text></patcit>.

0003This application claims the benefit of <patcit id="pcit0003" dnum="US61061096B"><text>US Patent Application number 61/061,096, filed June 12, 2008</text></patcit>.

0004This application claims the benefit of <patcit id="pcit0004" dnum="US61061097B"><text>US Patent Application number 61/061,097, filed June 12, 2008</text></patcit>.

TECHNICAL FIELD

0005The disclosure herein relates generally to fraud detection and analysis. In particular, this disclosure relates to fraud detection using behavior-based modeling.

BACKGROUND

0006Tracking fraud in the online environment is a hard problem to solve. Fraudster tactics rapidly evolve, and today's sophisticated criminal methods mean online account fraud often doesn't look like fraud at all. In fact, fraudsters can look and behave exactly like a customer might be expected to look and behave. Accurate detection is made even more difficult because today's fraudsters use multi-channel fraud methods that combine both online and offline steps, any one of which looks perfectly acceptable but when taken in combination amount to a fraudulent attack. Identifying truly suspicious events that deserve action by limited fraud resources is like finding a needle in a haystack.

0007Consequently, customer financial and information assets remain at risk, and the integrity of online channels is at risk. Companies simply do not have the resources to anticipate and respond to every possible online fraud threat. Today's attacks expose the inadequacies of yesterday's online fraud prevention technologies, which cannot keep up with organized fraudster networks and their alarming pace of innovation.

0008Reactive strategies are no longer effective against fraudsters. Too often, financial institutions learn about fraud when customers complain about losses. It is no longer realistic to attempt to stop fraudsters by defining new detection rules after the fact, as one can never anticipate and respond to every new fraud pattern. Staying in reactive mode makes tracking the performance of online risk countermeasures over time more difficult. Adequate monitoring of trends, policy controls, and compliance requirements continues to elude many institutions.

0009The conventional technologies that hope to solve the online fraud problem, while often a useful and even necessary security layer, fail to solve the problem at its core. These solutions often borrow technology from other market domains (e.g. credit card fraud, web analytics), then attempt to extend functionality for online fraud detection with mixed results. Often they negatively impact the online user experience.

0010Conventional alternatives attempting to solve the online fraud problem include multi-factor and risk-based authentication solutions and fraud rule-, fraud indicator- and fraud pattern-based transaction monitoring solutions. The multi-factor and risk-based authentication solutions are ineffective because they typically result in high false detections (false positives) and return non-actionable information. Authentication failure and the need for challenge questions are not accurate indicators of fraud, and challenge rates are too high to be acted upon by limited fraud investigation resources. Their fraud detection capabilities (e.g., device identification, cookies, etc.) do not deliver the performance required and lack the rich behavior models and account history necessary to investigate suspicious activity. Recently fraudsters have demonstrated the ability to circumvent this technology completely.

0011Fraud rule-, fraud indicator- and fraud pattern-based transaction monitoring solutions are generally always behind the latest fraud techniques. These solutions merely react to known threats instead of recognizing new threats as they happen. They require complicated rules development and maintenance, known fraud "truth sets" for algorithm training, and ongoing "care and feeding" maintenance to try to remain current. As a result, these solutions are unable to spot new fraud types and patterns. Once a breach occurs, most return minimal detail on any given fraud instance, little context, limited characterization of individual user behavior, no visual analytics, less granular risk scoring, and minimal forensics.

INCORPORATION BY REFERENCE

0012Each patent, patent application, and/or publication mentioned in this specification is herein incorporated by reference in its entirety to the same extent as if each individual patent, patent application, and/or publication was specifically and individually indicated to be incorporated by reference.

BRIEF DESCRIPTION OF THE DRAWINGS

0013<ul id="ul0001" list-style="none" compact="compact"><li><figref idref="f0001"><b>Figure 1</b></figref> is a block diagram of the Fraud Prevention System (FPS), under an embodiment.</li><li><figref idref="f0002"><b>Figures 2A</b></figref><b>and</b><figref idref="f0003"><b>2B</b></figref> show a block diagram of FPS integration with an online banking application, under an embodiment.</li><li><figref idref="f0004"><b>Figure 3</b></figref> is a flow diagram for a method of predicting expected behavior using the FPS, under an embodiment.</li><li><figref idref="f0004"><b>Figure 4</b></figref> is a flow diagram for a method of estimating actions of an account owner using the FPS, under an embodiment.</li><li><figref idref="f0005"><b>Figure 5</b></figref> is a flow diagram for a method of determining the relative likelihood a future event is performed by the user versus the fraudster using the FPS, under an embodiment.</li><li><figref idref="f0006"><b>Figure 6</b></figref> is a flow diagram for using the FPS to generate warnings of possible fraudulent activity, under an embodiment.</li><li><figref idref="f0007"><b>Figure 7</b></figref> shows the use of conventional fraud techniques ("fraud knowledge") applied to activities of a user ("normal user") under the prior art</li><li><figref idref="f0008"><b>Figure 8</b></figref> shows the use of dynamic account modeling applied to activities of a user, under an embodiment.</li><li><figref idref="f0009"><b>Figure 9</b></figref> is an example screen of the FPS graphical interface (AUI), under an embodiment.</li><li><figref idref="f0010"><b>Figure 10</b></figref> shows a variation of the example screen (<figref idref="f0009">Figure 9</figref>) of the FPS graphical interface (AUI), under an embodiment.</li><li><figref idref="f0011"><b>Figure 11</b></figref> is an example AUI showing normal use behavior for a user, under an embodiment.</li><li><figref idref="f0012"><b>Figure 12</b></figref> is an example AUI showing a first RED alert for a user, under an embodiment</li><li><figref idref="f0013"><b>Figure 13</b></figref> is an example AUI showing a second RED alert for a user, under an embodiment.</li><li><figref idref="f0014"><b>Figure 14</b></figref> is an example AUI showing additional for a user account, under an embodiment.</li><li><figref idref="f0015"><b>Figure 15</b></figref> is an example AUI showing the Fraud Match view, under an embodiment.</li><li><figref idref="f0016"><b>Figure 16</b></figref> is another example AUI showing the results obtained in the Fraud Match View plotted over time, under an embodiment.</li></ul>

DETAILED DESCRIPTION

0014Fraud prevention systems and methods are described below for use in the prevention of account fraud and identity theft, providing real-time risk management solutions that protect online and off-line channels. The fraud prevention systems and methods described herein, collectively referred to herein as the fraud prevention system (FPS), support the end-to-end online risk management process with behavior-based modeling and rich analytics. The FPS offers an analytics-based software solution that addresses the entire risk management lifecycle, as described in detail below.

0015The FPS of an embodiment connects data analytics, the online domain, and fraud expertise by providing predictive models of individual behavior, dynamically adjusting to identify anomalous and suspicious activity, and then providing actionable alerts and rich investigation capabilities as part of a comprehensive risk management solution. The FPS automatically detects new and evolving fraud threats without any requirement for fraud rule/pattern development or ongoing maintenance effort

0016In the following description, numerous specific details are introduced to provide a thorough understanding of, and enabling description for, embodiments of the FPS. One skilled in the relevant art, however, will recognize that these embodiments can be practiced without one or more of the specific details, or with other components, systems, etc. In other instances, well-known structures or operations are not shown, or are not described in detail, to avoid obscuring aspects of the disclosed embodiments.

0017In the descriptions and examples provided herein, a user or customer is an owner of an account, a fraudster is any person that is not the user or account owner and an analyst or employee is the user of the FPS system.

0018<figref idref="f0001"><b>Figure 1</b></figref> is a block diagram of the FPS 100, under an embodiment. The FPS 100 includes a Risk Engine 102 coupled to a Risk Application 104. The Risk Engine 102 includes or hosts applications, using predictive models of individual online customer behavior along with analytics that together detect fraud and minimize false positives. Unlike conventional approaches, the Risk Engine applications include real-time Dynamic Account Modeling that automatically detects new fraud attacks without requiring rules development or algorithm training. The Risk Application 104 features a visual analytic interface to aid investigation, resolution and risk monitoring. The visual analytic interface included in and/or coupled to the Risk Application 104 is also referred to herein as the analytical user interface (AUI). Going beyond simple alerts, the Risk Application 104 delivers analysts high-fidelity risk scores and extensive contextual information behind the risk score to support comprehensive analysis and investigation.

0019The Risk Engine 102 of an embodiment detects new and emerging fraud schemes using predictive models of individual online customer behavior and, as such, it differentiates normal user behavior from suspicious activity. The Risk Engine 102 may use fraud models based on known information about fraud threats when available, but is not dependent on knowing detailed fraud patterns or pre-defined fraud rules. To ease integration with the customer's online channel, the Risk Engine 102 features both a real-time API and file-based batch controller for wider integration and deployment options.

0020The Risk Engine 102 includes Dynamic Account Modeling, as described herein. The Dynamic Account Modeling, also referred to herein as "predictive modeling" or "modeling", uses predictive models of each individual online user's behavior. Because the Risk Engine 102 is not dependent on pre-defined fraud rules and automatically detects anomalous behavior, new threats are detected as they occur. Furthermore, the Risk Engine 102 easily handles real world situations such as changing user and fraudster behavior, the use of proxies, corporate firewalls, dynamic IP addresses, and upgrades to customer hardware and software. The advanced statistical models of the Risk Engine are based on probabilities that dynamically adjust to individual user behavior, recognizing that every user behaves differently and what might be unusual for one user may be normal for another

0021The Risk Application 104 provides a visual analytic interface to aid investigation, resolution and risk monitoring. Components of the Risk Application 104 display detailed views of online account activity from customer sessions with fine-grained risk scoring, as described in detail herein. The interactive configuration of the Risk Application 104 enables use by any employee involved in fraud prevention, including fraud analysts, IT security personnel, risk management analysts, online channel analysts, or even customer-facing employees. The Risk Application 104 functions include, but are not limited to, alert management, investigation and forensics, process management, and performance measurement, each of which is described in detail below.

0022The alert management function of the Risk Application 104 includes highly accurate risk score alerts that use adjustable thresholds to pinpoint only the most suspicious activity, isolating compromised accounts. High fidelity scoring allows fraud teams to optimize their time and effort by ensuring the right investigative priorities. This intuitive, actionable information focuses anti-fraud efforts.

0023The investigation and forensics function of the Risk Application 104 provides visual tools to scrutinize suspicious events with sophisticated investigation tools. The application returns session-specific context and detailed customer history to aid investigation. It detects coordinated attacks, correlating activity across accounts. Other business operations can leverage detailed account histories and customer activity to aid in the risk assessment of offline transactions.

0024The process management function of the Risk Application 104 includes case management tools that allow investigators to track any incident, manage related workflows, and analyze fraud case histories on an individual or aggregate basis.

0025The performance measurement function of the Risk Application 104 measures and reports on the effectiveness of fraud controls trended over time, increasing the risk management organization's understanding of risk levels. Metrics track risk trends, aggregate analysis across accounts, and aid compliance directives with auditable results.

0026The FPS of an embodiment is used to prevent one or more of online fraud, off-line fraud, and multi-channel fraud. As one example, <figref idref="f0002"><b>Figures 2A</b></figref><b>and</b><figref idref="f0003"><b>2B</b></figref> show a block diagram of FPS integration with an online banking application, under an embodiment. In this example, the Risk Engine 202 is coupled to the online banking application 210 using a real-time application programming interface (API) 212 and/or one or more applications (e.g., authentication, risk assessment, fraud detection and alert, investigations, compliance reporting, performance measurement, etc.) as appropriate to a configuration of the Risk Engine 202 and/or the online banking application 210. The FPS can be integrated with the online application 210 through a real time feed of event information or by processing log files that contain event information. As described above, the Risk Application 204 (labeled as the Fraud Application 204 in this example) functions to perform one or more of alert management, investigation and forensics, process management, and performance measurement, to name a few.

0027The user or "consumer" 220 in this example logs in to the online banking system 210 and uses the online banking system 210 to perform events (e.g., check account balance, view check images, transfer funds, etc.) in his/her account. The FPS comprises a risk engine 202 coupled to a risk application 204, as described herein. The risk engine 202 is a real-time event processor that receives data of user events or a set of events. The risk engine 202 also stores the user account model for the particular user. The risk engine 202 calculates a risk score using the event data and the user account model. The risk engine 202 uses the risk score and details of the observed event to update the user account model, and stores the updated user account model for use in evaluating the next subsequent set of event data (of a session) of the user. The risk engine 202 also transfers the risk score to the online banking application 210. The risk application 204 also provides alerts and allows authorized personnel to perform correlations, reporting, and investigations using the event data

0028Regardless of physical system configuration, the FPS functions to detect and prevent fraud using behavior-based models that correspond to a particular user's behavior. As one example, <figref idref="f0004"><b>Figure 3</b></figref> is a flow diagram for a method 300 of predicting expected behavior using the FPS, under an embodiment. Operations begin by dynamically generating 302 a causal model corresponding to a user. Components of the causal model are estimated 304 using event parameters of a first set of events undertaken by the user in an account of the user. Expected behavior of the user is predicted 306 during a second set of events using the causal model.

0029The FPS is configured and functions to prevent online fraud, off-line fraud, and multi-channel fraud. More specifically, the online fraud and off-line fraud includes account takeover fraud, which is when someone steals the account access credentials (username, password, PIN, etc.) of a user or account owner and then masquerades as that user and accesses account Multi-channel fraud includes all channels through which a user interacts with his/her bank or accesses bank accounts (e.g., ATM, call center, live branch visit, etc.). An example of multi-channel fraud is when someone steals account access credentials, accesses the account online and changes profile information or gets information about the account owner (eg., account balances, account numbers, signature from check images, etc.), and then commits fraud via other channels (check fraud by forging signature) using information gained via account access. This is an example where the financial fraud occurs off-line, but it started online with fraudster accessing user's account using stolen access credentials.

0030An event as used herein comprises an online event, an offline event, and/or a multiple-channel event. Consequently, the first set of events comprises at least one of online events, offline events, and multiple channel events. The second set of events comprises at least one of online events, offline events, and multiple-channel events. The online events are events that can be undertaken via electronic access to the account.

0031For online events, an online event comprises one or more of a login event and an activity event. A set of events comprises a session, and a session is a sequence of related events. The sequence of related online events comprises a session login event and a termination event, and can include one or more activity events.

0032For offline events, an offline event comprises one or more of an account access event and an activity event. A set of events comprises a session, and a session is a sequence of related events. The sequence of related online events comprises an account access event and a termination event, and can include one or more activity events.

0033Multi-channel events include online and offline events. Therefore, multi-channel events include one or more of a login event, an account access event, and an activity event.

0034As another example of FPS operation, <figref idref="f0004"><b>Figure 4</b></figref> is a flow diagram for a method 400 of predicting expected behavior of an account owner using the FPS, under an embodiment. Operations begin by receiving 402 observations corresponding to a first event. The first event of an embodiment includes actions taken in an account during electronic access of the account. Probabilistic relationships are generated 404 between the observations and derived behavior parameters of an owner of the account. Operations continue by generating 406 an account model to include the probabilistic relationships, and estimating 408 actions of the owner during a second event using the account model.

0035As yet another example of FPS operation, <figref idref="f0005"><b>Figure 5</b></figref> is a flow diagram for a method 500 of determining the relative likelihood a future event is performed by the user versus the fraudster using the FPS, under an embodiment. Operations begin by automatically generating 502 a causal model corresponding to a user. Generating the causal model comprises estimating components of the causal model using event parameters of a previous event undertaken by the user in an account of the user. Operations continue by predicting expected behavior 504 of the user during a next event in the account using the causal model. Predicting the expected behavior of the user includes generating expected event parameters of the next event. Operations continue by generating fraud event parameters 506 using a predictive fraud model. Generating the fraud event parameters assumes a fraudster is conducting the next event, the fraudster being any person other than the user. Operations continue by generating a risk score 508 of the next event using the expected event parameters and the fraud event parameters. The risk score indicates the relative likelihood the future event is performed by the user versus the fraudster.

0036<figref idref="f0006"><b>Figure 6</b></figref> is a flow diagram for using the FPS to generate warnings 600 of possible fraudulent activity, under an embodiment. Operations begin by generating a predictive user model 602 corresponding to a user. The predictive user model 602 includes numerous probability distributions representing event parameters observed during a first event in an account of the user. Predicted event parameters 604 are generated using the predictive user model 602. The predicted event parameters 604 are expected to be observed during a second event 624 in the account, where the second event follows the first event in time. Generation of the predicted event parameters 604 includes generating a first set of predicted probability distributions that represent the predicted event parameters under an assumption that the user is conducting the second set of online events.

0037A second set of predicted probability distributions is generated using a predictive fraud model 612. The second set of predicted probability distributions represents expected fraud event parameters 614 and assumes a fraudster is conducting the second set of online events, where the fraudster is any person other than the user. A comparison 634 is made between actual event parameters of the second event 624 to the predicted event parameters 604 and 614 during the second event, and a warning 606 generated when the actual event parameters 624 appear to be initiated by a person other than the user. The warning 606 comprises generating a risk score using information of the predicted event parameters 604, but the embodiment is not so limited. The user model 602 is updated 644 using information of the event parameters of the second event 624.

0038Conventional fraud detection is based on pre-specified rules, identified fraud patterns, or taking known fraud and processing it using supervised learning techniques, as described above. Conventional fraud detection is ineffective, in online fraud for example, because online fraud is very dynamic and technology development for conducting fraud is very dynamic and constantly changing. Also, activity associated with online fraud often does not look suspicious (e.g., viewing account information, check images, etc.). This makes it very difficult to craft rules to detect fraud because fraud can be very subtle and is constantly changing.

0039As opposed to attempting to determine exactly what fraud looks like or to precisely model fraud and then compare this model to a normal (average) user, embodiments of the FPS described herein instead analyze each individual user and the exact behavior of that user. This is more effective because the behavior of each user is a very small subset of the behavior included in a modeling of average behavior of many different users. Thus, the particular online banking activities or behavior typically observed in a single user (e.g., login from Palo Alto, California, login using a particular computer, login using a particular internet service provider (ISP), perform same types of activities (e.g., look at account balance, view check images, etc.)) can be used to establish an online behavior model of the user which is very specific and unique to each particular user. This makes fraud easier to detect because the fraudster does not know how the user behaves online so it is very difficult for the fraudster to appear like the account owner.. Notably, what may be normal for an "average" user may be very unusual for a specific user. Of equal importance, even behavior that might be considered "unusual" for the "average" user may be very normal for a particular individual. Both of these cases are therefore very distinctive and useful in distinguishing between legitimate and fraudulent activity.

0040The FPS uses a predictive model of each individual user to detect online fraud This real-time or dynamic predictive modeling, also referred to herein as Dynamic Account Modeling, is an application running on or under the Risk Engine of an embodiment. Exact behavior of the fraudster becomes less important using this approach because the analysis focuses more on the types of things users generally do instead of detecting specific known fraud patterns. Unlike a system in which fraud data of previous fraud activities is used to train a system or to generate rules, the FPS does not require rules or training. Thus, the FPS can detect new types of fraud even though this new fraud may not have been seen before because it is based on the user's online behavior. This results in high detection rates and low false alarm rates.

0041Generally, the FPS uses two types of models in preventing fraud. The FPS models behavior of a specific user through a predictive user model (PUM) that is used to calculate the probability of an observed event given the specific user. The FPS models behavior of fraudsters through a predictive fraud model (PFM) that is used to calculate the probability of an observed event given a fraudster. The probabilities are then used to calculate a risk score for a next occurrence of the event to which the probabilities correspond.

0042The models of the FPS described herein are supported using two hypotheses for each event: a first hypothesis assumes the observed event is by the real user associated with the specific account, and the second hypothesis assumes that the observed event is performed by a fraudster. An event includes, for example, an account login, and/or any particular activity taken in the account while logged into the account. Each event includes a set of parameters including, but not limited to, IP address and identification data of the computer used during the event to name a few.

0043The FPS generates and maintains the PUM, a specific causal model for each user, under the first hypothesis, and then uses the PUM to predict the expected actions of that individual user to which the model corresponds. The FPS generates the PUM for a user by estimating a probability function of a user based on previous user activity and also a normal expectation of how users behave. The FPS starts with a generic "normal" user activity model when no prior activity information is available for a user. As activity data is gathered for the user from events or activities taken by the user, parameters of the user model are estimated over time based on gathered observations of the user so that, at any point in time, an accurate PUM is available for a user. The PUM is thus developed recursively over time. User events are scored as they happen, and this provides a risk score for an event. Event parameters are then used to update the user model, and the updated user model is used to determine a risk score for the next subsequent user event

0044The PUM is built based on observed behavior of the user along with a statistical analysis of users in general. The structure of the PUM is pre-formulated so that there is no requirement to discover the structure of the model but rather to estimate unknown parameters of the model. The PUM development uses a causal model, represented or formulated in an embodiment as a Bayesian network, that relates (probabilities of) real-world derived parameters (e.g., location of the user (country, state, city), type of computer being used for the event, activities detected during an online session) to observable parameters of the session (e.g., IP address, HTTP header information, page views, etc.). The IP address provides an estimate of location information like country, state, city, network block, and internet service provider. The HTTP header provides information of the operating system (OS), user agent string, referrer string, and browser type of a computer used for an event. Therefore, the behavior of each user can be modeled using probability distributions of observable parameters of sessions and events of the user. The Bayesian network is decomposed into individual parameters and the relationships between the parameters. Distributions and conditional distributions are based on prior, observed data, "new mode" probability models, etc.

0045The user is related to the actual observable parameters (including time, IP address, browser, OS, etc.) corresponding to an event. The FPS uses a causal model based on user's observed behavior to predict future behavior. The PUM is therefore the structure formed by the real world parameters used or selected, the observed event parameters and the relationships between the real world parameters and observed event parameters.

0046The use of the causal model for specific users allows the FPS to detect fraudulent activity and events without the need for specific known rules, patterns, and/or indicators and without the need for training data of known fraud cases. Therefore, the FPS can detect all fraud, both known and unknown, including fraudulent activity that has never before been seen.

0047A PFM is generated under the second hypothesis of an embodiment. The PFM generally uses all other session or event data of all other online account holders who are not the user. This data is used to generate a probability of users at large. These probabilities can then be adjusted using known information of prolific fraudsters (e.g., that the rate of fraud coming from Nigeria is ten times higher than other (low-risk) countries), but this is not necessary. This is different from conventional fraud systems, which rely on information about fraud through the use of new and/or additional rules, indicators or patterns. In contrast, the FPS uses at large online activity to develop the PFM, a causal model that represents fraudsters (everyone not a particular account owner), and then adjusts the probabilities or expectations of the PFM based on how fraudsters behave. Thus the FPS is unique in how it incorporates information of fraudulent activities.

0048The models of an embodiment include the PUM, which is a joint probability distribution, as described above. The PUM is a causal model. The net effect or result of the PUM is a probability of the observed parameters or event given the specific user to which the PUM corresponds. The PUM is therefore a predicted probability distribution of event parameters for the next event given the specific user to which the PUM corresponds.

0049The FPS models also include the PFM, as described above, which is a joint probability distribution. The PFM is also a causal model. The net effect of the PFM is a probability of the observed parameters or event given a fraudster. The PFM is therefore a predicted probability distribution of event parameters for the next event given fraud.

0050A risk score is calculated for a next event using the results of the PUM and PFM. The next event is an event or action taken in a user's account that appears to be initiated or taken by the account owner. The risk score of the next event is determined or calculated by taking the probability of the observed event given fraud, as determined using the PFM, and dividing it by the probability of the observed event given the specific user, as determined using the PUM. The risk score can be used to generate alerts or warnings for the next event.

0051The FPS uses recursive model building to generate the PUM. The PUM does not represent the full detail of every event ever seen in the account of the user but, instead, it includes individual probability distributions for each of a number of particular parameters of one or more observed events. Each probability distribution of an observed parameter is a statistical distribution for the parameter over the observed events corresponding to the account. The individual probability distributions for the parameters are combined to form a joint probability distribution that is the PUM.

0052Generally, the PUM is generated by collecting event data in the form of observed parameters and, after each event, the PUM for the user to whom the events correspond is updated based on the observed parameters. The PUM then allows for propagation of the distribution of observed event parameters into a distribution of behavior event parameters, where the propagation includes the distribution of the observed parameters plus the prior model.

0053An example of model use begins with someone, either a user or fraudster, initiating an observed event. An observed event includes, for example, someone logging in to the user's account and/or any activity taken during an online session (e.g., checking account balance, transferring funds between accounts, viewing account information, etc.). The observed event may or may not be an online event. Each event includes or corresponds to one or more event parameters. Event parameters are directly observable parameters, or raw data that can be measured or observed, of an event. Examples of event parameters include, but are not limited to, network information that includes parameters of the network by which an online event is occurring (e.g., IP address, etc.) (country, state, city are derived parameters derived from network information; this is implied information in contrast to actual observed data of an event), user agent string (OS and browser of device or computer used for the event are derived parameters derived from user agent string; this is implied information in contrast to actual observed data of an event), and event or session time (timestamp), to name a few.

0054The models (e.g., PUM and PFM) of an embodiment are used to predict the actual observed event parameters for the next event given the model of the user's behavior during past events. Derived parameters, which are not directly observable, are then derived or propagated from the PUM and the observable parameters. Examples of derived parameters include, but are not limited to, geographic location (e.g., country, state, city, etc.) of user at time of event, device being used for event (e.g., device type/model, device OS, device browser, software applications, etc,), internet service provider (ISP), and user's local time of day of event, etc. The causal model of an embodiment includes probability relationships between derived parameters and event (observable) parameters, and probability relationships between different derived parameters. An example of relationships between parameters can be that the country of the user (event parameter) can relate to the ISP (derived parameter), and the ISP can relate to a particular set of IP addresses (event parameter).

0055The causal model of an embodiment is represented as a Bayesian network (BN). The BN of an embodiment uses or includes conditional probability distributions to model or represent the relationships between parameters (relationship between different derived parameters, relationship between event parameters and derived parameters, etc.). The BN, as embodied in the PUM, is or represents the distribution of the derived parameters, the distribution of observed parameters and the relationships between the observed and derived parameters. The result output from the PUM is a predicted distribution of expected event parameters of a next event. The distribution of the expected event parameters is used to calculate the risk score. The PUM is generated as described below.

0056The PUM is used to predict the event parameters of the next event. The predicted event parameters include the predicted probability distribution of what might be observed during the next event. The PUM therefore generates the predicted distribution of the event parameters for the next event. The next event is then observed and information of the observed event parameters is collected or received. Given the observed event parameter values (e.g., actual IP address), and the predicted probability distribution of all possible IP addresses that might be used (from the PUM, probability of the actual IP address given the user), the result is the probability of a specific observed event parameter (e.g., IP address) given the PUM. This is performed across all parameters.

0057The causal model of an embodiment therefore generates the likelihood of observing the observed parameter values given the current PUM (i.e., predicted distribution as defined by the PUM), and generates the likelihood of observing the observed parameter values given the current PFM (i.e., predicted distribution as defined by the PFM). The risk score is then calculated using these results, as described above.

0058As described herein, the PUM is generated by collecting event data in the form of observed parameters and, after each event, the PUM for the user to whom the events correspond is updated based on the observed parameters. The PUM then allows for propagation of the distribution of observed events into a distribution of behavior events, where the propagation includes the distribution of the observed parameters plus the prior model.

0059The update process updates the distribution of one or more observed parameters in the PUM to produce an updated PUM. The updated PUM therefore includes an updated expectation of one or more observed parameters in the form of an updated probability distribution relating to specific observed parameters. As an example, because a particular parameter (e.g., IP address (observed) in the US (location, derived parameter)) has been observed being used by the user during an event, this information is propagated back into the PUM to update the corresponding distribution so that, during the next subsequent event, there is a higher expectation that the same or similar parameter (IP address in the US) will be seen in the next event.

0060The model is updated periodically using actual observed event parameters since the last update of the model The joint probability distribution of an embodiment is updated by updating the probability distributions for each observed parameter included in the model The model update process of an embodiment is recursive and takes into account the last observed event, the previous user model (i.e., PUM), and the prior user model to name a few The previous user model includes the PUM that was current for as of the last or most recent observed event. The prior user model includes the predicted probability distribution (i.e., PUM) before any events have been observed.

0061The model update process includes two alternatives. In a first embodiment of the update process, data of the current observed event is used to update the previous user model, and the prior user model is considered to be embedded in the previous user model and thus updated as part of the recursive process that updates the prior user model in response to each occurrence of an observed event.

0062In a second embodiment of the update process, the update process maintains an observed frequency distribution for each observed event parameter. Consequently, instead of updating the previous user model, each event parameter probability distribution is updated using data of the current observed event. The updated observed frequency distribution for each event parameter is then integrated with the prior user model to generate the updated PUM.

0063The probability distributions included in the prior model can initially be adjusted, prior to receiving any observed event data of the user, using general statistical information about users at large and/or data of the specific user collected from the user or from the user's account profile. For example, the probability distributions can be adjusted using uniform probability distributions. The probability distributions can also be adjusted using probability data corresponding to residence information of the user (e.g., US resident, and 1% of US residents use particular block of IP addresses). Furthermore, the probability distributions can be adjusted using financial institution data of the user (e.g., user is XYZ Bank customer, and 95% of XYZ Bank customers are in the US).

0064The fraud model (i.e., PFM) of an embodiment is similar to the PUM in that it is a predictive distribution based on observed parameters and derived parameters of events. This is in contrast to conventional rule-based systems that use specific indicators (rules) relating to fraud. The rules can be weighted, however, a weighting is not a probability distribution so these systems have absolutely nothing in common with the embodiments described herein.

0065<figref idref="f0007"><b>Figure 7</b></figref> shows the difficulties and limitations of using conventional fraud techniques 702 (fraud knowledge 702) applied to activities of a user 704 (normal user 704) under the prior art. These conventional techniques, as described above, can detect some known fraud events 710 and 712, but can allow real fraud events 720 to go undetected while generating many false positives for events 730 and 732 that are not fraudulent activity, in contrast, <figref idref="f0008"><b>Figure 8</b></figref> shows the use of dynamic account modeling 701 applied to activities of a user, under an embodiment. The dynamic account modeling 701 applies a predictive model 701 of the specific user against event activities of the user's account and, in so doing, detects previously hidden fraud 720 and reduces false alarms for events 730 and 732 that are not fraudulent activity.

0066The FPS of an embodiment includes a graphical interface for a user's account that shows account activity along with corresponding parametric data. The graphical interface is also referred to herein as an analytical user interface (AUI). The AUI displays for any event in the account at least one of the risk score and the event parameters, to name a few functions The AUI comprises a horizontal axis representing time and a vertical axis representing the event parameters. The event parameters, as described above, include one or more of Internet Protocol (IP) data and Hypertext Transfer Protocol (HTTP) data. The IP data includes one or more of an IP address, IP address country, IP address city, IP network block, and internet service provider supporting an event. The HTTP data includes one or more of data of an operating system, a user agent string, a referrer string, and internet browser of a computer used for an event.

0067The AUI includes numerous columns, and each column represents at lease one event conducted in the account The columns of an embodiment are arranged according to date. The AUI also includes numerous rows, and a set of rows represent event parameters of the events. Considering the rows and columns, the AUI includes numerous intersection regions, and each intersection region is defined by an intersection of a row and a column. The intersection region corresponds to an event parameter of at least one event. Furthermore, the intersection region includes color coding relating the event parameter to a corresponding probability of the account model. The color coding represents a relative likelihood ratio that the event parameter corresponds to the user.

0068The AUI also includes a risk row representing risk of the events. Each intersection region defined by the intersection of the risk row with a column corresponds to the risk score of at least one event corresponding to the column. The intersection region includes color coding relating the risk score to at least one event The color coding represents a relative likelihood ratio that the user conducted the event.

0069<figref idref="f0009"><b>Figure 9</b></figref> is an example screen 800 of the AUI, under an embodiment. One type of AUI screen includes one or more information portions 802-804 along with a graph portion 806. The graph portion 806 of the AUI includes a horizontal axis 810 and a vertical axis 812. The horizontal axis 810 represents time (e.g., date). The horizontal or time axis 810 can be modeled as weekdays and weekends, and each day can be subdivided by morning, afternoon, evening, for example, but the embodiment is not so limited. The vertical axis 812 of the AUI represents categories of parameters (e.g., country, city, state, internet service provider, network, IP type, etc.) along with all different parameter values historically observed for the user's activity in a category. Each column 820 of the AUI represents a user login event or user session organized by date. The AUI includes a color-coded bar 870 in a region of the display, and the color-coded bar is an overall risk column for the user to whom the display corresponds.

0070The AUI displays a color coding (e.g., red 830, yellow 832, green 834, etc.) representing thresholds corresponding to the component risk scores of each parameter of an event. The FPS models behavior, as described above, based on the fact that as more data is received tying a particular user to a particular parameter value (e.g., 98% of logins by Jane Doe are in US), it determines a probability that this particular parameter will be different for the particular user (e.g., what is the probability that Jane Doe logs in from Mexico). The predicted probability distribution of the model parameters become much tighter or narrower as more event data is collected from the user, and the colors displayed on the AUI relate to each parameter of the event and the relative model probabilities (fraud versus user) corresponding to that parameter.

0071For example, for event 840. the parameters for country (United States 841), City, State (Vienna, Virginia 842), provider (AOL 843), and IP Type (proxy 844) can be coded green to show a high probability under the dynamic account modeling that the account owner is initiating the event. In contrast, for event 840 the parameters for country (Germany 851) and City, State (Frankfurt 852) can be coded red for an event to show a low probability under the dynamic account modeling that the account owner is initiating the event, while the parameters for provider (AOL 843) and IP Type (proxy 844) can be coded green for the same event to show a high probability under the dynamic account modeling that the account owner is initiating the event

0072The information portions 802-804 of the AUI can be used to display a variety of parameters or data as appropriate to the FPS and any integrated application For example, the AUI can display underlined parameter values 860 having an underline color (e.g., red, yellow, green, etc.) that correlates with the amount of risk associated with that particular parameter (e.g., Virginia (state) and Vienna (City) have a red underlining to indicate high probability of fraudster activity).

0073The adaptive nature of the FPS model is especially useful in situations where, for example, a user may travel frequently so that the parameters are frequently changing The FPS dynamically adapts to this behavior so that the behavior is not consistently flagged as fraud, as would happen under conventional rule-based systems. Therefore, the model adapts over time using data that shows particular behavior (e.g., user in Denver) has been observed from a user (e.g., user logs in from Denver), so what is the probability that the same behavior (e.g., user logs in from Denver in a subsequent event) will be observed in the future from the same user.

0074<figref idref="f0010"><b>Figure 10</b></figref> shows a variation of the example screen (<figref idref="f0009">Figure 9</figref>) of the AUI, under an embodiment. Referring to this example screen, information from all related activity events from the same online session is shown on the timeline within the same column 1001 that represents the session. Summary information about what types of activities occurred in each session are indicated by a color coded bar 1002. The color, Red, Yellow or Green indicates the associated risk for the activities of that type for that particular session. On the same screen, detailed information about each activity within the selected session can also be shown in one or more information boxes or regions 1003 of the AUI.

0075If suspected fraudulent activity is indicated by the FPS, the Risk Application allows an analyst to perform a fraud match. The fraud match of an embodiment allows the analyst to search for other sessions across all institutional accounts having similar characteristics (e.g., sessions originating from Mexico, sessions with provider AOL, etc.) in an attempt to identify other instances of fraud.

0076The FPS fraud match enables a comparison between data of one session and all other data of an institution in order to identify all sessions having one or more similar parameters. Thus, institutions can use the fraud match function to identify other suspicious sessions with parameters that are similar or the same (e.g., ISP, country, machine, etc.) as a suspected fraud attack.

0077The FPS therefore can provide a risk assessment based on the overall activity of all users within an institution over a specified period of time (e.g., day, multiple days, week, etc.) in order to help the institution determine if it is under attack This is a fundamental difference in the FPS when compared to conventional systems, because the FPS takes a risk management approach versus the approach of conventional systems, which is to try and stop all fraud.

0078All features of the FPS work together to allow a financial institution, for example, to understand fraud instead of attempting to make a prefect binary decision on whether to block a transaction as fraud, which is futile. The FPS recognizes that the importance is to understand fraud so that fraud can be recognized earlier using observable parameters (related or translated to derived parameters) and losses minimized versus trying to block any suspicious activity, which if done imperfectly only leads to customer dissatisfaction and inconvenience when non-fraudulent transactions are flagged as fraudulent based on conventional rules-based approaches. From a risk management perspective, the fraud match application allows an institution to look at all data collected over time according to one or a defined set of criteria in order to see an overall percentage of fraudulent activity related to the criteria. This allows smarter decisions to be made, for example, because knowing that a very high percentage of traffic with a certain ISP is not fraudulent might prevent a decision to block all traffic from the ISP based on a high occurrence of fraudulent activity in a recent period of time.

0079The FPS components described herein (e.g., Risk Engine, Risk Application, Dynamic Account Models, etc.) can be components of a single system, multiple systems, and/or geographically separate systems. The FPS components can also be subcomponents or subsystems of a single system, multiple systems, and/or geographically separate systems. The FPS components can be coupled to one or more other components (not shown) of a host system or a system coupled to the host system

0080The FPS of an embodiment includes and/or runs under and/or in association with a processing system. The processing system includes any collection of processor-based devices or computing devices operating together, or components of processing systems or devices, as is known in the art. For example, the processing system can include one or more of a portable computer, portable communication device operating in a communication network, and/or a network server. The portable computer can be any of a number and/or combination of devices selected from among personal computers and other processor-based devices, but is not so limited. The processing system can include components within a larger computer system.

0081The processing system of an embodiment includes at least one processor and at least one memory device or subsystem. The processing system can also include or be coupled to at least one database. The term "processor" as generally used herein refers to any logic processing unit, such as one or more central processing units (CPUs), digital signal processors (DSPs), application-specific integrated circuits (ASIC), etc. The processor and memory can be monolithically integrated onto a single chip, distributed among a number of chips or components of the FPS, and/or provided by some combination of algorithms. The FPS methods described herein can be implemented in one or more of software algorithm(s), programs, firmware, hardware, components, circuitry, in any combination.

0082The FPS components can be located together or in separate locations Communication paths couple the FPS components and include any medium for communicating or transferring files among the components. The communication paths include wireless connections, wired connections, and hybrid wireless/wired connections. The communication paths also include couplings or connections to networks including local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), proprietary networks, interoffice or backend networks, and the Internet. Furthermore, the communication paths include removable fixed mediums like floppy disks, hard disk drives, and CD-ROM disks, as well as flash RAM, Universal Serial Bus (USB) connections, RS-232 connections, telephone lines, buses, and electronic mail messages.

0083Following is a description of a fraud analysis example generated by the FPS using actual data of an account owner of a financial institution. The example is presented only to help describe operation of the FPS and are not intended to limit embodiments of the FPS to only the scope of these examples.

Fraud Analysis Example

0084<figref idref="f0011"><b>Figure 11</b></figref> is an example AUI showing normal use behavior for a user, under an embodiment. This is a frequent user and he/she logs in a few times a week. The normal behavior of this user consists of two normal patterns: (1) access from the San Francisco Bay Area using SBC/PacBell with a single machine, and (2) occasional access from an organization called DSS.MIL (which is a government organization) using another machine.

0085In this example, the FPS is configured only to process Login Attempts (i.e., the information whether a login succeeded or failed is not available to the system nor is other activities that occur within a single online session). For readability the AUI displays a separate User Name (user_26201) which is a generated for the account identifier string above.

0086On 4/2/2007 (column adjacent marker or slide bar 1102) there were 2 RED alerts for this user.

0087<figref idref="f0012"><b>Figure 12</b></figref> is an example AUI showing a first RED alert for an account event 1202, under an embodiment An attempted login occurred from Network Block 70.9.83.0 using a provider "spcsdns.net" via a proxy located in Indiana. Upon further investigation, it is believed that this network is operated by Sprint Mobile Broadband and that the IP address is a proxy which may hide the true location of the user (i.e., the user may not be in Indiana). The attempt was from a new OS (Vista) that had not been seen from this user. The login was at 04/02/2007 11:57 PM GMT, or 04/02/2007 06:57 PM Indiana Time.

0088<figref idref="f0013"><b>Figure 13</b></figref> is an example AUI showing a second RED alert for an account event 1302, under an embodiment. The second Red alert occurred approximately 2 hours after the first RED alert, and was an attempted login from Network Block 70.9.83.0 using a provider Comcast from Miami, Florida. In this case the Browser (Firefox) was different from any previous session from this user. The login was on Tue 04/03/2007 01:45 AM GMT, or Mon 04/02/2007 08:45 PM Miami Time.

0089<figref idref="f0014"><b>Figure 14</b></figref> is an example AUI showing additional information for account activity 1402, under an embodiment. This activity occurred eight hours later and was a sequence of four login attempts (probably failed logins) from what appears to be the real account holder. It was also noted that on March 21 a user (probably the real user) logged in from a Hilton Hotel in Pheonix; there is probably no reason to relate this to the fraud situation, but it may be worth noting for future reference.

0090The FPS Fraud Match was used to search for other similar user sessions. <figref idref="f0015"><b>Figure 15</b></figref> is an example AUI showing the Fraud Match view, under an embodiment A search was performed for other user sessions using the Comcast network block 67.191.79.0. The only sessions identified were as follows: the five sessions from a previous fraud case; one session from this fraud case; and the additional session corresponding to the first RED alert.

0091<figref idref="f0016"><b>Figure 16</b></figref> is another example AUI showing the results obtained in the Fraud Match View plotted over time, under an embodiment. The ability to perform various analyses of related events provides unique insight. In this example, the timeline view allows the analyst to determine if the related suspicious activity is changing over time (perhaps as a result of a wide spread fraud attack).

0092A detailed description of the dynamic account modeling follows.

Risk Based Hypothesis Test

0093A Bayesian Network is a well known representation of a probabilistic model that represents a set of variables and their probabilistic independencies as a graph of nodes (parameters) and edges (dependent relations). Bayesian Hypothesis Testing is a well known technique that can determine the optimal decision criteria for discriminating between two or more possible hypotheses given a set of observed data and known probability models for each hypothesis.

0094The Account Holder (User) is the real world person that owns the online account. In the case of ID Theft, a Fraudster is defined herein as any person other than the Account Holder. Mathematically, two hypotheses are: <ul id="ul0002" list-style="bullet" compact="compact"><li>H₀ = The observed event (for example, a login event) was generated by the Account Holder (aka User)</li><li>H₁ = The observed event (for example, a login event) was generated by someone else (i.e., a Fraudster)</li></ul>

0095If the true conditional probability was known by observing the current event given that the event was generated by the real User and conditional probability that the event was generated by a Fraudster, the optimal fraud / non-fraud decision statistic is the <i>relative likelihood ratio <b>L</b></i> as defined by <maths id="math0001" num="(0.1)"><math display="block"><mrow><mi>L</mi><mfenced><mi mathvariant="italic">Event</mi></mfenced><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><mi mathvariant="italic">Fraudster</mi><mo>|</mo><mi mathvariant="italic">Event</mi></mfenced></mrow><mrow><mi>P</mi><mfenced><mi mathvariant="italic">User</mi><mo>|</mo><mi mathvariant="italic">Event</mi></mfenced></mrow></mfrac><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><mi>F</mi><mo>|</mo><mi>E</mi></mfenced></mrow><mrow><mi>P</mi><mfenced><mi>U</mi><mo>|</mo><mi>F</mi></mfenced></mrow></mfrac><mn>.</mn></mrow></math><img file="EP3553713A1_D0001.tif" /></maths>

0096Using Bayes Rule, Equation (0.1) can be rewritten as: <maths id="math0002" num="(0.2)"><math display="block"><mrow><mi>L</mi><mfenced><mi>E</mi></mfenced><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><mi>E</mi><mo>|</mo><mi>F</mi></mfenced><mi>P</mi><mfenced><mi>F</mi></mfenced></mrow><mrow><mi>P</mi><mfenced><mi>E</mi><mo>|</mo><mi>U</mi></mfenced><mi>P</mi><mfenced><mi>U</mi></mfenced></mrow></mfrac><mo>,</mo></mrow></math><img file="EP3553713A1_D0002.tif" /></maths> and, alternatively as: <maths id="math0003" num="(0.3)"><math display="block"><mrow><mtable columnalign="left" width="auto"><mtr><mtd><mi>L</mi><mfenced><mi>E</mi></mfenced><mo>=</mo><mi mathvariant="italic">ρλ</mi><mfenced><mi>E</mi></mfenced></mtd></mtr><mtr><mtd><mi mathvariant="italic">where</mi></mtd></mtr><mtr><mtd><mi>λ</mi><mfenced><mi>E</mi></mfenced><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><mi>E</mi><mo>|</mo><mi>F</mi></mfenced></mrow><mrow><mi>P</mi><mfenced><mi>E</mi><mo>|</mo><mi>U</mi></mfenced></mrow></mfrac><mo>,</mo><mspace width="1em" /><mi mathvariant="italic">and ρ</mi><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><mi>F</mi></mfenced></mrow><mrow><mi>P</mi><mfenced><mi>U</mi></mfenced></mrow></mfrac><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><mi>F</mi></mfenced></mrow><mrow><mn>1</mn><mo>−</mo><mi>P</mi><mfenced><mi>F</mi></mfenced></mrow></mfrac></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0003.tif" /></maths>

0097The following apply in the above equations: <ul id="ul0003" list-style="bullet" compact="compact"><li><i>P</i>(<i>E</i> | <i>F</i>) is the <b><i>Fraud Model</i></b>, which is the expectation of observing the parameters of Event <i>E</i> given that the Event was caused by a Fraudster (someone other than the User)</li><li><i>P</i>(<i>E</i> | <i>U</i>) is the <b><i>User Model</i></b>, which is the expectation of observing the parameters of Event <i>E</i> given that the Event was caused by the real User</li><li><i>P</i>(<i>F</i>) is the <i>Prior Probability of <b>Fraud</b></i> (aka, the <b><i>apriori Fraud Expectation</i></b>), which is the prior probability that an Event would be caused by a Fraudster (without knowing anything else about the Event)</li><li><i>P</i>(<i>U</i>) is the <b><i>Prior Probability of the User</i></b> (aka, the <b><i>apriori User Expectation</i></b>), which is the prior probability that an Event would be caused by a Fraudster (without knowing anything else about the Event)</li></ul>

0098The Prior Probabilities and hence <i>ρ</i> are constant if the Events are independent from each other. When this is the case, the impact of <i>ρ</i> can be ignored as any decision criteria on <i>L(E)</i> can be performed (with appropriate scaling) on the Decision Statistic <i>λ</i>(<i>E</i>) instead.

0099For example, <i>λ</i>(<i>E</i>) can be used as part of a binary decision process by introducing a threshold: <maths id="math0004" num="(0.4)"><math display="block"><mrow><mtable columnalign="left" width="auto"><mtr><mtd><mi>Decide Fraud</mi><mspace width="1em" /><mi mathvariant="italic">if λ</mi><mfenced><mi>E</mi></mfenced><mo>></mo><mi>τ</mi></mtd></mtr><mtr><mtd><mi>Decide User</mi><mspace width="1em" /><mi mathvariant="italic">if</mi><mspace width="1em" /><mi>λ</mi><mfenced><mi>E</mi></mfenced><mo>≤</mo><mi>τ</mi></mtd></mtr></mtable><mn>.</mn></mrow></math><img file="EP3553713A1_D0004.tif" /></maths> Alternatively, <i>λ</i>(<i>E</i>) can be used to rank a set of Events from high to low fraud risk

0100Often it is easier to work with the log likelihood ratio. The Risk of an Event is formally defined herein to be: <maths id="math0005" num="(0.5)"><math display="block"><mrow><mi>R</mi><mfenced><mi>E</mi></mfenced><mo>=</mo><mi>ln</mi><mfenced><mi>λ</mi><mfenced><mi>E</mi></mfenced></mfenced><mo>=</mo><mi>ln</mi><mfenced><mfrac><mrow><mi>P</mi><mfenced><mi>E</mi><mo>|</mo><mi>F</mi></mfenced></mrow><mrow><mi>P</mi><mfenced><mi>E</mi><mo>|</mo><mi>U</mi></mfenced></mrow></mfrac></mfenced></mrow></math><img file="EP3553713A1_D0005.tif" /></maths>

0101Then <i>R</i>(<i>E</i>) is used as a decision statistic in the same way as <i>λ</i>(<i>E</i>) or <i>L</i>(<i>E</i>) are used.

Predictive Models

0102The problem now becomes how to calculate <i>R</i>(<i>E</i>). And, more specifically, how to calculate the two conditional probabilities <i>P</i>(<i>E</i> | <i>F</i>) and <i>P</i>(<i>E</i> | <i>U</i>), In this case, a sequence of Events is observed associated with a User's Account with the <i>k</i>'th Observed Event designated as <i>E^k.</i> Also, knowledge of the User can be updated based on previous observations. This previously observed information about a User is denoted as <i>U</i>^<i>k</i>-1 such that <i>P</i>(<i>E</i> | <i>U</i>^<i>k</i>-1) represents the estimated User Model after observing the sequence of Events <i>E</i>¹...<i>E</i>^<i>k</i>-1. Thus, Equations (0.3) and (0.5) can be rewritten as: <maths id="math0006" num="(0.6)"><math display="block"><mrow><mtable><mtr><mtd columnalign="left"><mi>L</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mi mathvariant="italic">ρλ</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup></mfenced></mtd><mtd><mspace width="1em" /></mtd></mtr><mtr><mtd columnalign="left"><mi>ρ</mi></mtd><mtd columnalign="left"><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><mi>F</mi></mfenced></mrow><mrow><mn>1</mn><mo>−</mo><mi>P</mi><mfenced><mi>F</mi></mfenced></mrow></mfrac></mtd><mtd><mspace width="1em" /></mtd></mtr><mtr><mtd columnalign="left"><mspace width="1em" /></mtd><mtd columnalign="left"><mo>≈</mo><mi>P</mi><mfenced><mi>F</mi></mfenced></mtd><mtd><mi mathvariant="italic">for P</mi><mfenced><mi>F</mi></mfenced><mo>≪</mo><mn>1</mn></mtd></mtr><mtr><mtd columnalign="left"><mi>λ</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup><mo>|</mo><mi>F</mi></mfenced></mrow><mrow><mi>P</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mtd><mtd><mspace width="1em" /></mtd></mtr><mtr><mtd columnalign="left"><mi>R</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mi>ln</mi><mfenced><mi>λ</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup></mfenced></mfenced></mtd><mtd><mspace width="1em" /></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0006.tif" /></maths>

0103Note that in this model the Event Fraud Model <i>P</i>(<i>X^k</i> | <i>F</i>) and the a priori expectations of Fraud (and the User) are constant, i.e., they do not change based on observing the previous Events <i>E</i>¹...<i>E</i>^<i>k</i>-1<i>.</i>

0104In practice, the conditional probabilities are expressed in terms of actual observed data for the Event In this case the observed data is the set of parameters that the online application is able to collect about the Event (for example the <i>Client IP Address</i> and the <i>User Agent String</i> of the user's browser) at the time of the Event This represents the observed parameters (i.e., the Observed Data) for the by the vector <i>D^k</i> = [<i>X</i>,<i>Y</i>,...,<i>Z</i>], where each element represents one of the observed parameters.

0105The definitions of the Fraud and User Models can be represented as: <maths id="math0007" num="(0.7)"><math display="block"><mrow><mtable><mtr><mtd columnalign="left"><mi>P</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup><mo>|</mo><mi>F</mi></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mi>P</mi><mfenced><msup><mi>D</mi><mi>k</mi></msup><mo>|</mo><mi>F</mi></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mi>P</mi><mfenced><mi>X</mi><mo>,</mo><mi>Y</mi><mo>,</mo><mn>...</mn><mo>,</mo><mi>Z</mi><mo>|</mo><mi>F</mi></mfenced></mtd><mtd columnalign="left"><mo>≜</mo><mi>Fraud Model</mi></mtd></mtr><mtr><mtd columnalign="left"><mi>P</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mi>P</mi><mfenced><msup><mi>D</mi><mi>k</mi></msup><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mi>P</mi><mfenced><mi>X</mi><mo>,</mo><mi>Y</mi><mo>,</mo><mn>....</mn><mo>,</mo><mi>Z</mi><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mtd><mtd columnalign="left"><mo>≜</mo><mi>User Model</mi></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0007.tif" /></maths> Each of these is a <i>predictive model</i> over the observed parameters, one for the fraudster and one for the user. When calculating <i>λ</i>(<i>E^k</i>) and <i>R</i>(<i>E^k</i>) there is an interest in the ratio of these models which will be able to be used to an advantage in some real world cases.

0106For purposes of explanation, there are two directly observable parameters assumed: <ul id="ul0004" list-style="bullet" compact="compact"><li>X = The IP address associated with the HTTP session</li><li>Y = The User Agent String of the device used to access the application</li></ul>

0107Then for an observed event, <i>D</i> = (<i>IP Addr</i> = <i>x, UserAgent</i> = <i>y</i>) calculations are: <maths id="math0008" num="(0.8)"><math display="block"><mrow><mi>λ</mi><mfenced><mi>E</mi></mfenced><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><mi mathvariant="italic">IP Addr</mi><mo>=</mo><mi>x</mi><mo>,</mo><mrow><mspace width="1em" /><mi mathvariant="italic">User Agent</mi></mrow><mo>=</mo><mi>y</mi><mo>|</mo><mi>F</mi></mfenced></mrow><mrow><mi>P</mi><mfenced><mi mathvariant="italic">IP Addr</mi><mo>=</mo><mi>x</mi><mo>,</mo><mrow><mspace width="1em" /><mi mathvariant="italic">User Agent</mi></mrow><mo>=</mo><mi>y</mi><mo>|</mo><mi>U</mi></mfenced></mrow></mfrac></mrow></math><img file="EP3553713A1_D0008.tif" /></maths>

0108The problem is that these probabilities are typically unknown and in general difficult if not impossible to calculate in this form. Even if independence is assumed between the observed parameters this would be faced with simpler yet still intractable problem of computing the individual terms (or at least the individual ratios) of the resulting likelihood ratio: <maths id="math0009" num="(0.9)"><math display="block"><mrow><mi>λ</mi><mfenced><mi>E</mi></mfenced><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><mi mathvariant="italic">IP Addr</mi><mo>=</mo><mi>x</mi><mo>|</mo><mi>F</mi></mfenced><mi>P</mi><mfenced><mi mathvariant="italic">User Agent</mi><mo>=</mo><mi>y</mi><mo>|</mo><mi>F</mi></mfenced></mrow><mrow><mi>P</mi><mfenced><mi mathvariant="italic">IP Addr</mi><mo>=</mo><mi>x</mi><mo>|</mo><mi>U</mi></mfenced><mi>P</mi><mfenced><mi mathvariant="italic">User Agent</mi><mo>=</mo><mi>y</mi><mo>|</mo><mi>U</mi></mfenced></mrow></mfrac></mrow></math><img file="EP3553713A1_D0009.tif" /></maths>

0109This problem is solved by decomposing the probability into more manageable components. One way of doing this is to introduce the derived, real-world behavior parameters as described previously as a conditioning parameter. For example, <i>P</i>(<i>IP Addr</i> = <i>x</i> | <i>U</i>) could be reformulated as: <maths id="math0010"><math display="block"><mrow><mi>P</mi><mfenced><mi mathvariant="italic">IP Addr</mi><mo>=</mo><mi>x</mi><mo>|</mo><mi>U</mi></mfenced><mo>=</mo><mstyle displaystyle="false"><mrow><mstyle displaystyle="true"><mrow><munder><mo>∑</mo><mi mathvariant="italic">Country</mi></munder></mrow></mstyle><mrow><mi>P</mi><mfenced><mi mathvariant="italic">IP Addr</mi><mo>=</mo><mi>x</mi><mo>|</mo><mi>U</mi><mo>,</mo><mi mathvariant="italic">Country</mi><mo>=</mo><mi>y</mi></mfenced><mi>P</mi><mfenced><mi mathvariant="italic">Country</mi><mo>=</mo><mi>y</mi><mo>|</mo><mi>U</mi></mfenced></mrow></mrow></mstyle></mrow></math><img file="EP3553713A1_D0010.tif" /></maths> This approach of decomposing complex probability models into a more computationally feasible network of causally related parameters is key to the Dynamic Account Modeling approach. Once the models have been reformulated as a causal model, the Bayesian Network formalism allows for propagation of information through a network of related parameters. To simplify the following discussion, this will often focus on the case with only one observed parameter <i>X</i>. Extending this to a full Bayesian Network that represents the entire PUM as described herein by introducing conditional parameters and distributions.

The User Model

0110To facilitate explanation, a description follows of the underlying math for a class of parameters that have the characteristics of discrete (it can only take on well defined set of values), finite cardinality (there are a finite (the perhaps unknown) set of values), and categorical (each value is independent of other values, i.e., there is no explicit or implicit ordering or distance between values). Similar models can be developed for other parameter types (for example, continuous parameters) Similarly, extending to conditional parameters is also straight forward under the teachings herein.

0111A number of variables are described as follows: <ul id="ul0005" list-style="bullet" compact="compact"><li><i>U^k</i> designates the updated User Information (Model) after <i>k</i> Events have been observed</li><li><i>X</i>^<i>k</i>+1 is the observed parameter for Event <i>k</i> + 1 where <i>X</i> ∈ {<i>x</i>₁, <i>x</i>₂,...,<i>x_n</i>}</li></ul>

0112The predictive User Model (distribution) on <i>X</i>^<i>k</i>+1 is a vector: <maths id="math0011" num="(0.10)"><math display="block"><mrow><mi>P</mi><mfenced><msup><mi>X</mi><mrow><mi>k</mi><mo>+</mo><mn>1</mn></mrow></msup><mo>|</mo><msup><mi>U</mi><mi>k</mi></msup></mfenced><mo>=</mo><mi>P</mi><mfenced><mi>X</mi><mo>|</mo><msup><mi>U</mi><mi>k</mi></msup></mfenced><mo>=</mo><mfenced open="{" close="}"><mi>p</mi><mfenced><msub><mi>x</mi><mn>1</mn></msub><mo>|</mo><msup><mi>U</mi><mi>k</mi></msup></mfenced><mo>,</mo><mi>p</mi><mfenced><msub><mi>x</mi><mn>2</mn></msub><mo>|</mo><msup><mi>U</mi><mi>k</mi></msup></mfenced><mo>,</mo><mn>...</mn><mo>,</mo><mi>p</mi><mfenced><msub><mi>x</mi><mi>n</mi></msub><mo>|</mo><msup><mi>U</mi><mi>k</mi></msup></mfenced></mfenced></mrow></math><img file="EP3553713A1_D0011.tif" /></maths> Similarly, before any Events for the User are observed this will have a prior distribution on <i>X</i> as: <maths id="math0012" num="(0.11)"><math display="block"><mrow><mi>P</mi><mfenced><msup><mi>X</mi><mn>1</mn></msup><mo>|</mo><msup><mi>U</mi><mn>0</mn></msup></mfenced><mo>=</mo><mi>P</mi><mfenced><mi>X</mi><mo>|</mo><msup><mi>U</mi><mn>0</mn></msup></mfenced><mo>=</mo><mfenced open="{" close="}"><mi>p</mi><mfenced><msub><mi>x</mi><mn>1</mn></msub><mo>|</mo><msup><mi>U</mi><mn>0</mn></msup></mfenced><mo>,</mo><mi>p</mi><mfenced><msub><mi>x</mi><mn>2</mn></msub><mo>|</mo><msup><mi>U</mi><mn>0</mn></msup></mfenced><mo>,</mo><mn>...</mn><mo>,</mo><mi>p</mi><mfenced><msub><mi>x</mi><mi>n</mi></msub><mo>|</mo><msup><mi>U</mi><mn>0</mn></msup></mfenced></mfenced></mrow></math><img file="EP3553713A1_D0012.tif" /></maths>

Combining Priors and Observations

0113One method for combining the prior probability distribution and the observed events is to use a Dirichlet Distribution. Other distributions or combining techniques may also be used. The Dirichlet Distribution is used to estimate an unknown multinomial probability distribution. More specifically, it extends the Beta distribution into multiple dimensions and provides for a smooth transition between the prior distribution and the observed distribution and allows for control over how quickly that transition occurs.

0114The Dirichlet distribution is a second order distribution (a distribution on a distribution). For example, for an event parameter <i>X</i> that can take on one and only one value per event <i>X</i> ∈ {<i>x</i>₁, <i>x</i>₂,...,<i>x_m</i>} and <i>P_X</i> = {<i>p</i>(<i>x</i>₁),<i>p</i>(<i>x</i>₂),..., <i>p</i>(<i>x_m</i>)}, the Dirichlet distribution on <i>P_X</i> can be expressed as: <maths id="math0013" num="(0.12)"><math display="block"><mrow><mi>p</mi><mfenced><msub><mi>P</mi><mi>X</mi></msub></mfenced><mo>=</mo><mi>D</mi><mfenced><msub><mi>P</mi><mi>X</mi></msub><mo>|</mo><msubsup><mi>P</mi><mi>X</mi><mn>0</mn></msubsup><mo>,</mo><mi>α</mi></mfenced></mrow></math><img file="EP3553713A1_D0013.tif" /></maths> and <maths id="math0014" num="(0.13)"><math display="block"><mrow><mi>D</mi><mfenced><msub><mi>P</mi><mi>X</mi></msub><mo>|</mo><msubsup><mi>P</mi><mi>X</mi><mn>0</mn></msubsup><mo>,</mo><mi>α</mi></mfenced><mo>≜</mo><mrow><mstyle displaystyle="true"><mrow><munder><mo>∏</mo><mi>i</mi></munder></mrow></mstyle><mrow><msup><mfenced><mi>p</mi><mfenced><msub><mi>x</mi><mi>i</mi></msub></mfenced></mfenced><mfenced><mi>α</mi><msup><mi>p</mi><mn>0</mn></msup><mo>−</mo><mfenced><msub><mi>x</mi><mi>i</mi></msub></mfenced><mo>−</mo><mn>1</mn></mfenced></msup></mrow></mrow></mrow></math><img file="EP3553713A1_D0014.tif" /></maths>

0115Here, <ul id="ul0006" list-style="bullet" compact="compact"><li><i>p</i>(<i>P_X</i>) is a scalar that is the probability that the probability distribution <i>P_X</i> is correct</li><li><maths id="math0015"><math display="inline"><mrow><msubsup><mi>P</mi><mi>X</mi><mn>0</mn></msubsup><mo>=</mo><mfenced open="[" close="]"><msup><mi>p</mi><mn>0</mn></msup><mfenced><msub><mi>x</mi><mn>1</mn></msub></mfenced><mo>,</mo><mo>…</mo><mo>,</mo><msup><mi>p</mi><mn>0</mn></msup><mfenced><msub><mi>x</mi><mi>m</mi></msub></mfenced></mfenced></mrow></math><img file="EP3553713A1_D0015.tif" /></maths> is the apriori (assumed) distribution (vector) over <i>X</i>, and</li><li><i>α</i> is a scaling factor (in units of number of observations) that essentially represents how much belief is put into the prior distribution. That is, it controls the rate of convergence away from the prior and toward the observed distribution.</li></ul>

0116Following the derivation, the maximum likelihood estimate <i>P̂_X</i> = <i>E</i>[<i>P_X</i>] as given by: <maths id="math0016" num="(0.14)"><math display="block"><mrow><msub><mrow><mover><mi>P</mi><mrow><mo>^</mo></mrow></mover></mrow><mi>X</mi></msub><mo>=</mo><mi>E</mi><mfenced open="[" close="]"><mi>p</mi><mfenced><msub><mi>x</mi><mi>i</mi></msub></mfenced><mo>|</mo><msubsup><mi>P</mi><mi>X</mi><mn>0</mn></msubsup><mo>,</mo><mi>α</mi><mo>,</mo><msub><mi>m</mi><mi>i</mi></msub><mo>,</mo><mi>k</mi></mfenced><mo>=</mo><mfrac><mrow><mi>α</mi><msup><mi>p</mi><mn>0</mn></msup><mfenced><msub><mi>x</mi><mi>i</mi></msub></mfenced><mo>+</mo><msub><mi>m</mi><mi>i</mi></msub></mrow><mrow><mi>α</mi><mo>+</mo><mi>k</mi></mrow></mfrac><mo>,</mo></mrow></math><img file="EP3553713A1_D0016.tif" /></maths> where <i>m_i</i> is the number of times <i>x_i</i> was observed and <i>k</i> = ∑<i>_jm_j</i> is the total number of observed events.

0117The Dirichlet can be used as an estimate of the predictive User Model so that each element <i>p</i>(<i>x_i</i> | <i>U</i>^<i>k</i>-1) of Equation (0.10) can be estimated as: <maths id="math0017" num="(0.15)"><math display="block"><mrow><mover><mi>p</mi><mrow><mo>^</mo></mrow></mover><mfenced><msub><mi>x</mi><mi>i</mi></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced><mo>=</mo><mfrac><mrow><mi mathvariant="italic">αp</mi><mfenced><msub><mi>x</mi><mi>i</mi></msub><mo>|</mo><msup><mi>U</mi><mn>0</mn></msup></mfenced><mo>+</mo><msub><mi>m</mi><mi>i</mi></msub></mrow><mrow><mi>α</mi><mo>+</mo><mi>k</mi></mrow></mfrac></mrow></math><img file="EP3553713A1_D0017.tif" /></maths>

0118The Dirichlet Model (Equation(0.15)) can be rewritten as: <maths id="math0018" num="(0.16)"><math display="block"><mrow><mover><mi>p</mi><mrow><mo>^</mo></mrow></mover><mfenced><msub><mi>x</mi><mi>i</mi></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced><mo>=</mo><mi mathvariant="italic">βp</mi><mfenced><msub><mi>x</mi><mi>i</mi></msub><mo>|</mo><msup><mi>U</mi><mn>0</mn></msup></mfenced><mo>+</mo><mfenced><mn>1</mn><mo>−</mo><mi>β</mi></mfenced><mfenced><mfrac><mrow><msub><mi>m</mi><mi>i</mi></msub></mrow><mi>k</mi></mfrac></mfenced><mo>,</mo></mrow></math><img file="EP3553713A1_D0018.tif" /></maths> where <maths id="math0019"><math display="block"><mrow><mi>β</mi><mo>=</mo><mfrac><mi>α</mi><mrow><mi>α</mi><mo>+</mo><mi>k</mi></mrow></mfrac><mn>.</mn></mrow></math><img file="EP3553713A1_D0019.tif" /></maths><maths id="math0020"><math display="block"><mrow><mn>1</mn><mo>−</mo><mi>β</mi><mo>=</mo><mfrac><mi>k</mi><mrow><mi>α</mi><mo>+</mo><mi>k</mi></mrow></mfrac></mrow></math><img file="EP3553713A1_D0020.tif" /></maths>

0119Hence, the estimated User Model provides a smooth and intuitive transition between the prior and observed distribution on <i>X</i> for a given User. The rate of convergence to the observed distribution is controlled by the parameter <i>α</i> which is in units of <i>k</i> (i.e., observed events).

0120This is a good model for some parameter types, however, it fails to account for other expectations on user behavior. Notable, for some parameter types (e.g., location) only a few observed values are expected for any given User. And for these parameters, the expectation of seeing a new parameter value may be based on the User's previously observed behavior. A model for incorporating this type of expectation is addressed in the next subsection.

Modified Event Model (New Mode Probability)

0121The Modified Event Model takes into account the expectation that a single user will only be observed with a finite set of parameter values. Furthermore, it recognizes that a user switching to a new (previously unobserved) parameter value is an event of interest unto itself. For example, an individual user in one or perhaps a small number of different countries is expected, and seeing the user in a new country is an interesting occurrence.

0122Consider the observed Random Variable <i>X</i> with all of the definitions from the previous section. While awaiting the k+1^'th observation, this can characterize the possible outcomes using a modified experiment based on a new random variable <img file="EP3553713A1_D0021.tif" /> where <maths id="math0021"><math display="inline"><mrow><msup><mi mathvariant="double-struck">N</mi><mrow><mi>k</mi><mo>+</mo><mn>1</mn></mrow></msup><mo>=</mo><mi mathvariant="italic">FALSE</mi></mrow></math><img file="EP3553713A1_D0022.tif" /></maths> if the observed value <i>X</i>^<i>k</i>+1 has been previously observed (for that user) and <maths id="math0022"><math display="inline"><mrow><msup><mi mathvariant="double-struck">N</mi><mrow><mi>k</mi><mo>+</mo><mn>1</mn></mrow></msup><mo>=</mo><mi mathvariant="italic">TRUE</mi></mrow></math><img file="EP3553713A1_D0023.tif" /></maths> if this is the first time observing the value (for that user), In other words, <maths id="math0023"><math display="inline"><mrow><msup><mi mathvariant="double-struck">N</mi><mrow><mi>k</mi><mo>+</mo><mn>1</mn></mrow></msup><mo>=</mo><mi mathvariant="italic">TRUE</mi></mrow></math><img file="EP3553713A1_D0024.tif" /></maths> is a <i>New Mode Event</i>. This can define the New Mode Probability <i>η</i> as: <maths id="math0024" num="(0.17)"><math display="block"><mrow><mi>P</mi><mfenced><mi mathvariant="double-struck">N</mi><mo>|</mo><mi>U</mi></mfenced><mo>=</mo><mo>|</mo><mtable><mtr><mtd><mi>η</mi></mtd><mtd columnalign="left"><mi>if</mi><mspace width="1em" /><mi mathvariant="double-struck">N</mi><mo>=</mo><mi mathvariant="italic">TRUE</mi></mtd></mtr><mtr><mtd><mn>1</mn><mo>−</mo><mi>η</mi></mtd><mtd><mi>if</mi><mspace width="1em" /><mi mathvariant="double-struck">N</mi><mo>=</mo><mi mathvariant="italic">FALSE</mi></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0025.tif" /></maths>

0123Combining the New Mode Event with the actual observed value, this can be written as: <maths id="math0025" num="(0.18)"><math display="block"><mrow><mi>p</mi><mfenced><msub><mi>x</mi><mi>i</mi></msub><mo>|</mo><msup><mi>U</mi><mi>k</mi></msup></mfenced><mo>=</mo><mo>|</mo><mtable><mtr><mtd><mi>η</mi><mfrac><mrow><mi>p</mi><mfenced><msub><mi>x</mi><mi>i</mi></msub><mo>|</mo><msup><mi>U</mi><mn>0</mn></msup></mfenced></mrow><mrow><mn>1</mn><mo>−</mo><mi>υ</mi></mrow></mfrac></mtd><mtd columnalign="left"><msub><mrow><mi>if</mi><mspace width="1em" /><mi>x</mi></mrow><mi>i</mi></msub><mspace width="1em" /><mi>not previously observed</mi></mtd></mtr><mtr><mtd><mfenced><mn>1</mn><mo>−</mo><mi>η</mi></mfenced><mover><mi>p</mi><mrow><mo>^</mo></mrow></mover><mfenced><msub><mi>x</mi><mi>i</mi></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mtd><mtd><msub><mrow><mi>if</mi><mspace width="1em" /><mi>x</mi></mrow><mi>i</mi></msub><mspace width="1em" /><mi>has been previously observed</mi></mtd></mtr></mtable><mo>,</mo></mrow></math><img file="EP3553713A1_D0026.tif" /></maths> where the following are defined: <ul id="ul0007" list-style="bullet" compact="compact"><li><i>η</i> is the New Mode Probability for this user based on the previous Events observed. The new mode probability <i>η</i> can be modeled in many different ways including statistical models based on historic data</li><li><i>υ</i> is the previously observed prior probability mass for <i>X</i>, specifically <maths id="math0026" num="(0.19)"><math display="block"><mrow><mtable><mtr><mtd><mi>υ</mi></mtd><mtd columnalign="left"><mo>=</mo><mstyle displaystyle="false"><mrow><mstyle displaystyle="true"><mrow><munder><mrow><mo>∑</mo></mrow><mrow><mfenced><msub><mi>x</mi><mi>i</mi></msub><mrow><mspace width="1em" /><mi>Previously Observed</mi></mrow></mfenced></mrow></munder></mrow></mstyle><mrow><mi>p</mi><mfenced><msub><mi>x</mi><mi>i</mi></msub><mo>|</mo><msup><mi>U</mi><mn>0</mn></msup></mfenced></mrow></mrow></mstyle></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd columnalign="left"><mo>=</mo><mn>1</mn><mo>−</mo><mstyle displaystyle="false"><mrow><mstyle displaystyle="true"><mrow><munder><mrow><mo>∑</mo></mrow><mrow><mfenced><msub><mi>x</mi><mi>j</mi></msub><mrow><mspace width="1em" /><mi>NOT Previously Observed</mi></mrow></mfenced></mrow></munder></mrow></mstyle><mrow><mi>p</mi><mfenced><msub><mi>x</mi><mi>j</mi></msub><mo>|</mo><msup><mi>U</mi><mn>0</mn></msup></mfenced></mrow></mrow></mstyle></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0027.tif" /></maths></li><li>And <i>p̂</i>(<i>x_i</i> | <i>U</i>^<i>k</i>-1) is the estimated probability of the previously observed value <i>x_i</i>, for example, Equation (0.16).</li></ul>

0124The decision to use the New Mode Model (i.e., Equation (0.19) or it's variants) versus a more traditional model such as the or the Dirichlet Model (i.e., Equation(0.16)) is determined by the type of parameter being modeled. If the parameter includes a strong expectation on whether a new mode (value) should be observed then Equation (0.18) provides additional fidelity in this respect. However, if the parameter is best modeled simply as an expectation of its value, then Equation(0.16) provides a simpler and mode direct way of modeling this behavior.

The Trust Model

0125The Trust Model accounts for the fact that an Event observed for a User could have been caused by a Fraudster. If that were the case, the User Model should not be updated with the observed information. Of course, this must be done probabilistically as the system is never absolutely certain whether the Event was caused by the User or a Fraudster.

0126The Trust Model is particularly important for fraud scenarios that occur over multiple sessions. This helps prevent a Fraudster from fooling the system (by biasing the model) with a number of benign-looking sessions before attempting more suspicious activity.

0127The basic idea is to consider two possible updated User Models after observing an Event. <ol id="ol0001" compact="compact"><li>1. <i>U</i>⁺ is the resulting User Model that includes the impact of a previous Event <i>E</i></li><li>2. <i>U</i>^- is the resulting User Model that ignores the impact of a previous Event <i>E</i></li></ol>

0128Then, the likelihood of a subsequent Event <i>E'</i> can be written as: <maths id="math0027" num="(0.20)"><math display="block"><mrow><mtable><mtr><mtd><mi>P</mi><mfenced><mi mathvariant="italic">Eʹ</mi><mo>|</mo><mi>U</mi></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mi>P</mi><mfenced><mi mathvariant="italic">Eʹ</mi><mo>|</mo><msup><mi>U</mi><mrow><mo>+</mo></mrow></msup></mfenced><mi>P</mi><mrow><mfenced><msup><mi>U</mi><mrow><mo>+</mo></mrow></msup><mrow><mspace width="1em" /><mi mathvariant="italic">is correct</mi></mrow><mo>|</mo><mi>U</mi></mfenced><mo>+</mo><mi>P</mi><mfenced><mi mathvariant="italic">Eʹ</mi><mo>|</mo><msup><mi>U</mi><mrow><mo>−</mo></mrow></msup></mfenced><mi>P</mi><mfenced><msup><mi>U</mi><mrow><mo>−</mo></mrow></msup><mrow><mspace width="1em" /><mi mathvariant="italic">is correct</mi></mrow><mo>|</mo><mi>U</mi></mfenced></mrow></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd columnalign="left"><mo>=</mo><mi>P</mi><mfenced><mi mathvariant="italic">Eʹ</mi><mo>|</mo><msup><mi>U</mi><mrow><mo>+</mo></mrow></msup></mfenced><mi>P</mi><mfenced><msup><mi>U</mi><mrow><mo>+</mo></mrow></msup><mrow><mspace width="1em" /><mi mathvariant="italic">is correct</mi></mrow><mo>|</mo><mi>U</mi></mfenced><mo>+</mo><mi>P</mi><mfenced><mi mathvariant="italic">Eʹ</mi><mo>|</mo><msup><mi>U</mi><mrow><mo>−</mo></mrow></msup></mfenced><mfenced><mn>1</mn><mo>−</mo><mi>P</mi><mfenced><msup><mi>U</mi><mrow><mo>+</mo></mrow></msup><mrow><mspace width="1em" /><mi mathvariant="italic">is correct</mi></mrow><mo>|</mo><mi>U</mi></mfenced></mfenced></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0028.tif" /></maths>

0129Where <i>P</i>(<i>U</i>⁺<i>is correct</i> | <i>U</i>) is essentially the probability that the Event <i>E</i> was in fact caused by the User. This term is defined as the Trust of the Event, <i>T_E</i> : <maths id="math0028" num="(0.21)"><math display="block"><mrow><mtable><mtr><mtd><msub><mi>T</mi><mi>E</mi></msub></mtd><mtd columnalign="left"><mo>≜</mo><mi>P</mi><mfenced><msup><mi>U</mi><mrow><mo>+</mo></mrow></msup><mrow><mspace width="1em" /><mi mathvariant="italic">is correct</mi></mrow><mo>|</mo><mi>U</mi></mfenced><mo>=</mo><mn>1</mn><mo>−</mo><mi>P</mi><mfenced><msup><mi>U</mi><mrow><mo>−</mo></mrow></msup><mrow><mspace width="1em" /><mi mathvariant="italic">is correcte</mi></mrow><mo>|</mo><mi>U</mi></mfenced></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd columnalign="left"><mo>≜</mo><mi>P</mi><mfenced><mi mathvariant="italic">That User U was the cause of observed Event E</mi></mfenced></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd columnalign="left"><mo>=</mo><mi>P</mi><mfenced><mi>U</mi><mo>|</mo><mi>E</mi></mfenced></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd columnalign="left"><mo>=</mo><mn>1</mn><mo>−</mo><mi>P</mi><mfenced><mi>F</mi><mo>|</mo><mi>E</mi></mfenced></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0029.tif" /></maths>

0130Combining this with Equations(0.1) and (0.3) yields: <maths id="math0029" num="(0.22)"><math display="block"><mrow><mtable><mtr><mtd><mi mathvariant="italic">ρλ</mi><mfenced><mi>E</mi></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mi>L</mi><mfenced><mi>E</mi></mfenced></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd columnalign="left"><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><mi>F</mi><mo>|</mo><mi>E</mi></mfenced></mrow><mrow><mi>P</mi><mfenced><mi>U</mi><mo>|</mo><mi>E</mi></mfenced></mrow></mfrac></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd columnalign="left"><mo>=</mo><mfrac><mrow><mn>1</mn><mo>−</mo><mi>P</mi><mfenced><mi>U</mi><mo>|</mo><mi>E</mi></mfenced></mrow><mrow><mi>P</mi><mfenced><mi>U</mi><mo>|</mo><mi>E</mi></mfenced></mrow></mfrac></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd columnalign="left"><mo>=</mo><mfrac><mrow><mn>1</mn><mo>−</mo><msub><mi>T</mi><mi>E</mi></msub></mrow><mrow><msub><mi>T</mi><mi>E</mi></msub></mrow></mfrac></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0030.tif" /></maths>

0131Rearranging to solve for <i>T_E</i> : <maths id="math0030" num="(0.23)"><math display="block"><mrow><mtable><mtr><mtd><msub><mi>T</mi><mi>E</mi></msub></mtd><mtd columnalign="left"><mo>=</mo><mfrac><mn>1</mn><mrow><mn>1</mn><mo>+</mo><mi mathvariant="italic">ρλ</mi><mfenced><mi>E</mi></mfenced></mrow></mfrac></mtd></mtr><mtr><mtd><mi>ρ</mi></mtd><mtd><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><mi>F</mi></mfenced></mrow><mrow><mn>1</mn><mo>−</mo><mi>P</mi><mfenced><mi>F</mi></mfenced></mrow></mfrac><mo>≈</mo><mi>P</mi><mfenced><mi>F</mi></mfenced></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0031.tif" /></maths>

0132Intuitively, <i>P</i>(<i>F</i>) will always be &lt;&lt; 1 so that when the relative likelihood ratio <i>λ</i>(<i>E</i>) &lt;&lt; 1 / <i>P</i>(<i>F</i>), the Trust of the Event will be ≈ 1. Conversely, the Trust of the Event will be significantly reduced when <i>λ</i>(<i>E</i>) ≥ 1 / <i>P</i>(<i>F</i>).

0133The Trust of previous Events can be used in the estimate (update) of the User Model. For the Dirichlet User Model described in Equation (0.16), the <i>Accumulated Trust</i> can be used instead of the <i>Count Observed</i> for deriving the Predicted User Model each parameter value (aka Mode). Specifically: <maths id="math0031" num="(0.24)"><math display="block"><mrow><mover><mi>p</mi><mrow><mo>^</mo></mrow></mover><mfenced><msub><mi>x</mi><mi>i</mi></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>+</mo><mn>1</mn></mrow></msup></mfenced><mo>=</mo><msub><mi>β</mi><mi>τ</mi></msub><mi>p</mi><mfenced><msub><mi>x</mi><mi>i</mi></msub><mo>|</mo><msup><mi>U</mi><mn>0</mn></msup></mfenced><mo>+</mo><mfenced><mn>1</mn><mo>−</mo><msub><mi>β</mi><mi>τ</mi></msub></mfenced><mfrac><mrow><msub><mi>τ</mi><mi>i</mi></msub></mrow><mrow><mstyle displaystyle="false"><mrow><munder><mrow><mo>∑</mo></mrow><mi>j</mi></munder><mrow><msub><mi>τ</mi><mi>j</mi></msub></mrow></mrow></mstyle></mrow></mfrac></mrow></math><img file="EP3553713A1_D0032.tif" /></maths> Where the prior weight coefficient <i>β_τ</i> is now calculated based on the Accumulated Trust over all observed values for the parameter, i.e.: <maths id="math0032" num="(0.25)"><math display="block"><mrow><msub><mi>β</mi><mi>τ</mi></msub><mo>=</mo><mfrac><mi>α</mi><mrow><mi>α</mi><mo>+</mo><mstyle displaystyle="false"><mrow><munder><mo>∑</mo><mi>j</mi></munder><mrow><msub><mi>τ</mi><mi>j</mi></msub></mrow></mrow></mstyle></mrow></mfrac></mrow></math><img file="EP3553713A1_D0033.tif" /></maths>

0134Here the following are followed: <ul id="ul0008" list-style="bullet" compact="compact"><li><i>p</i>(<i>x_i</i> | <i>U</i>⁰) is the prior (user) probability of observing the value <i>x_i</i></li><li><i>α</i> is the Dirichlet scaling factor (in units of the number of observations)</li><li><i>τ_i</i> is the <i>Accumulated Trust</i> of the Events in which <i>x_i</i> was observed for this user. <maths id="math0033"><math display="block"><mrow><msub><mi>τ</mi><mi>i</mi></msub><mo>=</mo><mstyle displaystyle="false"><mrow><mstyle displaystyle="true"><mrow><munder><mo>∑</mo><mrow><mi mathvariant="italic">E where X</mi><mo>=</mo><msub><mi>x</mi><mi>i</mi></msub></mrow></munder></mrow></mstyle><mrow><msub><mi>T</mi><mi>E</mi></msub></mrow></mrow></mstyle></mrow></math><img file="EP3553713A1_D0034.tif" /></maths></li><li>∑<i>_j τ_j</i> is the total Accumulated Trust across all observed values of <i>X</i> for this user</li></ul>

0135Referring back to the definition and interpretation of <i>T_E</i> in (Equation(0.23)), in cases where the Event is generally consistent with the User Model (ie., <i>λ</i>(<i>E</i>) &lt;&lt; 1 / <i>P</i>(<i>F</i>)), <i>T_E</i> ≈ 1 so this equation behaves equivalently to the original Dirichlet Model (Equation (0.15)). However if an Event has very high risk (<i>λ</i>(<i>E</i>) ≥ 1 / <i>P</i>(<i>F</i>)), the resulting <i>T_E</i> may be significantly less than 1 and it will have a correspondingly reduced influence to the resulting updated User Model. Likewise, the Trust Score can be used in the New Mode Model of Equation (0.18) by using a similar substitution.

Time Decay Model

0136The derivation of the User Model up to this point does not factor in the passage of time and more specifically that the User may change the behavior over time such that observed behavior a long time ago may not reflect the current expected behavior This issue is addressed by introducing a Time Decay Model for the User Model.

0137The basic idea behind the Time Decay Model is that the relevancy of an observed event decreases over time. The exponential decay function forms a computationally attractive basis of the model. Using an exponential decay function, the relative weight of each event decays according to the function: <maths id="math0034" num="(0.26)"><math display="block"><mrow><mi>ω</mi><mfenced separators=","><mi>t</mi><msub><mi>t</mi><mi mathvariant="italic">Event</mi></msub></mfenced><mo>=</mo><msup><mi>e</mi><mrow><mo>−</mo><mfrac><mrow><mi>t</mi><mo>−</mo><msub><mi>t</mi><mi mathvariant="italic">Event</mi></msub></mrow><mi>λ</mi></mfrac></mrow></msup></mrow></math><img file="EP3553713A1_D0035.tif" /></maths> The following apply for this function: <ul id="ul0009" list-style="bullet" compact="compact"><li><i>t</i> is the current time (or any time after the Event was observed)</li><li><i>t_Event</i> is the time the Event was observed</li><li><i>λ</i> is the decay parameter (in the same unit as <i>t</i>) of the model</li></ul>

0138This weighting function can be applied recursively from one point in time to another. Specifically, for two future points in time <i>t</i>₂ > <i>t</i>₁ > <i>t_Event</i> : <maths id="math0035" num="(0.27)"><math display="block"><mrow><mtable><mtr><mtd><mi>ω</mi><mfenced separators=","><msub><mi>t</mi><mn>2</mn></msub><msub><mi>t</mi><mi mathvariant="italic">Event</mi></msub></mfenced></mtd><mtd columnalign="left"><mo>=</mo><msup><mi>e</mi><mrow><mo>−</mo><mfenced><mfrac><mrow><msub><mi>t</mi><mn>2</mn></msub><mo>−</mo><msub><mi>t</mi><mi mathvariant="italic">Event</mi></msub></mrow><mi>λ</mi></mfrac></mfenced></mrow></msup><mo>=</mo><msup><mi>e</mi><mrow><mo>−</mo><mfenced><mfrac><mrow><mfenced><msub><mi>t</mi><mn>2</mn></msub><mo>−</mo><msub><mi>t</mi><mn>1</mn></msub></mfenced><mo>+</mo><mfenced><msub><mi>t</mi><mn>1</mn></msub><mo>−</mo><msub><mi>t</mi><mi mathvariant="italic">Event</mi></msub></mfenced></mrow><mi>λ</mi></mfrac></mfenced></mrow></msup></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd columnalign="left"><mo>=</mo><msup><mi>e</mi><mrow><mo>−</mo><mfenced><mfrac><mrow><msub><mi>t</mi><mn>2</mn></msub><mo>−</mo><msub><mi>t</mi><mn>1</mn></msub></mrow><mi>λ</mi></mfrac></mfenced></mrow></msup><msup><mi>e</mi><mrow><mo>−</mo><mfenced><mfrac><mrow><msub><mi>t</mi><mn>1</mn></msub><mo>−</mo><msub><mi>t</mi><mi mathvariant="italic">Event</mi></msub></mrow><mi>λ</mi></mfrac></mfenced></mrow></msup></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd columnalign="left"><mo>=</mo><mi>ω</mi><mfenced separators=","><msub><mi>t</mi><mn>2</mn></msub><msub><mi>t</mi><mn>1</mn></msub></mfenced><mi>ω</mi><mfenced separators=","><msub><mi>t</mi><mn>1</mn></msub><msub><mi>t</mi><mi mathvariant="italic">Event</mi></msub></mfenced></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0036.tif" /></maths>

0139With this background, the Time Decay Model is now described Define M<i>_i</i> (<i>t</i>) as the <i>Accumulated Observed Mass</i> for the parameter value <i>x_i</i> ∈ <i>X</i>. The Accumulated Observed Mass could be based on Event Count (i.e., the base weight for each Event is 1) the Trust of an Event (the base weight for an Event is <i>T_E</i>) or some other metric that weights each observed Event. However, as defined, the Accumulated Observed Mass can also vary over time.

0140Using the exponential decay function, a definition of specific form for the Accumulated Observed Mass for a given time <i>t</i> given a specific exponential time constant is: <maths id="math0036" num="(0.28)"><math display="block"><mrow><msub><mi mathvariant="normal">M</mi><mrow><mi>λ</mi><mo>,</mo><mi>i</mi></mrow></msub><mfenced><mi>t</mi></mfenced><mo>=</mo><msubsup><mi mathvariant="normal">M</mi><mrow><mi>λ</mi><mo>,</mo><mi>i</mi></mrow><mi mathvariant="italic">Last</mi></msubsup><msup><mi>e</mi><mrow><mfrac><mrow><mo>−</mo><mfenced><mi>t</mi><mo>−</mo><msubsup><mi>t</mi><mi>i</mi><mi mathvariant="italic">Last</mi></msubsup></mfenced></mrow><mi>λ</mi></mfrac></mrow></msup></mrow></math><img file="EP3553713A1_D0037.tif" /></maths>

0141The following apply for the Accumulated Observed Mass: <ul id="ul0010" list-style="bullet" compact="compact"><li><maths id="math0037"><math display="inline"><mrow><msubsup><mi mathvariant="normal">M</mi><mrow><mi>λ</mi><mo>,</mo><mi>i</mi></mrow><mi mathvariant="italic">Last</mi></msubsup><mo>=</mo><msub><mi mathvariant="normal">M</mi><mrow><mi>λ</mi><mo>,</mo><mi>i</mi></mrow></msub><mfenced><msubsup><mi>t</mi><mi>i</mi><mi mathvariant="italic">Last</mi></msubsup></mfenced></mrow></math><img file="EP3553713A1_D0038.tif" /></maths> is the Accumulated Observed Mass for the value <i>x_i</i> immediately after the last Event in which <i>x_i</i> was observed.</li><li><maths id="math0038"><math display="inline"><mrow><msubsup><mi>t</mi><mi>i</mi><mi mathvariant="italic">Last</mi></msubsup></mrow></math><img file="EP3553713A1_D0039.tif" /></maths> is the timestamp of the last Event in which <i>x_i</i> was observed. The value of <maths id="math0039"><math display="inline"><mrow><msubsup><mi>t</mi><mi>i</mi><mi mathvariant="italic">Last</mi></msubsup></mrow></math><img file="EP3553713A1_D0040.tif" /></maths> is stored as part of the User Model (each <i>x_i</i> has its own <maths id="math0040"><math display="inline"><mrow><msubsup><mi>t</mi><mi>i</mi><mi mathvariant="italic">Last</mi></msubsup></mrow></math><img file="EP3553713A1_D0041.tif" /></maths>)</li><li><i>t</i> is the current time and is usually set by the time of the next Event to evaluate</li><li><i>λ</i> is the exponential time constant and is a static parameter of the model</li></ul><maths id="math0041"><math display="inline"><mrow><msubsup><mi mathvariant="normal">M</mi><mrow><mi>λ</mi><mo>,</mo><mi>i</mi></mrow><mi mathvariant="italic">Last</mi></msubsup></mrow></math><img file="EP3553713A1_D0042.tif" /></maths> and <maths id="math0042"><math display="inline"><mrow><msubsup><mi>t</mi><mi>i</mi><mi mathvariant="italic">Last</mi></msubsup></mrow></math><img file="EP3553713A1_D0043.tif" /></maths> are calculated recursively as part of the User Model Update process. Specifically, whenever an Event is observed that contains the value <i>x_i</i>, the User Model is updated using <maths id="math0043" num="(0.29)"><math display="block"><mrow><mtable><mtr><mtd><msubsup><mi mathvariant="normal">M</mi><mrow><mi>λ</mi><mo>,</mo><mi>i</mi></mrow><mrow><mi mathvariant="italic">Last</mi><mo>|</mo><mi>k</mi></mrow></msubsup></mtd><mtd columnalign="left"><mo>=</mo><msubsup><mi>m</mi><mi>i</mi><mrow><msup><mi>E</mi><mi>k</mi></msup></mrow></msubsup><mo>+</mo><msubsup><mi mathvariant="normal">M</mi><mi>λ</mi><mrow><mi mathvariant="italic">Last</mi><mo>|</mo><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msubsup><msup><mi>e</mi><mrow><mfrac><mrow><mo>−</mo><mfenced><msup><mi>t</mi><mi mathvariant="italic">Event</mi></msup><mo>−</mo><msubsup><mi>t</mi><mi>i</mi><mrow><mi mathvariant="italic">Last</mi><mo>|</mo><mo>−</mo><mn>1</mn></mrow></msubsup></mfenced></mrow><mi>λ</mi></mfrac></mrow></msup></mtd></mtr><mtr><mtd><msubsup><mi>t</mi><mi>i</mi><mrow><mi mathvariant="italic">Last</mi><mo>|</mo><mi>k</mi></mrow></msubsup></mtd><mtd columnalign="left"><mo>=</mo><msup><mi>t</mi><mi mathvariant="italic">Event</mi></msup></mtd></mtr></mtable><mo>,</mo></mrow></math><img file="EP3553713A1_D0044.tif" /></maths> where: <ul id="ul0011" list-style="bullet" compact="compact"><li><maths id="math0044"><math display="inline"><mrow><msubsup><mi mathvariant="normal">M</mi><mrow><mi>λ</mi><mo>,</mo><mi>i</mi></mrow><mrow><mi mathvariant="italic">Last</mi><mo>|</mo><mi>k</mi></mrow></msubsup></mrow></math><img file="EP3553713A1_D0045.tif" /></maths> is the new (updated) Accumulated Observed Mass for the value <i>x_i</i> immediately after the current Event <i>k</i> (in which <i>x_i</i> was observed)</li><li><maths id="math0045"><math display="inline"><mrow><msubsup><mi mathvariant="normal">M</mi><mrow><mi>λ</mi><mo>,</mo><mi>i</mi></mrow><mrow><mi mathvariant="italic">Last</mi><mo>|</mo><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msubsup></mrow></math><img file="EP3553713A1_D0046.tif" /></maths> is the Accumulated Observed Mass for <i>x_i</i> prior to observing the most recent Event</li><li><maths id="math0046"><math display="inline"><mrow><msubsup><mi>m</mi><mi>i</mi><mrow><msup><mi>E</mi><mi>k</mi></msup></mrow></msubsup></mrow></math><img file="EP3553713A1_D0047.tif" /></maths> is the Incremental Observed Mass for <i>x_i</i> based for the current (single) Event <i>k</i>. <ul id="ul0012" list-style="none" compact="compact"><li>∘ If the Observed Mass is based on Count Observed, then <maths id="math0047"><math display="inline"><mrow><msubsup><mi>m</mi><mi>i</mi><mrow><msup><mi>E</mi><mi>k</mi></msup></mrow></msubsup><mo>=</mo><mn>1</mn></mrow></math><img file="EP3553713A1_D0048.tif" /></maths></li><li>∘ If the Observed Mass is based on the Event Trust, then <maths id="math0048"><math display="inline"><mrow><msubsup><mi>m</mi><mi>i</mi><mrow><msup><mi>E</mi><mi>k</mi></msup></mrow></msubsup><mo>=</mo><msub><mi>T</mi><mrow><msup><mi>E</mi><mi>k</mi></msup></mrow></msub></mrow></math><img file="EP3553713A1_D0049.tif" /></maths></li></ul></li><li><i>t^Event</i> is the timestamp of the most recent Event <i>k</i> (in which <i>x_i</i> was observed)</li><li><maths id="math0049"><math display="inline"><mrow><msubsup><mi>t</mi><mi>i</mi><mrow><mi mathvariant="italic">Last</mi><mo>|</mo><mi>k</mi></mrow></msubsup></mrow></math><img file="EP3553713A1_D0050.tif" /></maths> is the new (updated) <i>Last Time Observed</i> for the value <i>x_i</i> based on Event <i>k</i></li><li><maths id="math0050"><math display="inline"><mrow><msubsup><mi>t</mi><mi>i</mi><mrow><mi mathvariant="italic">Last</mi><mo>|</mo><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msubsup></mrow></math><img file="EP3553713A1_D0051.tif" /></maths> is the <i>Last Time Observed</i> for the value <i>x_i</i> prior to this most recent Event</li></ul>

0142If this is the first time <i>x_i</i> is observed (for this User), the initial update reduces to: <maths id="math0051" num="(0.30)"><math display="block"><mrow><mtable><mtr><mtd><msubsup><mi mathvariant="normal">M</mi><mrow><mi>λ</mi><mo>,</mo><mi>i</mi></mrow><mrow><mi mathvariant="italic">Last</mi><mo>|</mo><mi>k</mi></mrow></msubsup></mtd><mtd columnalign="left"><mo>=</mo><msubsup><mi>m</mi><mi>i</mi><mrow><msup><mi>E</mi><mi>k</mi></msup></mrow></msubsup></mtd></mtr><mtr><mtd columnalign="left"><msubsup><mi>t</mi><mi>i</mi><mrow><mi mathvariant="italic">Last</mi><mo>|</mo><mi>k</mi></mrow></msubsup></mtd><mtd columnalign="left"><mo>=</mo><msup><mi>t</mi><mi mathvariant="italic">Event</mi></msup></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0052.tif" /></maths>

0143Evaluating an Event follows exactly the same process with the Time Decay model as without except that the Accumulated Observed Mass M_{<i>λ</i>,<i>i</i>} (<i>t</i>) is used instead of the Count Observed or the Accumulated Trust in calculating the Risk Score of an Event. Specifically, <ul id="ul0013" list-style="bullet" compact="compact"><li>M_{<i>λ</i>,<i>i</i>} (<i>t</i>) is used instead of <i>m_i</i> in Equation (0.16) if the Event Count is used as the basis of <maths id="math0052"><math display="inline"><mrow><msubsup><mi>m</mi><mi>i</mi><mrow><msup><mi>E</mi><mi>k</mi></msup></mrow></msubsup><mn>.</mn></mrow></math><img file="EP3553713A1_D0053.tif" /></maths> Also, <i>k</i> (which is now real-valued) is calculated using the summation <maths id="math0053"><math display="inline"><mrow><mstyle displaystyle="false"><mrow><mstyle displaystyle="true"><mrow><munder><mrow><mo>∑</mo></mrow><mi>j</mi></munder></mrow></mstyle><mrow><msub><mi mathvariant="normal">M</mi><mrow><mi>λ</mi><mo>,</mo><mi>l</mi></mrow></msub></mrow><mfenced><mi>t</mi></mfenced></mrow></mstyle></mrow></math><img file="EP3553713A1_D0054.tif" /></maths> which sums the Accumulated Observed Mass over all previously observed values <i>x_j</i></li><li>M_{<i>λ</i>,<i>i</i>} (<i>t</i>) is used instead of <i>τ_i</i> in Equation (0.24) or if the Event Trust is used as the basis of <maths id="math0054"><math display="inline"><mrow><msubsup><mi>m</mi><mi>i</mi><mrow><msup><mi>E</mi><mi>k</mi></msup></mrow></msubsup><mn>.</mn></mrow></math><img file="EP3553713A1_D0055.tif" /></maths> Similarly, the normalization is now done using the summation <maths id="math0055"><math display="inline"><mrow><mstyle displaystyle="false"><mrow><mstyle displaystyle="true"><mrow><munder><mrow><mo>∑</mo></mrow><mi>j</mi></munder></mrow></mstyle><mrow><msub><mi mathvariant="normal">M</mi><mrow><mi mathvariant="italic">λ</mi><mo>,</mo><mi>l</mi></mrow></msub></mrow><mfenced><mi>t</mi></mfenced></mrow></mstyle></mrow></math><img file="EP3553713A1_D0056.tif" /></maths> instead of <maths id="math0056"><math display="inline"><mrow><mstyle displaystyle="false"><mrow><mstyle displaystyle="true"><mrow><munder><mo>∑</mo><mi>j</mi></munder></mrow></mstyle><mi>τ</mi></mrow></mstyle></mrow></math><img file="EP3553713A1_D0057.tif" /></maths></li></ul> More complex decay models can be used, for example a weighted average of multiple exponential decays.

Fraud Impersonation Model

0144The formulation described above assumes that the Fraudster acts independently of the User, i.e., that the Fraudster does not know anything about users in general or about the specific User and/or even if the fraudster did the fraudster would not be able or choose to do anything different because of that knowledge, As fraudsters become more sophisticated this assumption no longer holds and may impact the performance of the algorithm.

0145The Impersonation Model addresses this issue. Consideration may be given to two related but different scenarios: <ol id="ol0002" compact="compact"><li>1. The Fraudster has knowledge of Users in general (perhaps for a particular target bank). Essentially, the Fraudster may be able to use this knowledge to guess what a typical user might do. For example a Fraudster attacking a US bank might safely assume that most Users will access the online application from the US so the fraudster may use a US proxy to hide the fraudster's location and perhaps more importantly to look like a normal user. Of course, this is more relevant for some parameters (e.g., Country) but not for others because the fraudster may be unable to sufficiently guess what an user may use (e.g., in the case of a User Agent String) and/or it would be difficult to mimic their behavior (e.g., to come from the exact same network block).</li><li>2. The Fraudster has been able to learn something about a specific User (perhaps by collecting data from a Phishing Site or by installing Malware on the User's machine). And based on this information the fraudster may change the attack profile to look like that specific User. This creates more opportunities and a more sophisticated attack profile. Still, this is more relevant to some parameters than others. For example, it is relatively easy to look like a specific User Agent String but it is much more difficult to use the exact same network block (which would require sophisticated malware on the user's machine).</li></ol>

0146Both cases are based on the same basic model, however this model is applied at different times: 1) the ability to guess is handled by adjusting the Parameter Priors for the Fraudster while 2) the ability to actively impersonate a specific user is handled dynamically.

0147For the case that a Fraudster can guess the behavior of users in general, adjustments can be made to the Parameter Priors in the Fraud Model to account for this possibility. In particular, this defines the probability that a Fraudster could guess the behavior of users for each parameter in the model: <maths id="math0057" num="(0.31)"><math display="block"><mrow><msub><mi>P</mi><mi mathvariant="italic">Guess</mi></msub><mo>≜</mo><mi>Probability that Faudster guesses parameter value</mi></mrow></math><img file="EP3553713A1_D0058.tif" /></maths>

0148Essentially, this says that with probability <i>P_Guess</i> the Fraudster knows the prior probability (for the specific parameter) of Users in general (for the specific target bank and/or application). This can be easily factored into the model by modifying the Fraud Parameter Prior for the parameter being considered. This is done using: <maths id="math0058" num="(0.32)"><math display="block"><mrow><mi>P</mi><mfenced><mi>X</mi><mo>|</mo><msup><mrow><mover><mi>F</mi><mrow><mo>^</mo></mrow></mover></mrow><mn>0</mn></msup></mfenced><mo>=</mo><msub><mi>P</mi><mi mathvariant="italic">Guess</mi></msub><mi>P</mi><mfenced><mi>X</mi><mo>|</mo><msup><mi>U</mi><mn>0</mn></msup></mfenced><mo>+</mo><mfenced><mn>1</mn><mo>−</mo><msub><mi>P</mi><mi mathvariant="italic">Guess</mi></msub></mfenced><mi>P</mi><mfenced><mi>X</mi><mo>|</mo><msup><mi>F</mi><mn>0</mn></msup></mfenced></mrow></math><img file="EP3553713A1_D0059.tif" /></maths>

0149This modified Fraud Parameter Prior is used instead of the original Fraud Parameter Prior. In practice, this is done offline and the Risk Engine simply uses the modified Fraud Parameter Prior values.

0150The more interesting and challenging case is when a Fraudster is actually able to observe a User and then to mimic the behavior (or at least the observed parameters). In this case the Impersonation Model must take into account a number of effects as follows: the probability that a Fraudster would try to mimic a particular observed parameter; the probability that the Fraudster is able to observe (or otherwise learn about) a specific behavior (observed parameters) of a specific User (e.g., the Fraudster is able to observe the actual IP address or User Agent string that a User would have while accessing the online application); the probability that the fraudster is able to mimic the specific parameter value that was observed for the User. For any particular parameter this models the probability of the combination of these conditions by a single, statically defined parameter as follows: <maths id="math0059" num="(0.33)"><math display="block"><mrow><msub><mi>P</mi><mi mathvariant="italic">Imp</mi></msub><mo>≜</mo><mi>Probability that Faudster successfully impersonates the parameter value</mi></mrow></math><img file="EP3553713A1_D0060.tif" /></maths>

0151Then, at any point in time the resulting Fraud Model is a probabilistic combination of the original Fraud Model (which is simply the prior) and the Impersonated User Model. <maths id="math0060" num="(0.34)"><math display="block"><mrow><mi>P</mi><mfenced><msup><mi>X</mi><mi>k</mi></msup><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced><mo>=</mo><msub><mi>P</mi><mi mathvariant="italic">Imp</mi></msub><mi>P</mi><mfenced><msup><mi>X</mi><mi>k</mi></msup><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced><mo>+</mo><mfenced><mn>1</mn><mo>−</mo><msub><mi>P</mi><mi mathvariant="italic">Imp</mi></msub></mfenced><mi>P</mi><mfenced><msup><mi>X</mi><mi>k</mi></msup><mo>|</mo><msup><mi>F</mi><mn>0</mn></msup></mfenced></mrow></math><img file="EP3553713A1_D0061.tif" /></maths>

0152This model can be used directly in the calculation of the Likelihood Ratio and Risk for an Event (see Equation(0.6)): <maths id="math0061" num="(0.35)"><math display="block"><mrow><mtable><mtr><mtd><msub><mi>λ</mi><mi mathvariant="italic">Imp</mi></msub></mtd><mtd columnalign="left"><mo>=</mo><mfrac><mrow><msub><mi>P</mi><mi mathvariant="italic">Imp</mi></msub><mi>P</mi><mfenced><msup><mi>X</mi><mi>k</mi></msup><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced><mo>+</mo><mfenced><mn>1</mn><mo>−</mo><msub><mi>P</mi><mi mathvariant="italic">Imp</mi></msub></mfenced><mi>P</mi><mfenced><msup><mi>X</mi><mi>k</mi></msup><mo>|</mo><msup><mi>F</mi><mn>0</mn></msup></mfenced></mrow><mrow><mi>P</mi><mfenced><msup><mi>X</mi><mi>k</mi></msup><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd columnalign="left"><mo>=</mo><msub><mi>P</mi><mi mathvariant="italic">Imp</mi></msub><mo>+</mo><mfenced><mn>1</mn><mo>−</mo><msub><mi>P</mi><mi mathvariant="italic">Imp</mi></msub></mfenced><mfrac><mrow><mi>P</mi><mfenced><msup><mi>X</mi><mi>k</mi></msup><mo>|</mo><msup><mi>F</mi><mn>0</mn></msup></mfenced></mrow><mrow><mi>P</mi><mfenced><msup><mi>X</mi><mi>k</mi></msup><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd columnalign="left"><mo>=</mo><msub><mi>P</mi><mi mathvariant="italic">Imp</mi></msub><mo>+</mo><mfenced><mn>1</mn><mo>−</mo><msub><mi>P</mi><mi mathvariant="italic">Imp</mi></msub></mfenced><mi>λ</mi><mfenced><msup><mi>X</mi><mi>k</mi></msup></mfenced></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0062.tif" /></maths> Therefore, <maths id="math0062" num="(0.36)"><math display="block"><mrow><mi>R</mi><mfenced><msup><mi>X</mi><mi>k</mi></msup></mfenced><mo>=</mo><mi>ln</mi><mfenced><msub><mi>P</mi><mi mathvariant="italic">Imp</mi></msub><mo>+</mo><mfenced><mn>1</mn><mo>−</mo><msub><mi>P</mi><mi mathvariant="italic">Imp</mi></msub></mfenced><mi>λ</mi><mfenced><msup><mi>X</mi><mi>k</mi></msup></mfenced></mfenced><mn>.</mn></mrow></math><img file="EP3553713A1_D0063.tif" /></maths> Looking at the limits, if <i>P_Imp</i> << 1 that if the original Fraud Likelihood Ratio <i>λ</i>(<i>X^k</i>) > 1 (i.e., the original Risk is > 0) that the resulting likelihood ratio and Risk is generally unaffected. However, if <i>λ</i>(<i>X^k</i>) < 1 (i.e., the original Risk is a relatively large negative number) that the inclusion of <i>P_Imp</i> effectively sets a lower bound on the Risk: <maths id="math0063" num="(0.37)"><math display="block"><mrow><mi>R</mi><mfenced><msup><mi>X</mi><mi>k</mi></msup></mfenced><mo>≥</mo><mi>ln</mi><mfenced><msub><mi>P</mi><mi mathvariant="italic">Imp</mi></msub></mfenced></mrow></math><img file="EP3553713A1_D0064.tif" /></maths>

0153Intuitively this makes sense as it essentially says that if a Fraudster could impersonate the observed parameters of a User this should limit the amount of confidence that is placed on observing a parameter value that would normally be expected to be seen from a User. In practice, this becomes useful when the User Model consists of many parameters and <i>P_Imp</i> is defined based on the nature of each parameter. For example, it is much easier to use a proxy that would allow a Fraudster to mimic the country of the user than it would be to mimic the exact city of a user.

0154Also, while the full model expressed in Equation (0.34) can be used, a simplistic model that simply sets a minimum risk according to Equation (0.37) could be used and would provide much of the same value (i.e., by limiting the amount of confidence that observing one expected parameter has on the overall risk score). Thus, <i>P_Imp</i> is interpreted as a conditional probability if the underlying parameter is also conditional.

Fraud Co-Occurrence Model

0155The Fraud Co-Occurrence Model attempts to model the observation that a fraud attack against a single online account often consists of a flurry of sessions. For example: an initial session (or sessions) may be used to steal credentials or to confirm that the stolen credentials are correct and, once that is confirmed, another attack vector will be used to carry out the fraud; multiple sessions may be used, each to carry out a piece of the fraudulent activity in an effort to keep financial activity below the radar of transaction monitoring rules; if one fraud attack is successful against an account, the fraudster may come back and try again.

0156Note that in these cases the sequence of fraudulent sessions may or may not have a similar profile. Also, in most cases the fraudster tries to move as quickly as they can to carry out the fraud before their activity is discovered or their access to the account is shut down. Mathematically, this implies that observing a (potentially) fraudulent session should influence the expectation that a subsequent Event may also be fraudulent. Rewriting Equation (0.3) for Event <i>E^k</i> using the updated User Model <i>U</i>^<i>k</i>-1: <maths id="math0064" num="(0.38)"><math display="block"><mrow><mtable columnalign="left" width="auto"><mtr><mtd><mi>L</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup></mfenced><mo>=</mo><mi mathvariant="italic">ρλ</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup></mfenced></mtd></mtr><mtr><mtd><mi mathvariant="italic">where</mi></mtd></mtr><mtr><mtd><mi>λ</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup></mfenced><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup><mo>|</mo><mi>F</mi></mfenced></mrow><mrow><mi>P</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac><mo>,</mo><mspace width="1em" /><mi mathvariant="italic">and ρ</mi><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><mi>F</mi></mfenced></mrow><mrow><mi>P</mi><mfenced><mi>U</mi></mfenced></mrow></mfrac><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><mi>F</mi></mfenced></mrow><mrow><mn>1</mn><mo>−</mo><mi>P</mi><mfenced><mi>F</mi></mfenced></mrow></mfrac></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0065.tif" /></maths>

0157In this equation <i>P</i>(<i>F</i>) is the <i>a priori</i> probability that any observed Event <i>E</i> is caused by a fraudster rather than the User. In the previous sections, assumptions that each Event is independent and that <i>P</i>(<i>F</i>) is constant such that <i>L</i>(<i>E</i>) and <i>λ</i>(<i>E</i>) can be used as equivalent decision statistics. However, as previously discussed, this is not the case as observing one fraudulent event could change some expectation of seeing fraud (i.e., <i>P</i>(<i>F</i>)) of subsequent events.

0158Note, that in addition to modifying <i>P</i>(<i>F</i>) this could also include some form of dynamic event prediction model for fraud, i.e., <i>P</i>(<i>E^K</i> | <i>F</i>^<i>k</i>-1), which is done for the User Model. However this is a difficult thing to define and would add a lot of complexity to the resulting algorithms and models.

0159Therefore the focus is on modifying the estimate <i>P</i>(<i>F</i>) based on the previous observations (of potentially fraudulent activity). Ideally, this would be done recursively such that the resulting model would not have to remember each previous event.

0160One such model is the exponential decay. This model implements the assumption that subsequent fraudulent activity (on a single account) tends to occur within a limited timeframe (for example, within the same day or a few days). It also takes advantage of the favorable <i>half-life</i> characteristic of the time-based exponential decay model.

0161Specifically, assume a fraudulent Event <i>E_F</i> at time <i>t_F</i> was seen and there is an increased a priori expectation (that decays over time) that if a subsequent Event <i>E'</i> at time <i>t'</i> was seen that it would also be fraud. One way to model this is to use an exponential decay model for the increased a priori expectation based on knowing that <i>E_F</i> was fraud: <maths id="math0065" num="(0.39)"><math display="block"><mrow><mi>P</mi><mfenced><mi mathvariant="italic">Fʹ</mi><mo>|</mo><msub><mi>E</mi><mi>F</mi></msub><mrow><mspace width="1em" /><mi mathvariant="italic">is Fraud</mi></mrow></mfenced><mo>≜</mo><mi>P</mi><mfenced><mi mathvariant="italic">Eʹ is Fraud</mi><mo>|</mo><msub><mi>E</mi><mi>F</mi></msub><mrow><mspace width="1em" /><mi mathvariant="italic">is Fraud</mi></mrow></mfenced><mo>=</mo><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced><mo>+</mo><mfenced><mi>ε</mi><mo>−</mo><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced></mfenced><msup><mi>e</mi><mrow><mo>−</mo><mfenced><mi>l</mi><mo>′</mo><mo>−</mo><msub><mi>t</mi><mi>r</mi></msub></mfenced><mo>/</mo><mi>μ</mi></mrow></msup></mrow></math><img file="EP3553713A1_D0066.tif" /></maths> where <ul id="ul0014" list-style="bullet" compact="compact"><li><i>P</i>(<i>F</i>₀) is the original (before any Events are observed) a priori probability that any Event is fraud</li><li><i>ε</i> is a parameter of the model that defines the new a priori fraud prior immediately after the event <i>E_i</i> is observed.</li><li><i>µ</i> is a parameter of the model that defines the half life decay of the increased fraud expectation.</li></ul>

0162Intuitively, upon seeing the fraudulent event <i>E_F</i>, the a priori expectation of seeing another Fraud Event immediately jumps from <i>P</i>(<i>F</i>₀) to <i>ε</i> and then decays back to <i>P</i>(<i>F</i>₀) with an exponential half-life equal to <i>µ</i>.

0163Of course, in a real situation there is no certainty that some previous Event <i>E_i</i> is fraud. To account for this uncertainty two cases may be considered, with one case conditioned on whether <i>E_i</i> was caused by fraud and another case conditioned on whether <i>E_i</i> was not caused by fraud. The first case uses <i>P</i>(<i>F^k</i> | <i>Eⁱ</i>) as defined above as the subsequent Fraud Prior while the second uses the original Fraud Prior <i>P</i>(<i>F</i>₀) : <maths id="math0066" num="(0.40)"><math display="block"><mrow><mi>P</mi><mfenced><msup><mi>F</mi><mi>k</mi></msup><mo>|</mo><msup><mi>E</mi><mi>i</mi></msup></mfenced><mo>=</mo><mi>P</mi><mfenced><msup><mi>F</mi><mi>k</mi></msup><mo>|</mo><msup><mi>E</mi><mi>i</mi></msup><mrow><mspace width="1em" /><mi mathvariant="italic">is Fraud</mi></mrow></mfenced><mi>P</mi><mfenced><msup><mi>F</mi><mi>i</mi></msup><mo>|</mo><msup><mi>E</mi><mi>i</mi></msup></mfenced><mo>+</mo><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced><mfenced><mn>1</mn><mo>−</mo><mi>P</mi><mfenced><msup><mi>F</mi><mi>i</mi></msup><mo>|</mo><msup><mi>E</mi><mi>i</mi></msup></mfenced></mfenced></mrow></math><img file="EP3553713A1_D0067.tif" /></maths>

0164Using Equation (0.21) substitute <i>P</i>(<i>Fⁱ</i> | <i>Eⁱ</i>) = 1 - <i>T_E</i> and rewrite as: <maths id="math0067" num="(0.41)"><math display="block"><mrow><mtable><mtr><mtd><mi>P</mi><mfenced><msup><mi>F</mi><mi>k</mi></msup><mo>|</mo><msup><mi>E</mi><mi>i</mi></msup></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced><msub><mi>T</mi><mrow><msup><mi>E</mi><mi>i</mi></msup></mrow></msub><mo>+</mo><mfenced open="[" close="]"><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced><mo>+</mo><mfenced><mi>ε</mi><mo>−</mo><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced></mfenced><mi>e</mi></mfenced><mfenced><mn>1</mn><mo>−</mo><msub><mi>T</mi><mrow><msup><mi>E</mi><mi>i</mi></msup></mrow></msub></mfenced></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd columnalign="left"><mo>=</mo><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced><mo>+</mo><mfenced><mn>1</mn><mo>−</mo><msub><mi>T</mi><mrow><msup><mi>E</mi><mi>i</mi></msup></mrow></msub></mfenced><mfenced><mi>ε</mi><mo>−</mo><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced></mfenced><msup><mi>e</mi><mrow><mfenced><msub><mi>t</mi><mi>k</mi></msub><mo>−</mo><msub><mi>t</mi><mi>i</mi></msub></mfenced><mo>/</mo><mi>μ</mi></mrow></msup></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0068.tif" /></maths> Note, for any interesting case, <i>ε</i> >> <i>P</i>(<i>F</i>₀) this can further simplify as: <maths id="math0068" num="(0.42)"><math display="block"><mrow><mi>P</mi><mfenced><msup><mi>F</mi><mi>k</mi></msup><mo>|</mo><msup><mi>E</mi><mi>i</mi></msup></mfenced><mo>≈</mo><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced><mo>+</mo><mfenced><mn>1</mn><mo>−</mo><msub><mi>T</mi><mrow><msup><mi>E</mi><mi>i</mi></msup></mrow></msub></mfenced><msup><mi mathvariant="italic">εe</mi><mrow><mfenced><msub><mi>t</mi><mi>k</mi></msub><mo>−</mo><msub><mi>t</mi><mi>i</mi></msub></mfenced><mo>/</mo><mi>μ</mi></mrow></msup></mrow></math><img file="EP3553713A1_D0069.tif" /></maths> which is the new Fraud Prior based on some previous, potentially fraudulent Event <i>E_i</i>. Note, alternatively, this could define <i>ε</i> as the increase in the fraud prior and in this case Equation (0.42) would be exact In practice both methods are equivalent.

0165There are potentially many previously observed Events (for this User Account) and in general the possible contribution of each should be considered. This is done by introducing a Fraud Co-Occurrence Update Model

0166Since the decay in the increased fraud expectation is exponential, the proportion of decay from any single Event only depends on the length of the decay interval and that <i>e</i>^{-(<i>t_k</i>-<i>t_i</i>)/<i>µ</i>} = <i>e</i>^{-(<i>t_k</i>-<i>t</i><sub2><i>k</i>-1</sub2>)/}<i>^µ e</i>^{-(<i>t</i><sub2><i>k</i>-1</sub2>-t<i>_i</i>)/<i>µ</i>}. This allows a recursive model to be defined for the Fraud Prior for the next observed Event <i>E^k</i> based on all previously observed Events {<i>E</i>¹,...,<i>E</i>^<i>k</i>-1} as: <maths id="math0069" num="(0.43)"><math display="block"><mrow><mtable><mtr><mtd columnalign="left"><mi>P</mi><mfenced><msup><mi>F</mi><mi>k</mi></msup></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced><mo>+</mo><msub><mi>γ</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msub><mi>ε</mi><msup><mi>e</mi><mrow><mfenced><mfrac><mrow><mo>−</mo><msub><mi>t</mi><mi>k</mi></msub><mo>−</mo><msub><mi>t</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msub></mrow><mi mathvariant="italic">µ</mi></mfrac></mfenced></mrow></msup></mtd></mtr><mtr><mtd columnalign="left"><msub><mi>γ</mi><mi>k</mi></msub></mtd><mtd columnalign="left"><mo>=</mo><mi>g</mi><mfenced separators=",,"><msub><mi>γ</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msub><msub><mi>T</mi><mrow><msup><mi>E</mi><mi>k</mi></msup></mrow></msub><mfenced><msub><mi>t</mi><mi>k</mi></msub><mo>−</mo><msub><mi>t</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msub></mfenced></mfenced></mtd></mtr><mtr><mtd columnalign="left"><msub><mi>γ</mi><mn>0</mn></msub></mtd><mtd columnalign="left"><mo>=</mo><mn>0</mn></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0070.tif" /></maths>

0167In this formulation, <i>γ</i>_<i>k</i>-1 essentially represents the <i>Accumulated Mistrust</i> through observed Event <i>E</i>^<i>k</i>-1. The choice of the update function <i>γ_k</i> = <i>g</i> ( ) defines how the affect from multiple Events are combined. A simple recursive update model that behaves as intended can be defined as: <maths id="math0070" num="(0.44)"><math display="block"><mrow><msub><mi>γ</mi><mi>k</mi></msub><mo>=</mo><mi>max</mi><mfenced><mfenced><mn>1</mn><mo>−</mo><msub><mi>T</mi><mrow><msup><mi>E</mi><mi>k</mi></msup></mrow></msub></mfenced><mo>,</mo><msub><mi>γ</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msub><msup><mi>e</mi><mrow><mo>−</mo><mrow><mfenced><msub><mi>t</mi><mi>k</mi></msub><mo>−</mo><msub><mi>t</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msub></mfenced><mo>/</mo><mi mathvariant="italic">µ</mi></mrow></mrow></msup></mfenced></mrow></math><img file="EP3553713A1_D0071.tif" /></maths>

0168Other variations are possible by using some accumulation of previous events while ensuring that <i>γ_k</i> ≤ 1. For example, an alternative model could allow <i>γ_k</i> to grow to some value if there is a plethora of highly suspicious events. For example, <maths id="math0071" num="(0.45)"><math display="block"><mrow><msub><mi>γ</mi><mi>k</mi></msub><mo>=</mo><mfenced><mn>1</mn><mo>−</mo><msub><mi>T</mi><mrow><msup><mi>E</mi><mi>k</mi></msup></mrow></msub></mfenced><mo>+</mo><msub><mi>γ</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msub><msup><mi>e</mi><mrow><mo>−</mo><mfenced><msub><mi>t</mi><mi>k</mi></msub><mo>−</mo><msub><mi>t</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msub></mfenced><mo>/</mo><mi mathvariant="italic">µ</mi></mrow></msup><mn>.</mn></mrow></math><img file="EP3553713A1_D0072.tif" /></maths>

0169The calculation of the Likelihood Ratio and associated Risk Score using the Fraud Co-Occurrence model can use Equation (0.42) directly. Though it is useful to see (and probably implement) the relative affect of this component To do so, the Fraud Co-Occurrence Coefficient Γ<i>^k</i> is defined to be <maths id="math0072" num="(0.46)"><math display="block"><mrow><mtable><mtr><mtd><msup><mi mathvariant="normal">Γ</mi><mi>k</mi></msup></mtd><mtd columnalign="left"><mo>≜</mo><mfrac><mrow><mover><mi>L</mi><mrow><mo>‾</mo></mrow></mover><mfenced><msup><mi>E</mi><mi>k</mi></msup></mfenced></mrow><mrow><mi>L</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup></mfenced></mrow></mfrac></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd><mo>=</mo><mfrac><mrow><mfrac><mrow><mi>P</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup><mo>|</mo><mi>F</mi></mfenced></mrow><mrow><mi>P</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac><mfenced><mfrac><mrow><mi>P</mi><mfenced><msup><mi>F</mi><mi>k</mi></msup></mfenced></mrow><mrow><mn>1</mn><mo>−</mo><mi>P</mi><mfenced><msup><mi>F</mi><mi>k</mi></msup></mfenced></mrow></mfrac></mfenced></mrow><mrow><mfrac><mrow><mi>P</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup><mo>|</mo><mi>F</mi></mfenced></mrow><mrow><mi>P</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac><mfenced><mfrac><mrow><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced></mrow><mrow><mn>1</mn><mo>−</mo><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced></mrow></mfrac></mfenced></mrow></mfrac></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0073.tif" /></maths> In this case <i>L</i> is the original Likelihood Ratio and <i><o ostyle="single">L</o></i> is the Likelihood Ratio that incorporates the Fraud Co-Occurrence Model. Observing that the first terms in both cases are identical and <i>F</i>₀ &lt;&lt; 1, this simplifies to: <maths id="math0073" num="(0.47)"><math display="block"><mrow><msup><mi mathvariant="normal">Γ</mi><mi>k</mi></msup><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><msup><mi>F</mi><mi>k</mi></msup></mfenced></mrow><mrow><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced><mfenced><mn>1</mn><mo>−</mo><mi>P</mi><mfenced><msup><mi>F</mi><mi>k</mi></msup></mfenced></mfenced></mrow></mfrac></mrow></math><img file="EP3553713A1_D0074.tif" /></maths>

0170Substituting Equation (0.43), provides: <maths id="math0074" num="(0.48)"><math display="block"><mrow><msup><mi mathvariant="normal">Γ</mi><mi>k</mi></msup><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced><mo>+</mo><msub><mi>γ</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msub><mi>ε</mi><msup><mi>e</mi><mrow><mfenced><mfrac><mrow><mo>−</mo><mfenced><msub><mi>t</mi><mi>k</mi></msub><mo>−</mo><msub><mi>t</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msub></mfenced></mrow><mi mathvariant="italic">µ</mi></mfrac></mfenced></mrow></msup></mrow><mrow><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced><mfenced><mn>1</mn><mo>−</mo><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced><mo>−</mo><msub><mi>γ</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msub><msup><mi mathvariant="italic">εe</mi><mrow><mfenced><mfrac><mrow><mo>−</mo><mfenced><msub><mi>t</mi><mi>k</mi></msub><mo>−</mo><msub><mi>t</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msub></mfenced></mrow><mi mathvariant="italic">µ</mi></mfrac></mfenced></mrow></msup></mfenced></mrow></mfrac></mrow></math><img file="EP3553713A1_D0075.tif" /></maths> And finally, observing that for any case of interest <i>P</i>(<i>F</i>₀) &lt;&lt; 1 - <i>ε</i>, this arrives at: <maths id="math0075" num="(0.49)"><math display="block"><mrow><mtable columnalign="left" width="auto"><mtr><mtd><msup><mi mathvariant="normal">Γ</mi><mi>k</mi></msup><mo>=</mo><mfrac><mrow><mn>1</mn><mo>+</mo><mi mathvariant="normal">E</mi><mi>a</mi></mrow><mrow><mn>1</mn><mo>−</mo><mi mathvariant="italic">εa</mi></mrow></mfrac></mtd></mtr><mtr><mtd><mi mathvariant="italic">where</mi></mtd></mtr><mtr><mtd><mi mathvariant="normal">E</mi><mo>=</mo><mfrac><mi>ε</mi><mrow><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced></mrow></mfrac></mtd></mtr><mtr><mtd><mi>a</mi><mo>=</mo><msub><mi>γ</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msub><msup><mi>e</mi><mfenced><mfrac><mrow><mo>−</mo><mfenced><msub><mi>t</mi><mi>k</mi></msub><mo>−</mo><msub><mi>t</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msub></mfenced></mrow><mi mathvariant="italic">µ</mi></mfrac></mfenced></msup></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0076.tif" /></maths> so that: <maths id="math0076" num="(0.50)"><math display="block"><mrow><mtable columnalign="left" width="auto"><mtr><mtd><mover><mi>L</mi><mrow><mo>‾</mo></mrow></mover><mfenced><msup><mi>E</mi><mi>k</mi></msup></mfenced><mo>=</mo><msup><mi mathvariant="normal">Γ</mi><mi>k</mi></msup><mi>L</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup></mfenced></mtd></mtr><mtr><mtd><mi>and</mi></mtd></mtr><mtr><mtd><mover><mi>R</mi><mrow><mo>‾</mo></mrow></mover><mfenced><msup><mi>E</mi><mi>k</mi></msup></mfenced><mo>=</mo><mi>ln</mi><mfenced><msup><mi mathvariant="normal">Γ</mi><mi>k</mi></msup></mfenced><mo>+</mo><mi>R</mi><mfenced><msup><mi>E</mi><mi>k</mi></msup></mfenced></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0077.tif" /></maths>

0171Hence, the Fraud Co-Occurrence Model essentially increases the Risk of a subsequent Event by an amount determined by the Accumulated Mistrust derived recursively from previous Events.

The Session Model

0172In addition to determining the risk of a single Event, the FPS can determine the risk of a sequence of related events. For example, in the context of online activity, a online session consists of one Login Event followed by one or more Activity Events (for example, checking an account balance, initiating a money transfer, viewing a check image, etc) and then some form of Termination Event (either an explicit logout by the user or some form of session timeout).

0173Consideration is given to a Generic Session Model that comprises 0, 1 or more observations of Activity Events. It is recognized that at any point in time a Session can be <i>Open</i> (where observing additional Activities) or <i>Closed</i> (and no additional Activities can be observed).

0174The <i>k^th</i> Session for a User is denoted as: <maths id="math0077" num="(0.51)"><math display="block"><mrow><msub><mi>S</mi><mi>k</mi></msub><mo>=</mo><mfenced separators=",,,"><msub><mi>A</mi><mn>1</mn></msub><msub><mi>A</mi><mn>2</mn></msub><mn>...</mn><msub><mi>A</mi><mi>N</mi></msub></mfenced><mo>,</mo></mrow></math><img file="EP3553713A1_D0078.tif" /></maths> where <i>A_n</i> is an observed Activity Event. Every Activity Event <i>A_n</i> has a Type (or Class) attribute <i>C_n</i> that takes the value of one of a set of predefined Types and a set of observed parameters that we designate by the vector <i>V_n</i>. Explicitly: <maths id="math0078" num="(0.52)"><math display="block"><mrow><mtable columnalign="left" width="auto"><mtr><mtd><msub><mi>A</mi><mi>n</mi></msub><mo>=</mo><mfenced separators=","><msub><mi>C</mi><mi>n</mi></msub><msub><mi>V</mi><mi>n</mi></msub></mfenced></mtd></mtr><mtr><mtd><msub><mi>C</mi><mi>n</mi></msub><mo>∈</mo><mfenced open="{" close="}" separators=",,,"><msup><mi>c</mi><mn>1</mn></msup><msup><mi>c</mi><mn>2</mn></msup><mn>...</mn><msup><mi>c</mi><mi>m</mi></msup></mfenced></mtd></mtr><mtr><mtd><msub><mi>V</mi><mi>n</mi></msub><mo>=</mo><mfenced separators=",,,"><msup><mi>v</mi><mn>1</mn></msup><msup><mi>v</mi><mn>2</mn></msup><mn>...</mn><msup><mi>v</mi><mi>p</mi></msup></mfenced></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0079.tif" /></maths> Differentiations can be made between an <i>Open Session</i> (a Session that may receive future Activity Events) and a <i>Closed Session</i> (a Session that may not receive future Activity Events). When necessary, an Open Session is designated as <img file="EP3553713A1_D0080.tif" /> and a Closed Session is designated as <img file="EP3553713A1_D0081.tif" /> .

0175In general, the likelihood ratio and associated Risk for the Session as: <maths id="math0079" num="(0.53)"><math display="block"><mrow><mtable><mtr><mtd><mi>λ</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow><mrow><mi>P</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd columnalign="left"><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><msub><mi>A</mi><mn>1</mn></msub><mo>,</mo><msub><mi>A</mi><mn>2</mn></msub><mo>,</mo><mn>...</mn><mo>,</mo><msub><mi>A</mi><mi>N</mi></msub><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow><mrow><mi>P</mi><mfenced><msub><mi>A</mi><mn>1</mn></msub><mo>,</mo><msub><mi>A</mi><mn>2</mn></msub><mo>,</mo><mn>...</mn><mo>,</mo><msub><mi>A</mi><mi>N</mi></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mtd></mtr><mtr><mtd><mi>R</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mi>log</mi><mfenced><mi>λ</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mfenced></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0082.tif" /></maths>

0176An Online Login Session is a special case of the Generic Session Model. Specifically, (ignoring cases with failed logins), an Online Login Session starts with a Login Event (which initiates an Open Session), then has 0, 1 or more Activity Events and eventually ends with some form of Termination Event which also serves to Close the Session. The Termination Event could be an explicit Log Out by the user, or it could be a timeout by the Online Banking Application or the Risk Engine.

0177Essentially, the Login and Termination Events are special types of Events that also designate the start and end of a Session. The corresponding Open and Closed Sessions are defined as: <maths id="math0080" num="(0.54)"><math display="block"><mrow><mtable><mtr><mtd><msub><mi>S̆</mi><mi>k</mi></msub></mtd><mtd columnalign="left"><mo>=</mo><mfenced open="{" close="}" separators=",,,,"><mi>L</mi><msub><mi>A</mi><mn>1</mn></msub><msub><mi>A</mi><mn>2</mn></msub><mn>...</mn><msub><mi>A</mi><mi>N</mi></msub></mfenced></mtd></mtr><mtr><mtd><msub><mi>S̑</mi><mi>k</mi></msub></mtd><mtd columnalign="left"><mo>=</mo><mfenced open="{" close="}" separators=",,,,,"><mi>L</mi><msub><mi>A</mi><mn>1</mn></msub><msub><mi>A</mi><mn>2</mn></msub><mn>...</mn><msub><mi>A</mi><mi>N</mi></msub><mi>T</mi></mfenced></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0083.tif" /></maths> In these definitions <i>L</i> denotes the Login Event and <i>T</i> denotes the Termination Event By definition, there can be one and only one Login Event. Likewise, for a Closed Session there is one and only one Termination Event while Open Sessions do not have a Termination Event. In general, both <i>L</i> and <i>T</i> may have parameters and types associated with them.

0178In most cases we can safely assume that both the Login Event and Termination Event are conditionally independent of each other and all other Activity Events given either the specific User or Fraud model. This allows for the rewriting of Equation (0.53) for an Online Login Session Model as: <maths id="math0081" num="(0.55)"><math display="block"><mrow><mtable><mtr><mtd><mtable><mtr><mtd><mi>λ</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow><mrow><mi>P</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd columnalign="left"><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><mi>L</mi><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced><mi>P</mi><mfenced><mi>T</mi><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced><mi>P</mi><mfenced><msub><mi>A</mi><mn>1</mn></msub><mo>,</mo><msub><mi>A</mi><mn>2</mn></msub><mo>,</mo><mn>...</mn><mo>,</mo><msub><mi>A</mi><mi>N</mi></msub><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow><mrow><mi>P</mi><mfenced><mi>L</mi><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced><mi>P</mi><mfenced><mi>T</mi><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced><mi>P</mi><mfenced><msub><mi>A</mi><mn>1</mn></msub><mo>,</mo><msub><mi>A</mi><mn>2</mn></msub><mo>,</mo><mn>...</mn><mo>,</mo><msub><mi>A</mi><mi>N</mi></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mtd></mtr></mtable></mtd></mtr><mtr><mtd columnalign="left"><mi mathvariant="italic">and</mi></mtd></mtr><mtr><mtd columnalign="left"><mtable><mtr><mtd><mi>R</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mi>log</mi><mfenced><mi>λ</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mfenced></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd columnalign="left"><mo>=</mo><msub><mi>R</mi><mi>L</mi></msub><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced><mo>+</mo><msub><mi>R</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow></msub><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced><mo>+</mo><msub><mi>R</mi><mi>T</mi></msub><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mtd></mtr></mtable></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0084.tif" /></maths> where: <ul id="ul0015" list-style="bullet" compact="compact"><li><maths id="math0082"><math display="inline"><mrow><msub><mi>R</mi><mi>L</mi></msub><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced><mo>=</mo><mi>log</mi><mfrac><mrow><mi>P</mi><mfenced><msub><mi>L</mi><mi>k</mi></msub><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow><mrow><mi>P</mi><mfenced><msub><mi>L</mi><mi>k</mi></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mrow></math><img file="EP3553713A1_D0085.tif" /></maths> is the Risk of the Login Event which can be computed as described above</li><li><maths id="math0083"><math display="inline"><mrow><msub><mi>R</mi><mi>T</mi></msub><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced><mo>=</mo><mi>log</mi><mfrac><mrow><mi>P</mi><mfenced><msub><mi>T</mi><mi>k</mi></msub><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow><mrow><mi>P</mi><mfenced><msub><mi>T</mi><mi>k</mi></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mrow></math><img file="EP3553713A1_D0086.tif" /></maths> is the Risk of the Termination Event. This can incorporate previous or expected behavior (for example, the User may always explicitly log out). In most situations both conditional probabilities are constant and usually equal to each other so this entire term can safely be ignored.</li><li><maths id="math0084"><math display="inline"><mrow><msub><mi>R</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow></msub><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced><mo>=</mo><mi>R</mi><mfenced><msub><mi>A</mi><mn>1</mn></msub><mo>,</mo><msub><mi>A</mi><mn>2</mn></msub><mo>,</mo><mo>…</mo><mo>,</mo><msub><mi>A</mi><mi>N</mi></msub></mfenced><mo>=</mo><mi>log</mi><mfrac><mrow><mi>P</mi><mfenced><msub><mi>A</mi><mn>1</mn></msub><mo>,</mo><msub><mi>A</mi><mn>2</mn></msub><mo>,</mo><mo>…</mo><mo>,</mo><msub><mi>A</mi><mi>N</mi></msub><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow><mrow><mi>P</mi><mfenced><msub><mi>A</mi><mn>1</mn></msub><mo>,</mo><msub><mi>A</mi><mn>2</mn></msub><mo>,</mo><mo>…</mo><mo>,</mo><msub><mi>A</mi><mi>N</mi></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mrow></math><img file="EP3553713A1_D0087.tif" /></maths> is the combined Risk of all Activity Events within the Session (aka <i>Activity Risk</i>) and is described below.</li></ul>

Calculating the Combined Activity Risk

0179An estimate of the Activity Likelihood Ratio and associated Activity Risk for Session <i>S_k</i> are provided as: <maths id="math0085" num="(0.56)"><math display="block"><mrow><mtable><mtr><mtd><msub><mi>λ</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow></msub><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mtd><mtd><mo>≜</mo><mi>λ</mi><mfenced separators=",,,"><msub><mi>A</mi><mn>1</mn></msub><msub><mi>A</mi><mn>2</mn></msub><mn>...</mn><msub><mi>A</mi><mi>N</mi></msub></mfenced><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><msub><mi>A</mi><mn>1</mn></msub><mo>,</mo><msub><mi>A</mi><mn>2</mn></msub><mo>,</mo><mn>...</mn><mo>,</mo><msub><mi>A</mi><mi>N</mi></msub><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow><mrow><mi>P</mi><mfenced><msub><mi>A</mi><mn>1</mn></msub><mo>,</mo><msub><mi>A</mi><mn>2</mn></msub><mo>,</mo><mn>...</mn><mo>,</mo><msub><mi>A</mi><mi>N</mi></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mtd></mtr><mtr><mtd><msub><mi>R</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow></msub><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mtd><mtd columnalign="left"><mo>≜</mo><mi>R</mi><mfenced separators=",,,"><msub><mi>A</mi><mn>1</mn></msub><msub><mi>A</mi><mn>2</mn></msub><mn>...</mn><msub><mi>A</mi><mi>N</mi></msub></mfenced><mo>=</mo><mi>log</mi><mfenced><mi>λ</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mfenced></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0088.tif" /></maths>

0180It is impractical to calculate this general form. However, estimating these terms using simpler models that are more tractable to work with captures the most salient affects. There are many ways to approach this problem. For this description the general form has been broken into three components as <maths id="math0086" num="(0.57)"><math display="block"><mrow><msub><mi>λ</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow></msub><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced><mo>≈</mo><msubsup><mi>λ</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">freq</mi></msubsup><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced><mo>×</mo><msubsup><mi>λ</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">order</mi></msubsup><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced><mo>×</mo><msubsup><mi>λ</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">params</mi></msubsup><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mrow></math><img file="EP3553713A1_D0089.tif" /></maths> where <ul id="ul0016" list-style="bullet" compact="compact"><li><maths id="math0087"><math display="inline"><mrow><msubsup><mi>λ</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">freq</mi></msubsup><mo>=</mo><mi mathvariant="italic">Activity Type Frequency Model</mi></mrow></math><img file="EP3553713A1_D0090.tif" /></maths> is the combined contribution from each Activity in the Session of the observed count of each Activity Type</li><li><maths id="math0088"><math display="inline"><mrow><msubsup><mi>λ</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">order</mi></msubsup><mo>=</mo><mi mathvariant="italic">Activity Type Order Model</mi></mrow></math><img file="EP3553713A1_D0091.tif" /></maths> is the combined contribution from each Activity in the Session of the specific order of the observed Activity Types. This defines <maths id="math0089"><math display="inline"><mrow><msubsup><mi>λ</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">order</mi></msubsup></mrow></math><img file="EP3553713A1_D0092.tif" /></maths> such that the underlying probability of any possible order is conditioned on the Activity Type Count.</li><li><maths id="math0090"><math display="inline"><mrow><msubsup><mi>λ</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">params</mi></msubsup><mo>=</mo><mi mathvariant="italic">Activity Type Parameter Model</mi></mrow></math><img file="EP3553713A1_D0093.tif" /></maths> is the combined contribution of the specific observed parameters for each Activity in the Session. This defines <maths id="math0091"><math display="inline"><mrow><msubsup><mi>λ</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">params</mi></msubsup></mrow></math><img file="EP3553713A1_D0094.tif" /></maths> such that the underlying probability likelihoods are conditioned on the Type of the observed Activity and in general they may be dependent on previously observed Activities.</li></ul>

0181By taking the natural log, the corresponding Risk values are defined as <maths id="math0092" num="(0.58)"><math display="block"><mrow><msub><mi>R</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow></msub><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced><mo>=</mo><msubsup><mi>R</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">freq</mi></msubsup><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced><mo>+</mo><msubsup><mi>R</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">order</mi></msubsup><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced><mo>+</mo><msubsup><mi>R</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">params</mi></msubsup><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mrow></math><img file="EP3553713A1_D0095.tif" /></maths>

0182Consideration is given to each term.

0183For a Closed Session, <maths id="math0093"><math display="inline"><mrow><msubsup><mi>λ</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">freq</mi></msubsup></mrow></math><img file="EP3553713A1_D0096.tif" /></maths> can be written as a product of likelihood ratios where the individual terms correspond to the expectation of seeing the observed number <i>n_c</i> of each Activity Type <i>c</i> : <maths id="math0094" num="(0.59)"><math display="block"><mrow><msubsup><mi>λ</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">freq</mi></msubsup><mfenced><msub><mrow><mover><mi>S</mi><mrow><mo>^</mo></mrow></mover></mrow><mi>k</mi></msub></mfenced><mo>=</mo><mrow><mstyle displaystyle="true"><mrow><munder><mrow><mo>∏</mo></mrow><mrow><mi>c</mi><mo>∈</mo><mfenced open="{" close="}" separators=",,,"><msup><mi>c</mi><mn>1</mn></msup><msup><mi>c</mi><mn>2</mn></msup><mspace width="1em" /><msup><mi>c</mi><mi>M</mi></msup></mfenced></mrow></munder></mrow></mstyle><mrow><mfrac><mrow><mi>p</mi><mfenced><msub><mi>N</mi><mi>c</mi></msub><mo>=</mo><msub><mi>n</mi><mi>c</mi></msub><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow><mrow><mi>P</mi><mfenced><msub><mi>N</mi><mi>c</mi></msub><mo>=</mo><msub><mi>n</mi><mi>c</mi></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mrow></mrow></mrow></math><img file="EP3553713A1_D0097.tif" /></maths> Similarly, the Risk of an Open Session can be computed. However, for an Open Session the minimum number Activities that will be observed for that session might be known. This is manifested by using ≥ instead of = within the probabilities: <maths id="math0095" num="(0.60)"><math display="block"><mrow><msubsup><mi>λ</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">freq</mi></msubsup><mfenced><msub><mi>S̆</mi><mi>k</mi></msub></mfenced><mo>=</mo><mrow><mstyle displaystyle="true"><mrow><munder><mrow><mo>∏</mo></mrow><mrow><mi>c</mi><mo>∈</mo><mfenced open="{" close="}" separators=",,,"><msup><mi>c</mi><mn>1</mn></msup><msup><mi>c</mi><mn>2</mn></msup><mspace width="1em" /><msup><mi>c</mi><mi>M</mi></msup></mfenced></mrow></munder></mrow></mstyle><mfrac><mrow><mi>P</mi><mfenced><msub><mi>N</mi><mi>c</mi></msub><mo>≥</mo><msub><mi>n</mi><mi>c</mi></msub><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow><mrow><mi>P</mi><mfenced><msub><mi>N</mi><mi>c</mi></msub><mo>≥</mo><msub><mi>n</mi><mi>c</mi></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mrow></mrow></math><img file="EP3553713A1_D0098.tif" /></maths> Similarly, the associated <maths id="math0096"><math display="inline"><mrow><msubsup><mi>R</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">freq</mi></msubsup></mrow></math><img file="EP3553713A1_D0099.tif" /></maths> values can be computed as: <maths id="math0097" num="(0.61)"><math display="block"><mrow><mtable columnalign="left" width="auto"><mtr><mtd><msubsup><mi>R</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">freq</mi></msubsup><mfenced><msub><mrow><mover><mi>S</mi><mrow><mo>^</mo></mrow></mover></mrow><mi>k</mi></msub></mfenced><mo>=</mo><mstyle displaystyle="false"><mrow><mstyle displaystyle="true"><mrow><munder><mrow><mo>∑</mo></mrow><mrow><mi>c</mi><mo>∈</mo><mfenced open="{" close="}" separators=",,,"><msup><mi>c</mi><mn>1</mn></msup><msup><mi>c</mi><mn>2</mn></msup><mspace width="1em" /><msup><mi>c</mi><mi>M</mi></msup></mfenced></mrow></munder></mrow></mstyle><mi>log</mi><mfenced><mfrac><mrow><mi>P</mi><mfenced><msub><mi>N</mi><mi>c</mi></msub><mo>=</mo><msub><mi>n</mi><mi>c</mi></msub><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow><mrow><mi>P</mi><mfenced><msub><mi>N</mi><mi>c</mi></msub><mo>=</mo><msub><mi>n</mi><mi>c</mi></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mfenced></mrow></mstyle></mtd></mtr><mtr><mtd><mi mathvariant="italic">and</mi></mtd></mtr><mtr><mtd><msubsup><mi>R</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">freq</mi></msubsup><mfenced><msub><mi>S̆</mi><mi>k</mi></msub></mfenced><mo>=</mo><mstyle displaystyle="false"><mrow><mstyle displaystyle="true"><mrow><munder><mrow><mo>∑</mo></mrow><mrow><mi>c</mi><mo>∈</mo><mfenced open="{" close="}" separators=",,,"><msup><mi>c</mi><mn>1</mn></msup><msup><mi>c</mi><mn>2</mn></msup><mspace width="1em" /><msup><mi>c</mi><mi>M</mi></msup></mfenced></mrow></munder></mrow></mstyle><mi>log</mi><mfenced><mfrac><mrow><mi>P</mi><mfenced><msub><mi>N</mi><mi>c</mi></msub><mo>≥</mo><msub><mi>n</mi><mi>c</mi></msub><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow><mrow><mi>P</mi><mfenced><msub><mi>N</mi><mi>c</mi></msub><mo>≥</mo><msub><mi>n</mi><mi>c</mi></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mfenced></mrow></mstyle></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0100.tif" /></maths> Note that all Activity Types are included in the calculation even if no specific Activities of that type are observed in the Session.

0184In most cases the specific order of activities within a session is not statistically different whether conducted by a fraudster or a user. Mathematically this means assumptions might be made that: <maths id="math0098"><math display="block"><mrow><msubsup><mi>λ</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">order</mi></msubsup><mo>=</mo><mn>1</mn></mrow></math><img file="EP3553713A1_D0101.tif" /></maths><maths id="math0099"><math display="block"><mrow><msubsup><mi>R</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">order</mi></msubsup><mo>=</mo><mn>0</mn></mrow></math><img file="EP3553713A1_D0102.tif" /></maths>

0185In the most general case, the expected probability distributions of the observed parameters of each Activity can be dependent on previously observed Activities. Also, in general, the relevant previous Activities could have occurred in this or some other earlier session (or a combination of both). Information from previous sessions is contained in the updated User Activity Model <i>U</i>^<i>k</i>-1 and the updated Fraud Activity Model <i>F</i>^<i>k</i>-1 (if one is used). Information about a previous Activity that occurred within the current session is available directly as all information about Activities are maintained for the life of a Session.

0186Therefore, in the most general form, <maths id="math0100"><math display="inline"><mrow><msubsup><mi>λ</mi><mi>A</mi><mi mathvariant="italic">params</mi></msubsup></mrow></math><img file="EP3553713A1_D0103.tif" /></maths> can be written as a product of the likelihood of each Activity: <maths id="math0101" num="(0.62)"><math display="block"><mrow><mtable><mtr><mtd columnalign="left"><msubsup><mi>λ</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">params</mi></msubsup><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mrow><mstyle displaystyle="true"><mrow><munder><mrow><mo>∏</mo></mrow><mi>J</mi></munder></mrow></mstyle><msubsup><mi>λ</mi><mrow><msub><mi>A</mi><mi>i</mi></msub></mrow><mi mathvariant="italic">params</mi></msubsup></mrow></mtd></mtr><mtr><mtd columnalign="left"><mi mathvariant="italic">where</mi></mtd><mtd columnalign="left"><mspace width="1em" /></mtd></mtr><mtr><mtd columnalign="left"><msubsup><mi>λ</mi><mrow><msub><mi>A</mi><mi>J</mi></msub></mrow><mi mathvariant="italic">params</mi></msubsup></mtd><mtd columnalign="left"><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><msub><mi>V</mi><mi>J</mi></msub><mo>|</mo><msub><mi>C</mi><mi>J</mi></msub><mo>,</mo><msub><mi>A</mi><mn>1</mn></msub><mo>,</mo><msub><mi>A</mi><mn>2</mn></msub><mo>,</mo><mn>...</mn><mo>,</mo><msub><mi>A</mi><mrow><mi>j</mi><mo>−</mo><mn>1</mn></mrow></msub><mo>,</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow><mrow><mi>P</mi><mfenced><msub><mi>V</mi><mi>J</mi></msub><mo>|</mo><msub><mi>C</mi><mn>1</mn></msub><mo>,</mo><msub><mi>A</mi><mn>1</mn></msub><mo>,</mo><msub><mi>A</mi><mn>2</mn></msub><mo>,</mo><mn>...</mn><mo>,</mo><msub><mi>A</mi><mrow><mi>j</mi><mo>−</mo><mn>1</mn></mrow></msub><mo>,</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0104.tif" /></maths>

0187And similarly: <maths id="math0102" num="(0.63)"><math display="block"><mrow><mtable><mtr><mtd><msubsup><mi>R</mi><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mi mathvariant="italic">params</mi></msubsup><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mstyle displaystyle="false"><mrow><mstyle displaystyle="true"><mrow><munder><mo>∑</mo><mi>j</mi></munder></mrow></mstyle><mrow><msubsup><mi>R</mi><mrow><msub><mi>A</mi><mi>j</mi></msub></mrow><mi mathvariant="italic">params</mi></msubsup></mrow></mrow></mstyle></mtd></mtr><mtr><mtd columnalign="left"><mi mathvariant="italic">where</mi></mtd><mtd><mspace width="1em" /></mtd></mtr><mtr><mtd columnalign="left"><msubsup><mi>R</mi><mrow><msub><mi>A</mi><mi>j</mi></msub></mrow><mi mathvariant="italic">params</mi></msubsup></mtd><mtd columnalign="left"><mo>=</mo><mi>log</mi><mfenced><msubsup><mi>λ</mi><mrow><msub><mi>A</mi><mi>j</mi></msub></mrow><mi mathvariant="italic">params</mi></msubsup></mfenced></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0105.tif" /></maths>

0188In most cases the parameters of an Activity are independent of previous Activities (the Type of the Activity may already have been conditioned). If the parameters of an Activity are independent of any previous activities, then <maths id="math0103" num="(0.64)"><math display="block"><mrow><msubsup><mi>λ</mi><mrow><msub><mi>A</mi><mi>J</mi></msub></mrow><mi mathvariant="italic">params</mi></msubsup><mo>=</mo><mfrac><mrow><mi>P</mi><mfenced><msub><mi>V</mi><mi>J</mi></msub><mo>|</mo><msub><mi>C</mi><mi>J</mi></msub><mo>,</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow><mrow><mi>P</mi><mfenced><msub><mi>V</mi><mi>J</mi></msub><mo>|</mo><msub><mi>C</mi><mi>J</mi></msub><mo>,</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mrow></math><img file="EP3553713A1_D0106.tif" /></maths>

Session Cost Model

0189From a business and risk perspective, different types of Activities may carry different costs. For example, missing fraud on a Money Transfer is probably more costly than missing fraud on Checking Account Balance. To accommodate this, the concept of Cost is introduced when computing the Risk of a Session.

0190Keeping with this decision theory approach where a possible cost is assigned to each decision outcome, and since this decision space is essentially to declare a Session as Fraud or User, there may be four possible outcomes for a decision: <ul id="ul0017" list-style="bullet" compact="compact"><li>FPS determines a Session is Fraud when in fact it was from the User. This is referred to as the <i>Cost of a False Alarm</i> and denoted as: ∘ <maths id="math0104"><math display="inline"><mrow><mi mathvariant="double-struck">C</mi><mfenced><mi>Decide</mi><mrow><mspace width="1em" /><mi mathvariant="italic">F</mi></mrow><mrow><mspace width="1em" /><mi>when really</mi><mspace width="1em" /></mrow><mi>U</mi></mfenced><mo>≜</mo><msub><mi mathvariant="double-struck">C</mi><mi mathvariant="italic">IA</mi></msub></mrow></math><img file="EP3553713A1_D0107.tif" /></maths></li><li>FPS determines a Session is Fraud when in fact it is Fraud. This may be referred to as the <i>Cost of Correct Fraud</i> and denoted as: ∘ <img file="EP3553713A1_D0108.tif" /> (Decide <i>F</i> when really <i>F</i>)</li><li>FPS determines a Session is User when in fact it is Fraud. This may be referred to as the <i>Cost of Missed Fraud</i> and denoted as: ∘ <maths id="math0105"><math display="inline"><mrow><mi mathvariant="double-struck">C</mi><mfenced><mi>Decide</mi><mrow><mspace width="1em" /><mi mathvariant="italic">U</mi></mrow><mrow><mspace width="1em" /><mi>when really</mi><mspace width="1em" /></mrow><mi>F</mi></mfenced><mo>≜</mo><msub><mi mathvariant="double-struck">C</mi><mi mathvariant="italic">Missed</mi></msub></mrow></math><img file="EP3553713A1_D0109.tif" /></maths></li><li>FPS determines a Session is User when in fact it was from the User. This may be referred to as the <i>Cost Correct User</i> and denoted as: ∘ <img file="EP3553713A1_D0110.tif" /> (Decide <i>U</i> when really <i>U</i>)</li></ul>

0191In general, when a decision might be made that a Session is Fraud, the expected cost is: <maths id="math0106" num="(0.65)"><math display="block"><mrow><mi>E</mi><mfenced open="[" close="]"><mi mathvariant="double-struck">C</mi><mo>|</mo><mrow><mi>Decide</mi><mspace width="1em" /></mrow><mi>F</mi></mfenced><mo>=</mo><mi mathvariant="double-struck">C</mi><mfenced><mrow><mi>Decide</mi><mspace width="1em" /></mrow><mi>F</mi><mrow><mspace width="1em" /><mi>when really</mi><mspace width="1em" /></mrow><mi>U</mi></mfenced><mi mathvariant="normal">P</mi><mfenced><mi>U</mi><mo>|</mo><msub><mi>S</mi><mi>k</mi></msub></mfenced><mo>+</mo><mi mathvariant="double-struck">C</mi><mfenced><mrow><mi>Decide</mi><mspace width="1em" /></mrow><mi>F</mi><mrow><mspace width="1em" /><mi>when really</mi><mspace width="1em" /></mrow><mi>F</mi></mfenced><mi mathvariant="italic">P</mi><mfenced><mi>F</mi><mo>|</mo><msub><mi>S</mi><mi>k</mi></msub></mfenced></mrow></math><img file="EP3553713A1_D0111.tif" /></maths> Likewise, when a decision is made that a Session is from the User, the expected cost is: <maths id="math0107" num="(0.66)"><math display="block"><mrow><mi>E</mi><mfenced open="[" close="]"><mi mathvariant="double-struck">C</mi><mo>|</mo><mrow><mi>Decide</mi><mspace width="1em" /></mrow><mi>U</mi></mfenced><mo>=</mo><mi mathvariant="double-struck">C</mi><mfenced><mrow><mi>Decide</mi><mspace width="1em" /></mrow><mi>U</mi><mrow><mspace width="1em" /><mi>when really</mi><mspace width="1em" /></mrow><mi>F</mi></mfenced><mi mathvariant="normal">P</mi><mfenced><mi>U</mi><mo>|</mo><msub><mi>S</mi><mi>k</mi></msub></mfenced><mo>+</mo><mi mathvariant="double-struck">C</mi><mfenced><mrow><mi>Decide</mi><mspace width="1em" /></mrow><mi>U</mi><mrow><mspace width="1em" /><mi>when really</mi><mspace width="1em" /></mrow><mi>F</mi></mfenced><mi mathvariant="italic">P</mi><mfenced><mi>F</mi><mo>|</mo><msub><mi>S</mi><mi>k</mi></msub></mfenced></mrow></math><img file="EP3553713A1_D0112.tif" /></maths> Therefore, to minimize the expected cost, the decision criteria is simplified by using: <maths id="math0108" num="(0.67)"><math display="block"><mrow><mtable><mtr><mtd columnalign="left"><mi>Choose</mi><mspace width="1em" /><mi>U</mi><mspace width="1em" /><mi>if</mi><mo>:</mo></mtd><mtd><mi>E</mi><mfenced open="[" close="]"><mi mathvariant="double-struck">C</mi><mo>|</mo><mrow><mi>Decide</mi><mspace width="1em" /></mrow><mi>F</mi></mfenced><mo>></mo><mi>E</mi><mfenced open="[" close="]"><mi mathvariant="double-struck">C</mi><mo>|</mo><mrow><mi>Decide</mi><mspace width="1em" /></mrow><mi>U</mi></mfenced></mtd></mtr><mtr><mtd columnalign="left"><mi mathvariant="italic">and</mi></mtd><mtd><mspace width="1em" /></mtd></mtr><mtr><mtd columnalign="left"><mi>Choose</mi><mspace width="1em" /><mi>F</mi><mspace width="1em" /><mi>if</mi><mo>:</mo></mtd><mtd><mi>E</mi><mfenced open="[" close="]"><mi mathvariant="double-struck">C</mi><mo>|</mo><mrow><mi>Decide</mi><mspace width="1em" /></mrow><mi>F</mi></mfenced><mo><</mo><mi>E</mi><mfenced open="[" close="]"><mi mathvariant="double-struck">C</mi><mo>|</mo><mrow><mi>Decide</mi><mspace width="1em" /></mrow><mi>U</mi></mfenced></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0113.tif" /></maths> And, alternatively: <maths id="math0109" num="(0.68)"><math display="block"><mrow><mtable columnalign="left" width="auto"><mtr><mtd><mi>Choose</mi><mspace width="1em" /><mi>F</mi><mspace width="1em" /><mi>if</mi><mo>:</mo><mspace width="1em" /><mfrac><mrow><mi>E</mi><mfenced open="[" close="]"><mi mathvariant="double-struck">C</mi><mo>|</mo><mrow><mi>Decide</mi><mspace width="1em" /></mrow><mi>U</mi></mfenced></mrow><mrow><mi>E</mi><mfenced open="[" close="]"><mi mathvariant="double-struck">C</mi><mo>|</mo><mrow><mi>Decide</mi><mspace width="1em" /></mrow><mi>F</mi></mfenced></mrow></mfrac><mo>></mo><mn>1</mn></mtd></mtr><mtr><mtd><mi mathvariant="italic">and</mi></mtd></mtr><mtr><mtd><mi>Choose</mi><mspace width="1em" /><mi>U</mi><mspace width="1em" /><mi>otherwise</mi></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0114.tif" /></maths>

0192The individual costs may represent any cost to the business, including actual fraud losses, resources used to respond an alert and negative impact on the customer if a transaction is stopped. An assumption is made that the cost of making the correct decision is 0, ie, <img file="EP3553713A1_D0115.tif" /> (Decide <i>F</i> when really <i>F</i>)=<img file="EP3553713A1_D0116.tif" /> (Decide <i>U</i> when really <i>U</i>) = 0 Recognition should be given that the cost of making an incorrect decision can depend on the Session itself (via the associated Activities). Using this, the decision criteria of Equation (0.68) is rewritten as: <maths id="math0110" num="(0.69)"><math display="block"><mrow><mfrac><mrow><msubsup><mi mathvariant="double-struck">C</mi><mi mathvariant="italic">Missed</mi><mrow><msub><mi>S</mi><mi>k</mi></msub></mrow></msubsup><mi>P</mi><mfenced><mi>F</mi><mo>|</mo><msub><mi>S</mi><mi>k</mi></msub></mfenced></mrow><mrow><msubsup><mi mathvariant="double-struck">C</mi><mi mathvariant="italic">FA</mi><mrow><msub><mi>S</mi><mi>k</mi></msub></mrow></msubsup><mi>P</mi><mfenced><mi>U</mi><mo>|</mo><msub><mi>S</mi><mi>k</mi></msub></mfenced></mrow></mfrac><mo>></mo><mn>1</mn></mrow></math><img file="EP3553713A1_D0117.tif" /></maths> Using Bayes Rule: <maths id="math0111" num="(0.70)"><math display="block"><mrow><mfrac><mrow><msubsup><mi mathvariant="double-struck">C</mi><mi mathvariant="italic">Missed</mi><mrow><msub><mi>S</mi><mi>k</mi></msub></mrow></msubsup><mi>P</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced></mrow><mrow><msubsup><mi mathvariant="double-struck">C</mi><mi mathvariant="italic">FA</mi><mrow><msub><mi>S</mi><mi>k</mi></msub></mrow></msubsup><mi>P</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced><mi>P</mi><mfenced><msub><mi>U</mi><mn>0</mn></msub></mfenced></mrow></mfrac><mo>></mo><mn>1</mn></mrow></math><img file="EP3553713A1_D0118.tif" /></maths> Recognizing that the user and fraud priors are related as <i>P</i>(<i>U</i>₀) = 1 - <i>P</i>(<i>F</i>₀) and that the fraud prior <i>P</i>(<i>F</i>₀) is constant, these terms can be moved into the threshold such that: <maths id="math0112" num="(0.71)"><math display="block"><mrow><mtable columnalign="left" width="auto"><mtr><mtd><mi>θ</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced><mi>λ</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced><mo>></mo><msup><mi>e</mi><mi>τ</mi></msup></mtd></mtr><mtr><mtd><mi mathvariant="italic">or</mi></mtd></mtr><mtr><mtd><mi>log</mi><mfenced><mi>θ</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mfenced><mo>+</mo><mi>R</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced><mo>></mo><mi>τ</mi></mtd></mtr><mtr><mtd><mi mathvariant="italic">where</mi></mtd></mtr><mtr><mtd><mtable><mtr><mtd><mi>θ</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mfrac><mrow><msubsup><mi mathvariant="double-struck">C</mi><mi mathvariant="italic">Missed</mi><mrow><msub><mi>S</mi><mi>k</mi></msub></mrow></msubsup></mrow><mrow><msubsup><mi mathvariant="double-struck">C</mi><mi mathvariant="italic">FA</mi><mrow><msub><mi>S</mi><mi>k</mi></msub></mrow></msubsup></mrow></mfrac><mo>≜</mo><mi mathvariant="italic">Cost Ratio</mi></mtd></mtr><mtr><mtd columnalign="left"><mi>τ</mi></mtd><mtd columnalign="left"><mo>=</mo><mi>log</mi><mfenced open="[" close="]"><mfrac><mrow><mn>1</mn><mo>−</mo><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced></mrow><mrow><mi>P</mi><mfenced><msub><mi>F</mi><mn>0</mn></msub></mfenced></mrow></mfrac></mfenced></mtd></mtr></mtable></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0119.tif" /></maths> A sufficient statistic can be defined as: <maths id="math0113" num="(0.72)"><math display="block"><mrow><mtable><mtr><mtd><msup><mi>R</mi><mi>θ</mi></msup><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mtd><mtd columnalign="left"><mo>≜</mo><mi mathvariant="italic">Cost Adjusted Risk</mi></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd columnalign="left"><mo>=</mo><mi>R</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced><mo>+</mo><mi>log</mi><mfenced open="[" close="]"><mi>θ</mi><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mfenced></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0120.tif" /></maths>

0193In other words, the Cost Adjusted Risk of the Session is a generalization of the simple Risk score that is able to incorporate the cost of different types of sessions. Therefore, the Cost Adjusted Risk for the Session can be used as the primary decision statistic for Sessions.

0194The cost ratio <i>θ</i> does not depend on the content of the Session (i.e., the costs were the same for all sessions), so it can be moved into the threshold such that the original <i>R</i>(<i>S_k</i>) is a sufficient statistic. This is usually a valid when only considering a single event type like a Login Event.

Activity Model

0195In general there are many types of activities and an appropriate risk model for an activity type should be based on the nature of the activity, In this section a general model is described that can be used for many types of activities. Other models can be derived and used based on similar logic.

0196This model described calculates the Risk of an activity based on whether any Activity of the Type (regardless of how many) have been observed in the Session. The Cost contribution can include a base cost, an incremental costs for each observed Activity and a cost that can be tied to a quantitative observed parameter of the Activity (for example, the amount of a money transfer).

0197The general form for calculating the Risk component from all Activities of a given type (i.e., <i>A</i> ∈ <i><o ostyle="single">A</o>_{c<sub2>i</sub2>}</i>) is as follows: <maths id="math0114" num="(0.73)"><math display="block"><mrow><msub><mi>R</mi><mrow><msub><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub></mrow></msub><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced><mo>=</mo><msubsup><mi>R</mi><mrow><msub><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub></mrow><mi mathvariant="italic">freq</mi></msubsup><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced><mo>+</mo><mstyle displaystyle="false"><mrow><mstyle displaystyle="true"><mrow><munder><mo>∑</mo><mrow><msub><mi>A</mi><mi>j</mi></msub><mo>∈</mo><msub><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub></mrow></munder></mrow></mstyle><mrow><msubsup><mi>R</mi><mrow><msub><mi>A</mi><mi>I</mi></msub></mrow><mi mathvariant="italic">params</mi></msubsup></mrow></mrow></mstyle><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mrow></math><img file="EP3553713A1_D0121.tif" /></maths> For this Activity Model Template all Activities of the Type should be treated as indistinguishable, i.e., <i>P</i>(<i>V</i> | <i>C</i>, <i>F</i>^<i>k</i>-1) = <i>P</i>(<i>V</i> | <i>C</i>, <i>U</i>^<i>k</i>-1), such that <maths id="math0115" num="(0.74)"><math display="block"><mrow><msubsup><mi>R</mi><mrow><msub><mi>A</mi><mi>j</mi></msub></mrow><mi mathvariant="italic">params</mi></msubsup><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced><mo>=</mo><mn>0</mn></mrow></math><img file="EP3553713A1_D0122.tif" /></maths> The quantity <maths id="math0116"><math display="inline"><mrow><msubsup><mi>R</mi><mrow><msub><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub></mrow><mi mathvariant="italic">freq</mi></msubsup><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mrow></math><img file="EP3553713A1_D0123.tif" /></maths> is based on whether an Activity of this type is observed (i.e., <i>N_{c<sub2>i</sub2>}</i> > 0) or not observed (i.e., <i>N_{c<sub2>i</sub2>}</i> = 0) in this session. This model is derived from a Beta distribution to estimate the likelihood of observing this type of Activity for this User, i.e.,: <maths id="math0117" num="(0.75)"><math display="block"><mrow><mtable><mtr><mtd columnalign="left"><mi>P</mi><mfenced><mi mathvariant="italic">Observe A</mi><mo>∈</mo><msub><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mfrac><mrow><msub><mi mathvariant="italic">αρ</mi><mi>U</mi></msub><mo>+</mo><msub><mi mathvariant="normal">Ω</mi><mrow><msup><mi>c</mi><mi>i</mi></msup><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mrow></msub></mrow><mrow><mi>α</mi><mo>+</mo><msub><mi mathvariant="normal">Ω</mi><mrow><mi mathvariant="italic">total</mi><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mrow></msub></mrow></mfrac></mtd></mtr><mtr><mtd columnalign="left"><mi>P</mi><mfenced><mi mathvariant="italic">Observe A</mi><mo>∈</mo><msub><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mtd><mtd columnalign="left"><mo>=</mo><msub><mi>ρ</mi><mi>F</mi></msub></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0124.tif" /></maths> where <ul id="ul0018" list-style="bullet" compact="compact"><li><i>ρ_F</i> = <i>fraud</i>_<i>occurance</i>_<i>prior</i> ∘ This is the prior probability of seeing this Activity Type within a session given Fraud</li><li><i>ρ_U</i> = <i>user</i>_<i>occurance</i>_<i>prior</i> ∘ This is the prior probability of seeing this Activity Type within a session given Fraud</li><li><i>α</i> = <i>alpha</i>_<i>occurance</i> ∘ This is the <i>α</i> associated with the Dirichlet Model for the User (in units of number of Sessions)</li><li><maths id="math0118"><math display="inline"><mrow><msub><mi mathvariant="normal">Ω</mi><mrow><msup><mi>c</mi><mi>i</mi></msup><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mrow></msub><mo>≜</mo><mi mathvariant="italic">The obseved Session occurrences of</mi><mspace width="1em" /><msup><mi>c</mi><mi>i</mi></msup><mspace width="1em" /><mi mathvariant="italic">for</mi><mspace width="1em" /><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mrow></math><img file="EP3553713A1_D0125.tif" /></maths> ∘ This is the observed occurrences (<i>count</i> or preferably the <i>accumulated trust</i>) of prior Sessions for this User that contain this Activity Type</li><li><maths id="math0119"><math display="inline"><mrow><msub><mi mathvariant="normal">Ω</mi><mrow><mi mathvariant="italic">total</mi><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mrow></msub><mo>≜</mo><mi mathvariant="italic">The total obseved session occurrences for</mi><mspace width="1em" /><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mrow></math><img file="EP3553713A1_D0126.tif" /></maths> ∘ This is the total number of observed Sessions (<i>count</i> or preferably the <i>accumulated trust</i>) of prior Sessions (regardless of whether this Activity Type was observed)</li></ul>

0198Using the definitions in Equation (0.75), <maths id="math0120"><math display="inline"><mrow><msubsup><mi>R</mi><mrow><msub><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub></mrow><mi mathvariant="italic">freq</mi></msubsup><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mrow></math><img file="EP3553713A1_D0127.tif" /></maths> is calculated as: <ol id="ol0003" compact="compact"><li>1. If <i>S_k</i> is open and no Activity of this type has been observed, then (see Equation (0.61): <maths id="math0121" num="(0.76)"><math display="block"><mrow><mtable><mtr><mtd><msubsup><mi>R</mi><mrow><msub><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub></mrow><mi mathvariant="italic">freq</mi></msubsup><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mi>log</mi><mfenced><mfrac><mrow><mi>P</mi><mfenced><msub><mi>N</mi><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub><mo>≥</mo><mn>0</mn><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow><mrow><mi>P</mi><mfenced><msub><mi>N</mi><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub><mo>≥</mo><mn>0</mn><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mfenced><mo>=</mo><mi>log</mi><mfenced><mfrac><mn>1</mn><mn>1</mn></mfrac></mfenced></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd columnalign="left"><mo>=</mo><mn>0</mn></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0128.tif" /></maths></li><li>2. If <i>S_k</i> is closed and no Activity of this type has been observed, then: <maths id="math0122" num="(0.77)"><math display="block"><mrow><mtable><mtr><mtd><msubsup><mi>R</mi><mrow><msub><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub></mrow><mi mathvariant="italic">freq</mi></msubsup><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mtd><mtd columnalign="left"><mo>=</mo><mi>log</mi><mfenced open="[" close="]"><mfrac><mrow><mn>1</mn><mo>−</mo><mi>P</mi><mfenced><mi mathvariant="italic">Observe A</mi><mo>∈</mo><msub><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow><mrow><mn>1</mn><mo>−</mo><mi>P</mi><mfenced><mi mathvariant="italic">Observe A</mi><mo>∈</mo><msub><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mfenced></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd><mo>=</mo><mi>log</mi><mfenced open="[" close="]"><mfrac><mrow><mfenced><mn>1</mn><mo>−</mo><msub><mi>ρ</mi><mi>F</mi></msub></mfenced><mfenced><mi>α</mi><mo>+</mo><msub><mi mathvariant="normal">Ω</mi><mrow><mi mathvariant="italic">total</mi><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mrow></msub></mfenced></mrow><mrow><mi>α</mi><mfenced><mn>1</mn><mo>−</mo><msub><mi>ρ</mi><mi>U</mi></msub></mfenced><mo>+</mo><mfenced><msub><mi mathvariant="normal">Ω</mi><mrow><mi mathvariant="italic">total</mi><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mrow></msub><mo>−</mo><msub><mi mathvariant="normal">Ω</mi><mrow><msup><mi>c</mi><mi>i</mi></msup><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mrow></msub></mfenced></mrow></mfrac></mfenced></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0129.tif" /></maths></li><li>3. If there has been at least one Activity of this type observed (regardless of whether <i>S_k</i> is open or closed), then: <maths id="math0123" num="(0.78)"><math display="block"><mrow><mtable><mtr><mtd><msubsup><mi>R</mi><mrow><msub><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub></mrow><mi mathvariant="italic">freq</mi></msubsup><mfenced><msub><mi>S</mi><mi>k</mi></msub></mfenced></mtd><mtd><mo>=</mo><mi>log</mi><mfenced open="[" close="]"><mfrac><mrow><mi>P</mi><mfenced><mi mathvariant="italic">Observe A</mi><mo>∈</mo><msub><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub><mo>|</mo><msup><mi>F</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow><mrow><mi>P</mi><mfenced><mi mathvariant="italic">Observe A</mi><mo>∈</mo><msub><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mfenced></mrow></mfrac></mfenced></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd columnalign="left"><mo>=</mo><mi>log</mi><mfenced open="[" close="]"><msub><mi>ρ</mi><mi>I</mi></msub><mfrac><mrow><mi>α</mi><mo>+</mo><msub><mi mathvariant="normal">Ω</mi><mrow><mi mathvariant="italic">total</mi><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mrow></msub></mrow><mrow><msub><mi mathvariant="italic">αρ</mi><mi>U</mi></msub><mo>+</mo><msub><mi mathvariant="normal">Ω</mi><mrow><msup><mi>c</mi><mi>i</mi></msup><mo>|</mo><msup><mi>U</mi><mrow><mi>k</mi><mo>−</mo><mn>1</mn></mrow></msup></mrow></msub></mrow></mfrac></mfenced></mtd></mtr></mtable></mrow></math><img file="EP3553713A1_D0130.tif" /></maths></li></ol>

0199The Missed Fraud and False Alarm Cost model uses a general parameterized form that can be used to model a variety of situations . Specifically (for the Fraud Cost): <maths id="math0124" num="(0.79)"><math display="block"><mrow><msubsup><mi mathvariant="double-struck">C</mi><mi mathvariant="italic">Missed</mi><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msubsup><mo>=</mo><msubsup><mi>β</mi><mi mathvariant="italic">type</mi><mi mathvariant="italic">Missed</mi></msubsup><mo>+</mo><msubsup><mi>β</mi><mi mathvariant="italic">count</mi><mi mathvariant="italic">Missed</mi></msubsup><msub><mi>N</mi><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub><mo>+</mo><mstyle displaystyle="false"><mrow><mstyle displaystyle="true"><mrow><munder><mrow><mo>∑</mo></mrow><mrow><msub><mi>A</mi><mi>l</mi></msub><mo>∈</mo><mover><mrow><msub><mi>A</mi><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub></mrow><mrow><mo>‾</mo></mrow></mover></mrow></munder></mrow></mstyle><mrow><msubsup><mi mathvariant="italic">β</mi><mi mathvariant="italic">quant</mi><mi mathvariant="italic">Missed</mi></msubsup><msubsup><mi mathvariant="italic">V</mi><mi mathvariant="italic">quantifier</mi><mrow><msub><mi mathvariant="italic">A</mi><mi mathvariant="italic">i</mi></msub></mrow></msubsup></mrow></mrow></mstyle></mrow></math><img file="EP3553713A1_D0131.tif" /></maths> where <ul id="ul0019" list-style="bullet" compact="compact"><li><i>N_{c<sub2>i</sub2>}</i> is the number of Activities of Type <i>cⁱ</i> that have been observed in this Session, including the current Activity</li><li><maths id="math0125"><math display="inline"><mrow><msubsup><mi>V</mi><mi mathvariant="italic">quantifier</mi><mi>A</mi></msubsup></mrow></math><img file="EP3553713A1_D0132.tif" /></maths> is the Quantifier parameter associated Activity <i>A</i></li><li>The <i>β</i>'<i>s</i> are cost coefficients provided as Activity Model Template Parameters <ul id="ul0020" list-style="none" compact="compact"><li>∘ <maths id="math0126"><math display="inline"><mrow><msubsup><mi mathvariant="italic">β</mi><mi mathvariant="italic">type</mi><mi mathvariant="italic">Missed</mi></msubsup><mo>=</mo><mi mathvariant="italic">missed_type_cost</mi></mrow></math><img file="EP3553713A1_D0133.tif" /></maths></li><li>∘ <maths id="math0127"><math display="inline"><mrow><msubsup><mi mathvariant="italic">β</mi><mi mathvariant="italic">count</mi><mi mathvariant="italic">Missed</mi></msubsup><mo>=</mo><mi mathvariant="italic">missed_count_cost</mi></mrow></math><img file="EP3553713A1_D0134.tif" /></maths></li><li>∘ <maths id="math0128"><math display="inline"><mrow><msubsup><mi mathvariant="italic">β</mi><mi mathvariant="italic">quant</mi><mi mathvariant="italic">Missed</mi></msubsup><mo>=</mo><mi mathvariant="italic">missed_quantifier_cost</mi></mrow></math><img file="EP3553713A1_D0135.tif" /></maths></li></ul></li></ul> The False Alarm Cost model uses the same general parameter form, but with a separate set of cost coefficients. <maths id="math0129" num="(0.80)"><math display="block"><mrow><msubsup><mi mathvariant="double-struck">C</mi><mi mathvariant="italic">FA</mi><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msubsup><mo>=</mo><msubsup><mi mathvariant="italic">β</mi><mi mathvariant="italic">type</mi><mi mathvariant="italic">FA</mi></msubsup><mo>+</mo><msubsup><mi mathvariant="italic">β</mi><mi mathvariant="italic">count</mi><mi mathvariant="italic">FA</mi></msubsup><msub><mi>N</mi><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub><mo>+</mo><mstyle displaystyle="false"><mrow><mstyle displaystyle="true"><mrow><munder><mo>∑</mo><mrow><msub><mi>A</mi><mi>j</mi></msub><mo>∈</mo><msub><mrow><mover><mi>A</mi><mrow><mo>‾</mo></mrow></mover></mrow><mrow><msup><mi>c</mi><mi>i</mi></msup></mrow></msub></mrow></munder></mrow></mstyle><mrow><msubsup><mi mathvariant="italic">β</mi><mi mathvariant="italic">quant</mi><mi mathvariant="italic">FA</mi></msubsup><msubsup><mi mathvariant="italic">V</mi><mi mathvariant="italic">quantifier</mi><mrow><msub><mi mathvariant="italic">A</mi><mi mathvariant="italic">j</mi></msub></mrow></msubsup></mrow></mrow></mstyle></mrow></math><img file="EP3553713A1_D0136.tif" /></maths> where <ul id="ul0021" list-style="bullet" compact="compact"><li>The <i>β</i>'<i>s</i> are cost coefficients provided as Activity Model Template Parameters <ul id="ul0022" list-style="none" compact="compact"><li>∘ <maths id="math0130"><math display="inline"><mrow><msubsup><mi mathvariant="italic">β</mi><mi mathvariant="italic">type</mi><mi mathvariant="italic">FA</mi></msubsup><mo>=</mo><mi mathvariant="italic">FA_type_cost</mi></mrow></math><img file="EP3553713A1_D0137.tif" /></maths></li><li>∘ <maths id="math0131"><math display="inline"><mrow><msubsup><mi mathvariant="italic">β</mi><mi mathvariant="italic">count</mi><mi mathvariant="italic">FA</mi></msubsup><mo>=</mo><mi mathvariant="italic">FA_count_cost</mi></mrow></math><img file="EP3553713A1_D0138.tif" /></maths></li><li>∘ <maths id="math0132"><math display="inline"><mrow><msubsup><mi mathvariant="italic">β</mi><mi mathvariant="italic">quant</mi><mi mathvariant="italic">FA</mi></msubsup><mo>=</mo><mi mathvariant="italic">FA_quantifier_cost</mi></mrow></math><img file="EP3553713A1_D0139.tif" /></maths></li></ul></li></ul>

0200The embodiments described herein include a method comprising: automatically generating a causal model corresponding to a user; estimating a plurality of components of the causal model using event parameters of a first set of events undertaken by the user in an account of the user; and predicting expected behavior of the user during a second set of events using the causal model.

0201Automatically generating the causal model of an embodiment includes generating statistical relationships between components of the plurality of components.

0202The method of an embodiment comprises representing the causal model as a Bayesian network.

0203Automatically generating the causal model of an embodiment includes generating a joint probability distribution that includes the plurality of components.

0204The plurality of components of an embodiment includes a plurality of probability distribution functions that represent the event parameters.

0205The event parameters of an embodiment are observable parameters collected during the first set of events.

0206The event parameters of an embodiment include one or more of Internet Protocol (IP) data and Hypertext Transfer Protocol (HTTP) data.

0207The IP data of an embodiment includes one or more of an IP address, IP address country, IP address city, IP network block, and internet service provider supporting an event.

0208The HTTP data of an embodiment includes one or more of data of an operating system, a user agent string, a referrer string, and internet browser of a computer used for an event.

0209Automatically generating the causal model of an embodiment includes generating statistical relationships between the event parameters and derived parameters.

0210The derived parameters of an embodiment include one or more of geographic area from which a device is initiating the second set of events, location of the device, identification of the device, and electronic service provider of the device.

0211Predicting the expected behavior of the user of an embodiment includes generating expected event parameters of the second set of events.

0212Generating the expected event parameters of an embodiment includes generating a first set of predicted probability distributions that represent the expected event parameters, wherein generating the first set of predicted probability distributions assumes the user is conducting the second set of events.

0213The method of an embodiment comprises receiving a predictive fraud model The method of an embodiment comprises generating a second set of predicted probability distributions that represent expected fraud event parameters, wherein generating the second set of predicted probability distributions assumes a fraudster is conducting the second set of events, wherein the fraudster is any person other than the user.

0214The method of an embodiment comprises automatically generating the predictive fraud model by estimating a plurality of fraud components of the predictive fraud model using fraud event parameters of previous fraudulent events undertaken in a plurality of accounts, wherein the previous fraudulent events are events suspected as having been conducted by the fraudster.

0215Automatically generating the predictive fraud model of an embodiment includes generating statistical relationships between fraud components of the plurality of fraud components.

0216Automatically generating the predictive fraud model of an embodiment includes generating statistical relationships between the fraud event parameters and derived fraud parameters.

0217The derived fraud parameters of an embodiment include one or more of a location of the device, identification of the device, and electronic service provider of the device.

0218The method of an embodiment comprises generating in real-time a risk score of an event of the second set of events using the expected event parameters and the expected fraud event parameters along with the observed parameters.

0219The method of an embodiment comprises generating an alert corresponding to an event of the second set of events when the expected behavior indicates a person other than the user is conducting the event.

0220The method of an embodiment comprises automatically updating the causal model using a second set of event parameters collected during the second set of events.

0221The second set of event parameters of an embodiment are observable parameters collected during the second set of events.

0222Automatically updating the causal model of an embodiment includes updating a joint probability distribution that includes the plurality of components.

0223Automatically updating the causal model of an embodiment includes updating at least one of the plurality of components.

0224Automatically updating the causal model of an embodiment includes updating at least one of a plurality of probability distribution functions that represent the event parameters, the updating modifying the at least one of the plurality of probability distribution functions by considering data of the second set of event parameters.

0225The method of an embodiment comprises generating a probability distribution function for each of the event parameters of the first set of events. The method of an embodiment comprises generating an updated probability distribution function for each of the event parameters by applying data of a second set of event parameters of the second set of events to the probability distribution function.

0226The method of an embodiment comprises receiving a baseline causal model that corresponds to the user, the baseline causal model generated without using data of any event The method of an embodiment comprises generating the causal model by generating a joint probability distribution that includes the plurality of components, wherein the plurality of components includes the updated probability distribution function for any event parameter represented in the causal model.

0227The first set of events and the second set of events of an embodiment comprise at least one of online events, offline events, and multiple channel events.

0228Online events of an embodiment are events undertaken via electronic access to the account.

0229Events of an embodiment comprise login events.

0230Events of an embodiment comprise activity events.

0231A set of events of an embodiment comprises a session, wherein the session is a sequence of related events.

0232The sequence of related events of an embodiment comprises a session login event and a termination event.

0233The sequence of related events of an embodiment comprises at least one activity event.

0234The method of an embodiment comprises determining probabilistically that the second set of events was conducted by the user. The method of an embodiment comprises automatically updating the causal model using a second set of event parameters collected during the second set of events.

0235The method of an embodiment comprises updating the causal model to include a trust factor, the trust factor representing a probability that the second set of events was in fact conducted by the user.

0236The method of an embodiment comprises updating the causal model to include an accumulated trust factor, the accumulated trust factor representing a cumulative probability across a plurality of sets of events that an event parameter in the plurality of sets of events was in fact conducted by the user.

0237Automatically generating the causal model of an embodiment comprises generating the causal model to include a decay parameter.

0238The decay parameter of an embodiment comprises an exponential decay function by which a relative weight of each event in a set of events in the account changes with passage of time since the event.

0239The embodiments described herein include a method comprising: receiving a plurality of observations corresponding to a first event, the first event including actions taken in an account during electronic access of the account; generating probabilistic relationships between the observations and derived parameters of an owner of the account; automatically generating an account model to include the probabilistic relationships; and estimating actions of the owner during a second event using the account model, wherein the second event follows the first event in time

0240The embodiments described herein include a method comprising: automatically generating a causal model corresponding to a user, the generating comprising estimating a plurality of components of the causal model using event parameters of a previous event undertaken by the user in an account of the user, predicting expected behavior of the user during a next event in the account using the causal model, wherein predicting the expected behavior of the user includes generating predicted event parameters of the next event, receiving observed event parameters of the next event; and updating the causal model for use in a future event, the updating comprising regenerating the plurality of components based on a relationship between the expected event parameters and the observed event parameters.

0241The embodiments described herein include a system comprising a processor executing at least one application, the application receiving event parameters of a first set of events undertaken by the user in an account of the user, the application automatically generating a causal model corresponding to a user by estimating a plurality of components of the causal model using the event parameters of the first set of events, the application using the causal model to output a prediction of expected behavior of the user during a second set of events.

0242Automatically generating the causal model of an embodiment includes generating statistical relationships between components of the plurality of components.

0243Automatically generating the causal model of an embodiment includes generating a joint probability distribution that includes the plurality of components,

0244The plurality of components of an embodiment includes a plurality of probability distribution functions that represent the event parameters.

0245The event parameters of an embodiment are observable parameters collected during the first set of events.

0246The event parameters of an embodiment include one or more of Internet Protocol (IP) data and Hypertext Transfer Protocol (HTTP) data.

0247The IP data of an embodiment includes one or more of an IP address, IP address country, IP address city, IP network block, and internet service provider supporting an event.

0248The HTTP data of an embodiment includes one or more of data of an operating system, a user agent string, a referrer string, and internet browser of a computer used for an event.

0249Automatically generating the causal model of an embodiment includes generating statistical relationships between the event parameters and derived parameters.

0250The derived parameters of an embodiment include one or more of geographic area from which a device is initiating the second set of events, location of the device, identification of the device, and electronic service provider of the device.

0251Predicting the expected behavior of the user of an embodiment includes generating expected event parameters of the second set of events.

0252Generating the expected event parameters of an embodiment includes generating a first set of predicted probability distributions that represent the expected event parameters, wherein generating the first set of predicted probability distributions assumes the user is conducting the second set of events.

0253The system of an embodiment comprises receiving a predictive fraud model. The system of an embodiment comprises generating a second set of predicted probability distributions that represent expected fraud event parameters, wherein generating the second set of predicted probability distributions assumes a fraudster is conducting the second set of events, wherein the fraudster is any person other than the user.

0254The system of an embodiment comprises generating in real-time a risk score of an event of the second set of events using the expected event parameters and the expected fraud event parameters along with the observed parameters.

0255The system of an embodiment comprises generating an alert corresponding to an event of the second set of events when the expected behavior indicates a person other than the user is conducting the event.

0256The system of an embodiment comprises automatically updating the causal model using a second set of event parameters collected during the second set of events.

0257Automatically updating the causal model of an embodiment includes updating at least one of a plurality of probability distribution functions that represent the event parameters, the updating modifying the at least one of the plurality of probability distribution functions by considering data of the second set of event parameters.

0258The system of an embodiment comprises generating a probability distribution function for each of the event parameters of the first set of events. The system of an embodiment comprises generating an updated probability distribution function for each of the event parameters by applying data of a second set of event parameters of the second set of events to the probability distribution function.

0259The first set of events and the second set of events of an embodiment comprise at least one of online events, offline events, and multiple channel events.

0260Online events of an embodiment are events undertaken via electronic access to the account.

0261Events of an embodiment comprise login events.

0262Events of an embodiment comprise activity events.

0263A set of events of an embodiment comprises a session, wherein the session is a sequence of related events.

0264The system of an embodiment comprises determining probabilistically that the second set of events was conducted by the user. The system of an embodiment comprises automatically updating the causal model using a second set of event parameters collected during the second set of events.

0265The system of an embodiment comprises updating the causal model to include a trust factor, the trust factor representing a probability that the second set of events was in fact conducted by the user.

0266The system of an embodiment comprises updating the causal model to include an accumulated trust factor, the accumulated trust factor representing a cumulative probability across a plurality of sets of events that an event parameter in the plurality of sets of events was in fact conducted by the user.

0267Automatically generating the causal model of an embodiment comprises generating the causal model to include a decay parameter.

0268The decay parameter of an embodiment comprises an exponential decay function by which a relative weight of each event in a set of events in the account changes with passage of time since the event.

0269The embodiments described herein include a system comprising a processor executing at least one application, the application receiving event parameters of a first set of events undertaken by a user in an account of the user, the application automatically generating an account model corresponding to the user, the account model comprising a plurality of components, wherein generating the account model comprises generating the plurality of components using the event parameters of the first set of events, the application predicting expected behavior of the user during a second set of events using the account model, the application generating an updated version of the account model for use in a future set of events, the updating comprising regenerating the plurality of components using the second set of events

0270The embodiments described herein include a method comprising: automatically generating a causal model corresponding to a user, the generating comprising estimating a plurality of components of the causal model using event parameters of a previous event undertaken by the user in an account of the user; predicting expected behavior of the user during a next event in the account using the causal model, wherein predicting the expected behavior of the user includes generating expected event parameters of the next event; using a predictive fraud model, generating fraud event parameters, wherein generating the fraud event parameters assumes a fraudster is conducting the next event, wherein the fraudster is any person other than the user; and generating a risk score of the next event using the expected event parameters and the fraud event parameters, the risk score indicating the relative likelihood the future event is performed by the user versus the fraudster.

0271The method of an embodiment comprises automatically generating the predictive fraud model by estimating a plurality of fraud components of the predictive fraud model using the fraud event parameters of previous fraudulent events undertaken in a plurality of accounts, wherein the previous fraudulent events are events suspected as having been conducted by the fraudster.

0272Automatically generating the predictive fraud model of an embodiment includes generating statistical relationships between fraud components of the plurality of fraud components.

0273Automatically generating the predictive fraud model of an embodiment includes generating a joint probability distribution that includes the plurality of fraud components.

0274The plurality of fraud components of an embodiment includes a plurality of fraud probability distribution functions that represent the fraud event parameters.

0275The fraud event parameters of an embodiment are observable fraud parameters collected during the previous fraudulent events.

0276Automatically generating the predictive fraud model of an embodiment includes generating statistical relationships between the fraud event parameters and derived fraud parameters.

0277The derived fraud parameters of an embodiment include one or more of a location of the device, identification of the device, and electronic service provider of the device.

0278The method of an embodiment comprises generating the predictive fraud model.

0279Generating the predictive fraud model of an embodiment comprises generating an original fraud model to include a probability of observing an event given that the event is caused by the fraudster and absent any other information about the event

0280Generating the predictive fraud model of an embodiment comprises generating a probabilistic combination of the original fraud model and an impersonation model.

0281The method of an embodiment comprises generating the original fraud model to include a probability of observing an event given that the event is caused by the fraudster and absent any other information about the event.

0282Generating the predictive fraud model of an embodiment comprises generating the predictive fraud model to include an impersonation probability, wherein the impersonation probability is a probability that the fraudster successfully impersonates a parameter value of an event parameter of a set of events undertaken by the user.

0283The impersonation model of an embodiment comprises a probability that the fraudster mimics an event parameter of a set of events undertaken by the user.

0284The impersonation model of an embodiment comprises a probability that the fraudster observes an event parameter of a set of events undertaken by the user.

0285The method of an embodiment comprises identifying at least one previous fraud event, a previous fraud event comprising a previous event in the account potentially caused by the fraudster. The method of an embodiment comprises generating the original fraud model by estimating a plurality of components of the fraud model using event parameters of at least one previous fraud event undertaken in the account, the at least one previous fraud event potentially conducted by the fraudster.

0286The method of an embodiment comprises modifying the predictive fraud model based on at least one previous event potentially conducted by the fraudster.

0287The method of an embodiment comprises generating the predictive fraud model to include a fraud co-occurrence coefficient for at least one previous event potentially conducted by the fraudster.

0288The fraud co-occurrence coefficient of an embodiment represents an accumulated mistrust derived recursively from the at least one previous event potentially conducted by the fraudster.

0289The fraud co-occurrence coefficient of an embodiment comprises a coefficient representing an affect of a plurality of previous events potentially conducted by the fraudster.

0290Automatically generating the causal model of an embodiment includes generating statistical relationships between components of the plurality of components.

0291Automatically generating the causal model of an embodiment includes generating a joint probability distribution that includes the plurality of components.

0292The plurality of components of an embodiment includes a plurality of probability distribution functions that represent the event parameters of the previous event.

0293The event parameters of an embodiment are observable parameters collected during the previous event.

0294The event parameters of an embodiment include one or more of Internet Protocol (IP) data and Hypertext Transfer Protocol (HTTP) data.

0295The IP data of an embodiment includes one or more of an IP address, IP address country, IP address city, IP network block, and internet service provider supporting an event.

0296The HTTP data of an embodiment includes one or more of data of an operating system, a user agent string, a referrer string, and internet browser of a computer used for an event.

0297Automatically generating the causal model of an embodiment includes generating statistical relationships between the event parameters and derived parameters.

0298The derived parameters of an embodiment include one or more of geographic area from which a device is initiating the next event, location of the device, identification of the device, and electronic service provider of the device.

0299Predicting the expected behavior of the user of an embodiment includes generating expected event parameters of the next event.

0300Generating the expected event parameters of an embodiment includes generating a first set of predicted probability distributions that represent the expected event parameters, wherein generating the first set of predicted probability distributions assumes the user is conducting the next event.

0301The method of an embodiment comprises generating an alert corresponding to the next event when the risk score indicates a person other than the user is conducting the next event.

0302The method of an embodiment comprises automatically updating the causal model using a second set of event parameters collected during the next event

0303The second set of event parameters of an embodiment is observable parameters collected during the next event.

0304Automatically updating the causal model of an embodiment includes updating a joint probability distribution that includes the plurality of components.

0305Automatically updating the causal model of an embodiment includes updating at least one of the plurality of components.

0306Automatically updating the causal model of an embodiment includes updating at least one of a plurality of probability distribution functions that represent the event parameters, the updating modifying the at least one of the plurality of probability distribution functions by considering data of the second set of event parameters.

0307The method of an embodiment comprises generating a probability distribution function for each of the event parameters of the previous event. The method of an embodiment comprises generating an updated probability distribution function for each of the event parameters by applying data of a second set of event parameters of the next event to the probability distribution function.

0308The method of an embodiment comprises receiving a baseline causal model that corresponds to the user, the baseline causal model generated without using data of any event. The method of an embodiment comprises generating the causal model by generating a joint probability distribution that includes the plurality of components, wherein the plurality of components includes the updated probability distribution function for any event parameter represented in the causal model.

0309The previous event and the next event of an embodiment comprise at least one of online events, offline events, and multiple channel events.

0310Online events of an embodiment are events undertaken via electronic access to the account.

0311An event of an embodiment comprises a login event.

0312An event of an embodiment comprises an activity event

0313The method of an embodiment comprises determining probabilistically that the next event was conducted by the user. The method of an embodiment comprises automatically updating the causal model using a second set of event parameters collected during the next event.

0314The method of an embodiment comprises updating the causal model to include a trust factor, the trust factor representing a probability that the next event was in fact conducted by the user.

0315The method of an embodiment comprises updating the causal model to include an accumulated trust factor, the accumulated trust factor representing a cumulative probability across a plurality of events that an event parameter in the plurality of events was in fact conducted by the user.

0316Automatically generating the causal model of an embodiment comprises generating the causal model to include a decay parameter.

0317The decay parameter of an embodiment comprises an exponential decay function by which a relative weight of each event in the account changes with passage of time since the event.

0318The embodiments described herein include a method comprising: automatically generating an account model corresponding to a user, the generating of the account model using event parameters of a previous event performed by the user in an account of the user to generate predicted distributions of the event parameters for a next event in the account, wherein the account model includes the predicted distributions of the event parameters; receiving observed event parameters of the next event as the next event occurs; generating a first probability using the account model, wherein the first probability is a probability of observing the observed event parameters assuming the user is conducting the next event; generating a second probability using a fraud model, wherein the second probability is a probability of observing the observed event parameters assuming a fraudster is conducting the next event, wherein the fraudster is a person other than the user; and generating a risk score using the first probability and the second probability, the risk score indicating the relative likelihood the next event is performed by the user versus the fraudster.

0319The embodiments described herein include a method comprising: generating probabilistic relationships between observations of a first event and derived parameters of an owner of an account; automatically generating an account model including the probabilistic relationships; dynamically updating the account model using observations of a second event; and using the account model to predict during a third event whether the owner or a fraudster is perpetuating the third event, wherein an event includes actions taken in the account during electronic access of the account.

0320The embodiments described herein include a system comprising a processor executing at least one application, the application automatically generating a predictive user model corresponding to a user, wherein the predictive user model includes a plurality of probability distributions representing event parameters observed during a first event in an account of the user, the application generating predicted event parameters using the predictive user model, the predicted event parameters expected to be observed during a second event in the account, the second event following the first event, the application comparing actual event parameters of the second event to the predicted event parameters during the second event and generating an alert corresponding to the second event when the actual event parameters appear to be initiated by a person other than the user

0321The embodiments described herein include a system comprising a processor executing at least one application, the application automatically generating a causal model corresponding to a user by estimating a plurality of components of the causal model using event parameters of a previous event undertaken by the user in an account of the user, the application predicting expected behavior of the user during a next event in the account using the causal model, wherein predicting the expected behavior of the user includes generating expected event parameters of the next event, the application using a predictive fraud model, generating fraud event parameters, wherein generating the fraud event parameters assumes a fraudster is conducting the next event, wherein the fraudster is any person other than the user, the application generating a risk score of the next event using the expected event parameters and the fraud event parameters, the risk score indicating the relative likelihood the future event is performed by the user versus the fraudster.

0322The system of an embodiment comprises automatically generating the predictive fraud model by estimating a plurality of fraud components of the predictive fraud model using the fraud event parameters of previous fraudulent events undertaken in a plurality of accounts, wherein the previous fraudulent events are events suspected as having been conducted by the fraudster.

0323Automatically generating the predictive fraud model of an embodiment includes generating statistical relationships between fraud components of the plurality of fraud components.

0324Automatically generating the predictive fraud model of an embodiment includes generating a joint probability distribution that includes the plurality of fraud components.

0325The plurality of fraud components of an embodiment includes a plurality of fraud probability distribution functions that represent the fraud event parameters, wherein the fraud event parameters are observable fraud parameters collected during the previous fraudulent events.

0326Automatically generating the predictive fraud model of an embodiment includes generating statistical relationships between the fraud event parameters and derived fraud parameters.

0327The derived fraud parameters of an embodiment include one or more of a location of the device, identification of the device, and electronic service provider of the device.

0328The system of an embodiment comprises generating the predictive fraud model.

0329Generating the predictive fraud model of an embodiment comprises generating an original fraud model to include a probability of observing an event given that the event is caused by the fraudster and absent any other information about the event

0330Generating the predictive fraud model of an embodiment comprises generating a probabilistic combination of the original fraud model and an impersonation model.

0331The system of an embodiment comprises generating the original fraud model to include a probability of observing an event given that the event is caused by the fraudster and absent any other information about the event.

0332Generating the predictive fraud model of an embodiment comprises generating the predictive fraud model to include an impersonation probability, wherein the impersonation probability is a probability that the fraudster successfully impersonates a parameter value of an event parameter of a set of events undertaken by the user.

0333The impersonation model of an embodiment comprises a probability that the fraudster mimics an event parameter of a set of events undertaken by the user.

0334The impersonation model of an embodiment comprises a probability that the fraudster observes an event parameter of a set of events undertaken by the user.

0335The system of an embodiment comprises identifying at least one previous fraud event, a previous fraud event comprising a previous event in the account potentially caused by the fraudster. The system of an embodiment comprises generating the original fraud model by estimating a plurality of components of the fraud model using event parameters of at least one previous fraud event undertaken in the account, the at least one previous fraud event potentially conducted by the fraudster.

0336The system of an embodiment comprises modifying the predictive fraud model based on at least one previous event potentially conducted by the fraudster.

0337The system of an embodiment comprises generating the predictive fraud model to include a fraud co-occurrence coefficient for at least one previous event potentially conducted by the fraudster.

0338The fraud co-occurrence coefficient of an embodiment represents an accumulated mistrust derived recursively from the at least one previous event potentially conducted by the fraudster.

0339The fraud co-occurrence coefficient of an embodiment comprises a coefficient representing an affect of a plurality of previous events potentially conducted by the fraudster.

0340Automatically generating the causal model of an embodiment includes generating a joint probability distribution that includes the plurality of components.

0341The plurality of components of an embodiment includes a plurality of probability distribution functions that represent the event parameters of the previous event.

0342The event parameters of the previous event of an embodiment are observable parameters collected during the previous event.

0343The event parameters of the previous event of an embodiment include one or more of Internet Protocol (IP) data and Hypertext Transfer Protocol (HTTP) data.

0344The IP data of an embodiment includes one or more of an IP address, IP address country, IP address city, IP network block, and internet service provider supporting an event.

0345The HTTP data of an embodiment includes one or more of data of an operating system, a user agent string, a referrer string, and internet browser of a computer used for an event.

0346Automatically generating the causal model of an embodiment includes generating statistical relationships between the event parameters and derived parameters.

0347The derived parameters of an embodiment include one or more of geographic area from which a device is initiating the next event, location of the device, identification of the device, and electronic service provider of the device.

0348Predicting the expected behavior of the user of an embodiment includes generating expected event parameters of the next event, wherein generating the expected event parameters includes generating a first set of predicted probability distributions that represent the expected event parameters, wherein generating the first set of predicted probability distributions assumes the user is conducting the next event.

0349The system of an embodiment comprises generating an alert corresponding to the next event when the expected behavior indicates a person other than the user is conducting the next event.

0350The system of an embodiment comprises automatically updating the causal model using a second set of event parameters collected during the next event, wherein the second set of event parameters is observable parameters collected during the next event.

0351Automatically updating the causal model of an embodiment includes updating at least one of a plurality of probability distribution functions that represent the event parameters, the updating modifying the at least one of the plurality of probability distribution functions by considering data of the second set of event parameters.

0352The previous event and the next event of an embodiment comprise at least one of online events, offline events, and multiple channel events, wherein online events are events undertaken via electronic access to the account.

0353An event of an embodiment comprises at least one of a login event and an activity event.

0354The system of an embodiment comprises determining probabilistically that the next event was conducted by the user. The system of an embodiment comprises automatically updating the causal model using a second set of event parameters collected during the next event.

0355The system of an embodiment comprises updating the causal model to include a trust factor, the trust factor representing a probability that the next event was in fact conducted by the user.

0356The system of an embodiment comprises updating the causal model to include an accumulated trust factor, the accumulated trust factor representing a cumulative probability across a plurality of events that an event parameter in the plurality of events was in fact conducted by the user.

0357Automatically generating the causal model of an embodiment comprises generating the causal model to include a decay parameter, wherein the decay parameter comprises an exponential decay function by which a relative weight of each event in the account changes with passage of time since the event.

0358The embodiments described herein include a system comprising: a risk engine executing on a processor and coupled to a financial system that includes an account, the risk engine generating an account model corresponding to a user and events conducted in the account, the generating of the account model using event parameters of a previous event performed by the user in the account to generate predicted distributions of the event parameters for a next event in the account, the risk engine receiving event parameters of the next event as the next event occurs, the risk engine generating a first probability using the account model, wherein the first probability is a probability of observing the event parameters assuming the user is conducting the next event, the risk engine generating a second probability using a fraud model, wherein the second probability is a probability of observing the event parameters assuming a fraudster is conducting the next event, wherein the fraudster is a person other than the user, wherein the events conducted in the account comprise the previous event and the next event, the risk engine generating a risk score using the first probability and the second probability, the risk score indicating the relative likelihood the next event is performed by the user versus the fraudster; and a risk application executing on the processor, the risk application comprising an analytical user interface (AUI), the AUI displaying for any event in the account at least one of the risk score and the event parameters.

0359The AUI of an embodiment comprises a horizontal axis representing a sequence of events ordered by time.

0360The AUI of an embodiment comprises a vertical axis representing the event parameters.

0361The event parameters of an embodiment include one or more of Internet Protocol (IP) data and Hypertext Transfer Protocol (HTTP) data

0362The IP data of an embodiment includes one or more of an IP address, IP address country, IP address city, IP network block, and internet service provider supporting an event.

0363The HTTP data of an embodiment includes one or more of data of an operating system, a user agent string, a referrer string, and internet browser of a computer used for an event.

0364The AUI of an embodiment comprises a plurality of columns, wherein each column of the plurality of columns represents at lease one event of the events conducted in the account, wherein the plurality of columns are arranged according to date.

0365The AUI of an embodiment comprises a plurality of rows, wherein a set of rows of the plurality of rows represent event parameters of the events.

0366The AUI comprises of an embodiment a plurality of intersection regions, each intersection region defined by an intersection of a row of the set of rows and a column, wherein the intersection region corresponds to an event parameter of the at least one event, wherein the intersection region includes color coding relating the event parameter to a corresponding probability of the account model.

0367The color coding of an embodiment represents a relative likelihood ratio that the event parameter corresponds to the user.

0368The AUI of an embodiment comprises a risk row representing risk of the event, wherein each intersection region defined by the intersection of the risk row with a column corresponds to the risk score of the at least one event corresponding to the column.

0369The intersection region of an embodiment includes color coding relating the risk score to the at least one event.

0370The color coding of an embodiment represents a relative likelihood ratio that the user conducted the at least one event.

0371The at least one event of an embodiment comprises at least one of an online event, an offline event, and a multiple-channel event.

0372Online events of an embodiment are events undertaken via electronic access to the account

0373The at least one event of an embodiment comprises a login event

0374The at least one event of an embodiment comprises an activity event.

0375The at least one event of an embodiment comprises a session, wherein the session is a sequence of related events.

0376The sequence of related events of an embodiment comprises a session login event and a termination event.

0377The sequence of related events of an embodiment comprises at least one activity event following the login event.

0378Generating the account model of an embodiment includes generating statistical relationships between predicted distributions.

0379Generating the account model of an embodiment includes generating a joint probability distribution that includes the predicted distributions,

0380The predicted distributions of an embodiment include a plurality of probability distribution functions that represent the event parameters.

0381The event parameters of an embodiment are observable parameters collected during the previous event

0382Generating the account model of an embodiment includes generating statistical relationships between the event parameters and derived parameters.

0383The derived parameters of an embodiment include one or more of geographic area from which a device is initiating the next event, location of the device, identification of the device, and electronic service provider of the device.

0384Generating the risk score of an embodiment includes generating expected event parameters of the next event.

0385Generating the expected event parameters of an embodiment includes generating a first set of predicted probability distributions that represent the expected event parameters, wherein generating the first set of predicted probability distributions assumes the user is conducting the second set of events.

0386The system of an embodiment comprises receiving a predictive fraud model. The system of an embodiment comprises generating a second set of predicted probability distributions that represent expected fraud event parameters, wherein generating the second set of predicted probability distributions assumes a fraudster is conducting the next event.

0387The system of an embodiment comprises automatically generating the predictive fraud model by estimating a plurality of fraud components of the predictive fraud model using fraud event parameters of previous fraudulent events undertaken in a plurality of accounts, wherein the previous fraudulent events are events suspected as having been conducted by the fraudster.

0388Automatically generating the predictive fraud model of an embodiment includes generating statistical relationships between fraud components of the plurality of fraud components.

0389Automatically generating the predictive fraud model of an embodiment includes generating statistical relationships between the fraud event parameters and derived fraud parameters.

0390The derived fraud parameters of an embodiment include one or more of a location of the device, identification of the device, and electronic service provider of the device.

0391The system of an embodiment comprises generating the predictive fraud model,

0392Generating the predictive fraud model of an embodiment comprises generating an original fraud model to include a probability of observing an event given that the event is caused by the fraudster and absent any other information about the event

0393Generating the predictive fraud model of an embodiment comprises generating a probabilistic combination of the original fraud model and an impersonation model.

0394The system of an embodiment comprises generating the original fraud model to include a probability of observing an event given that the event is caused by the fraudster and absent any other information about the event

0395Generating the predictive fraud model of an embodiment comprises generating the predictive fraud model to include an impersonation probability, wherein the impersonation probability is a probability that the fraudster successfully impersonates a parameter value of an event parameter of a set of events undertaken by the user.

0396The impersonation model of an embodiment comprises a probability that the fraudster mimics an event parameter of a set of events undertaken by the user

0397The impersonation model of an embodiment comprises a probability that the fraudster observes an event parameter of a set of events undertaken by the user

0398The system of an embodiment comprises identifying at least one previous fraud event, a previous fraud event comprising a previous event in the account potentially caused by the fraudster. The system of an embodiment comprises generating the original fraud model by estimating a plurality of components of the fraud model using event parameters of at least one previous fraud event undertaken in the account, the at least one previous fraud event potentially conducted by the fraudster.

0399The system of an embodiment comprises modifying the predictive fraud model based on at least one previous event potentially conducted by the fraudster.

0400The system of an embodiment comprises generating the predictive fraud model to include a fraud co-occurrence coefficient for at least one previous event potentially conducted by the fraudster.

0401The fraud co-occurrence coefficient of an embodiment represents an accumulated mistrust derived recursively from the at least one previous event potentially conducted by the fraudster.

0402The fraud co-occurrence coefficient of an embodiment comprises a coefficient representing an affect of a plurality of previous events potentially conducted by the fraudster

0403The system of an embodiment comprises selectively updating the account model using a second set of event parameters collected during the next event

0404The second set of event parameters of an embodiment is observable parameters collected during the next event.

0405Automatically updating the account model of an embodiment includes updating a joint probability distribution that includes a plurality of components of the account model.

0406Automatically updating the account model of an embodiment includes updating at least one of a plurality of components of the account model.

0407Automatically updating the account model of an embodiment includes updating at least one of a plurality of probability distribution functions that represent the event parameters, the updating modifying the at least one of the plurality of probability distribution functions by considering data of the second set of event parameters.

0408The system of an embodiment comprises generating a probability distribution function for each of the event parameters of the prior event The system of an embodiment comprises generating an updated probability distribution function for each of the event parameters by applying data of a second set of event parameters of the next event to the probability distribution function.

0409The system of an embodiment comprises receiving a baseline account model that corresponds to the user, the baseline account model generated without using data of any event The system of an embodiment comprises generating the account model by generating a joint probability distribution that includes a plurality of components of the account model, wherein the plurality of components includes the updated probability distribution function for any event parameter represented in the account model.

0410The previous event and the next event of an embodiment comprise at least one of online events, offline events, and multiple channel events.

0411Online events of an embodiment are events undertaken via electronic access to the account.

0412Events of an embodiment comprise login events.

0413Events of an embodiment comprise activity events.

0414The events of an embodiment comprise a session, wherein the session is a sequence of related events.

0415The sequence of related events of an embodiment comprises a session login event and a termination event.

0416The sequence of related events of an embodiment comprises at least one activity event.

0417The system of an embodiment comprises determining probabilistically that the next event was conducted by the user. The system of an embodiment comprises automatically updating the account model using a second set of event parameters collected during the next event.

0418The system of an embodiment comprises updating the account model to include a trust factor, the trust factor representing a probability that the next event was in fact conducted by the user.

0419The system of an embodiment comprises updating the account model to include an accumulated trust factor, the accumulated trust factor representing a cumulative probability across a plurality of events that an event parameter in the plurality of events was in fact conducted by the user.

0420Automatically generating the account model of an embodiment comprises generating the account model to include a decay parameter.

0421The decay parameter of an embodiment comprises an exponential decay function by which a relative weight of each event of the events in the account changes with passage of time since the event.

0422The embodiments described herein include a system comprising: a risk engine executing on a processor, the risk engine receiving from a financial system observations corresponding to a prior event, the prior event including actions taken in an account of the financial system during electronic access of the account, the risk engine estimating parameters of an account model using the observations and dynamically generating an account model to include the parameters, the account model corresponding only to the user, the risk engine using output of the account model to generate a risk score that is a relative likelihood an event in the account following the prior event is performed by the user versus the fraudster, and a risk application executing on the processor, the risk application comprising an analytical user interface (AUI), the AUI displaying for any event in the account at least one of the risk score and event parameters of any event in the account.

0423Aspects of the FPS described herein may be implemented as functionality programmed into any of a variety of circuitry, including programmable logic devices (PLDs), such as field programmable gate arrays (FPGAs), programmable array logic (PAL) devices, electrically programmable logic and memory devices and standard cell-based devices, as well as application specific integrated circuits (ASICs). Some other possibilities for implementing aspects of the FPS include: microcontrollers with memory (such as electronically erasable programmable read only memory (EEPROM)), embedded microprocessors, firmware, software, etc. Furthermore, aspects of the FPS may be embodied in microprocessors having software-based circuit emulation, discrete logic (sequential and combinatorial), custom devices, fuzzy (neural) logic, quantum devices, and hybrids of any of the above device types. Of course the underlying device technologies may be provided in a variety of component types, e.g., metal-oxide semiconductor field-effect transistor (MOSFET) technologies like complementary metal-oxide semiconductor (CMOS), bipolar technologies like emitter-coupled logic (ECL), polymer technologies (e.g., silicon-conjugated polymer and metal-conjugated polymer-metal structures), mixed analog and digital, etc

0424It should be noted that any system, method, and/or other components disclosed herein may be described using computer aided design tools and expressed (or represented), as data and/or instructions embodied in various computer-readable media, in terms of their behavioral, register transfer, logic component, transistor, layout geometries, and/or other characteristics . Computer-readable media in which such formatted data and/or instructions may be embodied include, but are not limited to, non-volatile storage media in various forms (e.g., optical, magnetic or semiconductor storage media) and carrier waves that may be used to transfer such formatted data and/or instructions through wireless, optical, or wired signaling media or any combination thereof. Examples of transfers of such formatted data and/or instructions by carrier waves include, but are not limited to, transfers (uploads, downloads, e-mail, etc.) over the Internet and/or other computer networks via one or more data transfer protocols (e.g., HTTP, FTP, SMTP, etc.). When received within a computer system via one or more computer-readable media, such data and/or instruction-based expressions of the above described components may be processed by a processing entity (e.g., one or more processors) within the computer system in conjunction with execution of one or more other computer programs.

0425Unless the context clearly requires otherwise, throughout the description and the claims, the words "comprise," "comprising," and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of "including, but not limited to." Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words "herein," "hereunder," "above," "below," and words of similar import, when used in this application, refer to this application as a whole and not to any particular portions of this application. When the word "or" is used in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list and any combination of the items in the list.

0426The above description of embodiments of the FPS is not intended to be exhaustive or to limit the systems and methods to the precise forms disclosed. While specific embodiments of, and examples for, the FPS are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the systems and methods, as those skilled in the relevant art will recognize. The teachings of the FPS provided herein can be applied to other systems and methods, not only for the systems and methods described above,

0427The elements and acts of the various embodiments described above can be combined to provide further embodiments. These and other changes can be made to the FPS in light of the above detailed description.

0428In general, in the following claims, the terms used should not be construed to limit the FPS to the specific embodiments disclosed in the specification and the claims, but should be construed to include all systems that operate under the claims. Accordingly, the FPS is not limited by the disclosure, but instead the scope of the FPS is to be determined entirely by the claims.

0429While certain aspects of the FPS are presented below in certain claim forms, the inventors contemplate the various aspects of the FPS in any number of claim forms. Accordingly, the inventors reserve the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the FPS.

0430Other aspect of the invention are defined in the following clauses: <ul id="ul0023" list-style="none"><li>Clause 1. A method comprising automatically generating a causal model corresponding to a user; estimating a plurality of components of the causal model using event parameters of a first set of events undertaken by the user in an account of the user; and predicting expected behavior of the user during a second set of events using the causal model.</li><li>Clause 2. The method of clause 1, wherein automatically generating the causal model includes generating statistical relationships between components of the plurality of components.</li><li>Clause 3. The method of clause 1, comprising representing the causal model as a Bayesian network.</li><li>Clause 4. The method of clause 1, wherein automatically generating the causal model includes generating a joint probability distribution that includes the plurality of components.</li><li>Clause 5. The method of clause 4, wherein the plurality of components includes a plurality of probability distribution functions that represent the event parameters.</li><li>Clause 6. The method of clause 5, wherein the event parameters are observable parameters collected during the first set of events.</li><li>Clause 7. The method of clause 6, wherein the event parameters include one or more of Internet Protocol (IP) data and Hypertext Transfer Protocol (HTTP) data.</li><li>Clause 8. The method of clause 7, wherein the IP data includes one or more of an IP address, IP address country, IP address city, IP network block, and internet service provider supporting an event.</li><li>Clause 9. The method of clause 7, wherein the HTTP data includes one or more of data of an operating system, a user agent string, a referrer string, and internet browser of a computer used for an event.</li><li>Clause 10. The method of clause 1, wherein automatically generating the causal model includes generating statistical relationships between the event parameters and derived parameters.</li><li>Clause 11. The method of clause 10, wherein the derived parameters include one or more of geographic area from which a device is initiating the second set of events, location of the device, identification of the device, and electronic service provider of the device.</li><li>Clause 12. The method of clause 1, wherein predicting the expected behavior of the user includes generating expected event parameters of the second set of events. Clause 13. The method of clause 12, wherein generating the expected event parameters includes generating a first set of predicted probability distributions that represent the expected event parameters, wherein generating the first set of predicted probability distributions assumes the user is conducting the second set of events.</li><li>Clause 14. The method of clause 1, comprising: receiving a predictive fraud model; and generating a second set of predicted probability distributions that represent expected fraud event parameters, wherein generating the second set of predicted probability distributions assumes a fraudster is conducting the second set of events, wherein the fraudster is any person other than the user.</li><li>Clause 15. The method of clause 14, comprising automatically generating the predictive fraud model by estimating a plurality of fraud components of the predictive fraud model using fraud event parameters of previous fraudulent events undertaken in a plurality of accounts, wherein the previous fraudulent events are events suspected as having been conducted by the fraudster.</li><li>Clause 16. The method of clause 15, wherein automatically generating the predictive fraud model includes generating statistical relationships between fraud components of the plurality of fraud components.</li><li>Clause 17. The method of clause 15, wherein automatically generating the predictive fraud model includes generating statistical relationships between the fraud event parameters and derived fraud parameters.</li><li>Clause 18. The method of clause 17, wherein the derived fraud parameters include one or more of a location of the device, identification of the device, and electronic service provider of the device.</li><li>Clause 19. The method of clause 14, comprising generating in real-time a risk score of an event of the second set of events using the expected event parameters and the expected fraud event parameters along with the observed parameters.</li><li>Clause 20. The method of clause 1, comprising generating an alert corresponding to an event of the second set of events when the expected behavior indicates a person other than the user is conducting the event.</li><li>Clause 21. The method of clause 1, comprising automatically updating the causal model using a second set of event parameters collected during the second set of events.</li><li>Clause 22. The method of clause 21, wherein the second set of event parameters are observable parameters collected during the second set of events.</li><li>Clause 23. The method of clause 21, wherein automatically updating the causal model includes updating a joint probability distribution that includes the plurality of components.</li><li>Clause 24. The method of clause 21, wherein automatically updating the causal model includes updating at least one of the plurality of components.</li><li>Clause 25. The method of clause 21, wherein automatically updating the causal model includes updating at least one of a plurality of probability distribution functions that represent the event parameters, the updating modifying the at least one of the plurality of probability distribution functions by considering data of the second set of event parameters.</li><li>Clause 26. The method of clause 21, comprising: generating a probability distribution function for each of the event parameters of the first set of events; and generating an updated probability distribution function for each of the event parameters by applying data of a second set of event parameters of the second set of events to the probability distribution function.</li><li>Clause 27. The method of clause 26, comprising: receiving a baseline causal model that corresponds to the user, the baseline causal model generated without using data of any event; and generating the causal model by generating a joint probability distribution that includes the plurality of components, wherein the plurality of components includes the updated probability distribution function for any event parameter represented in the causal model.</li><li>Clause 28. The method of clause 1, wherein the first set of events and the second set of events comprises at least one of online events, offline events, and multiple channel events.</li><li>Clause 29. The method of clause 28, wherein online events are events undertaken via electronic access to the account.</li><li>Clause 30. The method of clause 1, wherein events comprise login events.</li><li>Clause 31. The method of clause 1, wherein events comprise activity events.</li><li>Clause 32. The method of clause 1, wherein a set of events comprises a session, wherein the session is a sequence of related events.</li><li>Clause 33. The method of clause 32, wherein the sequence of related events comprises a session login event and a termination event.</li><li>Clause 34. The method of clause 33, wherein the sequence of related events comprises at least one activity event.</li><li>Clause 35. The method of clause 1, comprising: determining probabilistically that the second set of events was conducted by the user; automatically updating the causal model using a second set of event parameters collected during the second set of events.</li><li>Clause 36. The method of clause 35, comprising updating the causal model to include a trust factor, the trust factor representing a probability that the second set of events was in fact conducted by the user.</li><li>Clause 37. The method of clause 35, comprising updating the causal model to include an accumulated trust factor, the accumulated trust factor representing a cumulative probability across a plurality of sets of events that an event parameter in the plurality of sets of events was in fact conducted by the user.</li><li>Clause 38. The method of clause 1, wherein automatically generating the causal model comprises generating the causal model to include a decay parameter.</li><li>Clause 39. The method of clause 38, wherein the decay parameter comprises an exponential decay function by which a relative weight of each event in a set of events in the account changes with passage of time since the event.</li><li>Clause 40. A method comprising: receiving a plurality of observations corresponding to a first event, the first event including actions taken in an account during electronic access of the account; generating probabilistic relationships between the observations and derived parameters of an owner of the account; automatically generating an account model to include the probabilistic relationships; and estimating actions of the owner during a second event using the account model, wherein the second event follows the first event in time.</li><li>Clause 41. A method comprising: automatically generating a causal model corresponding to a user, the generating comprising estimating a plurality of components of the causal model using event parameters of a previous event undertaken by the user in an account of the user; predicting expected behavior of the user during a next event in the account using the causal model, wherein predicting the expected behavior of the user includes generating predicted event parameters of the next event; receiving observed event parameters of the next event; and updating the causal model for use in a future event, the updating comprising regenerating the plurality of components based on a relationship between the expected event parameters and the observed event parameters.</li><li>Clause 42. A system comprising a processor executing at least one application, the application receiving event parameters of a first set of events undertaken by the user in an account of the user, the application automatically generating a causal model corresponding to a user by estimating a plurality of components of the causal model using the event parameters of the first set of events, the application using the causal model to output a prediction of expected behavior of the user during a second set of events.</li><li>Clause 43. The system of clause 42, wherein automatically generating the causal model includes generating statistical relationships between components of the plurality of components.</li><li>Clause 44. The system of clause 42, wherein automatically generating the causal model includes generating a joint probability distribution that includes the plurality of components.</li><li>Clause 45. The system of clause 44, wherein the plurality of components includes a plurality of probability distribution functions that represent the event parameters. Clause 46. The system of clause 45, wherein the event parameters are observable parameters collected during the first set of events.</li><li>Clause 47. The system of clause 46, wherein the event parameters include one or more of Internet Protocol (IP) data and Hypertext Transfer Protocol (HTTP) data.</li><li>Clause 48. The system of clause 47, wherein the IP data includes one or more of an IP address, IP address country, IP address city, IP network block, and internet service provider supporting an event.</li><li>Clause 49. The system of clause 47, wherein the HTTP data includes one or more of data of an operating system, a user agent string, a referrer string, and internet browser of a computer used for an event.</li><li>Clause 50. The system of clause 42, wherein automatically generating the causal model includes generating statistical relationships between the event parameters and derived parameters.</li><li>Clause 51. The system of clause 50, wherein the derived parameters include one or more of geographic area from which a device is initiating the second set of events, location of the device, identification of the device, and electronic service provider of the device.</li><li>Clause 52. The system of clause 42, wherein predicting the expected behavior of the user includes generating expected event parameters of the second set of events.</li><li>Clause 53. The system of clause 52, wherein generating the expected event parameters includes generating a first set of predicted probability distributions that represent the expected event parameters, wherein generating the first set of predicted probability distributions assumes the user is conducting the second set of events.</li><li>Clause 54. The system of clause 53, comprising: receiving a predictive fraud model; and generating a second set of predicted probability distributions that represent expected fraud event parameters, wherein generating the second set of predicted probability distributions assumes a fraudster is conducting the second set of events, wherein the fraudster is any person other than the user.</li><li>Clause 55. The system of clause 54, comprising generating in real-time a risk score of an event of the second set of events using the expected event parameters and the expected fraud event parameters along with the observed parameters.</li><li>Clause 56. The system of clause 42, comprising generating an alert corresponding to an event of the second set of events when the expected behavior indicates a person other than the user is conducting the event.</li><li>Clause 57. The system of clause 42, comprising automatically updating the causal model using a second set of event parameters collected during the second set of events.</li><li>Clause 58. The system of clause 57, wherein automatically updating the causal model includes updating at least one of a plurality of probability distribution functions that represent the event parameters, the updating modifying the at least one of the plurality of probability distribution functions by considering data of the second set of event parameters.</li><li>Clause 59. The system of clause 57, comprising: generating a probability distribution function for each of the event parameters of the first set of events; and generating an updated probability distribution function for each of the event parameters by applying data of a second set of event parameters of the second set of events to the probability distribution function.</li><li>Clause 60. The system of clause 42, wherein the first set of events and the second set of events comprises at least one of online events, offline events, and multiple channel events.</li><li>Clause 61. The system of clause 60, wherein online events are events undertaken via electronic access to the account.</li><li>Clause 62. The system of clause 42, wherein events comprise login events.</li><li>Clause 63. The system of clause 42, wherein events comprise activity events.</li><li>Clause 64. The system of clause 42, wherein a set of events comprises a session, wherein the session is a sequence of related events.</li><li>Clause 65. The system of clause 42, comprising: determining probabilistically that the second set of events was conducted by the user; automatically updating the causal model using a second set of event parameters collected during the second set of events.</li><li>Clause 66. The system of clause 65, comprising updating the causal model to include a trust factor, the trust factor representing a probability that the second set of events was in fact conducted by the user.</li><li>Clause 67. The system of clause 65, comprising updating the causal model to include an accumulated trust factor, the accumulated trust factor representing a cumulative probability across a plurality of sets of events that an event parameter in the plurality of sets of events was in fact conducted by the user.</li><li>Clause 68. The system of clause 42, wherein automatically generating the causal model comprises generating the causal model to include a decay parameter.</li><li>Clause 69. The system of clause 68, wherein the decay parameter comprises an exponential decay function by which a relative weight of each event in a set of events in the account changes with passage of time since the event.</li><li>Clause 70. A system comprising a processor executing at least one application, the application receiving event parameters of a first set of events undertaken by a user in an account of the user, the application automatically generating an account model corresponding to the user, the account model comprising a plurality of components, wherein generating the account model comprises generating the plurality of components using the event parameters of the first set of events, the application predicting expected behavior of the user during a second set of events using the account model, the application generating an updated version of the account model for use in a future set of events, the updating comprising regenerating the plurality of components using the second set of events.</li><li>Clause 71. A method comprising: automatically generating a causal model corresponding to a user, the generating comprising estimating a plurality of components of the causal model using event parameters of a previous event undertaken by the user in an account of the user; predicting expected behavior of the user during a next event in the account using the causal model, wherein predicting the expected behavior of the user includes generating expected event parameters of the next event; using a predictive fraud model, generating fraud event parameters, wherein generating the fraud event parameters assumes a fraudster is conducting the next event, wherein the fraudster is any person other than the user; and generating a risk score of the next event using the expected event parameters and the fraud event parameters, the risk score indicating the relative likelihood the future event is performed by the user versus the fraudster.</li><li>Clause 72. The method of clause 71, comprising automatically generating the predictive fraud model by estimating a plurality of fraud components of the predictive fraud model using the fraud event parameters of previous fraudulent events undertaken in a plurality of accounts, wherein the previous fraudulent events are events suspected as having been conducted by the fraudster.</li><li>Clause 73. The method of clause 72, wherein automatically generating the predictive fraud model includes generating statistical relationships between fraud components of the plurality of fraud components.</li><li>Clause 74. The method of clause 72, wherein automatically generating the predictive fraud model includes generating a joint probability distribution that includes the plurality of fraud components.</li><li>Clause 75. The method of clause 74, wherein the plurality of fraud components includes a plurality of fraud probability distribution functions that represent the fraud event parameters.</li><li>Clause 76. The method of clause 75, wherein the fraud event parameters are observable fraud parameters collected during the previous fraudulent events.</li><li>Clause 77. The method of clause 71, wherein automatically generating the predictive fraud model includes generating statistical relationships between the fraud event parameters and derived fraud parameters.</li><li>Clause 78. The method of clause 77, wherein the derived fraud parameters include one or more of a location of the device, identification of the device, and electronic service provider of the device.</li><li>Clause 79. The method of clause 71, comprising generating the predictive fraud model.</li><li>Clause 80. The method of clause 79, wherein generating the predictive fraud model comprises generating an original fraud model to include a probability of observing an event given that the event is caused by the fraudster and absent any other information about the event</li><li>Clause 81. The method of clause 79, wherein generating the predictive fraud model comprises generating a probabilistic combination of the original fraud model and an impersonation model.</li><li>Clause 82. The method of clause 81, comprising generating the original fraud model to include a probability of observing an event given that the event is caused by the fraudster and absent any other information about the event.</li><li>Clause 83. The method of clause 81, wherein generating the predictive fraud model comprises generating the predictive fraud model to include an impersonation probability, wherein the impersonation probability is a probability that the fraudster successfully impersonates a parameter value of an event parameter of a set of events undertaken by the user.</li><li>Clause 84. The method of clause 81, wherein the impersonation model comprises a probability that the fraudster mimics an event parameter of a set of events undertaken by the user.</li><li>Clause 85. The method of clause 81, wherein the impersonation model comprises a probability that the fraudster observes an event parameter of a set of events undertaken by the user.</li><li>Clause 86. The method of clause 81, comprising: identifying at least one previous fraud event, a previous fraud event comprising a previous event in the account potentially caused by the fraudster; generating the original fraud model by estimating a plurality of components of the fraud model using event parameters of at least one previous fraud event undertaken in the account, the at least one previous fraud event potentially conducted by the fraudster.</li><li>Clause 87. The method of clause 86, comprising modifying the predictive fraud model based on at least one previous event potentially conducted by the fraudster.</li><li>Clause 88. The method of clause 86, comprising generating the predictive fraud model to include a fraud co-occurrence coefficient for at least one previous event potentially conducted by the fraudster.</li><li>Clause 89. The method of clause 88, wherein the fraud co-occurrence coefficient represents an accumulated mistrust derived recursively from the at least one previous event potentially conducted by the fraudster.</li><li>Clause 90. The method of clause 88, wherein the fraud co-occurrence coefficient comprises a coefficient representing an affect of a plurality of previous events potentially conducted by the fraudster.</li><li>Clause 91. The method of clause 71, wherein automatically generating the causal model includes generating statistical relationships between components of the plurality of components.</li><li>Clause 92. The method of clause 71, wherein automatically generating the causal model includes generating a joint probability distribution that includes the plurality of components.</li><li>Clause 93. The method of clause 92, wherein the plurality of components includes a plurality of probability distribution functions that represent the event parameters of the previous event.</li><li>Clause 94. The method of clause 93, wherein the event parameters are observable parameters collected during the previous event.</li><li>Clause 95. The method of clause 94, wherein the event parameters include one or more of Internet Protocol (IP) data and Hypertext Transfer Protocol (HTTP) data.</li><li>Clause 96. The method of clause 95, wherein the IP data includes one or more of an IP address, IP address country, IP address city, IP network block, and internet service provider supporting an event.</li><li>Clause 97. The method of clause 95, wherein the HTTP data includes one or more of data of an operating system, a user agent string, a referrer string, and internet browser of a computer used for an event.</li><li>Clause 98. The method of clause 71, wherein automatically generating the causal model includes generating statistical relationships between the event parameters and derived parameters.</li><li>Clause 99. The method of clause 98, wherein the derived parameters include one or more of geographic area from which a device is initiating the next event, location of the device, identification of the device, and electronic service provider of the device.</li><li>Clause 100. The method of clause 71, wherein predicting the expected behavior of the user includes generating expected event parameters of the next event.</li><li>Clause 101. The method of clause 100, wherein generating the expected event parameters includes generating a first set of predicted probability distributions that represent the expected event parameters, wherein generating the first set of predicted probability distributions assumes the user is conducting the next event.</li><li>Clause 102. The method of clause 71, comprising generating an alert corresponding to the next event when the risk score indicates a person other than the user is conducting the next event.</li><li>Clause 103. The method of clause 71, comprising automatically updating the causal model using a second set of event parameters collected during the next event.</li><li>Clause 104. The method of clause 103, wherein the second set of event parameters is observable parameters collected during the next event.</li><li>Clause 105. The method of clause 103, wherein automatically updating the causal model includes updating a joint probability distribution that includes the plurality of components.</li><li>Clause 106. The method of clause 103, wherein automatically updating the causal model includes updating at least one of the plurality of components.</li><li>Clause 107. The method of clause 103, wherein automatically updating the causal model includes updating at least one of a plurality of probability distribution functions that represent the event parameters, the updating modifying the at least one of the plurality of probability distribution functions by considering data of the second set of event parameters.</li><li>Clause 108. The method of clause 103, comprising: generating a probability distribution function for each of the event parameters of the previous event; and generating an updated probability distribution function for each of the event parameters by applying data of a second set of event parameters of the next event to the probability distribution function.</li><li>Clause 109. The method of clause 108, comprising: receiving a baseline causal model that corresponds to the user, the baseline causal model generated without using data of any event; and generating the causal model by generating a joint probability distribution that includes the plurality of components, wherein the plurality of components includes the updated probability distribution function for any event parameter represented in the causal model.</li><li>Clause 110. The method of clause 71, wherein the previous event and the next event comprise at least one of online events, offline events, and multiple channel events.</li><li>Clause 111. The method of clause 110, wherein online events are events undertaken via electronic access to the account.</li><li>Clause 112. The method of clause 71, wherein an event comprises a login event.</li><li>Clause 113. The method of clause 71, wherein an event comprises an activity event.</li><li>Clause 114. The method of clause 71, comprising: determining probabilistically that the next event was conducted by the user; automatically updating the causal model using a second set of event parameters collected during the next event.</li><li>Clause 115. The method of clause 114, comprising updating the causal model to include a trust factor, the trust factor representing a probability that the next event was in fact conducted by the user.</li><li>Clause 116. The method of clause 114, comprising updating the causal model to include an accumulated trust factor, the accumulated trust factor representing a cumulative probability across a plurality of events that an event parameter in the plurality of events was in fact conducted by the user.</li><li>Clause 117. The method of clause 71, wherein automatically generating the causal model comprises generating the causal model to include a decay parameter.</li><li>Clause 118. The method of clause 117, wherein the decay parameter comprises an exponential decay function by which a relative weight of each event in the account changes with passage of time since the event.</li><li>Clause 119. A method comprising: automatically generating an account model corresponding to a user, the generating of the account model using event parameters of a previous event performed by the user in an account of the user to generate predicted distributions of the event parameters for a next event in the account, wherein the account model includes the predicted distributions of the event parameters; receiving observed event parameters of the next event as the next event occurs; generating a first probability using the account model, wherein the first probability is a probability of observing the observed event parameters assuming the user is conducting the next event; generating a second probability using a fraud model, wherein the second probability is a probability of observing the observed event parameters assuming a fraudster is conducting the next event, wherein the fraudster is a person other than the user; and generating a risk score using the first probability and the second probability, the risk score indicating the relative likelihood the next event is performed by the user versus the fraudster.</li><li>Clause 120. A method comprising: generating probabilistic relationships between observations of a first event and derived parameters of an owner of an account; automatically generating an account model including the probabilistic relationships; dynamically updating the account model using observations of a second event; and using the account model to predict during a third event whether the owner or a fraudster is perpetuating the third event, wherein an event includes actions taken in the account during electronic access of the account.</li><li>Clause 121. A system comprising a processor executing at least one application, the application automatically generating a predictive user model corresponding to a user, wherein the predictive user model includes a plurality of probability distributions representing event parameters observed during a first event in an account of the user, the application generating predicted event parameters using the predictive user model, the predicted event parameters expected to be observed during a second event in the account, the second event following the first event, the application comparing actual event parameters of the second event to the predicted event parameters during the second event and generating an alert corresponding to the second event when the actual event parameters appear to be initiated by a person other than the user.</li><li>Clause 122. A system comprising a processor executing at least one application, the application automatically generating a causal model corresponding to a user by estimating a plurality of components of the causal model using event parameters of a previous event undertaken by the user in an account of the user, the application predicting expected behavior of the user during a next event in the account using the causal model, wherein predicting the expected behavior of the user includes generating expected event parameters of the next event, the application using a predictive fraud model, generating fraud event parameters, wherein generating the fraud event parameters assumes a fraudster is conducting the next event, wherein the fraudster is any person other than the user, the application generating a risk score of the next event using the expected event parameters and the fraud event parameters, the risk score indicating the relative likelihood the future event is performed by the user versus the fraudster.</li><li>Clause 123. The system of clause 122, comprising automatically generating the predictive fraud model by estimating a plurality of fraud components of the predictive fraud model using the fraud event parameters of previous fraudulent events undertaken in a plurality of accounts, wherein the previous fraudulent events are events suspected as having been conducted by the fraudster.</li><li>Clause 124. The system of clause 123, wherein automatically generating the predictive fraud model includes generating statistical relationships between fraud components of the plurality of fraud components.</li><li>Clause 125. The system of clause 123, wherein automatically generating the predictive fraud model includes generating a joint probability distribution that includes the plurality of fraud components.</li><li>Clause 126. The system of clause 125, wherein the plurality of fraud components includes a plurality of fraud probability distribution functions that represent the fraud event parameters, wherein the fraud event parameters are observable fraud parameters collected during the previous fraudulent events.</li><li>Clause 127. The system of clause 122, wherein automatically generating the predictive fraud model includes generating statistical relationships between the fraud event parameters and derived fraud parameters.</li><li>Clause 128. The system of clause 127, wherein the derived fraud parameters include one or more of a location of the device, identification of the device, and electronic service provider of the device.</li><li>Clause 129. The system of clause 122, comprising generating the predictive fraud model.</li><li>Clause 130. The system of clause 129, wherein generating the predictive fraud model comprises generating an original fraud model to include a probability of observing an event given that the event is caused by the fraudster and absent any other information about the event</li><li>Clause 131 The system of clause 129, wherein generating the predictive fraud model comprises generating a probabilistic combination of the original fraud model and an impersonation model.</li><li>Clause 132. The system of clause 131, comprising generating the original fraud model to include a probability of observing an event given that the event is caused by the fraudster and absent any other information about the event.</li><li>Clause 133. The system of clause 131, wherein generating the predictive fraud model comprises generating the predictive fraud model to include an impersonation probability, wherein the impersonation probability is a probability that the fraudster successfully impersonates a parameter value of an event parameter of a set of events undertaken by the user.</li><li>Clause 134. The system of clause 131, wherein the impersonation model comprises a probability that the fraudster mimics an event parameter of a set of events undertaken by the user.</li><li>Clause 135. The system of clause 131, wherein the impersonation model comprises a probability that the fraudster observes an event parameter of a set of events undertaken by the user.</li><li>Clause 136. The system of clause 131, comprising:identifying at least one previous fraud event, a previous fraud event comprising a previous event in the account potentially caused by the fraudster; generating the original fraud model by estimating a plurality of components of the fraud model using event parameters of at least one previous fraud event undertaken in the account, the at least one previous fraud event potentially conducted by the fraudster.</li><li>Clause 137. The system of clause 136, comprising modifying the predictive fraud model based on at least one previous event potentially conducted by the fraudster.</li><li>Clause 138. The system of clause 136, comprising generating the predictive fraud model to include a fraud co-occurrence coefficient for at least one previous event potentially conducted by the fraudster.</li><li>Clause 139. The system of clause 138, wherein the fraud co-occurrence coefficient represents an accumulated mistrust derived recursively from the at least one previous event potentially conducted by the fraudster.</li><li>Clause 140. The system of clause 138, wherein the fraud co-occurrence coefficient comprises a coefficient representing an affect of a plurality of previous events potentially conducted by the fraudster.</li><li>Clause 141. The system of clause 122, wherein automatically generating the causal model includes generating a joint probability distribution that includes the plurality of components.</li><li>Clause 142. The system of clause 141, wherein the plurality of components includes a plurality of probability distribution functions that represent the event parameters of the previous event.</li><li>Clause 143. The system of clause 142, wherein the event parameters of the previous event are observable parameters collected during the previous event.</li><li>Clause 144. The system of clause 143, wherein the event parameters of the previous event include one or more of Internet Protocol (IP) data and Hypertext Transfer Protocol (HTTP) data.</li><li>Clause 145. The system of clause 144, wherein the IP data includes one or more of an IP address, IP address country, IP address city, IP network block, and internet service provider supporting an event.</li><li>Clause 146. The system of clause 144, wherein the HTTP data includes one or more of data of an operating system, a user agent string, a referrer string, and internet browser of a computer used for an event.</li><li>Clause 147. The system of clause 122, wherein automatically generating the causal model includes generating statistical relationships between the event parameters and derived parameters.</li><li>Clause 148. The system of clause 147, wherein the derived parameters include one or more of geographic area from which a device is initiating the next event, location of the device, identification of the device, and electronic service provider of the device.</li><li>Clause 149. The system of clause 122, wherein predicting the expected behavior of the user includes generating expected event parameters of the next event, wherein generating the expected event parameters includes generating a first set of predicted probability distributions that represent the expected event parameters, wherein generating the first set of predicted probability distributions assumes the user is conducting the next event.</li><li>Clause 150. The system of clause 122, comprising generating an alert corresponding to the next event when the expected behavior indicates a person other than the user is conducting the next event.</li><li>Clause 151. The system of clause 122, comprising automatically updating the causal model using a second set of event parameters collected during the next event, wherein the second set of event parameters is observable parameters collected during the next event.</li><li>Clause 152. The system of clause 151, wherein automatically updating the causal model includes updating at least one of a plurality of probability distribution functions that represent the event parameters, the updating modifying the at least one of the plurality of probability distribution functions by considering data of the second set of event parameters.</li><li>Clause 153. The system of clause 122, wherein the previous event and the next event comprise at least one of online events, offline events, and multiple channel events, wherein online events are events undertaken via electronic access to the account.</li><li>Clause 154. The system of clause 122, wherein an event comprises at least one of a login event and an activity event.</li><li>Clause 155. The system of clause 122, comprising:determining probabilistically that the next event was conducted by the user;automatically updating the causal model using a second set of event parameters collected during the next event.</li><li>Clause 156. The system of clause 155, comprising updating the causal model to include a trust factor, the trust factor representing a probability that the next event was in fact conducted by the user.</li><li>Clause 157. The system of clause 155, comprising updating the causal model to include an accumulated trust factor, the accumulated trust factor representing a cumulative probability across a plurality of events that an event parameter in the plurality of events was in fact conducted by the user.</li><li>Clause 158. The system of clause 122, wherein automatically generating the causal model comprises generating the causal model to include a decay parameter, wherein the decay parameter comprises an exponential decay function by which a relative weight of each event in the account changes with passage of time since the event.</li><li>Clause 159. A system comprising: a risk engine executing on a processor and coupled to a financial system that includes an account, the risk engine generating an account model corresponding to a user and events conducted in the account, the generating of the account model using event parameters of a previous event performed by the user in the account to generate predicted distributions of the event parameters for a next event in the account, the risk engine receiving event parameters of the next event as the next event occurs, the risk engine generating a first probability using the account model, wherein the first probability is a probability of observing the event parameters assuming the user is conducting the next event, the risk engine generating a second probability using a fraud model, wherein the second probability is a probability of observing the event parameters assuming a fraudster is conducting the next event, wherein the fraudster is a person other than the user, wherein the events conducted in the account comprise the previous event and the next event, the risk engine generating a risk score using the first probability and the second probability, the risk score indicating the relative likelihood the next event is performed by the user versus the fraudster; and a risk application executing on the processor, the risk application comprising an analytical user interface (AUI), the AUI displaying for any event in the account at least one of the risk score and the event parameters.</li><li>Clause 160. The system of clause 159, wherein the AUI comprises a horizontal axis representing a sequence of events ordered by time.</li><li>Clause 161. The system of clause 160, wherein the AUI comprises a vertical axis representing the event parameters.</li><li>Clause 162. The system of clause 161, wherein the event parameters include one or more of Internet Protocol (IP) data and Hypertext Transfer Protocol (HTTP) data.</li><li>Clause 163. The system of clause 162, wherein the IP data includes one or more of an IP address, IP address country, IP address city, IP network block, and internet service provider supporting an event.</li><li>Clause 164. The system of clause 162, wherein the HTTP data includes one or more of data of an operating system, a user agent string, a referrer string, and internet browser of a computer used for an event.</li><li>Clause 165. The system of clause 161, wherein the AUI comprises a plurality of columns, wherein each column of the plurality of columns represents at lease one event of the events conducted in the account, wherein the plurality of columns are arranged according to date.</li><li>Clause 166. The system of clause 165, wherein the AUI comprises a plurality of rows, wherein a set of rows of the plurality of rows represent event parameters of the events.</li><li>Clause 167. The system of clause 165, wherein the AUI comprises a plurality of intersection regions, each intersection region defined by an intersection of a row of the set of rows and a column, wherein the intersection region corresponds to an event parameter of the at least one event, wherein the intersection region includes color coding relating the event parameter to a corresponding probability of the account model.</li><li>Clause 168. The system of clause 167, wherein the color coding represents a relative likelihood ratio that the event parameter corresponds to the user.</li><li>Clause 169. The system of clause 165, wherein the AUI comprises a risk row representing risk of the event, wherein each intersection region defined by the intersection of the risk row with a column corresponds to the risk score of the at least one event corresponding to the column.</li><li>Clause 170. The system of clause 169, wherein the intersection region includes color coding relating the risk score to the at least one event.</li><li>Clause 171. The system of clause 170, wherein the color coding represents a relative likelihood ratio that the user conducted the at least one event.</li><li>Clause 172. The system of clause 165, wherein the at least one event comprises at least one of an online event, an offline event, and a multiple-channel event.</li><li>Clause 173. The system of clause 172, wherein online events are events undertaken via electronic access to the account.</li><li>Clause 174. The system of clause 165, wherein the at least one event comprises a login event.</li><li>Clause 175. The system of clause 165, wherein the at least one event comprises an activity event.</li><li>Clause 176. The system of clause 165, wherein the at least one event comprises a session, wherein the session is a sequence of related events.</li><li>Clause 177. The system of clause 176, wherein the sequence of related events comprises a session login event and a termination event.</li><li>Clause 178. The system of clause 177, wherein the sequence of related events comprises at least one activity event following the login event.</li><li>Clause 179. The system of clause 159, wherein generating the account model includes generating statistical relationships between predicted distributions.</li><li>Clause 180. The system of clause 159, wherein generating the account model includes generating a joint probability distribution that includes the predicted distributions.</li><li>Clause 181. The system of clause 180, wherein the predicted distributions include a plurality of probability distribution functions that represent the event parameters.</li><li>Clause 182. The system of clause 181, wherein the event parameters are observable parameters collected during the previous event.</li><li>Clause 183. The system of clause 159, wherein generating the account model includes generating statistical relationships between the event parameters and derived parameters.</li><li>Clause 184. The system of clause 183, wherein the derived parameters include one or more of geographic area from which a device is initiating the next event, location of the device, identification of the device, and electronic service provider of the device.</li><li>Clause 185. The system of clause 159, wherein generating the risk score includes generating expected event parameters of the next event.</li><li>Clause 186. The system of clause 185, wherein generating the expected event parameters includes generating a first set of predicted probability distributions that represent the expected event parameters, wherein generating the first set of predicted probability distributions assumes the user is conducting the second set of events.</li><li>Clause 187. The system of clause 159, comprising: receiving a predictive fraud model; and generating a second set of predicted probability distributions that represent expected fraud event parameters, wherein generating the second set of predicted probability distributions assumes a fraudster is conducting the next event.</li><li>Clause 188. The system of clause 187, comprising automatically generating the predictive fraud model by estimating a plurality of fraud components of the predictive fraud model using fraud event parameters of previous fraudulent events undertaken in a plurality of accounts, wherein the previous fraudulent events are events suspected as having been conducted by the fraudster.</li><li>Clause 189. The system of clause 188, wherein automatically generating the predictive fraud model includes generating statistical relationships between fraud components of the plurality of fraud components.</li><li>Clause 190. The system of clause 188, wherein automatically generating the predictive fraud model includes generating statistical relationships between the fraud event parameters and derived fraud parameters.</li><li>Clause 191. The system of clause 190, wherein the derived fraud parameters include one or more of a location of the device, identification of the device, and electronic service provider of the device.</li><li>Clause 192. The system of clause 187, comprising generating the predictive fraud model.</li><li>Clause 193. The system of clause 192, wherein generating the predictive fraud model comprises generating an original fraud model to include a probability of observing an event given that the event is caused by the fraudster and absent any other information about the event</li><li>Clause 194. The system of clause 192, wherein generating the predictive fraud model comprises generating a probabilistic combination of the original fraud model and an impersonation model.</li><li>Clause 195. The system of clause 194, comprising generating the original fraud model to include a probability of observing an event given that the event is caused by the fraudster and absent any other information about the event.</li><li>Clause 196. The system of clause 194, wherein generating the predictive fraud model comprises generating the predictive fraud model to include an impersonation probability, wherein the impersonation probability is a probability that the fraudster successfully impersonates a parameter value of an event parameter of a set of events undertaken by the user.</li><li>Clause 197. The system of clause 194, wherein the impersonation model comprises a probability that the fraudster mimics an event parameter of a set of events undertaken by the user.</li><li>Clause 198. The system of clause 194, wherein the impersonation model comprises a probability that the fraudster observes an event parameter of a set of events undertaken by the user.</li><li>Clause 199. The system of clause 194, comprising: identifying at least one previous fraud event, a previous fraud event comprising a previous event in the account potentially caused by the fraudster; generating the original fraud model by estimating a plurality of components of the fraud model using event parameters of at least one previous fraud event undertaken in the account, the at least one previous fraud event potentially conducted by the fraudster.</li><li>Clause 200. The system of clause 199, comprising modifying the predictive fraud model based on at least one previous event potentially conducted by the fraudster.</li><li>Clause 201. The system of clause 199, comprising generating the predictive fraud model to include a fraud co-occurrence coefficient for at least one previous event potentially conducted by the fraudster.</li><li>Clause 202. The system of clause 201, wherein the fraud co-occurrence coefficient represents an accumulated mistrust derived recursively from the at least one previous event potentially conducted by the fraudster.</li><li>Clause 203. The system of clause 201, wherein the fraud co-occurrence coefficient comprises a coefficient representing an affect of a plurality of previous events potentially conducted by the fraudster.</li><li>Clause 204. The system of clause 159, comprising selectively updating the account model using a second set of event parameters collected during the next event.</li><li>Clause 205. The system of clause 204, wherein the second set of event parameters is observable parameters collected during the next event.</li><li>Clause 206. The system of clause 204, wherein automatically updating the account model includes updating a joint probability distribution that includes a plurality of components of the account model.</li><li>Clause 207. The system of clause 204, wherein automatically updating the account model includes updating at least one of a plurality of components of the account model.</li><li>Clause 208. The system of clause 204, wherein automatically updating the account model includes updating at least one of a plurality of probability distribution functions that represent the event parameters, the updating modifying the at least one of the plurality of probability distribution functions by considering data of the second set of event parameters.</li><li>Clause 209. The system of clause 204, comprising:generating a probability distribution function for each of the event parameters of the prior event; and generating an updated probability distribution function for each of the event parameters by applying data of a second set of event parameters of the next event to the probability distribution function.</li><li>Clause 210. The system of clause 209, comprising:receiving a baseline account model that corresponds to the user, the baseline account model generated without using data of any event; and generating the account model by generating a joint probability distribution that includes a plurality of components of the account model, wherein the plurality of components includes the updated probability distribution function for any event parameter represented in the account model.</li><li>Clause 211.The system of clause 159, wherein the previous event and the next event comprise at least one of online events, offline events, and multiple channel events.</li><li>Clause 212.The system of clause 211, wherein online events are events undertaken via electronic access to the account.</li><li>Clause 213.The system of clause 159, wherein events comprise login events.</li><li>Clause 214.The system of clause 159, wherein events comprise activity events.</li><li>Clause 215.The system of clause 159, wherein the events comprise a session, wherein the session is a sequence of related events.</li><li>Clause 216.The system of clause 215, wherein the sequence of related events comprises a session login event and a termination event.</li><li>Clause 217.The system of clause 216, wherein the sequence of related events comprises at least one activity event.</li><li>Clause 218.The system of clause 159, comprising: determining probabilistically that the next event was conducted by the user; automatically updating the account model using a second set of event parameters collected during the next event.</li><li>Clause 219.The system of clause 218, comprising updating the account model to include a trust factor, the trust factor representing a probability that the next event was in fact conducted by the user.</li><li>Clause 220. The system of clause 218, comprising updating the account model to include an accumulated trust factor, the accumulated trust factor representing a cumulative probability across a plurality of events that an event parameter in the plurality of events was in fact conducted by the user.</li><li>Clause 221.The system of clause 159, wherein automatically generating the account model comprises generating the account model to include a decay parameter.</li><li>Clause 222. The system of clause 221, wherein the decay parameter comprises an exponential decay function by which a relative weight of each event of the events in the account changes with passage of time since the event.</li><li>Clause 223. A system comprising: a risk engine executing on a processor, the risk engine receiving from a financial system observations corresponding to a prior event, the prior event including actions taken in an account of the financial system during electronic access of the account, the risk engine estimating parameters of an account model using the observations and dynamically generating an account model to include the parameters, the account model corresponding only to the user, the risk engine using output of the account model to generate a risk score that is a relative likelihood an event in the account following the prior event is performed by the user versus the fraudster; and a risk application executing on the processor, the risk application comprising an analytical user interface (AUI), the AUI displaying for any event in the account at least one of the risk score and event parameters of any event in the account.</li></ul>