In this series of three posts, we will be
looking at what it took to create a fraud detection and prevention
system on the ServiceNow platform for Virgin Trains, as demonstrated
during the NowForum 2018 keynote. We will explore the fundamentals of
such a system, the requirements that lead to it being built the way it
was, the exciting technologies that enabled us to create the final
solution and finally what the future holds.
To understand why such
a system is required, we need first to discern what fraud looks like on
the UK rail network. Now, because this isn’t an instructional piece on
‘how to commit fraud’, we won’t be going into too much detail here, but
we can tell you that the most prevalent form of fraudulent activity
exploits the Delay Repay scheme that all TOCs (Train Operating
Companies) are required to provide under regulations set out by National
Rail (Section 32/33 of National Rail Conditions of Travel).
There are two main categories of people committing fraud, there are
organised criminal’s and opportunistic consumers. These two groups are
generally different when it comes to detecting that fraud is being
committed, and importantly in the case of organised criminals, the
methods used make them a constantly moving target.
Now to the question ’how much fraud is being committed?’,
and this is where we move into the realms of assumption, because the
truth is nobody knows. Latest estimates put this figure at anywhere
between 10% – 30% of compensation paid out. To put this in perspective,
in the 7 months since Virgin Trains went live with CSM on the ServiceNow
platform, they have paid out a total of £10 million in compensation,
this put’s that figure at somewhere between £1.7 – £5.1 million a year, a
staggering statistic.
Now that we have a small understanding of
the problem at hand, we can start to look at the journey from Post-It
note to production. In late July of 2018, we met with two members of the
Virgin Trains compliance team at London Euston station, the objective
of the meeting was to come away with an understanding of how fraud was
being committed, and ultimately how we could use the data we have in
platform to detect and prevent fraud in the future. Before long, this
meeting resulted in a whiteboard filled with Post-It notes, which were
repeatedly being moved from one area to another, reiterating the case
that fraudulent activity is a constantly moving target. But the one
thing that was very clear is that we needed data, and lots of it.
Luckily enough, something we have an abundance of on the ServiceNow
platform.
At this stage we now understood the key concepts that we would need to employ when developing a solution on the platform:
- Fraudulent
activity, especially in the case of organised crime, is a moving
target. A solution would need to be built that didn’t require frequent
developer intervention.
- There is a need to analyse a consumer’s case/behaviour in singularity, as well as in context with their historical cases.
- Data was of the utmost importance, and not all data was immediately available on the platform.
- Data needed to be displayed in easily digestible forms, not currently native to the platform.
With
all of the above in mind, we set about developing the solution. There
are a number of ways we could have tackled this, we could have kept it
as simple as just using business rules, but in reality, that’s not a
simple solution at all, and certainly wouldn’t be friendly to
non-developers. Weighing up various possible solutions, we settled on
creating a fraud threshold framework. The important part to note here is
that we are building a framework, by using this methodology we are
creating an infinitely extensible solution that can abstract the
developer level configuration away from those that need to run and
adjust the system on a day to day basis. The following image aims to
show how this works. For simplicity, not all stages of the process have
been shown, but it gives an idea.
As
you can see, most of the activities involved in the process above are
executed away from the user’s (CSM Agent’s) session. This decision was
made due to the heavy processing that some of the Fraud Threshold
Definitions contain, by just running trigger conditions against the
user’s session, the impact to the user is minimal, in fact, it is
negligible. We achieve this by using the ServiceNow event queue.
In the next post
we will be looking more in depth at some of the more custom solutions
we had to develop to meet the requirements of the project, this will
include the ability to read barcodes from images, digital image
forensics and the consumer dashboard.
If you have any questions
around the UP3 product portfolio, or you want to understand how your
business could benefit from fraud detection and prevention, please do get in touch.