← All articles

797 accounts failed the studio’s own fraud rules. One carried a flag in-game.

The rules were already written, and they fire. Nothing downstream acted on them.

Fraud reaches your revenue reporting before it reaches your security review. The bookings include it, the cohorts you model include the accounts committing it, and anything you forecast on top inherits both.

We audited the analytics exports two live titles were already producing. No software development kit (SDK), no new tracking, nothing the studio did not already have.

~8%

of one title’s bookings in the window were fraud-suspect

The patterns were not subtle:

  • one payment receipt reused across five separate accounts
  • 90 purchases from a single account inside one hour
  • a currency balance of a billion where the game’s own ceiling is around twenty thousand, which is what a common mod menu writes

Payment fraud turned up in one title and currency manipulation in the other. Separate problems, separate fixes.

The rules already existed

797 vs 1

accounts caught by the studio’s own rules, against the number carrying a flag in-game

The detection logic was already written, and it fires. Nothing downstream acted on it. That is the cheapest win in LiveOps, sitting untaken.

Where this stops

Fraud-suspect is not confirmed loss. It means an account matches a known signature. Treat these figures as an upper bound on exposure. Confirming any individual case needs the studio’s own payment records.

This flags, it does not block. The audit was retrospective, run over exports after the fact. Stopping a transaction before it clears is a different capability with different latency requirements, and we are not going to describe one as the other.

What it does mean is that the number at the top of the revenue report is not the number, the cohorts underneath it are contaminated, and both were visible in data the studio was already collecting.

← All articles