Systems and methods for anti-money laundering analysis

Abstract

An advantage is the provision of systems and methods that can apply machine learning to accurately identify and investigate potential money laundering. [Solution] In one aspect, the present disclosure provides a computer implementation method for anti-money laundering (AML) analysis, comprising the steps of: (a) obtaining a dataset comprising a plurality of accounts by a computer, each of which accounts corresponds to an account holder among a plurality of account holders, and each of the plurality of accounts comprises a plurality of account variables, the plurality of account variables comprising financial transactions; (b) applying a trained algorithm to the dataset by a computer to generate a money laundering risk score for each of the plurality of account holders; and (c) identifying a subset of the plurality of account holders for investigation based on the money laundering risk scores of at least a plurality of account holders by a computer.

Description

Technical Field

[0001] (Cross - reference to related applications) This application claims priority to U.S. Provisional Patent Application No. 62 / 767,408, filed on November 14, 2018, which is incorporated herein by reference in its entirety.

Background Art

[0002] Anti - money laundering (AML) analysis of accounts and account - holders' financial transactions can use algorithms to identify suspicious accounts or parties that may be engaged in illegal or improper activities such as money laundering. AML analysis can generate a risk score and identify suspicious accounts or parties for further investigation.

Summary of the Invention

Means for Solving the Problems

[0003] Advantageously, the present disclosure provides systems and methods that can apply machine learning to accurately manage and predict accounts and account - holders associated with money - laundering risks. Such systems and methods can, all in real - time, almost in real - time, imminently, at regular intervals (e.g., weekly, daily, every four hours, etc.), in response to user requests, or the equivalent, based on the analysis of account variables from a plurality of heterogeneous data - source systems, the identification of suspicious accounts or account - holders for investigation, and the identification of actionable recommendations to the user, enable an accurate prediction of money - laundering risks.

[0004] In one respect, the Disclosure provides a computer implementation method for anti-money laundering (AML) analysis, comprising the steps of (a) obtaining a dataset comprising multiple accounts, each of which accounts corresponds to an account holder among multiple account holders, and each of the multiple accounts is defined by multiple account variables, the multiple account variables comprising financial transactions; (b) applying a trained algorithm to the dataset, by a computer, to generate a money laundering risk score for each of the multiple account holders and one or more primary risk drivers associated with the money laundering risk score; and (c) outputting a subset of at least multiple account holders based on the money laundering risk scores of at least multiple account holders, by a computer.

[0005] In some embodiments, the step of acquiring a dataset includes the step of acquiring and aggregating datasets from multiple heterogeneous sources. In some embodiments, the dataset comprises an internal dataset and an external dataset. In some embodiments, the multiple heterogeneous sources include one or more of the following: online and retail transactions, account and account holder characteristics, commercial transaction monitoring platforms, PEP lists, sanctions and regulatory catalogs, terrorism and crime watchlists, currency exchange history, or cross-border transaction information. In some embodiments, the method further includes the step of generating at least some of multiple account variables based on the aggregated dataset.

[0006] In some embodiments, the trained algorithm comprises a machine learning algorithm. In some embodiments, the machine learning algorithm comprises one or more of the following: support vector machines (SVMs), naive Bayes classification, linear regression, quantile regression, logistic regression, random forests, neural networks, gradient-boosted classifiers or regressors, or another supervised or unsupervised machine learning algorithm. In some embodiments, the step of generating a money laundering risk score for a given account holder comprises the step of using the trained algorithm to process multiple account variables for the account corresponding to the given account holder.

[0007] In some embodiments, the method further includes the step of a computer storing multiple money laundering risk scores in a database. In some embodiments, the method further includes the step of sorting multiple account holders based on money laundering risk scores for at least multiple account holders. In some embodiments, the step of obtaining at least a subset of the dataset is performed through a cloud-based network.

[0008] In some embodiments, the method further includes the step of identifying a subset of account holders for investigation when a given account holder's money laundering risk score meets a predetermined criterion. In some embodiments, each of the money laundering risk scores represents the probability that the account holder corresponding to the money laundering risk score has one or more accounts that have one or more financial transactions corresponding to money laundering activity. In some cases, the risk score may be the probability that an account is being used for money laundering. In some embodiments, the predetermined criterion is a money laundering risk score that is at least about 20%, at least about 30%, at least about 40%, at least about 50%, at least about 60%, at least about 70%, at least about 80%, at least about 90%, at least about 95%, or at least about 99%. In some embodiments, the method further includes the step of generating a weighted priority score for each of the multiple account holders based on at least the account holder's money laundering risk score and quantitative measures of the account holder or the account holder's transactions. In some embodiments, the quantitative measures include one or more of the following: the quantity of assets at risk, the quantity of total assets, net assets, the number or total value of suspicious transactions, the duration of suspicious transactions or activities, quantitative measures relating to an account holder's relationship to a set of accounts (e.g., duration, number of transactions), quantitative measures relating to an account holder's relationship to one or more other account holders, quantitative measures relating to the relationship between one or more characteristics of an account holder (e.g., account attributes, transactions) and one or more characteristics of another account holder, etc. In some embodiments, the method further includes the step of sorting a plurality of account holders based on a weighted priority score for at least a plurality of account holders. In some embodiments, the method further includes the step of storing a plurality of weighted priority scores in a database by a computer. In some embodiments, the method further includes the step of identifying a subset of a plurality of account holders for investigation when a given account holder's weighted priority score meets a predetermined criterion.In some embodiments, a predetermined criterion is a weighted priority score of a dollar amount of at least approximately $10,000, at least approximately $25,000, at least approximately $50,000, at least approximately $75,000, at least approximately $100,000, at least approximately $250,000, at least approximately $500,000, at least approximately $750,000, or at least approximately $1,000,000. In some embodiments, a predetermined criterion is a weighted priority score of at least approximately 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 15, 20, or more than 20 suspicious transactions. In some embodiments, a predetermined criterion is a weighted priority score of at least approximately 1, 2, 3, 4, 5, 6, or 7 days, approximately 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, or 12 months, or approximately 1, 2, 3, 4, 5 years, or more.

[0009] In some embodiments, the trained algorithm comprises a natural language processing algorithm configured to determine similarity scores between two or more accounts of a plurality of accounts based on text-based information associated with at least two or more accounts in part. The natural language processing algorithm may be an n-gram model.

[0010] In some embodiments, the multiple account variables include one or more of the following: cash ratio, layering risk, structured risk, credit risk, total income and expenses, address changes, transaction frequency, and transaction interval.

[0011] In some embodiments, each of the multiple money laundering risk scores represents the probability that the corresponding account is being used for money laundering.

[0012] In some embodiments, the training algorithm includes layering analysis, configured to detect transactions that exhibit layering.

[0013] In some embodiments, the trained algorithm includes foreign exchange analysis configured to identify one or more of the following: (i) transactions associated with known terrorist organizations, (ii) FOREX non-discriminatory transactions, (iii) suspicious transactions identified by SWIFT®, and (iv) inconsistent currency exchange transactions. In some embodiments, the trained algorithm includes suspicious party analysis configured to target and flag transactions with recipients or senders that have known ties to authorized entities or criminal or terrorist databases. In some embodiments, the trained algorithm includes transaction analysis configured to identify cash ratios, identify multiple deposits of similar size, or flag the use of unconventional financial modalities. In some embodiments, the trained algorithm includes account analysis configured to analyze the relationships between accounts and account holders and correlate criminal or suspicious activity based on historical events. In some embodiments, the trained algorithm includes structured analysis configured to identify structured transactions. In some embodiments, the trained algorithm includes graph techniques configured to analyze relationships between accounts.

[0014] In some embodiments, (c) includes the step of presenting a subset of account holders in a graphical user interface in descending order of money laundering risk score. In some embodiments, the subset of account holders comprises account holders flagged for investigation related to money laundering.

[0015] In another aspect, the disclosure provides a system for detecting fraudulent activity, comprising a user interface, one or more computer processors, and memory, which has machine-executable instructions that, depending on execution by one or more computer processors, cause one or more computer processors to perform actions including (a) acquiring account and transaction data associated with a plurality of accounts, (b) applying a trained algorithm to the account and transaction data to generate a money laundering risk score for each of the plurality of accounts, and (c) presenting a subset of at least a plurality of accounts in the user interface based on the money laundering risk scores of at least a plurality of accounts.

[0016] In some embodiments, the machine learning model may provide interpretability for the analysis results. The machine learning model may provide interpretability for surveillance and investigative analysts. In some cases, one or more contributing factors associated with the likelihood score may be identified, and individual contributing factors may be generated by the machine learning model. In some cases, the output of the machine learning model may include feature contributing factors and feature importance values ​​for each likelihood score. In some cases, the output of the machine learning model may include multiple features grouped by typology.

[0017] In some embodiments, the method further includes the step of a computer generating one or more recommended decisions based on an identified subset of multiple account holders. In some embodiments, the method further includes the step of generating an alert when the money laundering risk score for one or more account holders among multiple watchlist account holders meets a predetermined criterion. In some embodiments, the method further includes the step of generating an alert when the weighted priority score for one or more of a set of watchlist account holders meets a predetermined criterion. In some embodiments, the multiple money laundering risk scores are generated in real time, near real time, immediately, at regular intervals (e.g., weekly, daily, every four hours, etc.), on the user's request, or equivalent. In some embodiments, the method further includes the step of processing an identified subset of multiple account holders and generating an analysis chart, the analysis chart comprising visualizations and analysis information for each of the identified subsets of multiple account holders, and the step of displaying the analysis chart to the user. In some embodiments, the visualizations include geospatial visualizations. In some embodiments, analysis charts are generated and displayed to the user in real time, near real time, immediately, at regular intervals (e.g., weekly, daily, every four hours, etc.), upon user request, or equivalent.

[0018] Another aspect of the present disclosure provides a computer system comprising a digital processing device having at least one processor, an operating system configured to execute executable instructions, memory, and a computer program including instructions executable by the digital processing device to generate an application for anti-money laundering (AML) analysis, wherein the application comprises a first module programmed to acquire a dataset having a plurality of accounts, each of which accounts corresponds to an account holder among a plurality of account holders, and each of the plurality of accounts has a plurality of account variables, the plurality of account variables having financial transactions; a scoring module programmed to apply a trained algorithm to the dataset to generate a money laundering risk score for each of the plurality of account holders; an interpretability module for presenting the primary risk drivers of each money laundering risk score; and an identification module programmed to identify a subset of the plurality of account holders for investigation based on the money laundering risk scores of at least the plurality of account holders.

[0019] In some embodiments, the application further includes an aggregation module programmed to retrieve and aggregate datasets from multiple heterogeneous sources. In some embodiments, the datasets include an internal dataset and an external dataset. In some embodiments, the multiple heterogeneous sources include one or more of the following: online and retail transactions, account and account holder characteristics, commercial transaction monitoring platforms, PEP lists, sanctions and regulatory catalogs, terrorism and crime watchlists, currency exchange history, or cross-border transaction information. In some embodiments, the aggregation module is programmed to further generate at least some of multiple account variables based on the aggregated dataset.

