Jonas ForshellSenior Product Owner
jonas@jforshell.seEmail me

The fraud tool nobody had capacity to build

Analysts were checking accounts one at a time, while the signals they needed were already in the data. No developers were free to build against them, so I designed the investigation view and specified the search logic, and a QlikView specialist implemented it.

Context
Gaming platform, payments and risk operations
Role
Product Owner and Operations Manager
Period
2015 to 2018
Built with
QlikView, on existing data

The short version

Result
An estimated 40% less player-account fraud and around 50 support hours a month freed, at roughly a tenth of the projected build cost.
What I did
Designed a QlikView investigation view on data we already had and specified its search logic. A QlikView specialist built it.
The call
I designed it on existing data for a QlikView specialist to build, instead of waiting for developer time that wasn't coming.

What changed

Before
per account

Usernames, emails and payment details sat in different places, and analysts held the pattern in their heads one account at a time.

After
per ring

Analysts could search usernames, email patterns, IPs, registration and payment data together in one place, so accounts working as a group finally looked like one. Several of those groups ran to hundreds of accounts, the largest past a thousand.

Worth
after
40%
less player-account fraud
around 50 support hours a month freed
King · 2015 to 2018
WasUsernamesEmailsIPsPaymentsfour places, held in the analyst's head, one account at a time
NowUsernames · emails · IPs · registration · paymentsOne searcha group of linked accounts looks like one
Was
UsernamesEmailsIPsPayments
four places, held in the analyst's head, one account at a time
Now
All five, togetherOne search
a group of linked accounts looks like one
The data already existed.Nothing new was collected, and it didn't need a development project.Nothing new was collected.

The signals were already in the data

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

The signals were spread across accounts, payment methods, registration details and support history, and nobody could look at them together. Investigations were slow and fragmented. They ate support and review time, and two people could still reach different conclusions about the same account.

What I did

There was no capacity for a back office build, and there wouldn't be for a long time. So I designed a QlikView investigation solution on the data that already existed and specified the search logic behind it. A QlikView specialist implemented the report, because I didn't 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

What changed

Finding related fraudulent accounts got much faster. The team could also step in earlier and refund suspicious stolen-card transactions before they became chargebacks, which took away 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 my own estimates from being close to the work. None of them was audited.

How I got to it

Fourteen years at King

I'd been working this problem by hand since 2008 and leading the team on it from 2013, so by the time I was in a position to do something about it, I knew 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.

What it kept finding

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