Case study
Fraud is already inside your revenue numbers
The full write-up: the patterns found in exports the studio already had, and the two limits on what it proves.
← All case studies
Also as a PDF · 162 KB
Why this is a measurement problem
Fraudulent revenue sits inside reported bookings, and the accounts committing it sit inside the cohorts being modelled. Every forecast built on top inherits both.
What the exports contained
~8%
of one title's bookings were fraud-suspect
797 vs 1
caught by their rules, versus flagged in-game
- One payment receipt reused across five separate accounts
- 90 purchases from a single account within one hour
- A currency balance of a billion where the game's own ceiling is around twenty thousand, matching the maximum a common mod menu writes
Payment fraud appeared in one title and currency manipulation in the other. Separate problems, separate fixes.
The rules already existed
The studio had already written the detection logic, and it fires. Nothing downstream was acting on it.
Two limits on this result
Fraud-suspect is not confirmed loss. It means an account matches a known signature. Treat the figures as an upper bound on exposure. Confirming any individual case requires the studio's own payment records.
This flags, it does not block. The audit was retrospective, run across exports after the fact. Preventing a transaction before it clears is a different capability with different latency requirements.
This flags, it does not block. The audit was retrospective, run across exports after the fact. Preventing a transaction before it clears is a different capability with different latency requirements.
Client identifying details removed. Figures are those cleared for external use; where a result is not statistically powered it is described as such rather than quoted. [email protected]
← All case studies