​Data sharing to help combat fraud is a regularly shared “ideal” within the economic crime industry. It’s common to hear it raised as “what we should be doing” at external conferences. What interests me is that we don’t often talk about what we’d do if we had that information. We tend to talk about the actual blocker to doing the work to solve the problem. We talk about the challenges with sharing information rather than what the techniques are that we can use to combat economic crime.

Working for Pay.UK (the central UK retail operator), my colleagues and I sit in the middle of all UK retail payments. We manage Bacs, Faster Payments, Cheque Clearing, Confirmation of Payee, amongst many other services, and we’re responsible for building the New Payments Architecture (the NPA). But the sending of information is the cornerstone of what we do: whether that information is sort code and account number, or the name of the beneficiary, or remittance information that helps the recipient (for example, a business) reconcile their payments… or data for the use of detecting fraudulent payments.

Prior to working at Pay.UK, I was a bank supervisor at the PRA at the Bank of England, supervising some of the world’s largest banks. As part of that, I have led regulatory reviews on data governance and understand some of the challenges that organisations face with respect to managing data. Given what I’ve seen over most of my working life, making the exchange of data frictionless is the future I’m striving for. And I know that to combat fraud, making decisions as accurately and as quickly as possible is absolutely key.

I’m talking about it being ready to use for you: a world where you’re not having to muck about with data before you can actually do something useful with it.

But we know this isn’t the case now. There are many challenges we face with data on a daily basis, whether that’s in our jobs or whether it’s in our personal lives. For example:

•Challenges around manual reconciliation: invoicing, receipts, remittance data

•Bank statement clarity: we’ve probably all had statements where we don’t recognise where the money has gone, either a random reference number or the name of the parent organisation that owns the company you purchased from. Indeed, how can people identify fraudulent payments on their bank statements accurately if they don’t always understand what the entries are on it?

•Manual errors: data entered incorrectly by hand and in the worst-case scenarios, resulting in sizeable errors.

These instances are where the real impact of bad data manifests itself; a lack of trust in the data being received, ending up in people continually having to re-check and verify it. This ultimately drives increased costs and time before you’ve even done anything with the data, and in some instances, a financial cost, like a penalty or fee for late or inaccurate data submissions.

FinTech can help play a key role here, but like any problem you have to try and diagnose the underlying causes. Some examples might include:

•A wide range of sources of data in different systems (and if you’re at a large organisation, don’t underestimate the potential complexity and number of different data systems), in different locations, and internal vs externally managed systems

•Different assumptions around the data: Either variations in how the data is cut (for example, different “as at” dates), or when manipulation of the information excludes a subset of the data for some reason

•Different formats: for example, languages, structure, formatting - The typical, albeit simple, example here is when you receive data in an Excel spreadsheet that has a series of dates in one column. These dates might be in the wrong numerical format and need to be adjusted for the recipient to read correctly

•Variability in overall data quality resulting from manual entry or “human oversight”. How often do we see examples in the press from large banks where something has gone wrong from an incorrectly inputted data error?

•Inconsistent usage: instances where a customer has too many fields to select from and the chance to potentially put the same data into different fields. It could alternatively be a situation where the data attribute is defined differently by different people; for example: “length of customer relationship” could mean when the customer first had a relationship with a bank or when it first obtained a current account with the bank (the two not always being the same)

The list goes on but it’s clear FinTech can be at the heart of this and where creating standard can play a key role, by agreeing:

•The structure and language: so when you get the data it’s in the format you need it in already - This should lend itself to being hard coded and machine processable – fundamentally, “straight through processed” data

•Exactly the right information that should be inserted into each data field

•As consistent a way as possible of sending the information

•That it can evolve as the outcome(s) evolves (i.e. maximising the economies of scale across an entire business of having standardised data)

More and more of what I’m hearing is support and demand for standards to play a role in combatting fraud through improving data sharing – for large organisations, businesses, end users and regulators.

As we think about the challenges around fraud in 2023 and beyond, it is clear that standards have a key role to play and FinTech is at the heart of making that happen: both from an implementation and a “galvanising industry” perspective. The future isn’t about the process of sharing data, the future is about what we need to do with good quality data – and standardising fraud data is a key component to enabling that. If FinTech can overcome this challenge, we can get to combatting fraud sooner and earlier in the payments process.

You can read David's article and further industry insights in the latest edition of The Financial Technologist. Download your free copy here.