Launching Your PSP: A Comprehensive Checklist with a Deep Dive into Fraud Prevention by Akurateco & Fraudio

With Fintech being on the rise, launching an independent payment solution remains a hot topic for many entrepreneurs. The cornerstone of any Payment Service Provider (PSP) or payment gateway is its ability to remain resilient in the face of fraud.

Akurateco, in collaboration with Fraudio, recently recorded a webinar that offers essential insights and actionable knowledge on starting and operating a fraud-resistant PSP. The webinar covers everything from setting up your payment infrastructure to adopting advanced fraud prevention technologies. For your convenience, we’ve prepared a transcription of the discussion featuring Andrew Riabchuk, Founder and CTO of Akurateco, and João Moura, Founder and CEO of Fraudio. Read on!

Drivers for Companies to Launch Their Own PSPs in Today’s Market

Host: Let’s jump right into this with the first question. Andrew, could you share with us what drives companies in today’s market to launch their own PSPs?

Andrew: I would like to start with the potential types of companies and individuals that are seeking to launch their own PSPs, because of the different reasons that drive them. Even the term Payment Service Provider (PSP) may have different meanings because PSPs or payment gateways can be quite different. For instance, the companies that already have a client base and work with them, like platforms, banks, and other financial institutions could potentially be interested in launching their PSP since they already recognize it can provide new revenue streams for them and offer additional services for their customers. Even an acquiring bank that normally works with other payment service providers or intermediaries at a certain point would like to start its own PSP business. With a PSP of its own, customers will have a one-stop shop instead of working with this bank and a third-party PSP, which acts as a middleman.

Another segment that is interested in opening a PSP is merchants and large enterprises. The same applies to companies working internationally since they handle multiple payment methods. All of them have to work with multiple acquirers, payment providers, or other financial partners, which means that they have different dashboards, back offices, and accounting systems for each, as well as numerous other hassles and a lack of control over them. If the merchant or this enterprise grows large enough at some point, it makes absolute sense to finally get into control of their payments. At this stage, they can either create an internal PSP to cover their needs or even start a separate business as a PSP. It makes perfect sense for them since the driving force behind this decision is to work only with their own PSP that has many banks or payment providers connected to it instead of working with multiple payment partners. 

The third segment is small companies or individuals acting as Independent Sales Organizations (ISOs) and Merchant Services Providers (MSPs). They act as agents who bring clients to acquirers or payment processors, earning on referral fees that they receive. At some level of growth, it would make sense for them to run their own PSP. It could be a Payment Facilitator (PayFac), an agent model, a so-called distributive PSP, or a collective PSP. In any case, to start their own PSP they will need some technical background and plan. 

In summary, the main reasons driving individuals or enterprises to launch their PSPs are getting access to additional revenue streams, gaining control of the payment data and ensuring its efficiency, fighting potential fraud, and enhancing security in the current business since payments are vital to any business. So, no matter how good your product is, if you don’t have a structured and optimized payment flow, it won’t bring you revenue, and revenue is what counts.

The Checklist of Essentials for Creating a Minimum Viable Product (MVP) of a PSP

Host: Thank you, Andrew. Now that we know the intention and motivation behind launching a PSP, let’s move on to the operational part. Can you guide us through the checklist of essentials needed for creating a Minimum Viable Product (MVP) of a PSP, particularly focusing on securing the launch?

Andrew: As I said earlier, PSPs vary. They are targeting different verticals and working either on a collective or a distributive model. Depending on that, the list of requirements for their MVP would vary as well. As a collective PSP is probably the most desired one to launch, especially for standalone businesses dedicated to specific regions or business verticals, let’s take it as an example. I would divide the requirements for the MVP of such a PSP into four parts. There are legal and compliance requirements, software and technical requirements, operational tasks that must be completed, and security measures. 

The legal and compliance requirements depend on the geos and verticals you’re working with, requiring you to have a license. If you’re working on multiple geos and multiple verticals, you may even need multiple licenses, which requires lots of time and resources. Furthermore, if you want to process payments through your own platform installed on your servers with your own infrastructure, you must acquire a Payment Card Industry Data Security Standards (PCI DSS) certification. So, that’s the first step. It depends on the transaction volume, the country of residence, the type of infrastructure you use (dedicated servers or cloud infrastructure), whether the cloud provider or hosting is PCI DSS-certified, etc. Due to these factors, achieving compliance can be quite costly and time-consuming as well. Last but not least in terms of legal and compliance requirements, is the General Data Protection Regulation (GDPR) for the European Union or any other data privacy and security laws applied in other regions. Since PSPs are working with personal data, they have to align and comply with all regulations in the regions where their business operates, and it shouldn’t be overlooked. Besides, Europe, by far, has one of the strictest policies in this regard. 

