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.