Fraud is an ever-evolving threat. Not every fraud monitoring tool on the market can keep pace with the new schemes constantly popping up. That’s why it’s essential to deploy the right fraud solution – but to be successful, there are many factors to consider.
Regulatory compliance will always play an important role when deciding the must-haves in your fraud monitoring tool. These days, compliance with the Revised Payment Services Directive (PSD2) and its technical standards is one of the key drivers of change in Europe.
One of the new rules introduced by the PSD2 is mandatory transaction monitoring. As defined in the Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and Common and Secure Communication, transaction monitoring will become mandatory for all payment providers. To allow more user-friendly journeys, the RTS foresee cases where specific transactions may be exempted from SCA – provided proper transaction monitoring is in place and various conditions are met.
To find out more about the transaction monitoring requirements and how organizations can benefit from the exemptions listed in the technical standards, we sat down with Ralitsa Miteva, Business Solutions Manager at OneSpan. An expert in risk analytics and fraud detection, Ralitsa also explains which fraud monitoring features can make a real difference in preventing fraud and building trust.
Fraud Monitoring Requirements and Considerations under PSD2
Question: Let’s start with the basics. What do we mean by, “fraud monitoring tool”?
Ralitsa Miteva: A fraud monitoring tool is a system designed to identify and prevent fraud and controlled by fraud analysts. In the past, these tools had simpler functions, involved more manual work, and operated in a rather reactive mode. The banking tech stack was siloed and so was its fraud monitoring.
Today, new fraud systems tend to be more complex. At the same time, they remain agile and easy to use. They automate processes and work proactively. A modern fraud system is rarely a single tool, but rather a solution that natively integrates different technologies meant to work together.
Question: There’s a wide range of tools available to financial institutions (FIs). This encourages innovation among developers – but too much choice can also make the purchasing decision more difficult. What should FIs look for?
RM: At OneSpan, we have a team of experts with deep experience in fraud detection for the banking and payments industries. We’ve identified a core set of features that a fraud monitoring solution should have, in order to meet the latest market requirements. Generally, it should take into account the new generation of end users, new and more complex types of attacks, and evolving regulations.
When it comes to particular features, it’s important to mention that the solution should enable compliance with PSD2 and the requirements defined in its technical standards. All the required rules and reports should be available out-of-the box. However, the solution should not only cover the PSD2 requirements, but also expand beyond the regulatory scope. Last but not least, if you invest in a new solution today, it should meet all your current needs and the specifics of your business for the foreseeable future.
Question: It seems like all fraud monitoring solutions today offer a rule engine, but only some also offer different variations of machine learning algorithms. Why is it so important to combine both?
RM: So far, the benefit of a rule engine is indisputable when it comes to applying specific security policies, business logic, or set of conditions. It is capable of covering the relatively simple, known fraud patterns.
Machine learning, on the other hand, is the future of fraud analysis. It can scale much better and can spot extremely complex patterns as well as emerging fraud schemes.
I consider the combination of an advanced rule engine and machine learning algorithms – tailored to your needs – as essential to cover known fraud patterns, address unknown fraud, manage complexity, and handle business logic.
Question: What about other features?
RM: The ideal solution should follow a layered, context-aware online security approach in order to detect complex fraud attacks, such as those resulting from malware infection, which is now stipulated by the RTS.
This approach includes more than an analysis from an advanced decision analytics engine. It begins with the collection of data on the client side. We gather information on a single user and their actions throughout the whole user journey, across all channels and devices, and on a historical basis. This way, we gain a full view of the user, device, and account activity.
This whole range of data should be linked and monitored on the server side. I don’t think we can talk about a modern approach to fraud detection without taking all these layers into account.
The solution should also be able to analyze and respond to events in real time and not only for compliance reasons, which I will discuss in a moment. With thousands of transactions and increasing expectations from customers regarding fast payments, it is simply a must-have. A good solution should also be able to analyze the risk of all users, actions, and devices across all digital channels.
Finally, streamlining the operations of your fraud team is essential to minimize delays and errors in the investigation. This includes investigation tools and screens providing a comprehensive overview from multiple angles. The ability to produce reliable reports is also a must. PSD2 now has extensive requirements for fraud reporting, which means that the tool should be very flexible to provide all detailed data that regulators require.
Question: Let’s talk about compliance. PSD2 has been a hot topic for quite some time and FIs want to know why a fraud monitoring tool is an essential part of a PSD2-compliant architecture. Let’s start with some definitions. What does transaction monitoring entail, in the context of the RTS?
RM: According to Article 2 of the RTS, the term “transaction monitoring” refers to mandatory mechanisms that enable payment service providers (PSPs) to detect and prevent unauthorized or fraudulent payment transactions. All while applying strong customer authentication per Article 97 of PSD2.
These mechanisms are based on the analysis of payment transactions. According to the general authentication requirements, the analysis should consider several risk-based elements, covering at minimum:
- Checks against lists with compromised or stolen authentication elements
- Checks against known fraud scenarios
- Detection of malware infection of the authentication device
- Deviations in the amount of the transaction
- Analysis of the device/software, when provided by the PSP
For a large number of banks in Europe, transaction monitoring is not a new process. But creating particular standards and making them mandatory – this worried many FIs. They started to doubt if what they do today is enough to be compliant. In my view, we should not treat it as something negative, but rather as an improvement that protects customers and PSPs.
Question: What is the difference between “transaction monitoring” and “transaction risk analysis” in the light of the RTS?
RM: It’s important to emphasize “in the light of RTS”, since for many people these two terms are synonyms outside of the RTS context.
However, in the context of PSD2, the term “transaction monitoring” covers the scope of analysis discussed earlier and is legally required to support the process of strong customer authentication.
Transaction risk analysis requires a more detailed risk assessment, performed in real time. This analysis has a broader scope than the mandatory transaction monitoring as it includes a number of risk-based requirements, such as information on the location of the payer and of the payee. At minimum, it is aimed at assessing the risk of transactions in case a bank would like to benefit from exemptions allowed only with low fraud rates.
Question: What is Strong Customer Authentication, and is it always obligatory?
RM: In brief, Strong Customer Authentication (SCA) is an act of authentication that uses at least two out of the three factor categories: knowledge (“what I know”), possession (“what I have”), and inherence (“what I am”). These factors need to be mutually independent. A user has to be informed of the transaction details, and the authentication process must result in a unique code linked to these transaction details.
According to Article 97 of PSD2, PSPs should apply SCA when customers access their online payment accounts, no matter if they want to perform a monetary transaction or other types of operations, like adding a trusted beneficiary. It will also be obligatory for any actions performed through a remote channel that may carry a risk of fraud, like accessing a bank account via a mobile device. In some cases, PSPs may be exempted from applying SCA.
Question: What are the possible exemptions from SCA?
RM: The Regulatory Technical Standards foresee a range of cases, which, subject to certain conditions, will not require SCA. In general, we are talking about two types of exemptions: fixed and those that are based on transaction risk analysis.
The fixed exemptions include, among others, certain cases of low value transactions, viewing account information, transactions to one’s own accounts or to trusted beneficiaries, and recurring payments (like subscriptions).
There is also a set of risk-based conditions, which allow for exemptions based on the level of risk and low fraud rates.
We discuss the exemptions in detail in our recent white paper, Enabling PSD2-Compliant Fraud Monitoring with OneSpan Risk Analytics.
Question: Why is it important to have a proper fraud tool in place when implementing SCA in your user journeys?
RM: A proper fraud monitoring solution will provide a pre-built package containing a set of rules and reports. It will cover the mandatory transaction monitoring requirements and will support you in assessing and maintaining eligibility for exemptions from SCA. But, it will also expand beyond compliance, increasing the trust and the flexibility of your user journeys.
Question: Compliance is indeed a key factor in determining the set of fraud tool features, but it doesn’t end there. You already mentioned some features that will ensure that an organization not only complies with the regulations, but also has proper protection against the most popular fraud schemes. What are the other features that you would expect from a fraud tool?
RM: I think that many fraud solutions understate the importance and specifics of the mobile channel. Many vendors monitor this channel, but in some cases they may not leverage the whole range of available data. Some may not provide a secure channel to ensure the integrity of data points as they are transferred from the client side.
With mobile banking on the rise, we need to be able to better answer the challenges of this channel. Mobile-specific attacks are getting more complex and cannot be detected easily without an advanced solution. For example, what would happen if you analyzed the data collected from the mobile device – but this data had already been compromised before reaching the server side?
A good fraud solution should also integrate into the adaptive authentication process. It should be able to react immediately to changing threats in order to provide a frictionless and secure user journey. Remember that good user experience is one of the key differentiators for FIs. A frictionless, yet secure user journey through all digital channels is a must. Users should only experience friction if their actions have been evaluated as bearing risk above the acceptable level. A modern solution, integrated with adaptive authentication, will determine the level of risk and trigger the most suitable authentication method out of the available ones.
Question: OneSpan’s product offering includes Risk Analytics, a fraud monitoring solution. Does it have what it takes to satisfy the requirements of both a fraud analyst and a compliance manager?
RM: I am strongly convinced that it is a solution that will meet expectations. It includes all the features we talked about, including a pre-configured PSD2 package, and more. All of this in total makes OneSpan Risk Analytics an indispensable tool streamlining daily operations. It integrates with existing systems as well as with a variety of third-party applications. It adds a significant level of trust to the user journey and becomes one of the pillars of a great user experience.
Question: Thank you, Ralitsa. Where can readers get more details about the topics covered in our conversation?
RM: Anyone interested in the features of a fraud monitoring tool should check out our white paper: Buyer’s Guide to Evaluating Fraud Detection Tools.
We also have a new white paper covering the topics around transaction monitoring requirements in PSD2’s technical standards, including the exemptions mentioned earlier: Enabling PSD2-Compliant Fraud Monitoring with OneSpan Risk Analytics.
I would also like to invite our readers to watch our recorded webinar.