Next, the software and technical infrastructure. To become a PSP, whether collective or distributive, you have to run it on some payment gateway. You need to either build it in-house, buy it as a code, or rent it from companies like Akurateco. The choice depends on your requirements, the regions and verticals you’re working with, the desired payment integrations, the additional functionality you want to implement, and so on. 

Fraud detection and prevention tools are another crucial aspect. They should be implemented step by step. It doesn’t make sense to start with a very sophisticated system of fraud prevention if you don’t have enough transaction volume. In regards to fraud detection, you must have some simple checks like customer e-mail checks, IP checks, number of payment attempts, etc. Although it’s quite a long list, it can be simple to implement. And these simple checks, at least at the beginning, would help you to eliminate 80-85% of the potential fraud cases. But once you have your transaction volume rising it absolutely makes sense to turn to professionals and partner with companies like Fraudio that specialize in fraud prevention, have significant data sets, and are experienced in working with them. Otherwise, it could be quite a trap for you if you put a lot of effort into increasing your volume and your sales, and then fraudsters attack your business, and you are not able to respond in any way. So it’s always better to consider this in advance. 

A scalable architecture is also vital for launching a PSP. Although it takes much more time to deal with operational things, it is important to build robust merchant onboarding processes, which also relate to fraud prevention tools. Your merchant onboarding should be fast, but structured and preferably automatized. 

Another thing that is crucial for PSPs is to come to the market with a clear pricing structure. Although it’s hard to underestimate that, some players in the market, especially those working for years, have such a complicated pricing structure and a high number of pricing fees that it could be a deal breaker for their potential customers. 

The last part is security measures. Once you’re working on your own payment gateway and your own infrastructure, you mustn’t forget about end-to-end encryption in receiving payment data. Additionally, there are regular security audits. As for PCI DSS certification, it might involve quarterly audits and annual recertifications. In case you’re working with high-risk businesses where fraudulent activity is more common, you can partner with external audit companies that are doing penetration tests and audits from the inside and outside of your system. Finally, the final security measure would be the disaster and recovery plan.

The Importance of Considering Third-Party Fraud Prevention Services for Newly Launched PSPs

Host: Thank you, Andrew! João, why is it crucial for newly launched PSPs to consider third-party fraud prevention services from the start?

João: It’s a good question. For a payment business, it’s always a strategic decision as to when to start fraud prevention efforts. They can start them from the very beginning, prior to launching, or even plan on building their own fraud prevention system in-house with some anti-fraud rules. But it’s important to understand that this process is unfortunately extremely complex. So, to be able to access specialized fraud prevention expertise, individuals and organizations need to consider third-party services. These services must be scalable and be able to adapt to different fraud prevention measures and the life cycle of the business itself. In this way, when these specialized fraud prevention services take care of fraud, they will allow newly created PSPs to focus on their core business activities.

Generally, in the payments world, especially on the acquiring side, there are two types of concerns. On one hand, merchants worry about their own liability and fraud being perpetrated on their platforms. On the other hand, acquirers, payment facilitators, PSPs, and other fintech players that have some form of liability have their own concerns about merchant-initiated fraud, because when there’s a fraud happening in the merchant account itself, the liability for the fraud shifts to whoever did the underwriting and let them into the card network. Because of this, it’s also important for payment businesses to have someone who can protect them against that type of fraud. 

Then there’s also the compliance aspect. Complying with Anti-Money Laundering (AML) regulations has become critical and extremely front of mind to many individuals and businesses. Again, having to deal with developing a strategy for compliance with the necessary regulations without it being a company’s core business can be a heavy burden.

Strategies for Expanding Fraud Prevention Post-Launch

Host: Thank you for the answer, João. Building on that foundation, how can PSPs expand their fraud prevention strategies post-launch to address evolving threats?

João: I would say it depends on the stage of the business. At the very beginning, businesses need some form of light onboarding checks that prevent malicious actors from entering their platforms to protect the merchants they’re able to acquire. But they also shouldn’t put too much friction in the system. Otherwise, it’ll never really grow, and they’ll spend their resources focusing on the wrong aspect. So, it’s better to keep the fraud prevention manual from the beginning until the volumes start picking up. Maybe even just go with some pre-built models with the set of rules that have been tried and tested in the past by several other companies operating in the same region, in the same business segment (low or high-risk acquiring), and picking up from there. Basically, they need to establish and align the strategy of their PSP or the acquirer with an anti-fraud strategy and regulatory concerns tackling strategy, and then develop it as time goes on. 

