The real payment meets fraud journey | Leaders in Payments Podcast

Hello, and welcome to the Leaders in Payments Podcast. I'm your host, Greg Myers. Joining me today is a very special guest, Brian Rust, SVP and Deputy Chief Information Security Officer at Worldpay/Global Payments. Thank you so much for being here and welcome to the show.  

Thanks for having me, Greg.  

This episode is part of our signal series where we're cutting through the noise to reveal what truly matters in payments and FinTech. Today we're talking about the real fraud journey platforms face when they embed payments, where threats actually show up across onboarding, transactions, and refunds, and why the platform itself is increasingly the target. Brian's going to help us break it down in a practical way and share what layered defenses ISVs need to protect both their businesses and their merchants. So, Brian, before we dive deep into this topic, can you walk us through your professional journey and how you got to Worldpay/Global Payments? 

Yeah, absolutely. Like many people out there, I kind of have not a direct straight-line path into where I'm at now. Surprisingly enough, the question of what do you want to be when you grow up is still something I honestly don't know the answer to. I talked to my children about it. I'm like, just be happy. That's the ultimate goal. But I actually came up through the audit and compliance side of the house. Earlier in my career I was in operations roles. I ended up in audit and compliance companies like Genworth, Capital One, and McKesson. Audit does a really nice job of helping people learn the why and the how of controls and risk management. That kind of auditor mindset of looking for gaps and understanding this systematic risk, was really a natural bridge for me to move into cybersecurity. I was in cybersecurity leadership roles at General Electric, managing their global product security instant response team, as well as their assessment services, a wide variety. And then was at Regional Bank, the First Financial Bank that's based out of Cincinnati. I had a few different roles there, served as their interim CISO, and then was asked to come over here to Global Payments. Well, Worldpay, then Global Payments. And then I've been part of this organization for about 18 months now, I guess. Time seems to fly by, doesn't it? But that blend of governance for my audit days and kind of operational hands-on with responding to fraud and cybersecurity threats and things of that nature from financials and the industrial security space. What I focus on here is product security. As the deputy CISO, I'm responsible for commercial product security, essentially building the security into the payments platforms that power our merchants' businesses. So, this is from an ideation all the way through a run type of activity. My product security leaders are engaged throughout the product's lifecycle from advising and helping to the development teams to understand what's the risk, what could go wrong here, doing threat modeling, really kind of helping them understand how to secure the platform.  

So, most of the audience is going to be familiar with Worldpay and Global Payments and kind of the combination that's happening. I mean, obviously in the industry, everyone's well aware of that. But just for context, can you give us the quick 50,000-foot-level overview of the company and then kind of where your team fits into the broader organization? 

The combined Worldpay/Global Payments is a leader in payment technology, right? We process billions of transactions annually. Specifically, the product security and assessment services team, the product security team that I have operates in that intersection between development and security and working with the product teams as well. I'm not the information security team of no, never have been, never will be. If the business tells me they really want to do something, I'm going to advise them on the risk and help them understand what could go wrong and advisements. Like if you want to go check to see if the power works by shoving a fork into the outlet, you're going to find out if the power works or not. But that's a really bad way to go check and see if the power works. But if you're insisting to me that you're going to do it that way, I'm going to insist upon like, hey, can you wear some rubber gloves? Can we do this when nobody else is working? We design control structures to match the risk that is out there because being in business is about taking risk. There is a certain inherent risk that we have to take on being in part of business. And my team really sits in between that intersection of helping those development and product teams understand the risk and how to build controls to properly mitigate the risk that exists out there. I want to make sure that the software that your ISVs or the ISV partners are using is security by design. We focus on the payment ecosystem itself, making sure that when the ISV embeds our payments, they're not just inheriting the transaction capability, but they're also inheriting that security posture that we've been building from the ground up from the design perspective, all the way through the life cycle of the product. 

Well, let's dive in and we're going to sort of start at a higher level and then dig deeper as we go. So at a high level, how is the fraud landscape changing for these SaaS platforms or ISVs, kind of use the terms interchangeably, but how is the fraud landscape changing for them, the ones that are embedding payments? 

Fraud has really moved upstream. It used to be about let me steal this individual card and go use it. Fraudsters are targeting the platforms themselves. They're attacking the infrastructure of the ISV instead of just the fraudulent transactions. We see attacks on the account creation process, the API logic, and the refund workflows. The ISV is no longer just the software provider. They're the gatekeeper of that financial ecosystem for the merchants. 

Okay. And why are they, the fraudsters, increasingly targeting the platform itself? I think you kind of mentioned it used to be, hey, go after the card, but it's much different than that. So, they're not really even going after, necessarily, the individual merchants on the platform. It's actually the platform itself. So why are they increasingly targeting the platform? 

