Mitigating Fraud Threats as Open Banking Evolves in the U.S.

Rob Tharle, Fraud & Authentication Subject Matter Expert, NICE Actimize EMEA
Mitigating Fraud Threats as Open Banking Evolves in the U.S.

Open Banking Gains Traction

PSD2 has been a hot topic in Europe for a number of years and Open Banking is gaining traction around the world. At the recent RSA Conference, I spoke with many FIs about what’s happened in Europe and, even though the U.S. has had aggregators for some time, how this is now evolving into a greater Open Banking scheme.

Unlike Europe, the changes in the U.S. will be commercially driven rather than regulatory, and as such we’ll see a different implementation. However, we’ve already seen press reports this year of U.S. banks moving to an API and token model rather than screen scrapping, similar to PSD2.

As a quick review, the key elements of PSD2 are Strong Customer Authentication, Open APIs and Fraud Profiling. To learn more, check out my previous blogs here.  

Open Banking: Benefits and Threats

Open Banking promises to brings benefits to consumers and businesses alike, but also carries some threats. While we often discuss retail use cases, some of the best use cases are actually for businesses and corporations. We move from the simple aggregation capabilities of showing all accounts, through interest maximization, price comparison (utilities, insurance, finance etc.) to cash flow and budgeting. In the business and corporate space, of particular use are ease of loan applications through sharing the raw transaction data, saving valuable effort and speeding up loans, to allowing online accounts firms to easily manage this time-consuming process.

Addressing the Risks

First, moving to Open Banking with APIs has impacts on fraud systems. These impacts are from no longer seeing data on the whole session and the associated device and other key data elements. This reduces the intelligence available to make risk decisions on transactions, potentially letting more fraud through.

Second, there are the threats from the third-party providers, such as FinTechs. These take on different forms such as rogue firms and data compromises. However, moving to APIs rather than screen scrapping should be a positive step in compliance with GDPR and California Consumer Privacy Act (CCPA). When firms screen-scrape they can take all the data they want, whereas with an API you know exactly what data they are taking and have more control.

Of course, the simplest threat is using Open Banking as another social engineering vector. This helps fraudsters create more convincing stories to defraud customers. Threats will only increase as new services like Request for Payment are added in. Because these requests are seen directly in customers’ banking apps, they seem more legitimate.  

As Open Banking expands, new services spring up and card networks start to be disrupted. Along with the benefits, this can create risks of new cross channel attacks. For example, fraudsters can connect FinTech apps to a consumer’s bank account to help drain it, rather than actual account takeover.

We will also see some traffic moved from e-commerce card payments to push payments over real-time rails. This will have an impact on fraud models, as card and payments usually sit on separate rails and the transactions look very different too, with much less data in payments than cards. Cards are high volume, low value transactions compared to payments, so adapting fraud models will be required.

Further card schemes have very clear liability models, something that is missing from Open Banking. Banks will likely be the first port of call taking operational costs for mistakes and frauds at FinTechs. Even if they can demand the money back, will these startups have the funds, if they are subjected to sophisticated attacks? Even if they have insurance, this may be worthless if attacks are deemed Nation State sponsored and acts of war, as was the case with cyber insurance and WannaCry.

Open Banking and the U.S.

What can financial services organizations (FSOs) in the U.S. do to make the most of the opportunities, all while keeping their customers and themselves safe? Having a multi-layered strategy is key, starting with authentication strategy.

  • First, separate out the channels for FinTechs, Alexa/Google home and chatbots, from human interface channels. This allows identification and authentication to be tailored appropriately and identify the third parties, as well as the customers. This also helps with identifying credentials stuffing attacks.
  • Have a multi-factor authentication strategy, making use of device and behavioural biometrics and ensuring third-party channels are authenticated by redirection to your site or decouple authentication via your mobile app.
  • Try to avoid SMS as this has multiple threats. Though RCS is allowing it and can offer a safer alternative, still use Telco data to detect Sim Swaps.
  • Within this strategy, make it risk based, to avoid customers getting authentication fatigue.
  • Use MFA when the risk of the transaction is high, e.g. new devices, new beneficiaries, but do this on a score basis, not just a policy basis. Also, provide customers with the option to enable MFA for all transactions if they wish.

Once you are offering APIs, block screen scraping to secure customer data and only allow third parties who have registered and identify themselves with you to access your customers data (with their consent). On top of this, provide your customers control of how to view the consents they have given and revoke them easily, but also work with third parties to share intelligence to help reduce fraud in the ecosystem.

With third parties accessing your customers’ accounts, you should be risk assessing the third parties too, as well as your customers. Such entity profiling can then be used within your authentication strategy and how often you check their registration or certificates, reducing overheads on low risk transactions, which matters at scale. To support this the transactions need to be identified correctly,  as open banking transactions, who the third party is. Fraud tagging must be undertaken, so rules, models and lists can all be utilised to reduce risk and friction for customers.

From here, enrich the data you hold on the third parties, counterparties and your own customers by offering aggregation services yourself. This helps increase the stickiness of your services and gives you the data to make better risk decisions on your customers. This then helps you build new models to reflect the changing nature of fraud in these channels and keep them optimized as the fraud patterns evolve.

Open Banking: Moving Forward

I’ve outlined the issues I’ve been discussing with peers in the last few years in the UK and Europe, which in the last few months have been asked about in the U.S. There are both benefits and risks associated with Open Banking, however, we’re still near the start of the Open Banking journey and it’s one that is likely to evolve from cash management to balance sheet views under Open Finance. Like all tools, it can be used for good and bad, and I think we’ll see the fraudsters try to abuse it. However, by taking the correct action, you can help your customers achieve their financial goals safely.


Addressing Fraud Risk from COVID-19 Relief Efforts

May 7th, 2020
Rob Tharle, Fraud & Authentication Subject Matter Expert, NICE Actimize EMEA

A Changing Fraud Landscape: Navigating the Risks Amid COVID-19

April 17th, 2020
Rob Tharle, Fraud & Authentication Subject Matter Expert, NICE Actimize EMEA

UK Fraud Losses – What happened in 2019 and where are we headed now?

April 17th, 2020
Rob Tharle, Fraud & Authentication Subject Matter Expert, NICE Actimize EMEA
Speak to an Expert


We use cookies to ensure that we give you the best experience on this website. If you continue without changing your settings, we’ll assume that you are happy to receive all on the NICE website. However, if you would like, you can change your cookie settings at any time. To find out more about how we use this information, see ourPrivacy Policy.