[0020] In some embodiments, the trained algorithm comprises a machine learning algorithm. In some embodiments, the machine learning algorithm comprises one or more of the following: support vector machines (SVMs), naive Bayes classification, linear regression, quantile regression, logistic regression, random forests, neural networks, gradient-boosted classifiers or regressors, or another supervised or unsupervised machine learning algorithm. In some embodiments, the scoring module is programmed to generate a money laundering risk score for a given account holder by using the trained algorithm to process multiple account variables for accounts corresponding to a given account holder.

[0021] In some embodiments, the application further includes a storage module programmed by a computer to store multiple money laundering risk scores in a database. In some embodiments, the application further includes a sorting module programmed to sort multiple account holders based on a money laundering risk score for at least multiple account holders. In some embodiments, the first module is programmed to retrieve at least a subset of the dataset through a cloud-based network.

[0022] In some embodiments, the identification module is programmed to identify a subset of account holders for investigation when a given account holder's money laundering risk score meets a predetermined criterion. In some embodiments, each of the money laundering risk scores represents the probability that the account holder corresponding to the money laundering risk score has one or more accounts, each having one or more account variables, each having one or more financial transactions corresponding to money laundering activity. In some embodiments, the predetermined criterion is a money laundering risk score that is at least about 20%, at least about 30%, at least about 40%, at least about 50%, at least about 60%, at least about 70%, at least about 80%, at least about 90%, at least about 95%, or at least about 99%. In some embodiments, the scoring module is programmed to further generate a weighted priority score for each of the multiple account holders based on at least the account holder's money laundering risk score and quantitative measurements of the account holder or the account holder's transactions. In some embodiments, the quantitative measures include one or more of the following: the quantity of assets at risk, the quantity of total assets, net assets, the number or total value of suspicious transactions, the duration of suspicious transactions or activities, quantitative measures relating to an account holder's relationship to a set of accounts (e.g., duration, number of transactions), quantitative measures relating to an account holder's relationship to other account holders, or quantitative measures relating to an account holder's relationship to data of other account holders. In some embodiments, the application further includes a sorting module programmed to sort a plurality of account holders based on a weighted priority score for at least a plurality of account holders. In some embodiments, the application further includes a storage module programmed by a computer to store a plurality of weighted priority scores in a database. In some embodiments, an identification module programmed to identify a subset of a plurality of account holders for investigation when a given account holder's weighted priority score meets a predetermined criterion.In some embodiments, a predetermined criterion is a weighted priority score of a dollar amount of at least approximately $10,000, at least approximately $25,000, at least approximately $50,000, at least approximately $75,000, at least approximately $100,000, at least approximately $250,000, at least approximately $500,000, at least approximately $750,000, or at least approximately $1,000,000. In some embodiments, a predetermined criterion is a weighted priority score of at least approximately 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 15, 20, or more than 20 suspicious transactions. In some embodiments, a predetermined criterion is a weighted priority score of at least approximately 1, 2, 3, 4, 5, 6, or 7 days, approximately 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, or 12 months, or approximately 1, 2, 3, 4, 5 years, or more.

[0023] In some embodiments, the machine learning model may provide interpretability for the analysis results. The machine learning model may provide interpretability for surveillance and investigative analysts. In some cases, one or more contributing factors associated with the likelihood score may be identified, and individual contributing factors may be generated by the machine learning model. In some cases, the output of the machine learning model may include feature contributing factors and feature importance values ​​for each likelihood score. In some cases, the output of the machine learning model may include multiple features grouped by typology.

[0024] In some embodiments, the application further includes a recommendation module, which is programmed by a computer to generate one or more recommended decisions based on an identified subset of multiple account holders. In some embodiments, the application further includes an alert module, which is programmed to generate an alert when the money laundering risk score for one or more account holders among multiple watchlist account holders meets a predetermined criterion. In some embodiments, the application further includes an alert module, which is programmed to generate an alert when the weighted priority score for one or more of a set of watchlist account holders meets a predetermined criterion. In some embodiments, the scoring module is programmed to generate multiple money laundering risk scores in real time, near real time, immediately, at regular intervals (e.g., weekly, daily, every four hours, etc.), on the user's request, or equivalent. In some embodiments, the application further includes an analysis module program, which processes an identified subset of multiple account holders and generates an analysis chart, the analysis chart comprising visualizations and analysis information for each of the identified subsets of multiple account holders, and is programmed to display the analysis chart to the user. In some embodiments, the visualizations include geospatial visualizations. In some embodiments, the analysis module is programmed to generate and display analysis charts to the user in real time, near real time, immediately, at regular intervals (e.g., weekly, daily, every four hours, etc.) upon user request or equivalent.

[0025] Another aspect of the present disclosure provides a non-transitory computer-readable medium comprising machine-executable code that implements a method for anti-money laundering (AML) analysis in response to execution by one or more computer processors, the method comprising: (a) obtaining, by a computer, a dataset comprising a plurality of accounts, each of the plurality of accounts corresponding to an account holder among a plurality of account holders, each account of the plurality of accounts comprising a plurality of account variables, the plurality of account variables comprising financial transactions; (b) applying, by the computer, a trained algorithm to the dataset to generate a money laundering risk score for each of the plurality of account holders, the output of the trained algorithm further comprising a major risk driver for each money laundering risk score; and (c) identifying, by the computer, a subset of the plurality of account holders for investigation based at least on the money laundering risk scores of the plurality of account holders.

[0026] Another aspect of the present disclosure provides a non-transitory computer-readable medium comprising machine-executable code that implements any of the methods above or elsewhere in this specification in response to execution by one or more computer processors.

[0027] Another aspect of the present disclosure provides a system comprising one or more computer processors and a computer memory coupled thereto. The computer memory comprises machine-executable code that implements any of the methods above or elsewhere in this specification in response to execution by one or more computer processors.