Scale and efficiency, right? These fraudsters are running businesses. These are not just individual. There are some, don't get me wrong. There are individual threat actors that are out there. Generally speaking, these threat actors are well organized. If you peel back the onion on them, they run like corporations do. They have human resources, they have recruiting, they have people complaining about Bob cooking fish in the microwave at lunchtime. They run very sophisticated businesses. And if you think about it, where do you get more bang for your investment and resources and time? That's going after the platform. Say they find a vulnerability in how an ISV handles onboarding. They can spin up 500 fake merchant accounts pretty much overnight. Targeting the platform allows them to automate those attacks, right? It's about they're not just looking for that one door that's unlocked when you're walking around and trying to open car doors, right? They're really looking for a master key to the building which allows them broader access than just one access point would give them. So that's the reason why that they are increasingly targeting the platform. It's really just because it supports the scale of the business of fraud that they're in. 

That makes a lot of sense. So, when you think about the fraud journey, if we want to call it that, what are the main stages across the platform's life cycle? 

I like to think of this in kind of three areas. There's the entry, the action, and the exit. The entries - the onboarding, the actions - the transaction, and the exits - the post-transaction. The entries where the threat actors get in the door using the fake identities, the synthetic businesses, things of that nature. Once they get in, the action is that they're going to typically do traditional card testing and velocity attacks, right? Those are transaction typical. And then the post-transaction, the back end, this is the refund abuse, this is the chargeback fraud, this is the diverting funds before the platform notices, types of things. That's how I think about it. 

Okay. Yeah. And we're going to dive deeper, I think, into each one of those. So, let's start with the onboarding. What are the most common ways that these bad actors get onto the platform? 

Yeah, automation is a primary driver here. So, as I mentioned before, there are some individual actors out there, organized rings. They use bots to fill out the merchant applications automatically, right? They're trying to scale. If you think about the time it takes for an individual to sit and type and enter the information versus, you know, let's go try to enter the information for hundreds at all at one time. They're using data stolen from real businesses, right? Identity theft for a business or business identity theft. They're using that to pass your basic know-your customer, KYC. checks. They're impersonating the business to get approved for payment processing. That's really the onboarding of the most common ways that they're getting in the platform. 

What are the synthetic businesses, AI-generated identities? I mean, those are some kind of terms that we hear. What do they look like actually in practice? And what should the ISVs look for? What are the kind of the early signals? 

Reality, they look like a ghost, right? These are businesses that have an address that might be a residential house or it could be an empty lot, and you look up on Google Maps, and there's just nothing there. The website is usually a template that's been registered a handful of days ago, but claims to be in business for 20 years. So, if you've got a mismatch on, say like domain registration and how long the business has been business for, sometimes that's things that you can key off of. The threat actors are using AI to really reduce the complexity it is for them to go create these synthetic identities. AI really speeds up their ability to go generate all of these identities on a much faster scale, and they simply can prompt it to say, hey, I want a business. Generate me 35 businesses with websites that do XYZ in this region. It reduces those barriers of entry for the fraudsters to go create this. So, it allows them to create these really good synthetic identities for businesses or synthetic businesses very quickly. And it really reduces the complexity that they had previously to be able to go create this, right? Like it's fixing grammar language things for non-native language speakers. It's fixing those types of things that were usually like, yeah, people don't talk like that. But the AI is taking that kind of signals intelligence that we had before, and it's getting rid of that. So, it's making it harder for ISVs and others to be able to identify these as readily as before. And it allows the threat act to grow faster, right? It is accelerating their cycles from the start to the finish. But the early signals to your question are typically behavioral. We can still catch things like, hey, did the application form get filled out in an impossible amount of time for a human? Did it take three seconds to fill out the whole form? Is the IP address for the applicant different than the physical address of the business owner? As an ISV, you need to look at the metadata, not just the data that's in the form fields, but you really need to compare that metadata that's being passed when the forms are filled out and see if it aligns with the data that's presented for the business. 

Okay. So, once the account is live, so let's kind of move on to the next step. Where do you typically see the fraud show up next? Is it bot-driven accounts, account takeovers? Are we talking about transaction fraud? And then which one of those is kind of the most damaging for these platforms? 

It's usually card testing, right? You'll see the new merchant account that sell you processes a thousand transactions for a dollar or less in each in 10 minutes, right? They're using the platform or using your platform to validate the stolen card numbers. It is a way to just figure out do I have something that's going to sell on a card market for $20 or something that is essentially worthless from a card perspective. They are trying to determine the value of the cards that they have. It's incredibly damaging for the ISV because it can ruin your reputation with the card networks, right? It can lead to fines, it's loud, it's fast, and it burns the platforms that aren't really watching their velocity limits. 

So that was kind of in my mind, like the middle part, but now let's move to maybe the back end. Refund abuse is a big theme right now. So what patterns are you seeing there? And how can platforms reduce this abuse without it at the same time creating a bad experience for their customers? 

