How Much Fraud Is Your Bot Vendor Missing? One Real-Money Gaming Platform Found Out the Hard Way

A rapidly growing real-money online gaming platform wasn’t taking security lightly. With millions in real-money transactions flowing through their mobile apps daily, they had built what appeared to be a fortress:

Layer 1: CDN-based bot management solution

Layer 2: A bot management vendor (we will call them “Vendor X”) deployed in full protection mode.

Layer 3: Manual fraud review by their security team, supplementing automated detection with custom rules.

They had three independent defense systems with real-time blocking enabled, and yet, fraud was slipping through.

When your payment processor alerts you to a security issue

The first sign that something was wrong came from an unexpected source: their payment processor, which flagged 1,000+ accounts for account takeover—meaning the accounts had been accessed by someone other than the true owner.

The customer’s investigation found that these accounts had not been surfaced by either existing solution before the payment processor alert.

The fraud wasn’t subtle. Once they dug deeper, they found:

• Credential stuffing attacks using residential proxy networks
• Account takeover and payment fraud 
• Promotional abuse rings exploiting signup bonuses and referral credits
• Data scraping operations harvesting proprietary platform data for competitive arbitrage

Their security team was catching fraud manually, building custom rules to compensate for gaps. But this wasn’t scalable. And it raised an uncomfortable question: why are we still facing this issue?

The proof of concept

When the platform agreed to evaluate DataDome, they couldn’t risk disrupting their production security stack. So they positioned DataDome after both their CDN bot management solution and Vendor X. 

This meant DataDome only analyzed approximately 75% of traffic that both the CDN solution and Vendor X had already allowed through.

The security team ran this configuration for two weeks. The goal: determine whether DataDome could identify suspicious activity after existing controls had already cleared the traffic.

The results: 27–37x more fraud detected by DataDome

Registration fraud detection

DataDome caught nearly 2x as much fraud as Vendor X and manual review combined, despite only seeing the traffic Vendor X had approved.

Deposit fraud detection

DataDome identified 27x more fraudulent deposit attempts than Vendor X, from a fraction of the total traffic.

Withdrawal fraud detection

DataDome caught 37x more fraudulent withdrawal attempts than Vendor X.

What was getting through

The security team’s logs showed sophisticated, multi-stage fraud operations that had been allowed through by Vendor X. Here is what DataDome caught and how.

1. Residential proxy credential stuffing

Fraudsters used residential proxy networks to rotate through thousands of stolen credentials. Residential IPs look like legitimate users—real devices, real ISPs, no prior fraud history—making them difficult to catch with IP reputation alone.

How DataDome caught it: Behavioral analysis. Even with rotating IPs, the attack pattern was consistent: immediate login attempts after app launch with no prior browsing, identical device fingerprints appearing across different IPs, and high velocity across IP subnets. DataDome’s AI models detected the behavioral intent behind the pattern, not just the source of the request.

2. Device farm promotional abuse

Coordinated fraud rings used mobile device brands strongly associated with device farms to create accounts with referral codes, place orders using free promotional credits, deposit the minimum required amount, and immediately withdraw, cashing out bonuses along with the deposit.

The security team noted that fraud operators had become highly effective at exploiting promotional systems, and expressed frustration that patterns they considered obvious in their own logs were not being surfaced by their incumbent vendor.

How DataDome caught it: Custom field integration. DataDome ingested device manufacturer data the customer was already collecting and deployed detection rules matching their own fraud intelligence: flagging device brands strongly associated with device farms, cross-referencing with referral code abuse patterns, and identifying rapid deposit-to-withdrawal sequences within hours of account creation.

3. Registration bots bypassing validation

Automated account creation was hitting registration endpoints directly, skipping mandatory validation steps that legitimate users complete through the app.

How DataDome caught it: The customer provided their legitimate user journey. DataDome’s Galileo Threat Research team built rules to enforce it: challenging account creation that skipped required validation steps or completed registration in an implausibly short time frame.

4. Payment fraud with location spoofing

Fraudsters used one device to pass geolocation verification, then passed the approved authentication token to a different device for payment processing—a different device ID, different IP address, and a different session entirely.

How DataDome caught it: Based on the customer’s observations, device IDs being sent to Vendor X as a custom parameter did not appear to be used for correlation. DataDome ingested the same data and flagged mismatches between the device used for geolocation verification and the device used for payment. 

5. Data scraping for competitive intelligence

400,000+ requests targeted proprietary platform data with patterns consistent with automated scraping: cookieless requests, malformed and generic request headers, and abnormal pagination behavior. These were consistent with harvesting operations collecting data for competitive analysis.

How DataDome caught it: DataDome deployed rules targeting cookieless requests on sensitive data endpoints, malformed Accept-Language values, generic Accept: */* headers, and regional language header patterns with abnormal timing. 

DataDome’s approach: Behavioral AI and proactive support

Across all five attack types, the common thread was the same. Based on the customer’s observations, the existing controls appeared to analyze requests in isolation, relying largely on known signatures and reputation signals. Sophisticated attackers had already learned to evade these.

DataDome focused on behavioral intent—learning what legitimate user journeys looked like and flagging deviations, correlating signals across devices and sessions, and operationalizing the customer’s own fraud intelligence into automated detection rules.

Beyond detection, the support model differed significantly. In the customer’s experience, the incumbent vendor’s support was reactive: the customer identified fraud, then submitted tickets. DataDome assigned a dedicated threat research analyst for the duration of the POC, actively hunting threats and deploying custom rules, often on the same day. 

What this means for your platform

This platform didn’t have a bad security strategy. They had three layers of protection, a dedicated fraud review team, and a vendor they were paying to keep them safe. The problem wasn’t effort—it was that one of those layers wasn’t performing the way they assumed.

The 27–37x detection gap only became visible because they were willing to ask an uncomfortable question: what if our current vendor is missing something?

If you’re dealing with millions of real-time transactions and you’ve ever had fraud flagged by your payment processor before your bot vendor caught it—or found your team writing manual rules to cover gaps that should already be handled—it’s worth asking the same question.

We offer a no-disruption proof of concept, the same one this platform ran, where DataDome monitors traffic that your existing solution has already approved. You don’t have to change anything to see what’s getting through.

Reach out today for a demo, and our team will be happy to run a POC against your current vendor.