[0028] Additional aspects and advantages of the present disclosure will become readily apparent to those skilled in the art from the following detailed description, which illustrates, by way of example only, the illustrative embodiments of the present disclosure. As will be recognized, the present disclosure is capable of other and different embodiments, and some of its details are capable of modifications in various obvious respects, all without departing from the present disclosure. Accordingly, the drawings and description are to be regarded as illustrative in nature and not restrictive. The present invention provides, for example, the following. (Item 1) A computer-implemented method for anti-money laundering (AML) analysis, comprising: (a) obtaining, by a computer, a data set comprising a plurality of accounts, each of the plurality of accounts corresponding to an account holder among a plurality of account holders, each account of the plurality of accounts being defined by a plurality of account variables, the plurality of account variables comprising financial transactions; and (b) applying, by the computer, a trained algorithm to the data set to generate a money laundering risk score for each of the plurality of account holders and one or more major risk drivers associated with the money laundering risk score; and (c) outputting, by the computer, at least a subset of the plurality of account holders based at least on the money laundering risk scores of the plurality of account holders. A method comprising the above. (Item 2) The method according to item 1, wherein obtaining the data set comprises obtaining and aggregating data sets from a plurality of heterogeneous sources. (Item 3) The method according to item 2, wherein the data set comprises an internal data set and an external data set. (Item 4) The method according to item 2, wherein the plurality of heterogeneous sources comprise one or more of online and retail transactions, accounts and account holder characteristics within a preselected time window, a commercial transaction monitoring platform, a PEP list, a sanctions and regulations catalog, a terror and crime watch list, a currency exchange history, or cross-border transaction information. (Item 5) The method according to item 2, further comprising generating at least a portion of the plurality of account variables based on the aggregated data set. (Item 6) The method according to item 1, wherein the trained algorithm comprises a machine learning algorithm. (Item 7) The method according to item 6, wherein the machine learning algorithm comprises one or more of the following: support vector machines (SVMs), naive Bayes classification, linear regression, quantile regression, logistic regression, random forests, neural networks, gradient-boosted classifiers or regressors, or other supervised or unsupervised machine learning algorithms. (Item 8) The method according to item 6, wherein generating the money laundering risk score for a given account holder comprises using the trained algorithm to process a number of account variables for the account corresponding to the given account holder. (Item 9) The method according to item 1, further comprising storing the plurality of money laundering risk scores in a database using the computer. (Item 10) The method according to item 1, further comprising sorting the multiple account holders based on at least one money laundering risk score for each of the multiple account holders. (Item 11) The method described in item 1, wherein obtaining at least a subset of the aforementioned dataset is performed via a cloud-based network. (Item 12) The method according to item 1, further comprising outputting a subset of account holders when the money laundering risk score of each account holder in the subset meets a predetermined criterion. (Item 13) The method according to item 1, wherein each of the aforementioned multiple money laundering risk scores indicates the probability that the account holder corresponding to the money laundering risk score has one or more accounts that include one or more financial transactions corresponding to money laundering activities. (Item 14) The method described in item 13, wherein the specified criteria is a money laundering risk score of at least about 20%, at least about 30%, at least about 40%, at least about 50%, at least about 60%, at least about 70%, at least about 80%, at least about 90%, at least about 95%, or at least about 99%. (Item 15) The method according to item 1, further comprising generating a weighted priority score for each of the multiple account holders based on at least the money laundering risk score of the account holder and quantitative measurements of the account holder or the account holder's transactions. (Item 16) The method according to item 15, wherein the quantitative measurement comprises one or more quantitative measurements relating to the quantity of assets at risk, the quantity of total assets, net assets, the number or total value of suspicious transactions, the length of time of suspicious transactions or activities, or the account holder's relationship to a set of accounts. (Item 17) The method according to item 15, further comprising sorting the multiple account holders based on a weighted priority score for each of the multiple account holders. (Item 18) The method of item 15, further comprising storing the plurality of weighted priority scores in a database using the computer. (Item 19) The method of item 15, further comprising outputting the subset of account holders when the weighted priority score of each account holder in the subset meets a predetermined criterion. (Item 20) The method described in item 19, wherein the predetermined criteria are weighted priority scores that are dollar amounts of at least approximately $10,000, at least approximately $25,000, at least approximately $50,000, at least approximately $75,000, at least approximately $100,000, at least approximately $250,000, at least approximately $500,000, at least approximately $750,000, or at least approximately $1,000,000. (Item 21) The method described in item 19, wherein the predetermined criteria is a weighted priority score which is the number of suspicious transactions at least approximately 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 15, 20, or more than 20. (Item 22) The method described in item 19, wherein the predetermined criteria is a weighted priority score that is a length of time of at least about 1, 2, 3, 4, 5, 6, or 7 days, about 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, or 12 months, or about 1, 2, 3, 4, 5 years, or longer. (Item 23) The method according to item 1, further comprising using the computer to generate one or more recommended decisions based on an identified subset of the multiple account holders. (Item 24) The method described in item 1, further comprising generating an alert when the money laundering risk score for one or more account holders among multiple watchlist account holders meets a predetermined criterion. (Item 25) The method of item 15, further comprising triggering an alert when the weighted priority score for one or more of the set of watchlist account holders meets a predetermined criterion. (Item 26) The aforementioned multiple money laundering risk scores are generated in real time, according to the method described in item 1. (Item 27) The method according to item 1, further comprising processing an identified subset of the plurality of account holders and generating an analysis chart, wherein the analysis chart comprises visualization and analysis information for each of the identified subsets of the plurality of account holders, and displaying the analysis chart to a user. (Item 28) The visualization described above is the method described in item 27, including geospatial visualization. (Item 29) The analysis chart is generated in real time and displayed to the user, according to the method described in item 27. (Item 30) A computer system comprising a digital processing device having at least one processor, an operating system configured to execute executable instructions, memory, and a computer program including instructions executable by the digital processing device to generate an application for anti-money laundering (AML) analysis, the application is A first module programmed to acquire a dataset comprising multiple accounts, each of which corresponds to an account holder among multiple account holders, and each of the multiple accounts is defined by multiple account variables, the multiple account variables comprising financial transactions, and the first module A scoring module, the scoring module being programmed to apply a trained algorithm to the dataset and generate a money laundering risk score for each of the plurality of account holders and one or more major risk drivers associated with the money laundering risk score, A presentation module, which is programmed to present at least a subset of the multiple account holders in a graphical user interface based on the money laundering risk scores of at least the multiple account holders, and A system equipped with these features. (Item 31) The system described in item 30 further comprises an aggregation module programmed to acquire and aggregate datasets from multiple heterogeneous sources. (Item 32) The system described in item 31 comprises an internal dataset and an external dataset. (Item 33) The aforementioned multiple heterogeneous sources include one or more of the following systems as described in item 31: online and retail transactions, account and account holder characteristics, commercial transaction monitoring platforms, PEP lists, sanctions and regulatory catalogs, and terrorism and crime watchlists, currency exchange history, or cross-border transaction information. (Item 34) The system according to item 31, wherein the aggregation module is programmed to further generate at least some of the plurality of account variables based on the aggregated dataset. (Item 35) The aforementioned trained algorithm is the system described in item 30, comprising a machine learning algorithm. (Item 36) The machine learning algorithm is one or more of the following systems as described in item 35: support vector machines (SVMs), naive Bayes classification, linear regression, quantile regression, logistic regression, random forests, neural networks, gradient boosted classifiers, or other supervised or unsupervised machine learning algorithms. (Item 37) The system according to item 35, wherein the scoring module is programmed to generate the money laundering risk score for a given account holder by processing a number of account variables for the account corresponding to the given account holder using the trained algorithm. (Item 38) The system according to item 37, wherein the scoring module is programmed to process the multiple account variables of the account corresponding to a given account holder by fitting a statistical distribution to the multiple account variables. (Item 39) The system according to item 30, wherein the application further comprises a storage module programmed by the computer to store the plurality of money laundering risk scores in a database. (Item 40) The system according to item 30, wherein the application further comprises a sort module programmed to sort the multiple account holders based on at least one money laundering risk score for each of the multiple account holders. (Item 41) The system described in item 30, wherein the first module is programmed to retrieve at least a subset of the dataset through a cloud-based network. (Item 42) The system described in item 30, wherein the presentation module is programmed to present a subset of account holders for investigation when the money laundering risk score of each account holder in the subset meets a predetermined criterion. (Item 43) The system described in item 30, wherein each of the aforementioned money laundering risk scores indicates the probability that the account holder corresponding to the money laundering risk score has one or more accounts having one or more account variables that have one or more financial transactions corresponding to money laundering activities. (Item 44) The system described in item 43, wherein the specified criteria are a money laundering risk score of at least about 20%, at least about 30%, at least about 40%, at least about 50%, at least about 60%, at least about 70%, at least about 80%, at least about 90%, at least about 95%, or at least about 99%. (Item 45) The system according to item 30, wherein the scoring module is programmed to further generate weighted priority scores for each of the multiple account holders based on at least the account holder's money laundering risk score and quantitative measurements of the account holder or the account holder's transactions. (Item 46) The system described in item 45, wherein the quantitative measures include one or more quantitative measures relating to the quantity of assets at risk, the quantity of total assets, net assets, the number or total value of suspicious transactions, the length of time of suspicious transactions or activities, or the account holder's relationship to a set of accounts. (Item 47) The system according to item 45, wherein the application further comprises a sort module programmed to sort the multiple account holders based on a weighted priority score for at least one of the multiple account holders. (Item 48) The system according to item 45, wherein the application further comprises a storage module programmed by the computer to store the plurality of weighted priority scores in a database. (Item 49) The system according to item 45, wherein the presentation module is programmed to present a subset of account holders for investigation when the weighted priority score of each account holder in the subset meets a predetermined criterion. (Item 50) The system described in item 49, wherein the predetermined criteria are a weighted priority score of at least approximately $10,000, at least approximately $25,000, at least approximately $50,000, at least approximately $75,000, or at least approximately $100,000. (Item 51) The system described in item 49, wherein the predetermined criteria is a weighted priority score which is the number of suspicious transactions at least approximately 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 15, 20, or more than 20. (Item 52) The system described in item 49, wherein the predetermined criteria are a weighted priority score of a length of time of at least about 1, 2, 3, 4, 5, 6, or 7 days, about 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, or 12 months, or about 1, 2, 3, 4, 5 years, or longer. (Item 53) The system according to item 30, wherein the application further comprises a recommendation module programmed by the computer to generate one or more recommended decisions based on an identified subset of the plurality of account holders. (Item 54) The system described in item 30 further comprises an alert module programmed to generate an alert when the money laundering risk score of one or more account holders among multiple watchlist account holders meets a predetermined standard. (Item 55) The system described in item 45 further comprises an alert module programmed to generate an alert when the weighted priority score for one or more of the set of watchlist account holders meets a predetermined criterion. (Item 56) The scoring module is programmed to generate the multiple money laundering risk scores in real time, as described in item 30. (Item 57) The system according to item 30, further comprising an analysis module programmed to process an identified subset of the plurality of account holders and generate an analysis chart, wherein the analysis chart comprises visualization and analysis information for each of the identified subsets of the plurality of account holders, and to display the analysis chart to a user. (Item 58) The aforementioned visualization is a system described in item 57, including geospatial visualization. (Item 59) The system according to item 57, wherein the analysis module is programmed to generate the analysis chart in real time and to display the analysis chart to the user. (Item 60) A non-transient computer-readable medium comprising machine-executable code, the machine-executable code performing a method for anti-money laundering (AML) analysis in response to execution by one or more computer processors, the method (a) The computer obtains a dataset comprising multiple accounts, each of which corresponds to an account holder among multiple account holders, each of which is defined by multiple account variables, and each of which account variables comprises financial transactions. (b) The computer applies the trained algorithm to the dataset to generate a money laundering risk score for each of the multiple account holders and one or more key risk drivers associated with the money laundering risk score, (c) The computer outputs at least a subset of the account holders based on the money laundering risk score of at least the account holders. Non-transient computer-readable media, including [specific examples of such media]. (Item 61) The method according to item 1, wherein the trained algorithm comprises a natural language processing algorithm configured to determine similarity scores between two or more accounts among the plurality of accounts based on text-based information associated with at least two or more accounts in part. (Item 62) The aforementioned natural language processing algorithm is an n-gram model, as described in item 61. (Item 63) The method according to item 8, wherein the aforementioned account variables include one or more of the following: cash ratio, layering risk, structured risk, credit risk, total income and expenses, address change, transaction frequency, and transaction interval. (Item 64) The method according to item 1, wherein each of the aforementioned money laundering risk scores is the probability that the corresponding account is being used for money laundering. (Item 65) The method according to item 1, wherein the trained algorithm includes layering analysis configured to detect transactions that exhibit layering. (Item 66) The method described in Item 1, comprising foreign exchange analysis, wherein the trained algorithm is configured to identify one or more of the following: (i) transactions associated with a known terrorist organization, (ii) transactions that are not FOREX-discriminated, (iii) suspicious transactions identified by SWIFT®, and (iv) inconsistent currency exchange transactions. (Item 67) The method described in Item 1, comprising suspicious party analysis, wherein the trained algorithm is configured to target and flag transactions with recipients or senders that have known ties to authorized entities or criminal or terrorist databases. (Item 68) The method according to item 1, comprising transaction analysis, wherein the trained algorithm is configured to identify cash ratios, identify multiple deposits of similar size, or flag the use of unconventional financial modalities. (Item 69) The method according to item 1, comprising account analysis, wherein the trained algorithm is configured to analyze the relationship between accounts and account holders and to correlate criminal or suspicious activity based on historical events. (Item 70) The method according to item 1, wherein the trained algorithm includes structured analysis configured to identify structured transactions. (Item 71) The method according to item 1, wherein the trained algorithm includes graph techniques configured to analyze the relationships between accounts. (Item 72) (c) the method of item 1, which includes presenting a subset of the multiple account holders in the graphical user interface in descending order of money laundering risk score. (Item 73) The method according to item 1, wherein the subset of account holders includes account holders flagged for investigations related to money laundering. (Item 74) A system for detecting fraudulent activity, User interface and One or more computer processors, A memory comprising machine-executable instructions, wherein the machine-executable instructions are, in response to execution by one or more computer processors, provided to the one or more computer processors (a) Obtaining account and transaction data associated with multiple accounts, (b) Applying a trained algorithm to the account and transaction data to generate a money laundering risk score for each of the multiple accounts, (c) Presenting at least a subset of the above-mentioned accounts within the user interface based on the money laundering risk scores of at least the above-mentioned accounts. This involves performing operations that include memory and A system equipped with these features.

[0029] (Integrated by reference) All publications, patents, and patent applications referenced herein are incorporated herein by reference to the same extent as each individual publication, patent, or patent application is shown to be incorporated by specific and individual reference. To the extent that any publications and patents or patent applications incorporated by reference conflict with any disclosure contained herein, this specification is intended to take precedence and / or precede any such conflicting material. [Brief explanation of the drawing]

[0030] Novel features of this disclosure are specifically described in the appended claims. A deeper understanding of the features and advantages of this disclosure will be obtained by referring to the following detailed description and accompanying drawings (also referred to herein as "Figures") which describe illustrative embodiments in which the principles of this disclosure are utilized.

[0031] [Figure 1] Figure 1 shows an example of a typical AML business process, including prevention, detection, and reporting.

[0032] [Figure 2A] Figures 2A and 2B show examples of anti-money laundering (AML) dashboards for AML applications. [Figure 2B] Figures 2A and 2B show examples of anti-money laundering (AML) dashboards for AML applications.

[0033] [Figure 3] Figure 3 shows some examples of an AML dashboard that is programmed or configured to provide a geospatial view of priority cases.

[0034] [Figure 4] Figure 4 shows some examples of an AML dashboard that is programmed or configured to provide users with a way to triage suspicious incidents.

[0035] [Figure 5] Figure 5 shows some examples of AML dashboards that are programmed or configured to provide a way for users to take bulk action on incidents within a primary, prioritized grid.

