The subject matter described herein relates to systems, methods, and devices for grouping suspicious transactions into clusters with identifiable characteristics that set them apart from one another, and from the full dataset of suspicious transactions.
Transactions processed by a financial institution may be flagged with “alerts” that identify them as suspicious (e.g., potentially fraudulent) transactions. Alerted transactions may then be directed to a human fraud manager at the financial institution, who then divides them amongst a team of fraud analysts working under the fraud manager. This division is typically performed using simple filtering techniques, with characteristic readily identifiable by a human in near-real time, such as the dollar amount of the transaction, or the city from which the transaction originates. These filters tend to be quite simple, and may need to be updated frequently as the business climate changes. Furthermore, the filtered results may often represent a collection of dissimilar types of fraud. For example, the set of alerts from a particular city may include an online romance scam as well as a money mule scheme. The analyst then needs to address these varied types of alerts in different ways. For example, in one case the analyst may need to call the client to confirm the payment they made. In other cases within the same grouping, the analyst may need to file a SAR report, or escalate the fraud for more in-depth analysis. These varied responses can require repeated context switching, which may not allow for a streamlined alert solution pipeline. Even the resolutions for similar frauds by the same analyst can require context switching, since they may not be handled sequentially. Thus, a need exists.
Thus, it is to be appreciated that such commonly used alert filtering systems have numerous drawbacks, including subjectivity, inefficiency, long investigation times, inflexibility in the face of changing criminal behavior, overreliance on expert knowledge, uncertainty of results, and otherwise. Accordingly, long-felt needs exist for improved fraud management workflows that improve the productivity and efficiency of fraud analysis and thus reduce costs.
The information included in this Background section of the specification, including any references cited herein and any description or discussion thereof, is included for technical reference purposes only and is not to be regarded as subject matter by which the scope of the disclosure is to be bound.
The transaction clustering system disclosed herein includes systems, devices, and methods for, in real time or near-real time, identifying and classifying clusters of suspicious transactions with similar characteristics that may be difficult for a human to identify by inspection or simple filtering. Such clusters, and the classification data that sets them apart from other clusters and from the dataset as a whole, may be for more useful to fraud analysts than the classifications that are presently used. For example, a given cluster may represent twenty fraudulent transactions of the same type (e.g., stolen credit card numbers), regardless of the size or origin of the transaction. Sending these very similar alerts to the analyst may allow the analyst to respond to each one in a similar way, which may then serve to reduce context switching, improve throughput, and standardize resolution picking for similar kinds of alerts. Thus, the analyst may be more productive, and the analysis team may be able to handle a larger volume of suspicious transactions in a shorter period of time, with greater confidence in the results.
A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions. One general aspect includes a system adapted to automatically analyze clusters of suspicious transactions. The system includes a processor and a computer readable medium operably coupled thereto, the computer readable medium including a plurality of instructions stored in association therewith that are accessible to, and executable by, the processor, to perform operations which include: receiving a plurality of risk factors; and receiving a plurality of suspicious transactions, where each transaction of the plurality of suspicious transactions includes a respective set of values for the risk factors of the plurality risk factors. The operations also include: with a clustering algorithm, based on the sets of values for the risk factors for the transactions of the plurality of transactions: generating a plurality of data clusters; assigning each transaction to a cluster of the plurality of data clusters; and for each cluster: for each risk factor of the plurality of risk factors, computing a respective cluster mean and cluster standard deviation of the risk factor values for the transactions assigned to the cluster; identifying risk factors of the plurality of risk factors for which the cluster standard deviation is below a respective threshold value for the risk factor; and generating a list of the identified risk factors and their respective cluster means and cluster standard deviations, ranked in relation to their respective cluster standard deviations. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.
Implementations may include one or more of the following features. In some embodiments, the operations further include displaying the generated list, or a graphical representation thereof, to a user. In some embodiments, the operations further include initiating an automated action based on the generated list. In some embodiments, the automated action includes, as to one of the plurality of suspicious transactions, at least one of blocking the transaction, allowing the transaction, alerting a customer associated with the transaction, blocking a customer associated with the transaction, or suggesting a resolution action to a user. In some embodiments, the operations further include: for each respective risk factor in the plurality of risk factors, computing a full data mean and full data standard deviation of the values for the respective risk factor for each transaction of the plurality of suspicious transactions. In some embodiments, the respective threshold value for a respective risk factor is a function of the full data standard deviation for the respective risk factor, and where the generated list further includes the full data mean and full data standard deviation for each risk factor of the identified risk factors. In some embodiments, the respective threshold value for the respective risk factor is the full data standard deviation. In some embodiments, the plurality of risk factors includes at least one numerical risk factor and at least one categorical risk factor, and the clustering algorithm includes a K-prototype clustering algorithm. In some embodiments, the operations further include, when a current transaction of a cluster is selected by a user, suggesting a next transaction of the cluster to the user based on the respective values of the risk factors of the current transaction and next transaction. In some embodiments, the operations further include, when a current cluster is selected by a user, suggesting a next cluster to the user based on the respective cluster means of the risk factors of the current cluster and the next cluster. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.
One general aspect includes a computer-implemented method adapted to automatically analyze clusters of suspicious transactions. The computer-implemented method includes receiving a plurality of risk factors and a plurality of suspicious transactions, where each transaction of the plurality of suspicious transactions includes a respective set of values for the risk factors of the plurality risk factors. The method also includes, with a clustering algorithm, based on the sets of values for the risk factors for the transactions of the plurality of transactions: generating a plurality of data clusters; determining a cost function of the variation in values for each risk factor in the plurality of risk factors; by minimizing the cost function, assigning each transaction to a cluster of the plurality of data clusters; and for each cluster of the plurality of data clusters: for each risk factor of the plurality of risk factors, computing a respective cluster mean and cluster standard deviation of the risk factor values of the transactions assigned to the cluster; identifying risk factors of the plurality of risk factors for which the cluster standard deviation is below a threshold value; and generating a list of the identified risk factors and their respective cluster means and cluster standard deviations of their respective cost function, ranked in relation to their respective cluster standard deviations. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.
Implementations may include one or more of the following features. In some embodiments, the method further includes displaying the generated list, or a graphical representation thereof, to a user. In some embodiments, the method further included initiating an automated action based on the generated list. In some embodiments, the automated action includes, as to one of the plurality of suspicious transactions, at least one of blocking the transaction, allowing the transaction, alerting a customer associated with the transaction, blocking a customer associated with the transaction, or suggesting a resolution action to a user. In some embodiments, the method further includes: for each respective risk factor in the plurality of risk factors, computing a full data mean and full data standard deviation of the values for the respective risk factor for each transaction of the plurality of suspicious transactions. In some embodiments, the threshold value for a respective risk factor is a function of the full data mean for the respective risk factor, and the generated list further includes the full data mean and full data standard deviation for each risk factor of the identified risk factors. In some embodiments, the threshold value for the respective risk factor is the full data standard deviation of the respective risk factor. In some embodiments, the plurality of risk factors includes at least one numerical risk factor and at least one categorical risk factor, and the clustering algorithm includes a K-prototype clustering algorithm. In some embodiments, the method further includes, when a current transaction of a cluster is selected by a user, suggesting a next transaction to the user based on the respective risk factors of the current transaction and next transaction. In some embodiments, the method further includes, when a current cluster is selected by a user, suggesting a next cluster to the user based on the respective cluster means of the risk factors of the current cluster and the next cluster. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. A more extensive presentation of features, details, utilities, and advantages of the transaction clustering system, as defined in the claims, is provided in the following written description of various embodiments of the disclosure and illustrated in the accompanying drawings.
Illustrative embodiments of the present disclosure will be described with reference to the accompanying drawings, of which:
In accordance with at least one embodiment of the present disclosure, an transaction clustering system is provided which automatically separates a dataset of suspicious transactions into clusters with distinctive characteristics, and identifies the most important characteristics of each cluster. The transaction clustering system may for example identify and classify clusters of suspicious transactions with similar characteristics that may be difficult for a human to identify by inspection or simple filtering. Such clusters, and the classification data that sets them apart from other clusters and from the dataset as a whole, may be for more useful to fraud analysts than the classifications that are presently used. For example, a given cluster may represent twenty fraudulent transactions of the same type (e.g., stolen credit card numbers), regardless of the size or origin of the transaction.
Sending these very similar alerts to the analyst may allow the analyst to respond to each one in a similar way, which may then serve to reduce context switching, improve throughput, and standardize resolution picking for similar kinds of alerts. Thus, the analyst may be more productive, and the analysis team may be able to handle a larger volume of suspicious transactions in a shorter period of time, with greater confidence in the results.
The system is programmed to identify a number of different risk factors, such as the account ID or routing number where a transaction originates, or whether this is the first identified transaction for that account ID or routing number. The risk factors can include both numerical risk factors and categorical risk factors. Several, several dozen, or several hundred different risk factors may be used by the system.
When the system receives a group of suspicious transactions (e.g., several dozen, several hundred, several thousand, or more transactions), each transaction includes values for at least some of the risk factors. The system then performs statistical analysis of these values across the group to identify clusters of transactions (e.g., subsets of the group with similar characteristics), and to identify and report at least some of the common characteristics that set each group apart from the other groups, and from the dataset as a whole, as described below.
For each transaction in the received group, the system can compute a cost function for each risk factor. Once all the cost functions have been determined, the system can compute a full data mean and a full data standard deviation for the cost functions of each risk factor, representing the statistical distribution of cost function values for that risk factor across the entire group of transactions.
The individual transactions can be treated as individual datapoints in a multidimensional space, where each risk factor is represented by a dimension. Thus, if 50 risk factors are considered, then each transaction can be represented as a point in a 50-dimensional space. With a suitable clustering algorithm (e.g., a K-prototype clustering algorithm that accounts for both numerical and categorical variables), the system can then identify data points that are close to one another within, and distant from the geometric center of, the multidimensional space. Anywhere from two to several dozen clusters may be identified, although in some cases the system may be most useful when the number of clusters is between 5 and 15 or, alternatively, when each cluster contains between 20 and 200 data points, although other numbers of clusters or data points, both larger and smaller, may be used instead or in addition. The selected algorithm may be configured so that every point in the dataset (e.g., every transaction in the total group) is assigned to a cluster.
Once the clusters have been identified, then for each transaction within a cluster, the system can compute the cost function. The system can then compute a cluster mean and a cluster standard deviation for the cost functions of each risk factor within the cluster, representing the statistical distribution for the cost function of that risk factor within the cluster. For a given risk factor, differences between the cluster distribution and the full data distribution can help to identify whether that particular risk factor is a significant or insignificant identifying trait for that particular cluster.
Thus, for each cluster the system can, for example, produce a list of risk factors whose cluster standard deviation falls below a threshold value, ranked in reverse order of the cluster standard deviation, such that the most tightly clustered risk factors are listed first. For each of the listed risk factors, the system can for example display the name of the risk factor, the cluster mean and cluster standard deviation of the risk factor, a comparison between the cluster mean and the full data mean, and a comparison between the cluster standard deviation and the full data standard deviation.
Alternatively or in addition, the system may display the transactions and clusters graphically. For example, the system may display a two-dimensional projection of the data points in the multidimensional space, where the X and Y axes are eigenvectors of the dataset. The data points in different clusters may, for example, be represented with different colors or different symbols, or the system may draw borders or approximate borders around each cluster. The list data for a given cluster, as described above, may then for example be displayed as a pop-up when a user clicks on a data point or transaction belonging to that cluster.
Thus, the clusters identified by the system represent groups of suspicious transactions with similar characteristics that can be recognized and understood, in real time or near-real time, such as by a fraud analyst. The transactions within a cluster may then for example be handled sequentially or as a group, with similar resolution methods that reduce the need for context switching and thereby potentially improve accuracy in detecting fraud. Context switching may then occur when the analyst switches to a different cluster, may not be required when handling the transactions of that different cluster.
The transaction clustering system can be used with existing fraud detection or anomaly detection systems, whether newly installed or already operational. As such, the transaction clustering system may improve the fraud detection processes, costs, workflows, and investigation times, for users of virtually any fraud detection system. Such potential users may include financial services companies, financial software vendors, banks, retailers, fraud detection firms, etc.
The present disclosure aids substantially in fraud detection by decreasing context switching, improving throughput, and reducing investigation times for fraud, while improving the ability of fraud investigators to adapt to changing criminal behavior in real time or near-real time. Implemented on a processor in communication with a memory structure or database, the system disclosed herein provides practical reductions in the time needed to clear a dataset of alerts. This improved throughput transforms a subjective, labor-intensive filtering process into a fast, accurate, repeatable, and resource-efficient clustering process that can be executed against stored transactions on demand, without the normally routine need to rely on the expertise of human fraud detection managers. This unconventional approach improves the functioning of the fraud detection computer system (e.g., an integrated fraud management computer system), by reducing the time lost to context switching on the part of system operators (e.g., fraud investigators).
The transaction clustering system may be implemented as a process at least partially viewable on a display, and operated by a control process executing on a processor that accepts user inputs from a keyboard, mouse, touchscreen interface, or the like, or any combination thereof, and that is in communication with one or more databases. In that regard, the control process performs certain specific operations in response to different inputs or selections made at different times. Certain structures, functions, and operations of the processor, display, sensors, and user input systems are known in the art, while others are recited herein to enable novel features or aspects of the present disclosure with particularity.
These descriptions are provided for exemplary purposes only, and should not be considered to limit the scope of the transaction clustering system. Certain features may be added, removed, or modified without departing from the spirit of the claimed subject matter.
For the purposes of promoting an understanding of the principles of the present disclosure, reference will now be made to the embodiments illustrated in the drawings, and specific language will be used to describe the same. It is nevertheless understood that no limitation to the scope of the disclosure is intended. Any alterations and further modifications to the described devices, systems, and methods, and any further application of the principles of the present disclosure are fully contemplated and included within the present disclosure as would normally occur to one of ordinary skill in the art to which the disclosure relates. In particular, it is fully contemplated that the features, components, and/or steps described with respect to one embodiment may be combined with the features, components, and/or steps described with respect to other embodiments of the present disclosure. For the sake of brevity, however, the numerous iterations of these combinations will not be described separately.
The following terms will be used:
Furthermore, the filtered results (e.g., filtered groups 130 and 140) may each be collections related to different types of fraud. For example, the set of alerts from a particular city may include an online romance scam as well as a money mule scheme. The analyst may then need to then go through these varied types of alerts and, for example, call the client to confirm the payment they made versus filing a SAR report versus just escalating the fraud alert for greater scrutiny. This may require continuously context switching, which may interfere with a streamlined alert solution pipeline. Further, the resolutions for similar frauds, even for the same analyst, may not be standardized if they are not solved together.
The transaction clustering system 100 of the present disclosure, instead of (or in addition to) relying on simple human filtering 120 to divide fraud alerts amongst analysts, uses complex data, including various risk factors. On this rich data, the system deploys data clustering techniques (e.g., a data-driven clustering algorithm 150) to create multiple “clusters” 160 of transactions falling within similar risk areas. In the example shown in
Sending these clusters 160 (each containing very similar alerts) to an analyst may significantly reduce context switching, improve throughput, and standardize resolution choices for similar kinds of alerts, thus resulting in reduced investigation times 170.
The transaction clustering system 100 may for example be programmed to identify a number of different risk factors, such as the account ID or routing number where a transaction originates, or whether this is the first identified transaction for that account ID or routing number. The risk factors can include both numerical risk factors and categorical risk factors. Several, several dozen, or several hundred different risk factors may be used by the system.
When the transaction clustering system 100 receives a group of suspicious transactions (e.g., several dozen, several hundred, several thousand, or more transactions), each transaction may include values for at least some of the risk factors. The transaction clustering system 100 may then perform statistical analysis of these values across the group to identify clusters of transactions (e.g., subsets of the group with similar characteristics), and to identify and report at least some of the common characteristics that set each group apart from the other groups, and from the dataset as a whole, as described below.
When solving an alert, some existing systems permit a user to manually create or refine a search query, using simple human readable filters, to find “similar” alerts to the one that is currently being solved. However, the transaction clustering system 100 of the present disclosure does not require human intervention or human-constructed queries or filters to generate clusters of similar alerts. The transaction clustering system 100 thus represents a significant improvement over existing systems.
It is noted that block diagrams are provided herein for exemplary purposes; a person of ordinary skill in the art will recognize myriad variations that nonetheless fall within the scope of the present disclosure. For example, block diagrams may show a particular arrangement of components, modules, services, steps, processes, or layers, resulting in a particular data flow. It is understood that some embodiments of the systems disclosed herein may include additional components, that some components shown may be absent from some embodiments, and that the arrangement of components may be different than shown, resulting in different data flows while still performing the methods described herein.
In some embodiments, events from the RFDB 250 are also passed to a risk feed 290, and stored in the RADB 292 when completed. In some embodiments, a secondary clustering step 296 assigns a cluster number to each event (e.g., to each suspicious transaction in the simplified list), and stores these in the RADB 292. An output step 294 may also display or otherwise communicate the cluster number of a given event, alert, or suspicious transaction, as well as information about the cluster, to the fraud analyst working on that particular event, alert, or transaction.
Efficiency of the analyst is a key business metric to optimize for in the compliance industry. With the transaction clustering system 100 of the present disclosure, most of the alerts in an analyst's queue are likely to be similar. Thus, the analyst may not need to spend as much time in identifying fraudulent alerts, as they would using current systems. This is likely to improve the efficiency of Fraud Desk Analysts, at least in terms of both time and cost. With current systems, managers may be required to maintain an analyst's alert queue, and this may require constant updating of simple human readable filters. Conversely, the transaction clustering system 100 can automatically assign very similar alerts to individual analysts, thus reducing the need for manual intervention during this division of labor.
Customer data 330 may then be received into a customer data database 335, a recent data database 340, and a behavioral profiles database 345, each of which communicates with an extraction layer 350 of the fraud detection system 352. Both the data integration layer 325 and the extraction layer 350 may pass data to a solution analytics subsystem 355 of the fraud detection system 352. The solution analytics subsystem 355 may for example perform such tasks as transaction enrichment, score card execution, and execution of a first machine learning algorithm, which collectively help to define risk scores for the suspicious transactions. The solution analytics subsystem 355 may then pass the risk-scored transactions to a user analytics subsystem 360, which may for example perform such tasks as setting user analytics, operating an Analytics Authoring Environment (e.g., AAE, a tool for creating policies, rules and fraud detection pipelines), and execution of a second machine learning algorithm, which collectively create a comprehensive risk profile for each user account. The user analytics subsystem 360 may then pass the risk scored transactions (now enhanced by the user risk profile analytics) to an action rules subsystem 365, which may for example execute rules that identify potentially fraudulent transactions from the complete set of input transactions. It is noted that formatted or processed customer data from the extraction layer 350 may be passed into any of the data integration layer 325, solution analytics subsystem 355, user analytics subsystem 360, or action rules subsystem 365, as part of the processing operations described above.
The fraud detection system 352 may then, in real time or near-real time, pass alerts 370 (e.g., transactions that are deemed suspicious) to an investigation and analysis system 375. The alerts 370 may for example include analysis results, insights and features (e.g., values of the various risk factors) that have been generated or extracted by the fraud detection system 352. The investigation and analysis subsystem may for example organize investigation data, manage transaction alerts and pick resolutions (e.g., via Nice Actimize ActOne), and record or manage detection logs (e.g., Actimize Detection Logs or ADLs), in order to provide alerted transactions to the fraud investigation team. In some embodiments, the Investigation and analysis system 375 may pass the alerted transactions to a clustering system 380, such that similar transactions are grouped together for the convenience of fraud analysts, as described above. The alerted transactions, thus organized, can then be passed to a transmission layer 385, which transmits them to a data transporter 390 (e.g., Actimize X-sight Data Transporter or XDT) capable of transporting data to or from cloud storage or other storage.
The process or workflow shown in
One aim of the present disclosure is to reduce the efforts of fraud analysts by assigning similar alerts to one analyst and to display the alerts in an order that maximizes similarity and thus reduces context switching. This may be accomplished, for example, by automatically filtering the alerts and grouping them to show close to similar alerts in fraud analyst queue by making the use of clustering algorithm based on various risk factors. Alerts belonging to the same cluster may have similar behavioral patterns in terms of perceived fraud. The algorithms described herein can be fully automated, and can make use of risk factors that are not easily readable or interpretable by a human analyst, e.g., those that require evaluating a substantial number of clusters that cannot be timely analyzed by a person.
In step 410, the method 400 includes feeding or organizing the data associated with a dataset of suspicious transactions. This may for example include data pre-processing and data preparation of transactions stored in a database. In an example, the database includes rich, complex risk factors of mixed type, e.g., with numeric as well as categorical data. In an example, step 410 may include preprocessing the risk factors associated with the suspicious transactions, to remove any null values and to label the risk factors according to numerical and categorical (both binary and multinomial) data types. The numerical data may then be standardized (e.g., normalized) using the StandardScalar function in sklearn-python.
In an example, the method 400 makes use of two main algorithms: K-Prototype Clustering and our in-house developed function the “tell_me_whats_similar” function (described below in
In step 420, the feature-engineered results from step 410 serve as input to the clustering algorithm (e.g., a K-Prototype Clustering algorithm). Cluster center initialization may be performed at this step, e.g., with an initialization method such as “Huang” initialization.
In step 430, the K-Prototype Clustering algorithm, for both numeric and categorical variables, uses a dissimilarity function to calculate a proxy for the distance between two observations. Based on the dissimilarity function, it processes the “closest” transactions into clusters. Some embodiments may for example employ the “K modes” package in python to perform K prototype clustering on the dataset of suspicious transactions, which may be represented using mixed types risk factors. To automate the selection of optimized number of clusters, the algorithm may for example use the elbow method, which divides the data into clusters and for each transaction/observation outputs a number representing the cluster to which that transactions belongs. One possible embodiment employs risk elements of each alert X and Y shown as xj, yj below.
The dissimilarity function d2 may for example have the following formulation:
d
2(X,Y)=Σj=1p(xj−yj)2+γΣj=p+1mδ(xj,yj) (EQ. 1)
One benefit of this technique to the present disclosure is in the dissimilarity function being broken down into a Euclidean distance for real-valued variable pairs, or into a δ representing a nondimensional “distance” for categorical variable pairs. A weighted mean can be taken between the two using a weight γ to balance the two parts, to avoid favoring one type of attribute over the other type. In this example, (xj, yj j=1, . . . , p, p+1, . . . , m) represents the m variables corresponding to ith alert.
The clusters are formed in such a way that the cost function given below is minimized.
P(W,Q)=Σl=1k(Plr+Plc) (EQ. 2)
Where W is an n×k partition matrix and Q is set of objects in the same object domain, and here, Pr and Pc represent the cost functions of real-number-valued and categorical variables, respectively, k represents the total number of clusters to be formed, q represents one element of Q, and l is a running variable representing cluster number, used for summation over all clusters. Thus:
P
l
r=Σi=1nwi,lΣj=1p(xi,j−ql,j)2 (EQ. 3)
P
l
c=γΣi=1nwi,lΣj=p+1mδ(xi,j,ql,j) (EQ. 4)
Some possible examples of non-human-filterable risk factors (e.g., risk factors not easily read or interpreted by a human fraud investigator) include:
CombinedAmountRisk (an indicator of risk associated with the actor transferring a suspiciously large amount, given s/he has never transferred such a large amount before).
Some embodiments include 50 or more risk factors associated with each transaction, although other embodiments may use more or fewer risk factors, including such values as 5, 10, 25, 100, 300, or more.
In step 440, the method includes recalculating the clustering centers (e.g., the cluster's mean value for each risk factor).
In step 450, the method includes detecting that the cluster centers have moved from the previous iteration (e.g., are different by more than a specified threshold amount for one or more risk factors). Execution then returns to step 430 for another iteration.
In step 460, the method includes detecting that the cluster centers have not moved from the previous iteration (e.g., are not different by more than a specified threshold amount for any of the risk factors). Execution then proceeds to step 470.
In step 470, the method is complete, and the generated clusters may be considered final.
It is noted that flow diagrams are provided herein for exemplary purposes; a person of ordinary skill in the art will recognize myriad variations that nonetheless fall within the scope of the present disclosure. For example, the logic of flow diagrams may be shown as sequential. However, similar logic could be parallel, massively parallel, object oriented, real-time, event-driven, cellular automaton, or otherwise, while accomplishing the same or similar functions. In order to perform the methods described herein, a processor may divide each of the steps described herein into a plurality of machine instructions, and may execute these instructions at the rate of several hundred, several thousand, several million, or several billion per second, in a single processor or across a plurality of processors. Such rapid execution may be necessary in order to execute the method in real time or near-real time as described herein. For example, generating clusters of suspicious transactions may require processing dozens risk factors for each of hundreds or thousands of suspicious transactions, according to the equations described above, in a real-time or near-real-time flow that does not require a fraud investigation team to sit idle while waiting for the clustering results.
In step 510, the method includes receiving all of the transactions from a single cluster.
In step 520, the method includes assembling a list of risk factors found within the cluster.
In step 530, the method includes finding the useful, important, or significant risk factors for the cluster, as described below in
It is noted that for categorical (non-numeric) risk factors, the mean and/or standard deviation may be based on mode values (e.g., the most frequently observed value for that risk factor).
In step 540, the method includes assembling a list of the useful, important, or significant risk factors for the cluster.
In step 550, the method includes sorting the list of useful, important, or significant risk factors according to their importance. This may be done, for example the ratio of the cluster standard deviation to the full dataset standard deviation for each risk factor, such that the risk factor with the lowest ratio is ranked most important, and the risk factor with the highest ratio is considered least important. Other sorting mechanisms may be used instead or in addition, to produce an importance-ordered list of the risk factors that set the current cluster apart from other clusters, and from the full dataset.
In step 560, the method includes passing the importance-ordered list to the Risk Application Database (RADB) for later display to the user. This exemplary method is now complete.
Thus, in step 610, the method 600 includes receiving a list of values for a single risk factor within the current cluster. In some embodiments, step 610 may also include, for a selected risk factor of the current cluster, calculating a full dataset standard mean, as well as a cluster mean for the current cluster.
If the current risk factor is defined such that a lower value is considered more risky than a higher value (e.g., a credit score associated with the transaction), execution then proceeds to step 620. Alternatively, if the current risk factor is defined such that a higher value is considered riskier than a lower value (e.g., a dollar amount of the transaction over the transactor's credit limit), execution then proceeds to step 630.
In step 620, the method 600 includes determining whether, for the current risk factor, the cluster mean is less than the full dataset mean by a specified threshold amount (e.g., 0%, 5%, 10%, etc.) If no, execution proceeds to step 640. If yes, execution proceeds to step 650.
In step 630 the method 600 includes determining whether, for the current risk factor, the cluster mean is greater than the full dataset mean by a specified threshold amount (e.g., 0%, 5%, 10%, etc.) If no, execution proceeds to step 640. If yes, execution proceeds to step 650.
In step 640 the method 600 includes determining that the current risk factor is not useful, important, or significant. For the current risk factor and the current cluster, the method 600 is now complete.
In step 650 the method 600 includes determining that the current risk factor is indeed useful, important, or significant. For the current risk factor and the current cluster, the method 600 is now complete.
In some embodiments, via a similar process, risk factors may, instead or in addition, be ranked or excluded from ranking according to their interpretability. Thus, a risk factor that is easy for a human analyst to interpret may be included in the ranking, or may be ranked higher, whereas a risk factor that is difficult for a human analyst to interpret may be ranked lower, or may be excluded from the ranking altogether, as it may not provide useful cues to the analyst as to how to resolve that type of suspicious transaction.
The individual transactions 710 can be treated as individual datapoints in a multidimensional space, where each risk factor is represented by a dimension. Thus, if 50 risk factors are considered, then each transaction can be represented as a point in a 50-dimensional space. In some embodiments, clear, well-separated clusters may be considered more useful to the fraud analyst. Thus, the 2D plot 700 may represent a particular two-dimensional “shadow” of the 50-dimensional space, wherein the separation between clusters or datapoints is maximized This may be accomplished for example if the X and Y axes of the two-dimensional shadow are eigenvectors of the dataset in the 50-dimensional space.
With a clustering algorithm (e.g., a K-prototype clustering algorithm that accounts for both numerical and categorical variables), the system can then identify data points (e.g., transactions 710) that are close to one another within, and distant from the geometric center of, the multidimensional space. Anywhere from two to several dozen clusters may be identified, although in some cases the system may be most useful to the fraud analysis team when the number of clusters is between 5 and 15 or, alternatively, when each cluster contains between 20 and 200 data points, although other numbers of clusters or data points, both larger and smaller, may be used instead or in addition. The algorithm is configured so that every point in the dataset (e.g., every transaction 710 in the total group) is assigned to a cluster.
Thus, for each cluster 720 the system can for example, produce a list of risk factors whose cluster standard deviation falls below a threshold value, ranked in reverse order of the cluster standard deviation, such that the most tightly clustered risk factors are listed first. For each of the listed risk factors, the system can for example display the name of the risk factor, the cluster mean and cluster standard deviation of the risk factor, a comparison between the cluster mean and the full data mean, and a comparison between the cluster standard deviation and the full data standard deviation.
The data points in different clusters may for example be represented with different colors, different shading, different symbols, etc., or the transaction clustering system 100 may draw borders or approximate borders around each cluster, with certain outliers 730 possibly falling outside the drawn borders. The clusters may be marked in still other ways as would occur to a person of ordinary skill in the art. The list data for a given cluster 720, as described above, may then for example be displayed as a pop-up when a user clicks on a data point or transaction 710 belonging to that cluster 720.
Thus, the clusters 720 identified by the system represent groups of suspicious transactions 710 with similar characteristics that can be recognized and understood, in real time or near-real time, by a fraud analyst. The transactions within a cluster 720 may then for example be handled sequentially or as a group, with similar resolution methods that reduce the need for context switching. Context switching may be further minimized if, after analyzing a given transaction 710 within a cluster 720, the fraud analyst then selects, as the next transaction 710 to analyze, the transaction that is “closest” to the previous transaction in the multidimensional space or two-dimensional shadow. In some embodiments, the next closest data point is recommended automatically.
Context switching may then occur when the analyst switches to a different cluster. However, even in this case, context switching may be minimized if the next cluster is “close” to the previous cluster in the multidimensional space or in the 2D shadow. In some embodiments, when a fraud analyst has finished analyzing all the transactions 710 of a given cluster 720, the system automatically suggests the next closest cluster 720, and may additionally suggest the transaction 710 within that cluster that is closest to the last transaction analyzed by the fraud analyst. Thus, the transaction clustering system 100 provides methods for dramatically reducing context switching, and may thus improve the efficiency and throughput of the fraud analyst in analyzing transactions and detecting fraud.
It may be useful for the transaction clustering system 100 to help the fraud managers, as well as analysts, understand why the transactions in a particular cluster were clustered together. In some embodiments, this may be accomplished with a tell_me_whats_similar function, whose inputs are the transactions in a given cluster. The function can be explained as a two-step approach that sorts the risk-factors being used for cluster creation in the order of importance to the formation of the cluster as well as to the interpretability of the clustering result. For a given risk factor, differences between the cluster distribution and the full data distribution can help to identify whether that particular risk factor is a significant or insignificant identifying trait for that particular cluster.
For example, for each risk factor, the system may calculate the ratio of standard deviation (stddev) of cluster to the standard deviation for the full dataset. The risk factors with stddev_ratio<1 mean that the spread of risk factor reduces after clustering, hence those are vital in forming the cluster. Similarly, higher risk factor values signify a more risky transaction in that particular factor's purview, hence, clusters with cluster_mean>full_data_mean for risk factors may be considered riskier as described above.
These two conditions may provide useful cluster information to the fraud analyst.
Example code to execute the “tell me what's similar” fuction may include:
Example code for the “tell me what's similar function” itself may include:
Example output for the “tell me what's similar” function may include:
The output of the tell_me_whats_similar function may thus be a prioritized list of representative risk factors that help interpret the clustering in the context of Fraud Analysis. A sample tenant's data may include event attributes contained in the event_dump column of the ga_rf_event_history table of the database.
After analyzing the cluster, if the fraud analyst decides to take action either on a particular alert or on all the alerts belonging to one cluster, then (s)he can, if desired, make use of actions buttons 1040. If desired, an automated action can also be set up that would automatically hold/release all current and future cluster members as future transactions are sorted into clusters. This sort of automation can reduce the workload and time spent by the analyst/fraud manager, and can provide a higher level of automatic alert resolution. The solution history 1020 of the cluster may be helpful for the fraud analyst to decide if the action is to be taken for that alert or not.
In some embodiments, the user interface may suggest an action based on the resolution history from other transactions in the cluster, or in similar clusters identified previously. In some embodiments, the user interface may suggest the next alert or alerts to be resolved, for example by identifying the closest alert from the cluster (or from a different cluster, if the current cluster is now finished) and recommend this as the next alert to be looked at, to minimize context switching and maximize efficiency.
The processor 1160 may include a central processing unit (CPU), a digital signal processor (DSP), an ASIC, a controller, or any combination of general-purpose computing devices, reduced instruction set computing (RISC) devices, application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other related logic devices, including mechanical and quantum computers. The processor 1160 may also include another hardware device, a firmware device, or any combination thereof configured to perform the operations described herein. The processor 1160 may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
The memory 1164 may include a cache memory (e.g., a cache memory of the processor 1160), random access memory (RAM), magnetoresistive RAM (MRAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), flash memory, solid state memory device, hard disk drives, other forms of volatile and non-volatile memory, or a combination of different types of memory. In an embodiment, the memory 1164 includes a non-transitory computer-readable medium. The memory 1164 may store instructions 1166. The instructions 1166 may include instructions that, when executed by the processor 1160, cause the processor 1160 to perform the operations described herein. Instructions 1166 may also be referred to as code. The terms “instructions” and “code” should be interpreted broadly to include any type of computer-readable statement(s). For example, the terms “instructions” and “code” may refer to one or more programs, routines, sub-routines, functions, procedures, etc. “Instructions” and “code” may include a single computer-readable statement or many computer-readable statements.
The communication module 1168 can include any electronic circuitry and/or logic circuitry to facilitate direct or indirect communication of data between the processor circuit 1150, and other processors or devices. In that regard, the communication module 1168 can be an input/output (I/O) device. In some instances, the communication module 1168 facilitates direct or indirect communication between various elements of the processor circuit 1150 and/or the transaction clustering system 100. The communication module 1168 may communicate within the processor circuit 1150 through numerous methods or protocols. Serial communication protocols may include but are not limited to United States Serial Protocol Interface (US SPI), Inter-Integrated Circuit (I2C), Recommended Standard 232 (RS-232), RS-485, Controller Area Network (CAN), Ethernet, Aeronautical Radio, Incorporated 429 (ARINC 429), MODBUS, Military Standard 1553 (MIL-STD-1553), or any other suitable method or protocol. Parallel protocols include but are not limited to Industry Standard Architecture (ISA), Advanced Technology Attachment (ATA), Small Computer System Interface (SCSI), Peripheral Component Interconnect (PCI), Institute of Electrical and Electronics Engineers 488 (IEEE-488), IEEE-1284, and other suitable protocols. Where appropriate, serial and parallel communications may be bridged by a Universal Asynchronous Receiver Transmitter (UART), Universal Synchronous Receiver Transmitter (USART), or other appropriate subsystem.
External communication (including but not limited to software updates, firmware updates, or preset sharing between the processor and a central server) may be accomplished using any suitable wireless or wired communication technology, such as a cable interface such as a universal serial bus (USB), micro USB, Lightning, or FireWire interface, Bluetooth, Wi-Fi, ZigBee, Li-Fi, or cellular data connections such as 2G/GSM (global system for mobiles), 3G/UMTS (universal mobile telecommunications system), 4G/LTE/WiMax, or 5G. For example, a Bluetooth Low Energy (BLE) radio can be used to establish connectivity with a cloud service, for transmission of data, and for receipt of software patches. The controller may be configured to communicate with a remote server, or a local device such as a laptop, tablet, or handheld device, or may include a display capable of showing status variables and other information. Information may also be transferred on physical media such as a USB flash drive or memory stick.
As will be readily appreciated by those having ordinary skill in the art after becoming familiar with the teachings herein, the transaction clustering system advantageously provides improved workflow, decreased context switching, and reduced analysis times, and can thus significantly improve the throughput of a fraud analysis team. It is noted that the efficiency of the analyst may be considered a key business metric to optimize for in the compliance industry. The automated clustering algorithm can group most similar alerts together in real time, based on various complex risk factors, including non-human-readable risk factors, and can place these similar alerts in the analyst's queue. Where most of the alerts in the analyst's queue are similar, less time may be required to identify genuinely fraudulent transactions and the actions required to resolve them, thus improving the time and cost efficiency of fraud analysis teams or departments.
Accordingly, it can be seen that the transaction clustering system fills a long-standing need in the art, by addressing the limitations of present systems and improving the operation of fraud detection computer systems.
A number of variations are possible on the examples and embodiments described above. For example, different risk factors, different numbers of risk factors, different clustering algorithms, or different sorting criteria may be used. A greater or smaller number of clusters may be generated, from greater or smaller numbers of alerted transactions. The technology described herein may be implemented for fraud detection in financial or retail transactions, but may also be used for other applications where identifying and resolving anomalies in large datasets is desired.
The logical operations making up the embodiments of the technology described herein are referred to variously as operations, steps, objects, elements, components, layers, systems, subsystems, or modules. Furthermore, it should be understood that these may occur or be performed or arranged in any order, unless explicitly claimed otherwise or a specific order is inherently necessitated by the claim language.
All directional references e.g., upper, lower, inner, outer, upward, downward, left, right, lateral, front, back, top, bottom, above, below, vertical, horizontal, clockwise, counterclockwise, proximal, and distal are only used for identification purposes to aid the reader's understanding of the claimed subject matter, and do not create limitations, particularly as to the position, orientation, or use of the dimensional reduction integrated fraud management system. Connection references, e.g., attached, coupled, connected, joined, or “in communication with” are to be construed broadly and may include intermediate members between a collection of elements and relative movement between elements unless otherwise indicated. As such, connection references do not necessarily imply that two elements are directly connected and in fixed relation to each other. The term “or” shall be interpreted to mean “and/or” rather than “exclusive or.” The word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. Unless otherwise noted in the claims, stated values shall be interpreted as illustrative only and shall not be taken to be limiting.
The above specification, examples and data provide a complete description of the structure and use of exemplary embodiments of the transaction clustering system as defined in the claims. Although various embodiments of the claimed subject matter have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those of ordinary skill in the art could make numerous alterations to the disclosed embodiments without departing from the spirit or scope of the claimed subject matter.
Still other embodiments are contemplated. It is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative only of particular embodiments and not limiting. Changes in detail or structure may be made without departing from the basic elements of the subject matter as defined in the following claims.