The fraud tool nobody had capacity to build

The short version

The problem

Analysts checked accounts one at a time while the fraud signals sat spread across the data. Some of the groups they were missing ran to hundreds of accounts, and the largest to over a thousand.

What I did

Designed the investigation view and specified the search logic. A QlikView specialist built it.

What it was worth

An estimated 40% less player-account fraud, and around 50 support hours a month freed. Finding a group earlier meant closing it before more payouts went out, and refunding stolen-card transactions before they came back as costlier chargebacks.

The call

Built it on existing data with one specialist instead of waiting for developer resources that were never coming.

What changed

King's payment platform sat underneath a large volume of transactions across several markets, so a fraud decision had both revenue and support consequences.

The signals existed. They were spread across accounts, payment methods, registration details and support history. What was missing was a way to look at them together. Investigation work was fragmented and slower than it needed to be, it ate support time and internal review time, and it still left room for two people to reach different conclusions about the same account.

What I actually did

I did not open a discovery track or ask for a back-office build. There was no capacity for one and there would not be for a long time.

I designed a QlikView investigation solution on top of the data that already existed and specified the search logic behind it. A QlikView specialist implemented the report, because I did not have build access. Then I sat with the investigators while they used it.

Investigators could search and connect signals across accounts.

• IP addresses
• Email address patterns
• Usernames and username patterns
• Payment information
• Registration and account details

It was not the final state of the system. It was a working investigation capability at the moment the team needed one, which is a different and often more useful thing.

What changed

Finding related fraudulent accounts became much faster. The team could also intervene earlier, refunding suspicious stolen-card transactions before they turned into chargebacks, which removed some of the incentive for repeat fraud.

• Player-account fraud down by an estimated 40%
• An estimated 50 support hours a month freed, by stopping suspicious accounts before they generated further security reviews, payout checks and related handling
• Delivered at an estimated 10% of the projected cost of building the same capability into the administration system

These are informed estimates from close operational involvement, not audited measurements.

Nobody hands a Product Owner a fraud investigation problem on day one. I had been working this one by hand since 2008 and leading the team on it from 2013. By the time I could build something against it, I knew exactly what it needed to do.

1. June 2008
   Joined King on the payment support desk, where every fraud and payment decision landed as a case for someone to work through.
2. February 2013
   Risk and Fraud Lead, seeing the same patterns from the other side of the escalation.
3. November 2014
   Risk and Fraud Manager, leading a small second line payments and risk team.
4. June 2015
   Product Owner and Operations Manager for royalgames.com, with the fraud problem now inside my own scope and no capacity to build against it.
5. July 2018
   Moved to Product Owner for Payments. The fraud titles had gone, the investigation process stayed.

Fraud and risk stayed in my scope after this, through the payments role and after the formal fraud titles had gone. Over that time the investigation work surfaced several organised fraud groups, each involving hundreds of connected accounts. The largest ran to more than a thousand linked accounts.

That is the argument for the tool, rather than the percentage. A person holding patterns in their head does not find a ring of a thousand accounts.