[0036] [Figure 6]Figure 6 shows some examples of AML dashboards that are programmed or configured to provide a rich set of historical information about suspicious accounts or account holders, which may require analysts to spend time querying various other systems.

[0037] [Figure 7] Figure 7 shows some examples of AML dashboards that are programmed or configured to provide alerts and watchlists.

[0038] [Figure 8] Figure 8 shows some examples of AML dashboards where users can program or configure themselves to adjust alert dates, manage notifications, or add additional alert triggers on incoming data.

[0039] [Figure 9A] Figures 9A, 9B, and 9C show some examples of AML dashboards that are programmed or configured to provide a method for the user to select an incident file generation popup from an action menu dropdown for a single or bulk incident. [Figure 9B] Figures 9A, 9B, and 9C show some examples of AML dashboards that are programmed or configured to provide a method for the user to select an incident file generation popup from an action menu dropdown for a single or bulk incident. [Figure 9C] Figures 9A, 9B, and 9C show some examples of AML dashboards that are programmed or configured to provide a method for the user to select an incident file generation popup from an action menu dropdown for a single or bulk incident.

[0040] [Figure 10] Figure 10 shows an example of an AML model that can be trained using previously confirmed illegal activity cases.

[0041] [Figure 11] Figure 11 shows an example of an account dataset being processed through each of the analysis algorithms or features.

[0042] [Figure 12] Figure 12 shows an example of a feature that can be calculated based on the required set of data in the history with respect to its algorithm or composite feature requirements.

[0043] [Figure 13] Figure 13 illustrates an example of how a machine learning model can analyze illegal activity in an account by processing a set of features relating to a given account (e.g., "account X") in a high-dimensional space and generating a money laundering composite score.

[0044] [Figure 14A] Figure 14A illustrates an example of how a machine learning model can perform machine learning-based lead classification to identify suspicious typologies by analyzing a composite score of accounts or stakeholders and identifying suspicious / illegal and legitimate accounts or stakeholders.

[0045] [Figure 14B] Figure 14B shows an example of how a machine learning model can be adapted to an evolving risk typology.

[0046] [Figure 14C] Figure 14C provides an overview of how machine learning models can collect or aggregate raw data into a unified federated data lake, perform data structuring, apply machine learning rules and algorithms, generate alerts, and enable investigators to use the results to generate reports.

[0047] [Figure 14D] Figure 14D shows an example of how a machine learning model may be designed to perform comprehensive feature engineering.

[0048] [Figure 14E] Figure 14E shows an example of how a machine learning model may be designed to use features to detect money laundering across all risk typologies.

[0049] [Figure 14F] Figures 14F-14H illustrate an example of how a machine learning model may use a set of machine learning features designed to provide robust coverage of all types of digital information that can be used to identify suspicious activity. [Figure 14G] Figures 14F-14H illustrate an example of how a machine learning model may use a set of machine learning features designed to provide robust coverage of all types of digital information that can be used to identify suspicious activity. [Figure 14H] Figures 14F-14H illustrate an example of how a machine learning model may use a set of machine learning features designed to provide robust coverage of all types of digital information that can be used to identify suspicious activity.

[0050] [Figure 14I] Figure 14I illustrates an example of how machine learning models can provide interpretability for surveillance and investigative analysts.

[0051] [Figure 15] Figure 15 shows an example of how a machine learning model can use natural language processing (NLP) to identify the similarity between accounts, account holders, and account information.

[0052] [Figure 16] Figure 16 shows an example of how an AML model can use a trusted PageRank method.

[0053] [Figure 17]Figure 17 shows an example of how an AML model can use conventional clustering techniques to identify similarities between accounts that may indicate fraudulent activity.

[0054] [Figure 18] Figure 18 illustrates an example of how the analysis may be described using various classes based on the dominant issuance mode (e.g., placement, layering, foreign exchange, structured, suspicious activity, trading, and account).

[0055] [Figure 19] Figure 19 shows a computer system programmed or otherwise configured to implement the method provided herein. [Modes for carrying out the invention]

[0056] Preferred embodiments of the present invention are shown and described herein, but it will be apparent to those skilled in the art that such embodiments are provided only as examples. Numerous modifications, alterations, and substitutions will be conjured upon those skilled in the art without departing from the present invention. It should be understood that various alternatives to the embodiments of the present invention described herein may be employed in practicing the present invention.

[0057] The various terms used throughout this description may be read and understood as follows, unless the context indicates otherwise: “or” as used throughout is inclusive as if it were written as “and / or”; singular articles and pronouns as used throughout include their plural forms and vice versa; gender pronouns include their corresponding pronouns, so that the pronouns should not be understood as limiting any of those described herein to use, implementation, or execution by a single gender; and “exemplary” should be understood as “illustrative” or “symbolic,” and not necessarily “preferred” over other embodiments. Further definitions of terms may be provided herein, and these may apply to the preceding and succeeding instances of those terms, as will be understood from a careful reading of this description.

[0058] What is recognized herein is the need for systems and methods for improved anti-money laundering (AML) analysis that utilize machine learning techniques, which can be applied to more accurately identify accounts or account holders for investigation purposes. Such systems and methods for improved AML analysis may benefit institutions (e.g., banks) by, for example, improving the efficiency of AML operations, reducing regulatory exposure, and mitigating reputational damage risks. This disclosure, to our advantage, provides systems and methods that can apply machine learning to accurately manage and predict accounts and account holders associated with money laundering risk. Such systems and methods may enable accurate prediction of money laundering risk, all in real time, near real time, immediately, at regular intervals (e.g., weekly, daily, every four hours, etc.), on user request, or equivalent, based on the analysis of account variables, identification of suspicious accounts or account holders for investigation purposes, and identification of actionable recommendations to the user.

[0059] The systems and methods described herein may apply machine learning to anti-money laundering (AML) efforts to increase the accuracy of identifying suspicious activity and uncover new fraud modes. For example, an AML application may be a workflow-enabled application that allows compliance officers to gain operational efficiency by reducing the number of false positive alerts, improve the allocation of compliance resources, and focus on high-value investigations. An AML application may assist monitoring compliance analysts and financial crime managers by prioritizing suspicious accounts by the likelihood of fraudulent activity and the quantity of assets at risk. An AML application may also integrate and query a number of information sources (e.g., data sources) in real time, near real time, immediately, at regular intervals (e.g., weekly, daily, every four hours, etc.), on user request, or equivalent, as described elsewhere herein.

[0060] The systems and methods described in this disclosure can provide a single source of all relevant information, enabling compliance analysts to conduct all necessary investigations within a single platform and, once suspicions about an account or account holder are confirmed, to take action to generate an incident in the associated incident management system. Machine learning response prioritization can be complemented by a range of advanced analytics to support interpretability and faster triage. Together, compliance teams can dramatically improve operational efficiency in their AML activities.

[0061] The systems and methods of this disclosure may use machine learning algorithms powered by tens, hundreds, or thousands of complex analytical features that correlate high-frequency transactions (e.g., debits and credits) with reference lists, account information, and account holder information. Examples of analytical features may include high-speed funds, transaction size similarity of related accounts, number of unique transaction locations, suspicious foreign entity relevance, deposit amount variance, cash ratio, and graphs of transactions in space and / or time. Each analytical output may be fed into a machine learning model that classifies all accounts or account holders using a money laundering risk score. Such money laundering risk scores may be updated in real time, near real time, immediately before, at regular intervals (e.g., weekly, daily, every four hours, etc.), on user request, or equivalent, with all new transactions, accounts, account holders, or list changes.

[0062] In further embodiments, the AML application can track key performance metrics of AML activities, ensure operational improvements over time, and provide summary-level information on recent verified illegal activities and current suspected cases. In addition, the application may include a user interface (e.g., a graphical user interface, GUI) that is programmed or configured to display visualizations of output data (e.g., geospatial views and watchlists) which can be applied to summary-level or account-level information as desired.

[0063] In one embodiment, the AML application can be built on an integrated platform that enables real-time or near-real-time integration, as well as scalability in new data sources, computation, and flexibility for developing and iterating on machine learning models in progress.

[0064] In one embodiment, the AML application supports the identification of assets at risk. For example, account or account holder information can be analyzed to prioritize accounts or account holders by the highest expected cumulative amount of money laundering, and to weight the likelihood of illicit activity by the estimated amount of laundered funds. The classification of illicit activity can be improved through machine learning training on a set of confirmed money laundering cases and associated transactions as well as account or account holder information. In addition, advanced analytics can support machine learning interpretability and increase investigative efficiency based on targeted and actionable root cause identification. The AML application can improve customer satisfaction by reducing the number of investigations required due to more accurate predictions.

[0065] In one embodiment, an AML application supports AML operational efforts, thereby benefiting compliance officers. For example, streamlined data integration across multiple systems can enable faster case triage and gradual scaling for field investigation teams. AML operational efforts can incorporate managed workflows that support business processes for investigations. In addition, bidirectional integration with case management systems enables case generation with accurate data, thereby reducing back-office errors and accelerating case resolution times.

[0066] In one embodiment, an AML application helps compliance investigators identify suspicious activity that might otherwise be identified through other business processes, leading to more timely regulatory reporting.

[0067] In one embodiment, an AML application can help identify additional clients for further scrutiny, which may lead to reporting more suspicious activity to authorities, resulting in improved overall compliance with regulatory requirements (e.g., bank secrets laws, patriot laws).

[0068] In some embodiments, AML applications support regulatory requirements, thereby generating benefits in reducing regulatory exposure. For example, AML applications can enable consistent reporting of potentially fraudulent activity for contractual and regulatory reporting purposes. Improved asset recovery and suspicious activity identification can reduce risky fund and asset movements. In addition, improved AML efforts can confer a favorable position to banks as global leaders in combating criminal and terrorist activity.

[0069] In one embodiment, the AML application supports a group of users, including individuals such as compliance analysts. Compliance analysts may be involved in supporting commercial and transaction monitoring teams as they identify and incrementally scale up money laundering activities. They may implement a second line of defense, operate within a risk framework, and constantly strive to apply improved systems and methods for monitoring and identifying illegal activities.

[0070] Using the systems and methods described herein, users (e.g., compliance analysts) can analyze transactions and commercial activities using systems such as SMARTS, SWIFT®, and Actimize. Such users can understand regulatory requirements and apply risk frameworks to account activities. They can also incrementally extend activities outside the risk corridor (e.g., to financial crime enforcement officers).

[0071] Using the systems and methods described herein, users can perform a variety of tasks. Firstly, users can scrutinize the current pipeline of accounts at risk, as well as trends in group performance over the past few months. Users may have a queue of cases to triage and public investigations to pursue. Secondly, users can assess key performance indicators for targets. Thirdly, users can use machine learning scores (e.g., money laundering risk scores) to identify accounts and assets at risk. Fourthly, users can use robust filtering options to find accounts, transactions, blacklisted accounts or account holders, etc., across entire sets of accounts or account holders. For example, filters may, by default, return results sorted according to the likelihood of illegal activity, ensuring that accounts or account holders with the highest likelihood, risk, or suspicion of illegal activity are given importance.