Yeah, refund abuse is tricky because it's an exploitation of trust. When we see patterns on where a customer buys, say a high value item and then claims it never arrive, they get a refund and they keep the item, right? Or the fraudster poses as the merchant and processes a payment on a stolen card and then refunds it to a different card that they control. So then they pretend to be the merchant, purchase an item, refund it back. So, they're double dipping on multiple angles there. To stop this without hurting real customers, you need conditional logic, not allowing refunds to a different card other than the original purchase. Velocity limits on refunds. If a user's refunding half of all their purchases, flag them for a manual review. It's about causing friction, right? We need to add friction only for the anomalies. And as mentioned earlier, fraudsters are running a business, right? And they are doing things to automate their processes so they can go faster. If you're doing things to add friction to their process, you're making it more expensive for them, which is making it harder for them to do business with you, and you don't want them to do business with you, right? So, it's about making it harder for them and adding friction. And yeah, it's a cat and mouse game, right? We do something to add friction, they do something else, and it continues, but you got to have that spot of friction in there and really it's a balance. I get it, right? Like you've got customers that, hey, I bought it on this and you funded this, and they're sitting there asking. It's hard to say no. A lot of us grew up in a culture of the customer's always right, and it's an exploitation of trust. If somebody says that it didn't show up, like, well, yeah, sometimes it didn't show up. Sometimes the item got stolen somewhere else on the supply chain. Sometimes it's the end user. And it's really, really hard to tell the difference from one from the other. So then it comes down to mentioned earlier, we're in business to take risks. Everyone has to take some level of risk as being part of business. It's about setting up what are the appropriate controls to mitigate that risk that's in front of you. And that's that friction that I'm talking about and building into your operational processes. I know this beyond just like the cybersecurity side of it, but it fits into a holistic approach of how do you defend against these types of things? 

Sure. I would think ultimately you want no fraud, but if you can't have that, you want to catch it early. So, what are the core metrics or alerts that ISV should monitor in order to catch fraud early across their merchants, their users, and the transactions? 

I think I've mentioned some of these already, but I'd prioritize three things. Velocity, right? We spoke about that, spikes in transaction volume or frequency, things that just don't fit normal behavior. Decline rates, like if a merchant's decline rate spikes, say over 10 or 15%, they're probably underneath a card testing attack right now, right? There's normal rates that you see for each merchant or bucket of merchants or however you define your thing, you can do behavioral monitoring on those to be able to model what is the decline rate that we need to look at. And that's where going back and looking at your historical kind of attacks and where they fit, you can figure out where is that threshold for where you know your people that are monitoring will step in and say, hey, yeah, this is more than likely a card attack. Geographic mismatch is the third. If you've got a high volume of transactions coming from a single IP address or country that doesn't match the cardholders issuing bank, that's pretty table stakes. Let's go ahead and monitor for that. Those are kind of the core metrics and alerts that if you’re a ISV that you should really monitor. 

Okay. Well, we often hear this term layered defenses. So, what are the key layers that you'd consider sort of table stakes for an ISV? 

