Community Blog
Get the latest updates on the Splunk Community, including member experiences, product education, events, and more!

Detecting Cross-Channel Fraud with Splunk

AqibKazi
Splunk Employee
Splunk Employee

This article is the final installment in our three-part series exploring fraud detection techniques using Splunk. In our first article, we examined new account fraud through email manipulation. The second part focused on account takeover via brute force attacks. This third installment explores cross-channel fraud detection.

As part of my research into fraud detection, I recently participated in a fraud prevention workshop hosted by a regional banking consortium. During one session, a Fraud Operations Director shared a case where they uncovered a fraud scheme that had evaded detection for weeks, until they implemented  Splunk Enterprise Security  , along with the Splunk App for Fraud Analytics .

Understanding Cross-Channel Fraud

Cross-channel fraud represents a major challenge for financial institutions. Unlike single-channel attacks, cross-channel fraud spreads activity across multiple systems to stay below detection thresholds on any individual channel.

"Fraudsters know that most banks use siloed detection systems that don't talk to each other," the director explained. "By spreading activity across channels, initiating an account online, making changes via the call center, and conducting transactions through mobile they can avoid triggering alerts in any single system."

This siloed approach creates blind spots. Each channel might observe activity that seems merely unusual rather than suspicious, while the complete picture reveals fraudulent behavior.

Traditional fraud tools examine each channel separately. For example, web applications, mobile apps, call centers, branch transactions each have their own thresholds and rules. Fraudsters exploit these gaps, orchestrating activities to remain below alert thresholds in each system.

Fraud Pattern

The case began when the fraud team was reviewing high-risk accounts using the Fraud Posture dashboard. They noticed a user, acct_user5782, with a risk score of 149. What made this interesting was that the risk points came from multiple channels, both new account data and web traffic.

"What caught our attention wasn't the high score alone, but that it came from multiple channels," the director noted. "When signals light up across different systems, it's usually worth investigating."

AqibKazi_0-1746721996266.png

 

The risk score was triggered by multiple rules:

  • Shared password across accounts
  • Logins from multiple IP addresses
  • Logins from widely separated locations
  • Suspicious account creation patterns

Each signal individually might not warrant investigation in traditional systems, but their combination across channels pointed to coordinated fraud.

Investigation Process

The team began by examining the individual risk attributions to understand which rules had triggered.

The investigation revealed five different risk rules contributing to the event—some related to account opening patterns (marked as NewAcct) and others tied to login and web behavior.

"One rule caught our immediate attention," the director explained. "The shared password rule. Our site requires complex passwords, making it unlikely that multiple new users would create identical complex passwords in a short timeframe."

AqibKazi_1-1746721996268.png

 

To dig deeper, they used the Customer Accounts Analysis dashboard to search for other accounts using the same password as acct_user5782.

The search found another account, acct_user6417, using the exact same complex password. These accounts had different names, emails, and phone numbers, but shared this connection.

"Finding the same complex password across multiple accounts was a red flag," the director said. "With our password requirements, the chance of this happening randomly is nearly zero."

By examining multiple data sources, the team uncovered a pattern that would have remained hidden in their previous system. The accounts were created days apart, used different contact information, and showed distinct behavior when viewed in isolation, yet the cross-channel analysis revealed their connection.

Splunk Enables Cross-Channel Detection

The bank's cross-channel fraud detection relies on Splunk's ability to ingest, normalize, and correlate data from multiple sources.

  1. Data Integration and Normalization

The bank configured Splunk to ingest data from all customer-facing systems: web applications, mobile apps, call center logs, branch transactions, and authentication systems.

They implemented data normalization to ensure information from different systems could be compared. User identifiers, timestamps, IP addresses, and device information all needed consistent formatting to enable cross-channel correlation.

  1. Entity Resolution

A key component was entity resolution—recognizing when different identifiers across systems likely refer to the same entity (person, device, or location). This includes:

  • Normalizing email addresses to detect variations
  • Associating multiple phone numbers with potential users
  • Recognizing related IP addresses
  • Identifying device fingerprints across channels
  • Detecting shared attributes across seemingly unrelated accounts