[0072] Fifth, the user may conduct a deeper investigation into the accounts or account holders to be triaged and determine whether a step-by-step expansion (e.g., further investigation) is necessary. For example, the user may use charting features to visualize transactions and analysis. The user may correlate all relevant sanctions and PEP list information with respect to the associated accounts. In another embodiment, the user may assign accounts for triage and scrutiny among team members to prevent duplicate assessments. The user may decide whether to step-by-step. If step-by-step expansion is requested, the user may open a pop-up with pre-filled account or account holder information and direct the investigation to the appropriate crime detection team. If step-by-step expansion is not requested, the user may change the status of the case within the platform and inform the machine learning model that the case is not suspicious. The user may also add accounts or account holders to a watchlist for scrutiny at a future time and set up alerts for future points in time. If a user changes the status of an incident, such changes may be later examined and used to train one of the algorithms described herein.

[0073] Sixth, users may review existing watchlist accounts. Seventh, users may review past illegal activities for reference. For example, users may wish to retain records of previous incidents of illegal activity for future reference and cross-training purposes.

[0074] Financial Crime Managers (FSMs) may be involved in managing distributed teams of financial crime analysts who will implement AML activities and recommend deeper investigations. Their primary objectives may include overseeing suspicious cases in the pipeline, coordinating and cross-training among analysts, and monitoring team performance metrics. FMSs may perform a variety of tasks. For example, FMSs may determine the need for financial crime analysts and the alignment between that need and the software and other resources required to perform the tasks. In another embodiment, FMSs may monitor and track team and individual performance, including asset recovery, investigation hit rates, and team operational efficiency. Furthermore, FMSs may conduct cross-training and ensure that all team members are capable of assessing illegal activity using existing tools and applications.

[0075] A financial crimes administrator may use the systems and methods described in this disclosure to perform a variety of tasks. For example, a financial crimes administrator may include key performance metrics in an application dashboard to appropriately assess performance and expose targets. In another embodiment, a financial crimes administrator may set up alerts on the overall progress of investigations. Furthermore, a financial crimes administrator may scrutinize pre-verified fraud cases to support the identification of new machine learning features or improvements to the user interface (UI). A financial crimes administrator may support cross-training through team scrutiny of application features and machine learning outputs.

[0076] Compliance and risk officers may be involved in ensuring that all investigations meet stringent standards and are adequately documented for law enforcement authorities in accordance with regulatory requirements. Compliance and risk officers may use the systems and methods of this disclosure to perform a variety of tasks. For example, compliance and risk officers may define transaction data and related information required to be reported to external government and criminal authorities. In another embodiment, compliance and risk officers may support machine learning interpretability processes to ensure a certain level of traceability in suspicious cases identified by machine learning and investigative triggers employed by analysts. Furthermore, compliance and risk officers may generate special reports for third-party entities (for example, based on compliance and regulatory requirements).

[0077] In one respect, the disclosure includes (a) the step of obtaining a dataset comprising a plurality of accounts by computer, each of which accounts corresponds to an account holder among a plurality of account holders, each of which accounts comprises a plurality of account variables, the plurality of account variables comprising financial transactions; (b) the step of applying a trained algorithm by computer to the dataset to generate a money laundering risk score for each of the plurality of account holders; and (c) the step of identifying a subset of the plurality of account holders for investigation based on the money laundering risk scores of at least a plurality of account holders by computer.

[0078] In some embodiments, the AML may include a user interface (UI), such as a graphical user interface (GUI), which may be programmed or configured to provide information such as key executive-level performance indicators, summary information on current top suspected cases, alerts set regarding watchlist cases, and insights into recently verified cases of illegal activity.

[0079] Figure 1 illustrates an embodiment of a typical AML business process, including prevention, detection, and reporting. The systems and methods of this disclosure may utilize artificial intelligence methods to provide feedback between the reporting and detection phases, and between the detection and prevention phases. For example, in the prevention phase, such artificial intelligence methods may use artificial intelligence for improved Know Your Customer (KYC) profiling, enhanced due diligence, and AI-based client segmentation. In another embodiment, in the detection phase, such artificial intelligence methods may use artificial intelligence for transaction monitoring, alert triage, and prioritizing accounts for scrutiny and escalation (levels 1 and 2 scrutiny). In another embodiment, in the reporting phase, such artificial intelligence methods may use machine learning, regulatory audits, and indicators for closed-loop feedback, such as scenario / typology feedback loops (e.g., with respect to suspicious activity reporting, SAR).

[0080] Figures 2A and 2B show an example of an anti-money laundering (AML) dashboard for an AML application. The insight-driven dashboard has numerous components designed to focus the user on targets and new opportunities. All values ​​are updated as new data is integrated into the AML platform, ensuring that the user is viewing the latest insights and the composition of suspicious incidents.

[0081] The AML dashboard may be programmed or configured to display a set of global metrics (e.g., basic risk metrics and a summary of case status), a "watchlist" of high-risk clients, a set of team management tools (e.g., for scrutinizing team performance and tracking case resolution progress), AI prioritization of all cases, a case list (e.g., including an overview of cases with basic management of the investigative team), analyst performance (e.g., for scrutinizing relative analyst performance), performance trends, and key performance metrics (e.g., to provide a summary of key indicators of AML activities).

[0082] The AML dashboard may be programmed or configured to display a "watchlist" of high-risk clients (e.g., a shortlist of new potential money laundering cases that have occurred). Users can set up watchlists for suspicious accounts that may require scrutiny within the next month. Analysts typically know when a case has sufficient evidence of illegal activity to justify a phased investigation. The AML dashboard can support their subject matter expertise and allow the watchlist feature to provide automated reminders so they can scrutinize accounts in more detail again.

[0083] The AML dashboard may be programmed or configured to display a prioritized list of top cases based on an artificial intelligence-based (e.g., machine learning-based) risk score. For example, top cases may be classified by suspicious accounts or account holders that meet a predetermined risk threshold used by a machine learning model. Within the set of top cases, the machine learning interpretation may yield insights into the actual mode of illegal activity that most strongly connects to and explains the suspicious accounts or account holders.

[0084] The AML dashboard may be programmed or configured to display performance trends (for example, to track AML identifications over time). For instance, assets recovered or identified each month may be charted against the previous year and targets. Such performance trend information may be provided to guide executives to overall group performance on a monthly basis and to increase transparency.

[0085] The AML dashboard may be programmed or configured to display recently verified cases. Users may be interested in learning from identified accounts of other analysts of verified financial crimes. The AML platform can provide an easy way for users to scrutinize recent cases to seek additional information or to discuss cross-training and seek to contact assigned analysts to improve it. Using this display, executives can also recognize the value of the application in recently identified cases and risk scores as of the investigation date (e.g., money laundering risk score).

[0086] The AML dashboard may be programmed or configured to provide a workflow-intensive and machine learning-based approach to supporting compliance analyst activities. Thus, compliance analysts may navigate a main page where they can scrutinize suspicious cases identified by machine learning algorithms. When users navigate to a suspicious cases page, they can view a prioritized list of all accounts and / or account holders displaying summary information, as well as a set of filtering capabilities to identify different sets of cases. Users can also switch between a main grid of prioritized cases and a geospatial view of prioritized cases. The main list page can provide a variety of information and robust features even before users delve into individual account levels.

[0087] The AML dashboard may be programmed or configured to provide a geospatial view of prioritized cases, as shown in Figure 3. Analysts may be given the option to geospatially view top suspected cases, which may be color-coded by machine learning likelihood scores (e.g., money laundering risk scores). In addition, cases may be represented by icons of different sizes (e.g., circles of different radii) to indicate the relative account sizes associated with the case. This geospatial view may provide insights into target areas for investigations. Clustering and heatmaps may reveal additional insights into the distribution of risk between account types, account holders, and geographical areas.

[0088] The AML dashboard may be programmed or configured to provide users with a way to triage suspicious cases. Users can access a “quick view” of each suspicious case in a prioritized list by clicking a chart button. From this view (as shown in Figure 4), users can view the most important information about each case, plot different time-series information, navigate between cases, and manually flag them as “Office Rejection” or “Watchlist.”

[0089] The AML dashboard may be programmed or configured to provide a way for users to take bulk action on incidents in a primary, prioritized grid, as shown in Figure 5.

[0090] The AML dashboard may be programmed or configured to provide account details. Analysts may spend a significant amount of time investigating the details of each suspicious case identified by the application. When dozens of data sources are integrated into a single federated cloud picture, the AML platform can provide a rich set of historical information about a suspicious account or account holder, which analysts may otherwise have to spend time querying various systems. These may be grouped into navigation tabs within the details page, as shown in Figure 6. The AML dashboard may be programmed or configured to allow users to generate cases, add cases to a watchlist, and add comments about cases.

[0091] The AML dashboard may be programmed or configured to provide information including details and location, suspicious activity, charts, customer (account holder) interactions, blacklists, account details, user comments, commercial status, transactions, and flags and alerts.

[0092] The AML dashboard may be programmed or configured to provide alerts and watchlists, as shown in Figure 7. Users can trigger alerts, track suspicious incidents over time, apply a “watchlist” flag to be scrutinized for later dates, and notify other individuals using the AML framework. A dialog box may allow users to set up watchlist incidents and then instruct them to set timestamps and a set of individuals who should receive pending alerts. Using the AML platform and alert engine, analysts and other application users may adjust alert dates, manage notifications, or add additional alert triggers on incoming data, as shown in Figure 8.

[0093] The AML dashboard may be programmed or configured to allow users to generate incidents, as shown in Figures 9A, 9B, and 9C. To enhance the operational efficiency improvements that users can achieve using the AML platform, the AML dashboard can provide designated downstream source systems with the ability to generate incident files directly from the application. This approach can serve several purposes, including enabling users to be more efficient and avoid switching systems to scale incidents incrementally, enabling more accurate incident generation when automated using the most recent information within the AML platform, and enabling incidents to be generated with a unique identifier that will help inform machine learning models when incident results are received through a successful inbound integration process. The incident file generation popup can be selected from the action menu dropdown for single or bulk incidents.

[0094] The AML dashboard may be programmed or configured to use various relationship and transaction data to correlate all account activity and identify those accounts or account holders most likely to be engaged in illegal activity. Data sources may range from third-party information such as regulatory catalogs and PEP lists to transaction data of various financial regulatory instruments. Data sources may include, for example, account and account holder information, transactions, online and retail transactions, commerce monitoring platforms (e.g., transaction history), order management systems (e.g., information about securities orders), foreign exchange rate history, blacklists (e.g., criminal and terrorist databases and authorized overseas entities), politically exposed individuals, sanctions and regulatory catalogs, investigations, and credit bureau databases.