There are various ways in which businesses can develop their anti-fraud strategy. They can stay light on the transactional fraud side and put emphasis on the onboarding processes. This will most likely prevent money laundering issues, even though the duty of reporting will still be there. However, there still will be the danger of merchant-initiated fraud. At this point, PSPs can choose to have a very light approach when it comes to transactional fraud detection and offload the responsibility mostly to their merchants. And in the majority of cases, it works. For instance, in a low-risk segment of sales with low fraud rates. So, if you’re building a PSP that’s going to work mostly with small companies in low-risk industries where merchants rarely encounter fraud, it’s probably feasible. But then the PSPs will start seeing fraud coming from merchants. 

It can escalate quickly, going from something that looks very simple and almost safe into a major problem that puts their business at risk and puts pressure on it. To resolve this issue, they can start tightening the screws with deeper fraud prevention models that are a bit more aggressive. Then again, when they start tightening the screws rapidly, they can run into operational issues, so they’ll require a professional team to resolve them. And if they’re running a rules-based engine, it becomes quite complex quite quickly. So again, I truly believe that partnering up with experts and with people who ultimately are on your side, try to help your business, and have experience being on the same side as you in fighting fraud is a winning strategy.

Real-Life Scenarios and Strategies for Fraud Mitigation

Host: Perfect. Thank you, João. Do you have any real-life scenarios with specific fraud cases and specific strategies for fraud mitigation that you can share? 

João: Yeah, I can give details on a couple of different cases. The first one is a very prominent and almost obvious fraud pattern we observe in a lot of countries. In this case, the Point-of-Sale (POS) terminals were intentionally taken offline so that they couldn’t connect to the bank’s network to verify transactions in real time. This was made artificially to allow them to process cards that were stolen or had no funds available. Obviously, this was a form of merchant-initiated fraud, extremely prevalent among taxi drivers and supermarkets equipped with older POS terminals that can be taken offline rather easily. Having detected that certain stores had a higher ratio of offline to online transactions on POS terminals, we noticed there was something clearly wrong with them. Due to this, we reported fraudulent activity on the POS terminals and not just on the transactions themselves, leading to the investigation to uncover the fraudulent operations.

Another major case we saw over a year ago, which was a money laundering issue that actually led to a huge fine being imposed on a large bank. Due to confidentiality and legal concerns. I cannot reveal too much about this, but we’re talking about a fine that started at 800 million and then went above the billion mark. The merchant was operating a brick-and-mortar store in a specific vertical that’s not known for high transaction volume, and they leveraged a POS terminal. However, their volume was historic. We ran a test to detect fraudulent activity, and it was blatant and obvious that there was something wrong there. What we revealed was that the merchant had relocated their payment terminal country to Latin America, setting up Virtual Private Networks (VPNs) to connect to their home country. They were processing cards that had been deliberately loaded up with money from numerous illegal activities. And the volumes were massive, involving millions of euros being processed. This was made even more absurd by the fact that most of this volume was being processed overnight because of the time zone differences to minimize detection during active business hours. This blatant pattern of activity was detected during a test aimed at identifying such fraud. In this case, the subject of money laundering was a huge and very well-known bank. 

So, this case was more on the money laundering side. And then there was also a very interesting one on the issuing side. This was a cross-continent case that we spotted. The processed cards were issued in Indonesia, having a very specific BIN (Bank Identification Number), and then those cards were transported to Latin America for usage. Again, it’s quite prevalent. The cards were being used by merchants specifically established to process them. The cards were legally obtained but registered under fake identities, and they had specific limits within a range. But there were a lot of the cards, like really a lot. It was almost an entire BIN that was allocated in one sitting. Hundreds of thousands of these cards were used by a cluster of merchants to commit what is known as “bust-out fraud.” (This type of fraud involves maxing out credit cards that are obtained under false pretenses or with no intention of paying the bills). However, it wasn’t card abuse and couldn’t be considered fraud as the cards were being used by the legitimate cardholders to whom they were issued. Basically, there was a major issue with onboarding involving fake identities on the issuing side. Due to the scale of the fraud and the regulatory failures it exposed, the acquirer faced a lot of consequences as it had onboarded the merchants. However, the issuer was the one that had actually issued the cards. Therefore, it was then proven that it was a network involved both in acquiring the cards and on the merchant side. It was quite brutal since there was one card issuer that shut down their business because of this. This is a case that we know very well and have all the data for it. 

