On November 4th, we organized a roundtable with the Payment Integration experts from SEEBURGER and the Fraud & AML experts from SAS.

Both parties shared their insights into the currently developing market of real-time payments. The need for real-time payments is increasing and financial institutions are feeling the pressure to integrate the functionality of real-time payments.

But what does this integration process look like? What are the traits of a modern payment platform? And how do financial institutions manage Fraud & AML in the process?

In the following article, you will find answers to all these questions. Enjoy!

If fraud is a new area for payments for a bank, what does that process look like?

Ian Holmes (SAS): Fraud is not new to banks, but payments are an area where a fraud system needs to be enhanced in order to deal with the real-time environment. With SEPA, we are talking about 300 milliseconds for all of the processing to occur – not only the processing of the payment, but also all of the intelligence work to identify fraud and financial crime risk. Within that time, we no longer have the capacity to let people manually investigate these payments, because they are too high in volume and in processing speed. So, to be able to do that, we need the payments to be in a standardized format (which is where SEEBURGER comes in). Then we apply machine learning models and AI to extract the necessary information based on the different types of risk. We then respond to the systems with an approval in most cases, or we respond with a hold or declined decision based upon the risk identified. We then can allow the investigation to occur and compare that with other data in order to verify if the risk was correct. Sometimes it will happen that the held or cancelled transaction is genuine, but in most cases they are fraudulent. That output is used in a feedback loop so the AI and machine learning models can continuously update to enhance future performance.

How long does it take for a bank to become real-time ready? What steps do they need to take from an integration perspective?

Matt Burns (SEEBURGER): How do you define real-time ready? It is governed by what the bank is planning to do as a necessary overhaul to its systems to address the real-time transaction support. To address real-time transaction support, PSD2 and Open Banking, this drives us towards talking about ISO20022 message compliance, because this format provides the additional information that all the participants in a payments transaction need to have.

Fundamentally, it could be a multi-year programme of improvement. There has to be a decision around which systems to renovate, open up and improve in order to set-up real-time transactions. So, it’s not a straightforward approach and could it be undertaken in a number of phases. If a bank just wants to have access to a real-time scheme, they could potentially buy a real-time gateway which will give them access for processing and payment into the real-time network. However, there is still an impact on their backend systems, and that will take significant time and effort to integrate.

Guus Vermeulen (SEEBURGER): One of the biggest issues that we experience is that we need to integrate with those back-end systems, which are often quite old and asynchronous. This is in conflict with real-time payments. Ideally, you want to have back-end systems that are real-time as well. If this is not the case, most of the effort is spent to integrate between the incoming API and the asynchronous back-end system. What we see is that people who want to setup real-time processing usually buy an API management solution. But then the integration process is often ignored at first, after which they realize they do need to focus more on the back-end integration. And we have got the technology in place to support that and have been helping many banks in this particular area.

Matt Burns (SEEBURGER): Just to add to that, the larger and more complex the bank, typically the more back-end systems it has got. One of the banks we worked with had over 80 back-end systems. Which one of those has to be modified, renovated or replaced to meet the real-time world? That’s a significant challenge as a bank becomes more and more complex.

When should a bank start considering the needs for a fraud and AML system to support the requirements of a real-time payment processing system?

Ian Holmes (SAS): These really go in lockstep. Fraud and AML can sometimes be the business driver to upgrade their systems, given the regulatory consequences and fines as well as the reputational risk. Unfortunately, we have already seen some major banks in Europe receive heavy fines due to non-compliance from an AML perspective. As mentioned by Matt and Guus, the banks’ systems need to be upgraded to cope with this. Of course, the bank has to be interested in being able to stop or hold payments instead of just letting payments progress as in more asynchronous systems. They can upgrade their systems for that in the future, but one of the benefits of having a real-time payment processing system and a real-time fraud system is the ability to immediately decline specific transactions once the risk has been identified.

If you were to characterise the attributes of a modern payment platform what would they be?

Matt Burns (SEEBURGER): A modern payment platform has to support processes in real-time, instantaneous. So, it’s going to have to support the ISO20022 message formats, which incorporates necessary data enrichment. Another thing is the client onboarding experience. We see a lot of banks and their clients suffering because it’s taking weeks to get banks on board. So, it has got to provide a positive, effective and streamlined onboarding experience. The ability to self-servicing is also important, allowing customers to go through most of the onboarding themselves, without having to wait for support from the bank. That idea of having a frictionless user experience is important. The payment platform has to support that. Fault tolerance has been around for 25-30 years but is still very important (some of the legacy systems are even older than that). And of course, scalability; large volume handling due to the demand for more and faster payments.