[0095] An AML dashboard may be programmed or configured to use various external data sources. In some embodiments, an aggregation module may be programmed or configured to retrieve and aggregate datasets from multiple heterogeneous sources. For example, a dataset may comprise an internal dataset and an external dataset. Examples of heterogeneous sources may include smart devices, sensors, enterprise systems, Extraprize, and internet sources. Such datasets may persist across one or more data storage units to support the identification of money laundering activities. These Extraprize sources provide contextualized information to transaction data and account information derived from enterprise systems. For example, Google News can be used as a data source by using news articles and correlating information across journalism that references key entities such as criminal organizations and PEPs. The AML platform can further contextualize suspicious accounts by leveraging Google News and using sources such as Property Buyout, Experian, World Bank / IMF, and Intelius. "Property Buyout" may describe integration with land buyout and property buyout filings, which can provide key information to link organizations that are loosely affiliated with known licensed or terrorist entities. "Experian" can describe additional third-party context surrounding an individual, potentially providing loan, transaction, and other account histories. The World Bank / IMF provides macroeconomic information about various governments and economic stability around the world, thereby providing context for money movements and allowing for further characterization of suspicious activity. Intelius can provide search results for public records specifically for individuals (social networks, property records, background checks). AML machine learning model

[0096] An AML system may include a machine learning model configured to analyze information and detect money laundering risks. The machine learning model may be configured to independently calculate one or both of two significance measures for each suspected case: the likelihood of illegal activity (e.g., probability or proportion) and the estimated value of assets at risk due to the illegal activity (e.g., dollar amounts or equals). In some cases, the machine learning model may be configured to further calculate a measure of money laundering risk associated with an account and / or account holder. For example, a likelihood score indicating the level of money laundering risk may be calculated for the account and / or account holder.

[0097] A machine learning model may compute likelihood scores to estimate the similarity of “unmarked” accounts and / or account holders with actual cases of illegal activity that had not been previously investigated and confirmed. The likelihood score may be one output of the classification model, applied to the analysis results associated with the account or account holder.

[0098] AML models apply machine learning to detect money laundering and terrorist financing, aggregating and fusing weak signals in the data into strong indicators of illegal activity. This approach can focus on accounts and / or account holders, with all transactions, related account holders, and regulatory information surrounding them relevant.

[0099] The AML model may serve as input used by the classification model and may include a set of “features” that determine whether an account is similar to previous cases of financial crime. These features may be based on analysis and may include, for example, aggregated analysis results, metadata, and various derivatives from the raw data. Analysis results may be aggregated over a standard time window preceding the forecast date using various aggregation functions (sum, count, maximum, minimum, etc.). Starting with approximately 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 150, 200, 250, 300 or more analytical algorithms, the feature extraction process may generate approximately 10, 50, 100, 150, 200, 250, 300, 350, 400, 450, 500, 600, 700, 800, 900, 1,000 or more features. Metadata such as industry, financial instruments, account opening, postal code, and previous transaction statements may be associated with account holders, account types, locations, transactions, and branches linked to potentially suspicious incidents. Metadata may change over time. In some cases, metadata may be aligned / aggregated with analysis results corresponding to the same time window.

[0100] An AML model may use a machine learning model (e.g., a gradient classifier) ​​to generate a likelihood score. An AML model may also include a classification model that uses a set of model parameters obtained by training the classification model with features of previously confirmed illegal activity incidents (e.g., known financial crimes), known false positives, and unlabeled (typically assumed normal) opportunities. Labels (e.g., for training) may include suspected incident resolution and evaluation time.

[0101] At runtime, the AML model can be automatically applied using current parameters and characteristics to predict a risk score (e.g., a money laundering risk score) for each account or account holder, and the most recent score can be recorded and displayed to the user (e.g., through data visualization). A history of previously generated risk scores may also be available for investigation within the AML platform. The AML model may be updated in response to new data loaded into the system. The AML model may be updated periodically, in response to the detection of data changes (e.g., new data is added, a different set of data is selected, or indicators change), or in response to manual updates.

[0102] The AML model may be trained using previously confirmed illegal activity cases, confirmed illegal activity cases, confirmed suspicious activity cases, confirmed normal activity cases, and random sampling from remaining clients, as shown in Figure 10.

[0103] The set of machine learning features for the AML model may be trained using an account training set. Examples of features may include variables indicating an account having a certain cash ratio, being a foreign entity, having layering risk, having multiple locations, having structured risk, having a history of certain currency exchanges, having time between transactions, and having unusual withdrawals. Features may be converted into binary variables (e.g., "yes" or "no") based on thresholding using continuous values. Each account dataset is processed through the analysis algorithm or each of the features, as shown in Figure 11. Examples of features may include binary variables (e.g., "yes" or "no") related to cash ratio, foreign accounts, high-risk creditors, associated account risk, LLCs in transaction messages, currency exchanges, overall balance, and address changes.

[0104] Each feature may be calculated based on the required set of data in the history with respect to its algorithm or composite feature requirements, as shown in Figure 12. For example, the required set of data may include all transactions occurring within a certain duration (approximately 1, 2, 3, 4, 5, 6, or 7 days, approximately 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, or 12 months, or approximately 1, 2, 3, 4, 5 years, or longer). Features may also include transactions exceeding certain limits, the number of unique branch interactions, and transaction volume variance.

[0105] A machine learning model may analyze the illegality of an account by processing a set of features relating to a given account (e.g., "account X") in a high-dimensional space and generating a money laundering composite score, as shown in Figure 13. Various preferred methods can be used to compute the money laundering composite score. The money laundering composite score may be computed based on a linear or nonlinear relationship with the set of features. For example, the money laundering composite score may be computed, for example, by calculating a weighted sum of a subset or the entire set of features relating to a given account. In another embodiment, the money laundering composite score may be the output of a decision tree, where each node of the decision tree represents a logical partition based on feature thresholds. The account analysis results can be combined in a multi-dimensional space and compared with other classified accounts.

[0106] The machine learning model may perform machine learning-based lead classification and identify suspicious typologies by analyzing account or stakeholder composite scores and identifying suspicious / illegal and normal accounts or stakeholders, as shown in Figure 14A. For example, unclassified accounts and their data may be subjected to analytical algorithms and machine learning classifiers to detect accounts or account holders with a high probability of illegal activity. The machine learning model may be adapted to an evolving risk typology (as shown in Figure 14B) such that if an unusual account or stakeholder is investigated outside the scope of existing suspicions (left), the scope of suspicion may be updated to include the newly identified account or stakeholder (right).

[0107] As shown in Figure 14C, machine learning models may analyze raw data (including transaction data, account holder data, watchlists, and public data) across heterogeneous data sources and unify or aggregate such data into a unified federated data lake. Such data may be unified into a single system configured to capture news, social media, and other relevant public data, as well as features, in real time, near real time, immediately, at regular intervals (e.g., weekly, daily, every four hours, etc.), on user request, or equivalent. The unified federated data lake may be processed by data structuring and machine learning rules and / or algorithms to generate holistic intelligent alerts. Data structuring may be performed with hundreds or thousands of parameter manipulations using algorithms that predict holistic risk scores beyond static rules, enable fast fit and structurability, and detect evolving risk typologies. Alerts can be efficiently and effectively viewed by users such as investigators. All data may be maintained within a single UI, eliminating the need for cumbersome manual matching. In addition, risk-driven insights can enable effective case assignment by administrators. Sophisticated visualizations of client transactions and relevances can be provided by machine learning models. Furthermore, effective SAR identification can be performed with minimal false positives. Investigators may use the results and / or visualizations from the machine learning models to prepare reports. Machine learning-based AML systems may have advantages over other AML systems, which may feature heterogeneous data sources that are not unified, have near real-time data updates, limited and simple alerts, and do not allow manual investigations that are less efficient (e.g., in terms of time and cost) and may not be very effective (e.g., in identifying suspicious activity in a timely manner).

[0108] Machine learning models may be designed to process large volumes of high-frequency, heterogeneous data at scale. For example, a machine learning model may feature an advantage in integration by enabling unconstrained access to heterogeneous data (e.g., account holder data, transaction data, watchlist data, news, social media, etc.) in contrast to other systems where data is siloed across multiple systems and often only accessible through cumbersome queries from other teams. In another embodiment, a machine learning model may feature an advantage in synthesis by enabling algorithms to consider all relevant data, as all data is structured to generate hundreds or thousands of signals that fully represent the nuances of information in the raw data, in contrast to other systems where data may be constrained by simple or static rules that lack the refinement to fully represent the rich information in the raw data. In yet another embodiment, a machine learning model may feature an advantage in frequency by enabling real-time or near-real-time data and risk updates, as risk scores are generated as new data is received, in contrast to other systems where data and alerts may be updated infrequently (e.g., monthly). In another embodiment, machine learning models may feature historical advantages by allowing all data to be available at any given time, in contrast to other systems that may only provide access to recent history (e.g., a few months of data instead of several years available to alert rules and analysts), thereby enabling analysts and algorithms to use any or all of the client's history as input to assess the degree of risk.

[0109] Machine learning models may be designed to perform comprehensive feature engineering (as shown in Figure 14D) by structuring raw data and thereby generating hundreds or thousands of features (e.g., signals) for the algorithm using one or more of the following methods: parameter manipulation (e.g., across time, quantity, and transaction type), anomaly detection (for historical behavior and expected peer group behavior), segmentation (using supervised and / or unsupervised learning techniques), graph analysis (to detect networks of illegal accounts), or natural language processing (NLP) (to obtain SWIFT® telegraph messages and other raw text data). Data aggregation can be applied to any feature. For example, transaction data may be aggregated across time (about 1, 2, 3, 4, 5, 6, or 7 days, about 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, or 12 months, or about 1, 2, 3, 4, 5 years, or more). The machine learning algorithm may generate a predictive risk score (e.g., 97%) corresponding to a specific account or account holder. In some embodiments, the output of the machine learning model may further include key risk drivers such as a 5% contribution to “the number of cash equivalent debit transactions between $5,000 and $10,000 over the past 90 days” and a 3% contribution to “the number of high-risk credit transactions exceeding $10,000 over the past 180 days.”

[0110] A machine learning model may use a set of machine learning features designed to extract a comprehensive set of signals from raw data. The model can then be trained (as shown in Figure 14E) to use these signals to detect money laundering across all risk typologies. The feature set may be subdivided into feature classes such as: stakeholder attributes (e.g., client attributes or characteristics, including both internally and externally available data); stakeholder behavior (e.g., stakeholder behavior demonstrated through transactions, telegraphs, or other actions that leave a digital trace); anomalies (e.g., unusual transaction patterns for a described business, unusual patterns against historical criteria, unusual patterns against described revenue); relevance (e.g., proximity to known money launderers, similar transaction patterns to known money launderers, relevance to high-risk businesses or countries); and segmentation (e.g., segmentation based on country, transaction behavior, business sector, legal entity type, shared accounts, high-frequency relationships).

[0111] The machine learning model may use a set of machine learning features designed to provide robust coverage of all types of digital information that can be used to identify suspicious activity (as shown in Figures 14F-14H).

