• Daniel Cohen, Solutions Engineer at DataStax


• 10.08.2016 01:00 pm
banking fraud

Payments fraud is one of the biggest problems for online retailers and financial services firms, with the cost of payment card fraud globally estimated at $16 billion in 2015, up from $7 billion in 2010. Payments fraud remains a challenge for IT teams at businesses of all sizes, from fraudulent transactions on a local coffee shop’s card machine to sophisticated attacks against  the payment gateways behind the world’s biggest retailers. The use of stolen credit cards is by far the biggest contributor to online fraud while the use of mobile devices for financial transactions has increased the risk significantly.

With fraud affecting around one per cent of company turnover, the cost to businesses is huge, regardless of their size. The growing adoption of online and mobile payments will continue to raise significant risks against payments fraud. Even as US merchants adopt EMV Chip and PIN cards for secure payments within physical shops, the market for fraud is shifting online.

However, anti-fraud technologies are being developed to spot and stop fraud from taking place – as companies now make millions of low-latency transactions per second, retailers and banks can make use of algorithms that process transactions in real time to stop fraudulent transactions before they are completed.

The current state of fraud detection and prevention

Card fraud can happen in many different ways and online transactions are often the hardest to detect. The main problem is that by the time it’s been detected, the transaction has already occurred and someone is out of pocket. To improve fraud detection, it’s therefore important to determine which types of fraudulent transaction can be conducted.

The following people are typically involved in a card transaction:

1.     The Consumer - the entity who wants to purchase. This can be in-person at a Point of Sale, via an online site, through a mobile device or another channel.

2.     The Merchant - the other entity in the transaction that is selling the product or service

3.     The Acquirer - the financial institution that handles the transaction for the merchant

4.     The Credit Card Network - the credit card service that handles the transaction between the acquirer and the issuer

5.     The Issuer - the bank or financial institution that provided the consumer with their credit card

(c)miniaria/Shutterstock

As there are so many different organisations and individuals involved across the payment request, there are lots of gaps that can be exploited for fraud. In terms of preventing fraud, the Acquirer, Issuer and Credit Card Network all have existing processes in place to stop fraud:

1.     The Acquirer works for the merchant - they may provide some validation checks before sending the transaction on to the Credit Card Network.

2.     The Credit Card Network usually has watchlists and blacklists of card numbers that they want to monitor.

3.     The Issuer will be required to check if the consumer has enough available credit to process the transaction, as well as checking the existing status of the card and that the PIN used is correct.

So how can fraudulent transactions be made when there are so many safeguards that seem to be in place? The problem is that card payments have to be made in real time, yet many of the checks that are taking place at the same time often don’t run as quickly. In the race to ensure that customer experience remains as good as possible, the risk is that a fraudulent transaction can be carried out.

Improving fraud prevention in real time

As criminals are always looking for devious ways to circumvent existing security checks and processes, all the organisations across the payment chain must also be ever vigilant. Normally, the credit card companies will act as a choke point for transactions and where the bulk of security checks will be carried out. There are not many transaction steps that involve the Acquirer and the Issuer. To combat new types of fraud in real time, both Acquirers and Issuers can take over more control of the payment request.

To do this requires more insight into what is “normal behaviour” for the retailer and the customer. This can then create insight into anomalous transactions that can then be flagged for intervention.

So what does this look like in practice, and how can it be scaled up to cover the thousands or millions of transactions that take place every day? There are three points for Acquirers and Issuers to go through:

1.     Create unique rules for each merchant – this is based on previous transaction values and volumes, and creates a “default state” for both good and bad transactions that have happened in the past.

2.     Scan previous transactions to ensure consistency – by looking at past activity that is known to be good, any odd or potentially fraudulent transactions can be spotted. All future transactions can then be compared against this to spot anomalies as they take place.

3.     Require human interaction for transactions with certain attributes – for transactions that are flagged, confirmation from a senior member of staff can be added to the workflow. This should ensure that any “false positives” can be managed effectively and stop potential fraud. This can also stop employee fraud by ensuring that trusted members of staff are associated with those transactions and this is recorded for any audit processes.

Alternatively, retailers can use another channel to ask the customer to confirm their payment, such as via a text message or on a mobile app. If something looks out of line, then the bank can contact the customer to have them confirm, in real time, before the transaction goes through. Some banks have already started doing this now for their customers as a way to increase their perceptions of security.