Yeah, I mean, layered defense is Swiss cheese model, right? You take a bunch of pieces of Swiss cheese, you lay them on top of each other, the individual piece of cheese that's got holes, but stack them all together, it's really hard to find that single path through. Table stakes are no longer just a firewall, right? You can't just rely on your web application firewalls and things like that to stop all of that. You've got to have identity verification, document scanning, and biometric checks at onboarding, things of that nature. Device fingerprinting is another area of things. So, I mentioned this earlier in previous answer, but behavioral analysis, right? You can get to the point where you can assume a certain merchant's coming, who the merchant is before they actually log in based off of the fingerprinting on the device, where they're coming from, their pattern of when they log in and check things. There's a lot of those types of behavioral analysis that you can really tie in, mouse movements, typing speed, screen resolutions, things of that nature. Like people don't generally log in from a different machine every time. There's a pattern to how they interact with your site. And then the other one, I would say, is transaction monitoring, you know, rules that stop the money from moving if it violates set parameters, right? When I think about these types of layered defenses, I think of the anatomy of attack, right? So how you get from the initial compromise all the way through there's stages of that. And they call it a cyber kill chain on the cybersecurity side. The terminology came from a paper that Lockheed Martin put out 11 or 12 years ago now, of how do we systematically look at the history of an attack from initial compromise all the way through the objective met. And this, in a sense, almost always is the objective is stealing that money, right? There's a fraud kill chain that exists that that groups have been working on that follows along with that. Talk about layered defenses. Making sure you understand what that kill chain is and how and where you sit on that kill chain and where you can interact with the different steps along there, I think is really, really impactful. One of the things that I do with my teams is we align a lot of our work against MITRE attack. MITRE ATT&CK is a framework of ATT&CK that is known, observes tools, techniques, and tactics by cybersecurity or by threat actors that are generally cybersecurity focused. The world that we live in is, though, is that the fraud and cyber worlds have really emerged. So, your threat actor that was not financially motivated previously may be financially motivated now. And a lot of their tactics, their tools, their tactics, and their procedures that they're following mirror or look really similar to those cybersecurity tactics. So, you've got a fraud cyber kind of fusion that's happening. So, as part of your layered defense, if you have a separate fraud team from your cyber team, make sure that they're working together, make sure that they're talking, make sure that they are sharing intelligence between the two, participate in different information sharing groups if you have one available to you. Those are great ways that you can get signals intelligence to be able to help bolster your defenses, to really kind of layer those defenses in. End of the day, it's cliche, but it's people, right? People are always going to be our best lines of defense. There's automation and things we can do, but it comes down to people looking at those things we talked about earlier. You asked me about what are some things that you would monitor for, right? Someone's got to be sitting there monitoring that. Someone's got to make the decision and say this exceeded our threshold. What do we do now? So, understanding what's next for you and having those well-defined processes within your teams when things come up, then you're prepared and ready. I think we can go on for a whole hour on layered defense, Greg. I don't want to do that to you, but that's really kind of how I think about it. And just tie it back to like the work that my team does. From a layered defense perspective, I've got a product security team that is embedded with the development teams so we can better understand what the product is so we can help defend it better. Having a security team that knows the product as well as the product teams do and the engineers do is critical to be able to help secure that product. That is part of a layered defense is knowing your business, making sure that people up and down your stacks in different places know your business, vendor management, things of that nature, like all of that all fits into your defensive posture that allows you to better respond to things that come up and having a culture where people really are able to say, yes, this doesn't look right and make a conscious decision of let's go question this. Again, I type back to IFCs and customers and real customers. Got to do it in a way that increases the friction for the threat actor, but reduces the friction for customers, which then gets into there's always going to be some level of trust that has to exist. And that's where, again, people is the key of this all, right? Like in the day, it comes down to your people and really just empowering them with the ability to make those decisions to be able to help you figure that out. Again, touch on like three things though. We talk about layer defenses, I have three key layers that firewall is no longer your table stakes, device fingerprinting, behavioral analytics, and transaction monitoring. Those are the three or four things that I would say immediately. And then all the other stuff I added on there. 

I think it's great advice, great knowledge for people. I mean, explaining that, like you said, we could do a full episode on just that. So, one final question before we wrap up the show. If a platform or ISV wants to really get serious about fraud prevention right now, so let's say this quarter, what are the first three actions you'd prioritize to reduce risk quickly while staying compliant and protecting their reputation? 

If I was a chief information security officer at an ISV today or their security director, three things I'd do immediately is audit your onboarding process. Understand that process, make sure it's well documented, turn on CAPTCHA, bot detection on your signup forms. You got to stop that bleeding at the front door. You got to make sure you understand the process flows and where that is. Do a threat model on that, right? Understand where your weaknesses are, where you could be attacked, what could go wrong. Understand what your trust boundaries are of when you're passing information from one area to another through your trust boundaries and what your controls are on those trust boundaries. You know, I'd start right there with the auditing of your onboarding process. The next thing I look at is if you don't have velocity controls implemented, it's table stakes. You got to have hard-coded limits on how many transactions a new merchant can process within a certain time frame. Where that time frame fits could be 30 days, it could be 45 days. It really depends on what you think is right, but you've got to set a date and say, how do we treat new merchants differently than existing merchants? Because trust is built over time. Now, here's the thing you set it for 30 days, the threat actors start learning that it's 30 days, and then they stay quiet until day 31. So, I'm not going to say a hard set and fast date. What I will say is there is a time period that you should treat a new merchant differently until you build that reputation of trust, until you can get the behavioral monitoring on them to build the baselines to understand what normal interactions with this merchant looks like. And then talk to the processor, leverage tools at Global Payments, or if you're using another provider, leverage those tools that they already have. I can speak for Worldpay and Global Payments. We've got massive data sets on fraud. We can help you with that stuff, and we can really assist you with understanding those types of things. If you want help, reach out, right? We'll be glad. I'm sure your processor who is not Worldpay or Global Payments, will be glad to help you as well. We can really assist you with understanding those types of things. Turn on address verification or card security code filters, some things that are sometimes left off by default. There's different things that your processor is going to be able to help you with. And don't forget to use this as a resource to really secure your company and to be able to enable those merchants. 

Well, Brian, I think that's a great way to wrap up this show. So, thank you so much for being on the show today. I know your time is very valuable, so I really appreciate you being on. 

Yeah, thank you very much, Greg. It was a pleasure to be here. Have a good rest of your day. 

All right, you too, and to all you listeners out there, I thank you for your time as well. And until the next story.