[0112] The feature set may be subdivided into feature classes, including a set of “red flag” features (Figure 14F) such as suspicious information (e.g., a customer provides suspicious or incomplete information), record-keeping evasion (e.g., customer behavior is designed to avoid reporting thresholds or requirements), fund transfers (e.g., a customer makes suspicious transactions), inconsistent behavior (e.g., customer behavior deviates from expected behavior), cross-border transactions (e.g., a customer has ties to or makes transactions in high-risk geographic areas), shell company activities (e.g., a customer or account operates on behalf of an unknown recipient), and other features (e.g., other red flags, including suspicious loans, insurance, or other activities).

[0113] The feature set may be subdivided into feature classes, including a set of “money laundering step” features such as placement (e.g., introducing illegal funds into legitimate financial services), layering (e.g., moving funds to obfuscate traces to the origin of the funds), and integration (e.g., transactions to create an appearance of legitimacy for the source of funds) (Figure 14G).

[0114] The feature set may be subdivided into feature classes, including a set of “AML business function” features such as transaction monitoring (e.g., suspicious activity or transaction monitoring systems), customer verification (e.g., customer verification or client due diligence systems), and watchlists (watchlist filtering for politically exposed or otherwise relevant individuals) (Figure 14H).

[0115] Machine learning models can provide interpretability for analysis results. Machine learning models can provide interpretability for surveillance and investigative analysts (as shown in Figure 14I). In some cases, one or more contributing factors associated with likelihood scores may be identified, and individual contributing factors may be generated by the machine learning model. In some cases, the output of the machine learning model may include feature contributing factors and feature importance values ​​for each likelihood score. In some cases, the output of the machine learning model may include multiple features grouped by typology. For example, by viewing the contribution values ​​of different features categorized into different potential typologies (e.g., lack of transparency, cross-border transactions, structured activities, fund inflows, unusual fund transfers, high-risk relevance, inconsistent activity, and tax evasion) and different categories of feature contributions (e.g., account holder characteristics and changes, balances, structured activities, fund inflows, direct geographical and associated risks, natural language processing, transaction activity changes, and relevant party characteristics), analysts can understand the relative contributions and importance of different categories of potential typologies and features toward generating machine learning risk scores using machine learning models. For example, a higher value for a feature comprising the account holder's foreign account count, combined with other feature values, may have a relatively higher contribution toward the machine learning model's prediction, while a feature comprising the count of all transactions with counterparties at different financial institutions over the past two days may have a relatively smaller contribution toward the machine learning model's prediction of identifying suspicious incidents. Using such metrics for different feature and typology categories, surveillance and investigative analysis may model interpretability and incident scrutiny. In addition, machine learning models may use human-understandable features (such as transaction groups, account attributes, and time ranges of focus) to facilitate interpretability assessment by users such as surveillance and investigative analysts.

