By treating open banking – or API-banking – like any other banking channel, institutions can use static rules, dynamic profiling and machine-learning approaches to protect themselves from the increased threat of fraud, writes Jerome Kehrli.
Laughter – and a certain smugness – are not the usual response to the Payment Services Directive 2 (PSD2). But it is in Switzerland, where bankers are amazed that so few organizations elsewhere in Europe have come to grips with its implications, resulting in widespread panic.
From 13 January 2018, European banks will be forced to share their customer data with approved third parties. The panic stems from the understandable fear that such third parties will steal their business, bypassing them to make and take direct payments. Not only might this cut their revenues, but it also increases the risk of fraud.
The Swiss experience
For the Swiss, 13 January will simply force banks across Europe to do what they have been doing voluntarily for more than a dozen years. So here is what other European banks can learn from the Swiss experience.
Two events contributed to the natural opening up of Swiss banking to third parties: the growth of private wealth offices in Switzerland; and large corporates implementing their own payment systems. The number of private wealth offices and other external asset managers such as multi-family offices has grown from just a handful at the turn of the millennium to hundreds today. Companies such as Swiss watchmakers for instance, meanwhile, rolled out SAP systems that enabled them to pay their suppliers directly using APIs (direct / open banking).
Neither multi-family offices nor corporates held banking licenses, but they became significant sources of fund transfers and as such increasingly important players in the banking world. It made sense for banks to give them direct access to their own accounts. With APIs and open banking, third-party access has grown dramatically. Swiss banks operate in a very PSD2-like world, and it works for them.
But that’s not to say that this kind of liberalization comes without risk. Certainly, the security systems of third parties are unlikely to be as robust as those of a large financial institution, and there will be far more of them, yet the regulatory burden is on the latter to fight fraud. So what can be done?
Monitoring open banking
For me, based in Switzerland, it’s about how you think about open banking. I see it as just another channel like mobile banking or e-banking; it’s API banking. So when it comes to fighting fraud, the same principles apply. Build up profiles and institute static and dynamic rules on fund transfer, user activity as well as in-depth customer profiling
Admittedly, working through APIs leaves the bank blind to certain variables it would normally monitor with internet banking for example – such as session data, device, location and time. But API banking still works on behalf of customers and leaves footprints. There is a counterparty (the transaction recipient), an amount, a kind of activity, etc. In addition, the PSP – Third Party Payment Service Provider – can be profiled as well.
Banks will need to screen and monitor counterparty and third-party PSP behaviour to pick out patterns. Any new counterparty that emerges should be investigated – its location and the amount, for example. If these are suspicious the transaction should be blocked.
Similarly, the third-party PSP will have a typical behaviour pattern. Take a big watch corporation using direct banking to proceed with its payments, for example. It might pay suppliers during a window of three days towards the end of each month. If a request comes in on the 5th, it should be treated as suspicious and be monitored conscientiously. And those payments during the normal window will be to a regular group for a similar sum for a set number of times a year. Should one appear from a new source, at an unusual time of year or for a significantly different sum, it should be investigated.
Machine learning to spot and prevent fraud in real-time
Finally, the bank can apply rules – both static and dynamic. These will cover what is allowed, can be built up over time using machine learning and can cover the process and sequence of events. Anything that doesn’t fit with those rules, profiles or advanced analytics techniques can be blocked and investigated.
Static rules will stop an investment advisory app from ordering big transfers to odd countries and unknown counterparties, for example, or a payment automation provider from issuing a second of the same type of fund transfer. Neither transaction would fit with the usual modus operandi.
Advanced analytics, such as machine learning techniques based on Markov chains, would look at the sequence and be particularly useful in the fight against worm fraud. A worm is unlikely to replicate a payment sequence or workflow – for example, login, account list, balance, then payment. Instead, worms tend to go from login to payment – which should trigger a red flag.
At NetGuardians, we use machine-learning technology to monitor user activities on e-banking applications. The same technique can be applied to API monitoring. A typical third-party application connected to the banking information system will always use the APIs in the same sequence. Any new or unknown call sequence should raise an alert.
The specific solution for the Open / API banking works by profiling third-party payment service providers as well as customers, counterparties and all other transaction characteristics. A combination of various techniques – rule-based, profiling and machine learning – means every channel transaction, including API Banking and PSD2, is monitored in real-time.
Swiss bankers get it. They realize that the onus is on them to make sure that transaction security is tight – just as it is in their direct dealings with customers. And they have already seen the benefits that open banking brings. Get it right and banks will be able to increase the reach of their business. Get it wrong and they risk an explosion of fraud, with its associated losses, damaged reputations, fines and even the loss of their licenses.
Jerome Kehrli is Head of Research and Development at NetGuardians.