Using modern methods of detecting financial crime
Financial crime is a superset of fraud that includes fraud, account abuse, money laundering, embezzlement, sanctions violations, and a host of other crimes. Each of these by itself may not be obvious fraud, but collectively they lead to the general category of financial crime. Your company wants to improve its financial crime detection capabilities, so you need incremental steps for achieving better detection posture.
This article is part of the Use Case Explorer for Splunk Platform, which is designed to help you identify and implement prescriptive use cases that drive incremental business value. In the Use Case Explorer, this article is part of Financial Services and Insurance.
How to use Splunk software for this use case
With Splunk software, you can ingest machine generated data into a system that indexes all data in real-time and analyze the data using your rules. Doing so allows you to create reports for trending, anomalies, and pattern detection. Furthermore, since it’s impossible for humans to continuously watch dashboards, you can schedule your searches in your Splunk deployment and have them deliver results as actionable alerts.
The general process
- Understand your use cases. Begin with two basic questions: what problems do you see, and who does it matter to if the problems are solved? Then, when you create a list of use cases, you can enumerate them, categorize them, and prioritize them.
- Define your rules. Every business has its own set of rules for thresholds and possibly even secret algorithms to monitor behavior. Independent of product choice, spend some time defining rules for what constitutes fraud. You might start with your own knowledge of the business and then move onto your industry’s best practices that could be found through online reference or outside consultants.
- Define the data behind the rules. Rules are algorithms, but they do nothing without data. You need to know where data comes from and whether it can be accessed via computer systems to be processed in rules. Transaction logs, either buried in log files or hidden in databases, are a good start. You’ll also want to enrich the data with more meaning to make it easier to understand. For instance, if data says account number xxxx-9999 purchased this item in city X for Y dollars, then you may want to have your system enrich this data at search time with user names, home address, and phone number to provide some context, both for geographic patterns and for contacting the user directly from the event data. The enriched data may come from a database or configuration management database.
- Ingest the data and then search, report, and alert on it. The next few sections in this article discuss some specific ways to do so.
SPL Rule —> alert
Combine your rules with AND (which is the implied Boolean operator) and use WHERE clauses to filter out exceptions and thresholds. More complex searches can help differentiate rules and reduce alerts that fire on unimportant issues. With fewer alerts, you can triage and respond faster.
Any one notable event rule might not be nefarious, but the sum of the scores for all rules leads to a total score that gives confidence that the user, customer, account ID, institution, or entity has been compromised. This accumulated value of all the risk scores can enhance an analyst's ability to triage events so that a single issue does not create a bunch of false positives to investigate. It also allows the analysts to work on the highest scoring indicators first for a use case.
To implement this approach, add a weighted risk score to each rule. Then, turn each rule into a saved search in the Splunk platform that can be executed all at once in order to return a single, user-defined risk score per search that can be multiplied by a weight for importance. The grouping of all rules can be done by username, customer, account ID, institution, or whatever entity is a common way to identify the account.
In SPL, this could look like the following:
index=transactions |fields username | dedup username | join type=left username [savedsearch RiskScore_ConnectionFromRiskyCountry] | join type=left username [savedsearch RiskScore_ExcessiveLogins] | join type=left username [savedsearch RiskScore_AccountPasswordChange] | eval RiskScore_ConnectionFromRiskyCountry=RiskScore_ConnectionFromRiskyCountry*0.75 | eval RiskScore_ExcessiveLogins=RiskScore_ExcessiveLogins*1.5 | eval RiskScore_AccuntPasswordChange=RiskScore_AccountPasswordChange*.90 | eval Total_Risk=RiskScore_ConnectionFromRiskyCountry+RiskScore_AccuntPasswordChange+RiskScore_AccountPasswordChange | table Username, Total_Risk
- Use fillnull to put 0 into risk scores, if nothing returns.
- Use lookups to avoid hard coded weights.
- Use machine learning to update weights.
Tweak this approach as needed and architect it properly for your use case domain. For example, notice that the search above uses a left outer join to do the grouping. Rather than a join, you can use a series of appends to concatenate the results of the saved searches, and then use the Splunk stats command to group by username. This can lead to performance improvement.
Another performance improvement is to use summary indexes for a summary that is going to be looked back in time (i.e., money laundering use cases) or to use Splunk data models and data model acceleration for faster retrieval of data.
One final way to improve this search is to have each saved search run on a scattered schedule (not all at once, but with a few minute gaps) because account takeover is not a near real-time event until it happens. You can store the risk score for each username in a new summary risk index using the collect command. The Splunk platform can then run another scheduled search that uses an N-minute window with the streamstats command to group all risk scores by username from the risk index and fire an alert if the score is above a threshold.
Although the ideas above are better than using singular rules, you can improve your process even further. What if there was a framework that does what was described above, but also handles:
- case management
- sequencing of events
- management of alerts
- context of what the user did (not just the Risk Score, but other important information such what country was used in the wire transfer and the amount)
- mapping of rules to security frameworks such as MITRE ATT&CK and Cyber Kill Chain
- serving as a platform for collecting notable events
This is called Risk Based Alerting (RBA) in Splunk Enterprise Security, which is the next level of sophistication in detecting financial crime. RBA ships out of the box with Splunk Enterprise Security and all these features come with it. What this does is collect notable events within a risk index, apply some meta-data context, and allow for alerts when alert thresholds are met. The alerts themselves can be sent to a SOAR product such as Splunk SOAR to create automated playbooks to respond to the situation. A response could be to block the inbound IP, lock out the account, notify the account holder, and notify all involved company parties to analyze the case.
To understand RBA, refer to these articles:
Since account takeover and money laundering have been mentioned a few times now, the question of how one knows who is the leader of a fraud ring comes to mind. The stats command in the Splunk platform can help you find out who conducts the most transactions to the most number of accounts in a time period.
|stats sum(amount) AS amount count BY From_Account, To_Account |sort - count
This looks easy, but it does not give us a graph where A connects to B and B connects to C and so forth. Also, a number for connections may miss many edge cases when there are a million accounts and a few million transactions involved.
You can use directed graphs to find possible connections between accounts or users using a technique called eigenvector centrality to find the most connected nodes that may lead to fraud ring leaders. This is highlighted in this picture below with the large dot in the bottom center of the picture.
The search can still be used to find from and to accounts grouped by sender and receiver, but the graph is what does the work. It uses an app called 3D Network Topology Visualization that can be freely downloaded from Splunkbase to implement the use case. For details on how this is done for fraud ring detection, please download the free e-book, Bringing the Future Forward, and read the chapter on detecting financial crime using network topology graphs (written by Splunk Principal Architect Philipp Drieger).
The advantages of using any time series data at scale and quickly pivoting with rules, risk scores, and risk-based alerting should be a welcome addition to any organization’s financial crime detection posture, regardless of industry.
In addition, the Splunk Essentials for the Financial Services Industry app helps you automate the searches to detect financial crime. The app also provides more insight on how searches can be applied in your environment, how they work, the difficulty level, and what data can be valuable to run them successfully. You might be interested in:
Finally, the Splunk App for Fraud Analytics provides a number of other fraud detection solutions for financial services such as account takeover and new account abuse.
Still need help with this use case? Most customers have OnDemand Services per their license support plan. Engage the ODS team at OnDemand-Inquires@splunk.