From a more technical side, it is important to offer; microservices, AI and machine learning capability, and a whole host of APIs to connect to cloud-based services that are coming to the fore.

Guus Vermeulen (SEEBURGER): From an integration perspective there is a need to support the old back-end systems and the new systems. Our customers have the need to process more classical files and classical protocols, while at the same time there is a need to support APIs. If you can provide for both these requirements, then you can cover the complete scope of the project.

Is there anything you would like to add to this, from an AML and fraud perspective?

Ian Holmes (SAS): One of the biggest modernizations is going to be the AI and Machine Learning as Matt referenced. Systems have been using CAD transaction processing for many, many years because they allow for a high speed and high volume of throughput. Payments have been increasing rapidly, but it is mainly the speed that has been driving that. Fraud losses occur related to the speed of the settlement of those payments, because if we do not stop it as soon as we identify it, then the settlement process takes place and the money goes out of the door. It is very difficult to recover the money if you identify fraud afterwards, because fraudsters will probably move it into three different bank accounts to hide their footsteps.

Regarding the regulatory aspects, how easy is it for the incumbent institutions using your solutions, to use your tools to report towards the regulators?

Ian Holmes (SAS): Our solutions support much of the regulatory interaction, reporting from an AML perspective is key when a risk is identified. The ability to quickly compile those reports is one of the operating efficiency aspects. There’s an initiative in the industry called Robotic Process Automation, which falls under the umbrella term of AI, that is helping bank operators to complete many of the forms and documents quickly, which are required when the risk is identified. From a fraud perspective, PSD2 is a regulatory driven aspect in the industry, which we are keeping a close eye on. The requirements are quite well formalized, but some technical aspects were not clearly documented, making it difficult for banks to keep up. So, we are keeping an eye on that to allow that technical integration.

Matt Burns (SEEBURGER): We are also keeping a close eye on regulations, but it really depends on what our role is in the value chain here. We are a transport-translate-transform-integrate company. Our payment integration hub is about getting the data from a client’s accounts payable system, into the bank. The bank’s role is then to act upon that, once it’s gone through AML and fraud screening, to push that out for settlement. We don’t process or initiate the funds transfer, but we are very mindful of the fact that we are managing data. So, we have to meet certain internal requirements imposed upon us by the bank. However, where we fit with some of these external regulations is not as clear, but we are certainly watching it closely.

Do you have any use cases where real-time technology has been deployed to great effect in the financial services industry?

Matt Burns (SEEBURGER): I can share an example around real-time liquidity management, using real-time APIs to enable a bank’s cash management team to make real-time inquiries and advices on their corporate client’s balance positions. So now it’s a pull, whereas the client traditionally would have pushed it as an empty 940 or 941 message. So they inquire in real-time, bring that information over into the bank, maybe over a data lake into an analytical tool, perform some analytics around it and then convey advice back to the corporate around better use of excess liquidity. So, it’s enabling the cash management team to provide instantaneous advice that they couldn’t have done in the same way before. These are initiatives that are happening now and they are extending into treasury as well. These have typically been smaller corporates that don’t have sophisticated treasury management systems and a CEO and CFO driving that vision.

And what does that look like for AML and fraud, especially in digitally driven times since the lockdown?

Ian Holmes (SAS): The number of scams is increasing, which is being facilitated by the amount of digital interactions that we’re having. One of the areas where I see fraud changing is in the ability to take information prior to the payment and during the customer journey (i.e. by facial recognition and strong authentication). We now have a longer runway to ascertain risk using information gathered prior to the payments, allowing us to build profiles of customers. If a payment does occur, we now have a more precise way of identifying that risk. So, we have a wider view now, not only within the payment landscape but within the full customer journey.

If I talk about AML, the ability to process textual information of invoices related to our trade finance and trade surveillance activities is giving us a lot of advantage in assessing the actual risk. We can assess whether notes and information within these invoices tie in with the shipping details and the bill of landing or the value of the payment. For example, being able to calculate that the value of 5000 laptops identified in a container and assess if it equates to the value of the container as it is shipped around the world. That is really powerful and makes sure we can keep an eye on trades within the industry.