Let’s apply this approach to a more “real world” example and look at a busy local coffee shop. By analysing past transactions, the Acquirer can see that around 90 per cent of the card transactions that occur will be under £20 and 100 per cent will be under £50. Based on this analysis, the Acquirer can create a rule that, if at any stage a transaction is requested for over £50, then a senior member of staff is automatically notified and a confirmation is required for full processing.

Similarly, if a higher number of transactions above £20 take place on a given day, the Acquirer can notify the merchant. This might sound like a simple idea, but it requires effort on the part of the Acquirer to ensure that these rules are both in place and applied, and that the required people are notified if and when any rules are breached.

The difficult part here is to make the analysis and notification an accepted part of the Retailer and the Acquirer workflows so that activities are carried out in real time alongside any payment being taken. At the same time, business objectives can change over time – for example, a growth in business customers for the coffee shop may lead to more orders that break the £50 barrier. Managing these rules over time will require some input, but the combination of analytics and closer customer relationships should add up to reduce fraud.

This kind of payment analysis is possible for customers in their online banking applications – for example, flagging any transactions above a certain size, or notifying the customer if the volume of payments to online stores goes above a certain level during the month. Applying this approach at scale to payments can help prevent fraud for retailers as well.

Building real-time fraud prevention systems

This need to work in real time is the biggest issue for fraud detection and prevention. The data used to power the transaction – and the analytics that take place around each and every transaction – is at the heart of meeting both customer expectations and the fraud prevention requirements held by all the companies across the payment process. Any implementation around fraud prevention within payment applications therefore has to meet four needs around this data: Availability, Speed, Scalability and Security.

In today’s world, any client-facing application is a critical one. If a payment application is not available then it will be treated as a failure by the customers affected. Similarly, any failure in the fraud application component will be treated as significant – at best, there is the potential for fraud to take place, while at worst it may affect the whole payment system.

Ultimately, this kind of incident would hurt the business and its brand, as well as the brand of any company or service that relies on the fraud prevention system. Availability of the service should therefore be the number one requirement of any critical system. To support this, it’s therefore important to consider how transaction data is stored and analysed over time. Any database behind the fraud prevention system should be fully distributed, so that any incident large or small does not affect the ability to detect and prevent fraudulent transactions from happening.

Alongside availability, the ability to handle millions of transactions per second means that data has to be created, processed and stored incredibly quickly. Along with throughput comes latency. To provide the latency requirements that are needed for a queryable system to provide fraud prevention, we need to be able to write and read at incredible speed. To achieve this, data has to be grouped into related data sets for low latency reads. This is perfect for both reading and writing transactions for a particular credit card user. At the same time, any system has to be able to handle millions of transactions that can access the system at the same time without contention slowing down service requests.

(c) DesignPrax/Shutterstock

One element alongside speed is the ability to scale. For many companies, scalability is achieved by simply buying bigger servers or investing in more IT hardware. While this can deliver greater scale, it is a very capital-intensive approach driven by particular decisions on data architecture. Traditional applications are based on databases that have a master/slave architecture, where one server is in charge of operations while the others have assigned tasks.

This leads to a bottleneck in performance over time, which then leads to big investment costs each time scaling up is required. At some point, the ability to buy larger boxes will present its own limit. Even if you have a limitless budget, there may be no physical hardware available that can meet the need.

Instead, new data architectures can be considered. For example, peer-to-peer data architectures can help reduce the cost of scaling up over time. Rather than the “master/slave” approach, a fully distributed data management platform can spread operations and data evenly within a cluster. Rather than having to scale up the leader each time better performance is required, more nodes can be added. This makes scalability predictable and linear over time.

Alongside these requirements for performance, any fraud prevention implementation has to support security around the data used. For example, encryption of data and access control for the development team should all be in place as standard. As any application will handle payment card data, the PCI Data Security Standard should be used as a template to ensure compliance with all the necessary security steps as well.

For Retailers, Acquirers and Issuers, the ability to keep themselves protected against fraud is a substantial issue for the future. The growth of online fraud can affect companies of all sizes, so any response will involve co-operation across the industry. At the same time, it is possible to use data in new ways to spot transactions that are potentially fraudulent in real time. This has the best potential to help reduce the impact of fraud, both on individual companies and ultimately on the customers themselves.