By establishing these relationships, patterns of coordinated activity become visible even when the fraudster uses different identifiers across channels.

  1. Risk-Based Scoring with Cross-Channel Correlation

The bank implemented a risk scoring system that assigns weights to various signals based on their correlation with known fraud. The enhancement was adding cross-channel correlation rules that look for patterns spanning multiple systems.

These rules examine combinations of activities that, while individually normal, become suspicious when observed together:

  • Account creation followed by unusual login patterns
  • Address changes in one channel followed by transaction pattern changes in another
  • Multiple accounts sharing unusual elements
  • Impossible travel scenarios across channels
  1. Adaptive Thresholds

To reduce false positives while maintaining detection rates, the bank implemented adaptive thresholds that adjust based on historical patterns. Machine learning models analyze patterns of legitimate and fraudulent activity to refine these thresholds.

These models are valuable for cross-channel detection because they can identify subtle correlation patterns that would be difficult to code into rule-based systems.

Results

The implementation of cross-channel fraud detection has shown results. In the first three months, the bank identified 37 instances of coordinated fraud that would have likely gone undetected with their previous approach.

"In this specific case, we estimated the potential savings at around $250,000," the director explained. "The fraudster had already started establishing credit lines across the compromised accounts. Without cross-channel detection, we might not have caught this until after the funds were gone."

The team noted several benefits:

  1. Reduced false positives: By considering patterns across channels, they maintain a higher detection rate while decreasing false positives.
  2. Earlier detection: Fraudulent activity is identified earlier, often before significant financial damage occurs.
  3. Improved efficiency: Fraud analysts spend less time gathering data from multiple systems, as Splunk presents a unified view of cross-channel activity.

Strategic Changes

This implementation changed how the bank approaches fraud detection. Rather than thinking in channel-specific silos, they've adopted a holistic perspective that better reflects how customers and fraudsters interact with their systems.

"We used to have separate teams monitoring different channels, each with their own tools," the director shared. "Now we have a unified view and a consistent methodology across all channels."

The success has prompted the bank to expand cross-channel analytics to other areas:

  • Customer experience: The same cross-channel visibility helps identify friction points across different interaction channels.
  • Operational efficiency: Finding process breakdowns where customers need to switch channels to resolve issues.

Looking ahead, the team is exploring several enhancements:

  1. Additional data sources: Expanding to include third-party data, such as consortium data on known fraud patterns.
  2. Behavioral biometrics: Adding behavioral patterns like typing cadence and mouse movements to further distinguish between legitimate users and impostors.
  3. Real-time intervention: Moving from detection to prevention by implementing real-time decision engines.

Conclusion

Cross-channel fraud detection represents the next evolution in financial crime prevention. As fraudsters develop techniques that exploit siloed security approaches, institutions must adopt detection methods that provide a comprehensive view of customer activity.

By using  Splunk Enterprise Security  along with the Splunk App for Fraud Analytics to integrate data across channels, establish relationships between entities, and apply risk-based scoring with cross-channel correlation, this bank has enhanced their fraud detection capabilities.

For financial institutions still relying on channel-specific fraud detection, the message is clear: Effective fraud prevention requires breaking down data silos between channels and implementing unified analytics that can identify patterns that emerge only when seeing the complete picture.

This concludes our three-part series on fraud detection techniques using Splunk. We've explored new account fraud through email manipulation, account takeover via brute force attacks, and cross-channel fraud detection. We hope these real-world examples provide insights into how modern analytics can help financial institutions stay ahead of evolving fraud threats.

Get Updates on the Splunk Community!

Aligning Observability Costs with Business Value: Practical Strategies

 Join us for an engaging Tech Talk on Aligning Observability Costs with Business Value: Practical ...

Mastering Data Pipelines: Unlocking Value with Splunk

 In today's AI-driven world, organizations must balance the challenges of managing the explosion of data with ...

Splunk Up Your Game: Why It's Time to Embrace Python 3.9+ and OpenSSL 3.0

Did you know that for Splunk Enterprise 9.4, Python 3.9 is the default interpreter? This shift is not just a ...