That’s an interesting aspect of working with a company like Fraudio because we acquire data from a lot of different parties. Our engines are trained with real cases, very complex like these ones, and also with normal day-to-day fraud cases. We have billions of transactions and millions of fraud and money laundering cases in our data set. So basically through our integration with Akurateco, Akurateco’s clients can tap into our platform that has been trained with vast amounts of data. For small PSPs starting a new business without almost any data at all, it’s impossible to match the level of performance, because It’s just not how machine learning and AI systems work. You need data to train them. I hope this tickles the curiosity and gives some insight into the cases I shared. 

Host: Thank you, João. It’s always interesting to hear real-life cases firsthand. My comment is that the fraudulent activity becomes blatant and obvious once it gets caught. As soon as you catch them, you see they were attempting to do this. 

João: But also if you know where to look since they are typically obvious from the beginning. When you’re looking for those patterns they’re really easy to find. In this way, you’re able to find these problems after just a few transactions were completed or even while they’re being processed. After detecting fraud, you can also block transactions, merchants, and entities before funds settlement, literally reducing the exposure to fraud to zero. To detect more complex cases, you need a few transactions to go through since you cannot distinguish fraud by one transaction. But then if the transactions happen quickly and you see them taking place within a window of pre-settlement, it’s very simple to just block or delay the settlement while you do an investigation. You can release funds if the investigation turns out to be negative. This way, in really, a lot of cases we’re able to save 100% of what would otherwise be a massive fraud loss.

Akurateco’s Fraud Prevention Engine

Host: Yeah, I agree. So basically, João explained that for startup PSPs, it would be enough to have a manual set of rules within the system to detect very obvious fraud. Is there an engine within Akurateco to do this, Andrew?

Andrew: Yeah, sure. I wouldn’t say it’s simple, because the number of rules we have in the system is already pre-created based on our hands-on experience in payments. As of now, the system has more than 140 rules, from the very obvious ones like a number of payment attempts or matching IP with a BIN to much more sophisticated ones. Also, you can make a combination of those. Such a system could help you eliminate not only simple fraud but all potential fraud in 85% of cases. 

What’s more, our system can identify fraud and potential fraud patterns. For instance, we have a merchant-initiated fraud, which occurred on the side of the merchant, say when selling shoes. It has some specific tickets, peaks of sales, intensity of sales, and so on. But for some specific reason and at a certain time, the merchant by himself or his affiliates mixes this traffic with something different, which is not shoes. But it had the same ticket size, the same volume, and the same intensity. So, if you have enough data set and understand the behavior of the customer who is buying shoes, you can build your own model to see the difference in their activity and notice those peaks of strange behavior. 

Our experience is that having these anti-fraud rules in our system helped us to identify a specific merchant. There was a unique situation when after three or four months of working during the weekends, the merchant experienced a slight growth in sales and volumes. The model has recognized those peaks in the behavior, the intensity of the sales, and the other parameters that could not be identified if you look for them yourself. And after coming back to the merchant with the questions regarding this issue and not getting any clear answers, we blocked them. At the end of the day, although I cannot share the details, it was indeed not shoes at all. Of course, it turned out to be a potential risk for the acquiring bank and for anyone who was involved in that process. So it was obviously merchant-initiated fraud, which would not be possible to identify if you don’t have such manual fraud prevention checks.

Another simple example could be an e-commerce merchant working internationally that has different affiliates sending traffic to it. A merchant needs to measure the performance and indexes like the acceptance rate, fraud rate, chargeback rate, retries rate, and so on for each particular channel. In general, it could be the average level of chargebacks not exceeding the limit. However, it’s very important to track information by affiliate channels divided by the affiliate IDs and other parameters because then you can immediately see if they vary significantly from one affiliate to another. In this case, it probably makes sense to increase anti-fraud measures for this particular channel. On the one hand, you’ll safeguard yourself from surprises like a rapidly increasing chargeback ratio from 0.5% to 1.5-2%, which will bring you to closing your terminal. On the other hand, if you apply all those anti-fraud measures to all payment channels, it will not decrease your acceptance rate.

Host: I think the question is covered. Andrew and João, thank you so much for the input and insights. It was great to hear it from the horse’s mouth.