[0116] Machine learning models, as shown in Figure 15, may apply natural language processing (NLP) to transactions to derive important information such as identifying similarities between accounts, account holders, and account information. Such an NLP approach may be useful because many fraudulent activities may occur disguised as false or forged account information aimed at evading detection from legitimate account transactions. AML models may scrutinize all account or account holder information (industry, corporate transactions, account holder's name, address) and determine similarity scores for different accounts or account holders. Similarity scores may be important in identifying criminal activity that has moved accounts or shares characteristics that would support the separation of legitimate and criminal activity. Natural language processing applied to transaction messages may include text preprocessing (e.g., configuring a preprocessing pipeline and processing and preserving text data), training a corpus language model for n-gram counting, using machine learning models to read time series of counts and identify important n-grams and predict labels, implementing metrics for important n-grams, and incorporating NLP metrics along with other features in a general classifier.

[0117] AML models may use graph techniques and leverage existing broad and emerging relationships between focus attributes such as account similarity, transfers between entities, and degrees of isolation. These focus attributes can be particularly useful as input to machine learning classifiers when determining the likelihood of illegal activity with respect to any individual account or account holder. Various graph methods such as trusted PageRank, traversal, and clustering may be applied.

[0118] For example, a trusted PageRank method might assume that a set of “trusted” nodes can support the validation or ranking of other unknown nodes. In a search engine, trusted nodes may include government and educational websites. Analysis and evaluation of links from those sites could allow for the classification of nodes as a number of hops from trusted nodes. Alternatively, “untrusted” nodes could be used in the same manner, along with a degree of accessibility that defines highly high-risk nodes. While these methods can be useful, they may require augmentation to ensure that those nodes that “exploit loopholes in the system” are detected and eradicated. Coupled with trusted and untrusted nodes, random walks between nodes may be evaluated as hubs. On a website, links may traverse with a given probability of teleportation. The random walk may eventually reach trusted and untrusted nodes. This approach can enable the analysis of a broad system by utilizing trusted nodes, but it also avoids the problem of hackers attempting to become trusted nodes. In its application to anti-money laundering, trusted PageRank can be applied in a similar manner, where known "non-illegal" accounts are trusted and known illegal accounts are not. The graph can be traversed through inter-account transactions, inter-account relationships, and inter-account similarities. In addition, the links between accounts can be bidirectional and have quantities (e.g., in relation to transaction values). [ka]

[0119] The PageRank value for node acct is divided by the number of links L(v) from node v, set B acct The PageRank value may depend on each page v contained within the set (which includes all pages linked to node acct).

[0120] As illustrated by the embodiment in Figure 16, C is given a higher rank than E, even though E has more connections. However, C has a bidirectional link with B (a trusted node), which gives it further relevance. E's network is much weaker because none of its connected nodes have a clear trusted link with B.

[0121] In another embodiment, the traverse method may utilize two methods for characterizing nodes: depth and width. Depth traverse may analyze subnodes similar to those of branches and leaves on a tree. Only in the case of banking transactions, circular references are likely to be considered as termination depths with respect to a particular path. Using depth traverse, the number of connected nodes and the specific degree of account accessibility can be analyzed for those of falsely marked accounts. [ka]

[0122] Width traversal allows us to examine each level of complete isolation from the target node before moving to the next level. This approach may enable the analysis of all connected nodes, along with the specific degree of accessibility to the target node. [ka]

[0123] Traverse outputs can serve as features for machine learning models developed to characterize illegal activities.

[0124] In another embodiment, conventional clustering techniques can be applied to anti-money laundering to identify similarities between accounts that may indicate fraudulent activity, as shown in Figure 17. Clustering parameters can include account attributes, account transaction activity, or entities with which accounts are involved. Clustering can provide context for relationships between entities within a global sphere of visibility for banks. These clusters can be useful for machine learning classifiers as features to support the identification of clusters that are likely to be fraudulent, in addition to identifying emerging clusters as they form (e.g., as older ones become obsolete or as the risk increases, criminals begin to use different methods).

[0125] AML models can support the identification of a wide range of illegal activities, from money laundering to terrorist financing. In addition to machine learning models trained on historical cases of illegal activity, AML platforms can also provide a range of advanced analytics that support machine learning interpretability and systematize existing rules and business processes into near real-time streaming information. The analytics can be described using various classes based on the dominant issuance mode (e.g., placement, layering, foreign exchange, structured, suspicious activity, transaction, and account), as summarized in Figure 18.

[0126] Each analysis, like a transaction, can either employ a complex algorithm and apply it to the data source, or it can combine information from multiple systems to provide contextualized and nuanced output. In addition, analyses can be initiated for each account and updated with all new, relevant data attributes loaded into the AML platform, so that the AML platform becomes a single source for correlating data across systems, applying complex logic to each account, and supporting AML efforts.

[0127] Placement analysis may be designed to identify new accounts or large transactions that indicate the initiation of money laundering activity, such as large transactions, associated with new or modified accounts or suspicious account holders. Such analysis may include new transactions, suspicious account changes, suspicious identifications, and large transactions after account changes. "New transactions" may describe events for each transaction of a unique type on an account. "Suspicious account changes" may describe account changes that are closely associated with authorized entities or criminal / terrorist activity. "Suspicious identifications" may use NLP to flag suspicious or duplicate account holders. "Large transactions after account changes" may flag accounts or account holders with regard to suspicious activity when a new account holder or address is changed and large transactions occur within a given duration (e.g., 30 days).

[0128] AML models may include layering analysis designed to detect account transactions intended to spread money laundering activity by indicating the subsequent concealment of placement transactions. Such layering analysis may include unique types of transactions, transaction diversification, and persistent transactions. For example, unique types of transactions may include sets of transactions that occur within a short time period (e.g., about 1, 2, 3, 4, 5, 6, or 7 days, or about 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, or 12 months). Layering may indicate that criminals are trying to move money around and may include transactions such as ordering securities, issuing insurance policies, and moving money across different countries. Transaction diversification may include irregular transactions to similar businesses or account holders. Persistent transactions may include transactions that meet the size of a potential placement transaction.

[0129] An AML model may include foreign exchange analysis designed to identify transactions involving the movement of currencies and countries, and to flag suspicious transactions. Such foreign exchange analysis may include transactions with known terrorist associations, transactions without FOREX discrimination, suspicious transactions identified by SWIFT®, and inconsistent currency exchange transactions. “Transactions without FOREX discrimination” analysis may use existing terrorist databases and graphing techniques to link foreign exchange recipients to their degree of accessibility. “Transactions without FOREX discrimination” may describe a step of tracking fluctuations in FOREX rates between currencies and correlating them between transactions that occur. Because a legitimate account holder may send money across currencies, either regularly or very rarely (such as a remittance), such analysis may lead to the investigation of individuals waiting to move money when rates change favorably in a short period of time. “Suspicious transactions identified by SWIFT®” may describe transactions identified as suspicious using SWIFT®. An analysis of "inconsistent currency exchange" can track accounts that are moving money into different currencies without explanation.

[0130] AML models may include structured analysis designed to target types of transactions intended to go unnoticed by most financial reporting regulations. Such structured analysis may include steps to identify transactions that occur in multiple locations or that fall below certain limits. For example, structured analysis may identify structuring of transactions in multiple locations to circumvent federal reporting limits by using a number of unique transaction locations correlated with the consistency of the amount of dollars deposited or withdrawn. In another embodiment, structured analysis may identify the number of transactions that fall below the limits required to indicate identification by flagging accounts with a large number of transactions that fall below reporting limits but are within a certain threshold of those limits. Structured analysis may identify the number of transactions that fall below the identification limits by tracking the number of transactions that occur below the requirements for verifying identification, correlating the results across multiple locations, and identifying outliers.

[0131] An AML model may include a suspicious party analysis configured to target and flag transactions with recipients or senders who have known ties to authorized entities or criminal or terrorist databases. Such a suspicious party analysis may include transactions with suspicious entities, depositors with criminal records, transactions inconsistent with described occupations, and high-value transactions. "Transactions with suspicious entities" may describe a step of using graph techniques to establish some degree of access to suspicious entities, such as terrorist regimes or criminal ties. "Depositors with criminal records" may describe a step of flagging depositors who are not among the primary account holders but who are making transactions and also have criminal records or ties. "Transactions inconsistent with described occupations" may describe a step of comparing transaction sizes across occupations and flagging accounts that are clear outliers. "High-value transactions" may describe a step of flagging transactions at rates above normal for account types across a set of attributes.

[0132] AML models may include transaction analysis, which can be useful for identifying money launderers and terrorist investors. The placement, layering, and integration of such activities requires a precise and consistent set of transactions, which can be found using advanced analytics and machine learning. For example, transaction analysis may include a step of scrutinizing the cash ratio (e.g., the ratio of cash transactions to all transactions over a given time period) on a transaction-by-transaction and as a whole, since the cash ratio can provide contextual information about an account. In another embodiment, transaction analysis may include a step of identifying multiple deposits of similar size by tracking a highly consistent number of deposits that do not fall within a normal payment cycle. In yet another embodiment, transaction analysis may include a step of tracking transactions spatially and temporally by generating a multidimensional model of all transactions and identifying outliers to the number of transactions and unique locations (e.g., the number of transactions per unique location over a given time period). In yet another embodiment, transaction analysis may include a step of flagging various consistent uses of unconventional financial instruments by scrutinizing the use of financial instruments such as securities and life insurance using time-series tracking. In another embodiment, the transaction analysis may include a step of identifying unusual withdrawals, as large or consistent withdrawals may indicate illegal movement of funds.

[0133] An AML model may include account analysis, designed to help scrutinize the attributes and relationships of accounts and account holders and correlate criminal or suspicious activity based on historical events. Such account analysis may include multiple account holders at the same address, blacklists, unusual businesses, gaps in account data, and removed account information. "Multiple account holders at the same address" may explain an anomaly in the number of account holders (primary and secondary) associated with the same address. "Blacklists" may explain a step of correlating account holders and connected financial institutions with authorized entities or criminal or terrorist databases. "Unusual businesses" may explain a step of scrutinizing the use of business accounts and flagging suspicious activity. "Gaps in account data" may explain a step of scrutinizing accounts and identifying non-essential information that is absent and unusual for a given type of account. "Removed account information" may explain a step of providing contextualized information by correlating accounts with certain transactions or removed information. Computer system

[0134] This disclosure provides a computer system programmed to implement the method of this disclosure. Figure 19 shows a computer system 1901 programmed or otherwise configured to implement the method provided herein.

[0135] Computer system 1901 can adapt various aspects of this disclosure, such as (a) acquiring a dataset comprising multiple accounts, each of which accounts corresponds to an account holder among multiple account holders, and each of the multiple accounts comprises multiple account variables, each of which comprises a financial transaction; (b) applying a trained algorithm to the dataset to generate a money laundering risk score for each of the multiple account holders and one or more primary risk drivers associated with the money laundering risk score; and (c) identifying a subset of the multiple account holders for investigation based on the money laundering risk scores of at least the multiple account holders. Computer system 1901 may be a computer system located remotely from a user's electronic device or an electronic device. The electronic device may be a mobile electronic device.

[0136] Computer system 1901 includes a central processing unit (CPU, also referred to herein as "processor" and "computer processor") 1905, which may be a single-core or multi-core processor, or multiple processors for parallel processing. Computer system 1901 also includes memory or memory locations 1910 (e.g., random-access memory, read-only memory, flash memory), an electronic storage unit 1915 (e.g., a hard disk), a communication interface 1920 for communicating with one or more other systems (e.g., a network adapter), and peripheral devices 1925 such as a cache, other memory, data storage devices, and / or an electronic display adapter. The memory 1910, storage unit 1915, interface 1920, and peripheral devices 1925 communicate with the CPU 1905 through a communication bus (solid line), such as a motherboard. The storage unit 1915 may be a data storage unit (or data repository) for storing data. Computer system 1901 can be operationally coupled to a computer network ("network") 1930 using the communication interface 1920. Network 1930 may be the Internet, an intranet and / or an extranet, or an intranet and / or extranet that communicates with the Internet.

[0137] Network 1930 is, in some cases, a telecommunications and / or data network. Network 1930 may include one or more computer servers that enable distributed computing, such as cloud computing. For example, one or more computer servers may enable cloud computing via Network 1930 ("Cloud") to perform various aspects of the Analysis, Computation, and Generation of this Disclosure, such as: (a) acquiring a dataset having multiple accounts, each of which accounts corresponds to an account holder among multiple account holders, and each of the multiple accounts has multiple account variables, the multiple account variables having financial transactions; (b) applying a trained algorithm to the dataset to generate a money laundering risk score for each of the multiple account holders; and (c) identifying a subset of the multiple account holders for investigation based on the money laundering risk scores of at least the multiple account holders. Such cloud computing may be provided by a cloud computing platform such as, for example, Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform, IBM Cloud, and private clouds. Network 1930 can, in some cases, implement a peer-to-peer network that allows devices connected to computer system 1901 to behave as either clients or servers, using computer system 1901.

[0138] The CPU 1905 can execute a sequence of machine-readable instructions that may be embedded within a program or software. The instructions may be stored in a memory location such as memory 1910. The instructions can be directly directed to the CPU 1905, which can then be programmed or otherwise configured to implement the methods of this disclosure. Embodiments of the operations performed by the CPU 1905 may include fetching, decoding, executing, and writing back.

[0139] CPU1905 may be part of a circuit such as an integrated circuit. One or more other components of system 1901 may be included in the circuit. In some cases, the circuit is an application-specific integrated circuit (ASIC).

[0140] The storage unit 1915 can store files such as drivers, libraries, and saved programs. The storage unit 1915 can also store user data, such as user preferences and user programs. The computer system 1901 may include one or more additional data storage units located outside the computer system 1901, such as those located on a remote server that communicates with the computer system 1901 via an intranet or the internet.

[0141] Computer system 1901 can communicate with one or more remote computer systems through network 1930. For example, computer system 1901 can communicate with a user's remote computer system. Examples of remote computer systems include personal computers (e.g., portable PCs), slate or tablet PCs (e.g., Apple® iPad®, Samsung®) This includes Galaxy Tab, telephones, smartphones (e.g., Apple® iPhone®, Android-enabled devices, Blackberry®), or personal digital assistants. Users can access computer system 1901 via network 1930.

[0142] Methods described herein can be implemented using machine-executable code (e.g., a computer processor) stored on electronic storage locations of the computer system 1901, such as memory 1910 or electronic storage unit 1915. The machine-executable or machine-readable code can be provided in software form. During use, the code can be executed by the processor 1905. In some cases, the code can be read from the storage unit 1915 and stored on memory 1910 for quick access by the processor 1905. In some situations, the electronic storage unit 1915 can be omitted, and the machine-executable instructions are stored on memory 1910.

[0143] The code can be pre-compiled and configured for use with machines that have processors adapted to run the code, or it can be compiled during runtime. The code can be supplied in a programming language, which may be chosen to enable the code to be executed in a pre-compiled or as-compiled manner.

[0144] Aspects of the systems and methods provided herein, such as Computer System 1901, can be embodied in programming. Various aspects of the technology can typically be considered “products” or “manufactured goods” in the form of machine (or processor) executable code and / or associated data carried on or embodied on a certain type of machine-readable medium. Machine-executable code can be stored on electronic storage units such as memory (e.g., read-only memory, random-access memory, flash memory) or hard disks. The “storage” type medium can include any or all of the tangible memory of a computer, processor, or equivalent, or its associated modules such as various semiconductor memories, tape drives, disk drives, and equivalents, which can provide non-transient storage at any given time for software programming. All or part of the software may be communicated from time to time via the Internet or various other telecommunication networks. Such communication may enable, for example, the loading of software from one computer or processor to another, for example, from a management server or host computer to an application server computer platform. Therefore, other types of media that may contain software elements include optical, electrical, and electromagnetic waves, used across physical interfaces between local devices, through wired and optical fixed networks, and via various air links. Physical elements that carry such waves, such as wired or wireless links, optical links, or equivalents, may also be considered media that contain software. Unless limited to non-transient tangible “storage” media as used herein, the terms computer or machine “readable media,” etc., refer to any medium involved in providing instructions to a processor for execution.

[0145] Therefore, machine-readable media such as computer executable code may take many forms, but are not limited to, tangible storage media, carrier media, or physical transmission media. Non-volatile storage media include optical or magnetic disks, such as any storage device in any computer or equivalent, which may be used to implement, for example, a database as shown in the drawings. Volatile storage media include dynamic memory, such as the main memory of such a computer platform. Tangible transmission media include copper wires and optical fibers, including coaxial cables, i.e., wires that form buses in computer systems. Carrier media may take the form of electrical or electromagnetic signals, or acoustic or optical waves, such as those generated between radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tapes, any other magnetic media, CD-ROMs, DVDs or DVD-ROMs, any other optical media, punch cards, paper tapes, any other physical storage media with perforation patterns, RAM, ROMs, PROMs and EPROMs, FLASH®-EPROMs, any other memory chips or cartridges, carriers for transferring data or instructions, cables or links for transferring such carriers, or any other media from which a computer can read programming code and / or data. Many of these forms of computer-readable media may be involved in transporting one or more sequences of one or more instructions to a processor for execution.

[0146] The computer system 1901 includes, or can communicate with, an electronic display 1935 having a user interface (UI) 1940. Embodiments of the user interface (UI) include, but are not limited to, graphical user interfaces (GUIs) and web-based user interfaces. For example, the computer system may include a web-based dashboard (e.g., a GUI) configured to display, for example, a Bill of Materials (BOM) to the user.

[0147] The method and system of this disclosure can be implemented using one or more algorithms. The algorithms can be implemented using software in response to execution by the central processing unit 1905. For example, the algorithm can (a) acquire a dataset having multiple accounts, each of which corresponds to an account holder among multiple account holders, each of which has multiple account variables, each account variable having financial transactions, (b) apply a trained algorithm to the dataset to generate a money laundering risk score for each of the multiple account holders, and (c) identify a subset of the multiple account holders for investigation based on the money laundering risk scores of at least several account holders.

[0148] This disclosure is not limited to the algorithms disclosed herein. It should be understood that other algorithms compatible with the embodiments described may also be considered.

[0149] The description is given in relation to specific embodiments, but these specific embodiments are merely illustrative and not restrictive. Concepts illustrated in the embodiments may apply to other embodiments and implementations.

[0150] Preferred embodiments of the present invention are shown and described herein, but it will be apparent to those skilled in the art that such embodiments are provided only as examples. The present invention is not intended to be limited by the specific examples provided herein. The present invention is described with reference to the foregoing specification, but the description and illustration of embodiments herein are not meant to be constrained. Numerous variations, modifications, and substitutions will be recalled herein by those skilled in the art without departing from the present invention. Furthermore, it should be understood that all aspects of the present invention are not limited to the specific descriptions, configurations, or relative proportions described herein, depending on various conditions and variables. It should be understood that various alternatives to the embodiments of the present invention described herein may be adopted when practicing the present invention. Thus, it is also assumed that the present invention will cover any such alternatives, modifications, variations, or equivalents. The following claims define the scope of the present invention, and methods and structures within the scope of these claims, as well as their equivalents, are intended to be covered thereby.

Claims

[Claim 1] The invention described herein.

Images