“Payments Performance Optimization” is a pretty broad term, and it might mean different things to different people.

In a series of Payments on Fire episodes this year, Glenbrook’s Drew Edmond will be talking to guests who are approaching payments optimization from a variety of different angles, with a focus on primarily online, card not present merchants.

At the end of the day, a merchant wants the maximum number of good transactions to be authorized successfully. It sounds so simple. But is anything in payments really simple?

In this episode, Oban MacTavish, CEO and Co-founder of Spade, joins Drew to explore this issue by focusing on merchant data, and how issuers make decisions about card transactions.

Drew Edmond: Hey everybody. I’m Drew Edmond, an Associate Partner here at Glenbrook, and your host for this episode of Payments on Fire. Before we jump into our discussion today, I’m excited to announce that this episode is the first in a series of podcasts I’ll be hosting this year focused entirely on payments performance optimization, where I will be talking to people who are approaching payments optimization from a variety of different angles.

Now, first I want to say that I realize that payments performance optimization is a pretty broad term, and it might mean different things to different people. For the sake of this series, we are going to be discussing the concept of improving transaction and performance for primarily online card not present merchants, or at least omnichannel merchants that have some sort of card not present component.

We’re going to focus on what is essentially the number one metric for most online merchants, which is the transaction approval rate. You may hear it referred to as the acceptance rate or the payment success rate, or for you pessimists out there, they may look at the inverse metric and refer to the decline rate. But at the end of the day, we are all focused on the same thing.

A merchant wants the maximum number of good transactions to be authorized successfully. It sounds so simple, but is anything in payments really simple? If it is so simple, why does the same card for the same transaction from the same merchant get declined when one acquirer or PSP tries to authorize it, but then it’s successful when that same transaction is routed through another PSP.

If things are so simple, why does an issuing bank send a merchant a decline with a reason code that says invalid card number, then successfully authorizes the same transaction sent with the same exact data one second later?

Why would a bank decline a monthly subscription payment for a service I’ve used for three years claiming it is now suspected fraud. It wasn’t fraud the first 35 times, but the 36th purchase is somehow fraudulent. If you talk to any merchant, you’ll hear many questions like this because a lot can go wrong in payments and merchants have to fight the good fight consistently to maximize their performance.

Before we get too deep into the weeds, and believe me, we will be getting deep into the weeds in this series, but before we do that, let’s take a quick step back. Because you might say, Drew, e-commerce is growing by leaps and bounds. Global e-commerce is around $6.5 trillion in annual processing volume and growing year over year. So on the macro level, things look pretty great.

But if you are an online merchant, you know full well that it is a constant battle to reach maximum approval rates, conversion, and in the case of subscription merchants, customer retention related to failed payments. The world of e-commerce payments requires significant dedicated resources if a merchant wants to consistently experience optimal or even acceptable approval rates. And even with incredible effort, some merchants don’t come very close. And in our discussion today, we are going to dive into why this problem is so hard and so evergreen.

In this episode, we are going to explore this issue by focusing on merchant data and how issuers make decisions about card transactions. Joining me in this exploration is someone who is so dedicated to this issue that he started a company to address it head on. I’m very happy to welcome Oban MacTavish to Payments on Fire.

Oban is the CEO and co-founder of Spade, a company that specializes in enriching transaction data with the goal of improving transaction success while minimizing fraud. Oban, welcome to Payments on Fire.

Oban MacTavish: Great to be here. Excited to chat about it.

Drew Edmond: All right. Well, as we always do, let’s start with kind of the foundational ground level question here. We’re always curious about how people get into the payments industry, so let us know why you’re working in payments and what brought you to where you are today.

Oban MacTavish: I wish I had a really clean story unlike, or maybe like many people in payments, I think you kind of find your way in and suddenly now this is all you do and that’s all you can think about. I’m a two-time founder. My first time company was completely unrelated to payments, like we were working in vertical SaaS for wealth managers.

So very, very different experience. And I started that right out of college and did that for a couple years. COVID-19 happened, obviously the whole world got turned upside down and I ended up starting a second company, Spade, and really focused in on what I felt like was one of the most obvious unsolved problems in payments, and also just broadly fintech in that we have trillions of transactions, trillions of dollars and trillions of literal transactions happening globally along the card rails and obviously every other payment rail that are all relying on global standards that are transparently just like low quality.

if you’re trying to get tens of thousands of banks to agree on how exactly a message should be communicated, it’s going to be challenging, which creates situations where the data is incredibly lacking. And if you think about when these protocols were built, they were broadly built at a time when e-commerce wasn’t as widespread as it is today.

Payment methods are really, the idea was like you’re going to be in person taking a card in and a lot of the sort of things we would expect now, whether it be identity, risk scoring and all these really incredible things that have come out since, didn’t exist, so it creates a really weird standard.

And that’s why we built Spade. Really focus on the problem of how can we make it so our customers’ financial institutions can deeply understand their payments data and help them solve those really mission critical problems. There’s a whole lot we can talk about there, but I think that’s really the origin of Spade.

Drew Edmond: So let’s set the problem statement for the discussion. I think there’s a lot of different areas that we can go into and think about how Spade is approaching this and honestly just learning about what you’ve learned along the way as you started to grow Spade and the conversations you’ve had across the ecosystem with merchants, with issuers, folks in the ecosystem like that.

So I think about this kind of through the payments operations perspective. I used to be in that seat at a marketplace, at a payment service provider. Those teams are really dedicated to essentially, from a payments angle, increasing revenue and reducing costs, like any business really, but really focus on that through the lens of that core metric of approval rate, right? If we’re a merchant, a business that’s accepting a lot of cards, that acceptance rate is critical to your business, right? If it’s super low, you’re not making any money, and you want to optimize that and maximize that as much as possible. Now ultimately the issuer of the card being used is responsible for making the decision on whether that card transaction is approved or not.

And we should be fair to the banks a bit, right? They have to protect their own business. They’re protecting their customers of which we all are a part of, if we’re cardholders. They’re managing fraud and chargebacks and fraud loss and things like that. But we’re kind of claiming that banks are declining too many transactions, right? They’re declining too many good transactions.

I’d like to learn more about this from the bank’s perspective, given that you’re working so closely with them. So I’d love to learn from you, what data does a bank see during a card transaction that they use to actually make that transaction, and why is it so hard for them to make good decisions consistently about transactions?

Oban MacTavish: Yeah, it’s a great question. I think there’s, and it touches on some of the systematic problems that exist, the reality is most financial institutions see a lot less than the merchant. They know who Drew is, they know who Oban is, they know our history, and they have models if you think about the primary place they’ve enabled them to stop fraud is things like FICO Falcon, the network level scores that historically have really been focused on the consumer. It said, Hey, we can kind to figure out how Drew’s going to spend, and if Drew does something super weird, maybe your bank’s going to call you and say, Hey, this is really weird. Why are you trying to spend this much money? Why are you spending at this business, et cetera.

The problem is that that’s all been driven on the fact that they’ve had higher fidelity and data into what Drew looks like and actually very little context as to who the business on the other end of the transaction is. And I think with the rise of e-commerce where before, you could operate under an assumption, like Drew walked into the store, he took his card out, gave it to someone, they swiped it, you put in your pin.

There’s a lot of trust there. This is a real business. This isn’t a fake business. And if he’s getting scammed, it’s probably really hard for him to tell it’s a scam and what have you. The reality of e-commerce, scams, fraud, the dark net, buying card numbers, card testing schemes, BIN enumeration attacks, the vectors of attack from an online perspective have changed dramatically.

And unfortunately, the perspective on who the business is on the other end hasn’t. And that’s really where we come in. Not to just talk about what we do at Spade, but I think when we work with issuers, we’re really saying, Hey, you’re really good at understanding who Drew is. We don’t want to change that.

We’re not going to tell you we know more about Drew than you do because we don’t. but what we do know about is these businesses. We know that this business has a website that’s covered in stock images. We know this business has appeared on literal lists of people who are like, I’ve been scammed by this number. They’re calling me, and now they charged my card $5,000.

We’re really giving people a different perspective on the merchant, which is where banks have really historically struggled to find that perspective. And if you think about the strategies they employ, I think that is very clearly represented by it, right? They’re blocking MIDs, making adjustments based on MCC codes, maybe tracking the dispute rate on a specific MID. And the unfortunate reality is that many of the behaviors trustworthy merchants do to try to optimize their payments actually look a lot like a scammer.

And it’s this weird sort of double-edged sword where on one hand we all admit that we want to maximize auth rates because having your transaction declined is unbelievably frustrating and it damages your trust with your bank, but on the other hand, these fraudsters are very sophisticated.

They’re going to come in, they have five to ten different merchant IDs, they’re going to go to different MCC codes, they’re using the most trustworthy MCC codes, and it makes it really hard for the bank to come up with a strategy of saying, how do I minimize fraud losses while improving performance?

I have a lot of empathy for these teams because if you’re not JP Morgan Chase, you’re not Capital One, Bank of America, et cetera, you can’t employ thousands, hundreds of data scientists to tackle this problem every day. And the reality is most people, when you’re engaging most merchants, there’s going to be transactions happening at these less sophisticated banks where they really are limited in the strategies they can employ.

And I’m happy to dive more in there, but I think that’s a good place to start in terms of what exactly does it mean and how is the bank trying to handle that.

Drew Edmond: I always wonder about that, the variability across the issuers, right? We’ve got thousands of financial institutions in the United States alone from Bank of America down to People’s Trust of Arkansas, right? Extremely different resources related to not only the human ability or data scientists or folks that they can point at this particular problem, but also just the capital to spend on tools and those models and those types of things.

So I’m curious, how do they think about it? For some of the smaller banks or credit unions, and maybe even some of the larger ones, are they saying, I’ve got an issuer processor, they handle this for me. As long as I’m within a range of acceptability, I’m not even looking at this. How many banks are actively trying to solve this issue for the merchant rather than for themselves necessarily?

Oban MacTavish: Yeah. I think the funny part about it is that, I can’t speak to every bank and every financial institution is unique. They all have their own perspective on optimizing payment rails, payments and fraud, and where they sit on the spectrum of deciding what they wanted to do is very variable.

But what I can say is that two things are really clear. One, some people can’t even make any decisions at the auth flow. They rely on the processor. They might not even get the data at the time of auth. I think some merchants or people on the merchant side forget. They’re like, Well, of course, just look at the data. How Hard could this really be?

The fundamental truth is as a bank, you might not even get access to your payments data until a batch file at the end of the day. And that changes things. And I think it means that banks will often, it’s hard to approach these problems with a scalpel, when it’s so much easier to stamp out the problem with a hammer. And when your customers are calling you saying, oh my God, I’m losing thousands of dollars, what happened? I think the reality from the merchant’s perspective oftentimes is, Oh, that’s too bad. We lost that customer. Oh, their card was compromised. Maybe they’ll never buy a bed from us again.

To the bank, the person’s like, I’m going to rip out my mortgage. I don’t trust you anymore. How can I fix this? I often think about it, there is a fundamental difference between how much risk the bank is taking on as a business for every single payment and how much money they make versus the merchants, and they’re essentially completely inversely correlated.

Merchants, especially many of these subscription businesses, high margin, very sticky, all of your job is, Hey, I want to give you your subscription to a box of food you get every month. And their margin at minimum is probably 30, 40%, maybe higher, maybe lower, whatever. The bank is potentially making 1 to 2% per payment and the cost of being wrong there is a lost customer, which includes all of these financial products. It includes a lack of trust. It includes someone calling up their local radio station and saying they got scammed by their bank. And I do think there’s this massive, almost completely different perspective that the financial institutions and the merchants have.

And I lost track of your question, but I think that where this results in is a lack of the flexibility from a technical perspective. And it also means every single bank operates so, so, so differently.

Drew Edmond: Yeah, absolutely. I think each of these institutions is going to have different, maybe internal models when they think about risk, when they think about the various revenue streams that they have. That 1 to 2% that they make on that transaction, that’s not just profit. Oftentimes, it’s just going back into rewards or paying for other things that happen in the bank. It’s a funding stream, but it’s not just like, Hey, oh, we just made a bunch of money. It’s great.

Oban MacTavish: And I think it’s funny because when we talk to different sized banks, how they view their payments is so dependent on how they’re using their money and their risk profile and their scale. When we think about the core strategies they’re leveraging, it ranges from like the simplest rules, block an MCC, block an MCC if it’s over a certain dollar amount, block a MID, to people running real time authorization models based on external data that they partner with someone with their API. Cap One is a good example with their APIs or pulling in additional data, they’re trying to do all these things.

And I think the irony of all of this stuff is they’re still experiencing false declines, they’re still experiencing fraud. This is a completely unsolved problem. And I think one of the big questions I think the industry is trying to figure out is okay, whose responsibility is this? How much can the bank really solve or the merchant really solve by themselves?

Drew Edmond: With this podcast series on payment optimization, the points we want to make along the way as we talk to different folks, one is, no silver bullet. Two is that, because it’s such a diffused problem, there’s so many different angles to attack it at, right? That’s why I love that we’re starting here with the merchant data piece because I think it’s a really important component that actually doesn’t get talked about as much. You hear a lot about 3DS and you hear a lot about things that the merchant can do or that the PSPs are doing, but we often don’t hear a lot about the issuing side.

We’ll talk a little bit about Cap One and things like that in a moment, but we just hear a lot on the front end when ultimately that’s not where the decision’s being made. trying to do all these things to plug these holes, but ultimately it’s, we’re going to do all that and it’s still in the hands of the bank and let’s hope for the best. And so that’s why I was really excited about this conversation.

Oban MacTavish: Totally. It’s one of the things I find as we’ve spent time in merchant data, it’s one of the use cases that’s really stuck out to me as a huge, huge opportunity. That’s why I spend so much time here. So yeah, it’s near and dear to my heart.

Drew Edmond: I think that’s a great segue to the next question. Let’s dig in a little bit to Spade specifically because I think it’s helpful to understand where you started, where you’ve grown the business, what are your customers. Let’s get to the details on that because I think it’s important.

Oban MacTavish: Yeah, absolutely. So we like to call ourselves merchant intelligence, but I think for a long time people called it transaction enrichment or there’s a variety of different names for this. But in essence is we’re taking in those, as close to the metal as possible, payments payloads from financial institutions and fintech companies, and then telling them a lot more about who’s involved.

That’s the simplest way to think about it. How much more clarity can we give you about the merchant your customer is spending money with and what they might be doing there? It ranges from everything from literally just a name to contact information to categorization that doesn’t rely on MCC codes to potentially risk insights.

And then even some very unique things like our counterparty ID, which is a sort of a unified merchant ID. Think of it like if we took all of the MIDs that Amazon leverages, these millions of things, they’re popping up, they’re disappearing, with changing, et cetera, and we’re like, No, no, these are all Amazon.

And then we told the bank that. And all of this is really in the pursuit of helping them solve really hard problems. I know we’re talking about payments authorization today, but we help people solve rewards attribution problems. We help people solve reduced disputes by giving more clarity to customers, and surfacing contact information. So instead of calling their support desks, they’re calling the merchant and asking questions.

We’re also helping them solve things like fraud in payments, and I feel like it’s not a podcast if you don’t talk about AI, but people monetize their data lakes in a variety of ways and we’re really there to help them do it all.

We work with really big fintech companies like Stripe issuing, we work with Corpay, the largest B2B Mastercard issuer in the United States, and a whole host of other people. It’s a really interesting business to be in. We really focus on building a canonical source of merchant data and then doing the really hard job of taking that payment payload and telling the bank all about the business in under a real time P99 of under 50 milliseconds. This helps people do really hard things like authorization decisioning.

Drew Edmond: Right. Is it that you’re giving them a score or you’re providing them some list of data and they’re incorporating that into their own models?

Oban MacTavish: I think we just look at this from the payments lens, there’s a couple ways people leverage us. First off, we can tell you the geographic location data of this business. Now, for online payments, not really that important, but for something like an in-person card payment, you can compare that to the geographic location, you know where someone lives.

You can do things that can help track fast travel. How is someone spending with Apple Pay over here and they’re swiping their card over here and track ATO. And then we can do things like, we can give you this counterparty ID, this merchant ID, and then you can essentially look at the actual dispute rate across all these MIDs to prevent, some of the tactics people use like rotating to a new MID if their dispute rate gets too high. We can say, Wait a second, this is the same business. And we’ve done numerous POCs with people that have proven if you block based on our counterparty IDs, you save money on fraud losses. Because so much of the time a business will just change to a new MID.

They look like a completely new business to you and apparently get this clean slate. But that shouldn’t be the case. We should be ensuring that if you’re a really good high-quality business, you’re getting the benefit of that without having to follow some of these strategies. But if you’re a low-quality business who’s lying to customers, scamming, not sending things, your subscription goes from $399 to $400 in a single month, you should be punished for those things. And our goal is to really reveal some of that.

I think one of the most interesting examples of this is we tell the bank what the business does not based on MCC codes. So even if you put yourself under the MCC code of, restaurant, or large digital merchant, we’re going to tell the bank that you sell firearms. We’re going to tell the bank that you’re selling scheduled products. We’re going to tell the bank you’re gambling. Because from the bank’s perspective, they’re just trying to make the most informed decision. And I often think that if we move to a universe of clear communication, higher quality data, the best businesses, the real businesses, the people we want to be supporting will rise to the top. And they’re the ones who are going to benefit from more transparency and those who are leveraging some of these things to obfuscate their business. I think I’m happy that a bank is going to prevent scams from impacting old people. I think I’m on board for that.

Drew Edmond: Yeah, I can support that. I can fully support that. You make a really important point there though, because the ability to help them mitigate their losses on the fraud side and really shut down bad merchants, bad actors, bad transactions, it kind of opens them up a little bit to maybe even take a little bit more risk on good transactions that are maybe a little off that line of is this good or bad?

And we can maybe learn a little bit better and our models can get better by taking on some of those transactions and to your point, benefiting good merchants which is what we all want to do. We oftentimes talk about this issue in terms of accepting more transactions, in reality, we have to decline more bad transactions to make that happen. So I think having that available to do that helps with it.

Oban MacTavish: I think everyone and every bank you talk to who is at a level of sophistication where they can control whether or not they’re being authorized, is aware they’re probably being overly aggressive or there’s a chance they’re being overly aggressive. I don’t think you could ask any sort of card team at a bank and they’re going to say, Oh yeah, I’m perfect.

They want to make money too. I think the unfortunate reality is that they, I think, feel they have a different kind of job. They don’t really have as much margin to play with. Chargebacks and things like that are a little bit more problematic from a trust perspective. I think from their perspective, the goal from all these banks is to say, how can we let in more good ones and stop more bad ones?

And I think that’s really our pitch to them. Such a funny example of this is that from a bank’s perspective, a new Target POS system opening is the same risk as a business that popped up yesterday, which is crazy. That’s not true. We can all agree with that. You’re like, No, target is a huge business. It’s very likely that this is just a new location, et cetera. But the bank doesn’t know that. You’re just both just a net new MID they’ve never seen before trying to process a payment.

Drew Edmond: Yeah. I think it’s this making decisions in a vacuum sometimes where you’re lacking the context. There is context, there is data there, but you just don’t have it and it just results in poor outcomes. And so what can we do to improve that?

Oban MacTavish: Absolutely.

Drew Edmond: Yeah, so going back, you mentioned Capital One before and they’ve been in the news lately talking about the ability for payment service providers and fraud solutions and folks like that that can pass additional information or pass risk scores to them to allow them to make better decisions about transactions.

American Express has had the product Enhanced Authorizations for years. Similar concept around give us more data, give us names and email address and IP addresses and things like that that can just, again, just enrich our ability, enrich the data to improve our ability to make transactions. Do you see this as the future? Obviously there’s parallels in in terms of how you think about it, in terms of using more data to make better decisions broadly.

But I’m curious how you think about those solutions versus how you’re approaching it. Is it kind of complimentary? Is it competitive?

Oban MacTavish: I think it’s a good interesting question. I think where this belongs is an interesting one. I think the fintech, the banking universe is, we operate in a universe where there’s a handful of very, very important players who move a lot of this data around. So I think there’s an inherent comfortability with centralized power with some of these things.

I think it’s often complimentary. I think the reality, the kinds of data that these businesses are passing to people like a Cap One via this API is not the kind of data that in most cases we’re attempting to offer. Our goal is to be view validated business information and we think we have a unique lens to that and we want to make that possible.

Cap One, when it’s collecting, it is probably collecting stuff that looks a lot closer to PII, it looks a lot closer to checkout data and we have looked into the angles of exploring to help bridge the gap with some of these things. But I think as of today, I think it is, in a lot of ways, is the future.

I don’t think authorization rates are a problem you can solve without much stronger direct data sharing between these two sides. And it’s no accident that Amex has had industry leading fraud rates, or I guess incredibly low fraud rates, for a long time. Obviously there’s a part of that being the subset of consumers that leverage Amex financial products. But the other piece is they are a closed loop, or at least were for a very, very, very long time, and they have very unique perspectives on the businesses on the other side.

They know what’s happening at checkout. They know this information that I think just creates these faster feedback loops and creates better fraud models. I think what’s so interesting about the banks deciding to stand up their own endpoints is that even though they make up the vast majority of payments, oftentimes the areas that are most problematic are not your authorization rate at Chase or Cap One.

The places that merchants often suffer from, maybe not from a true dollar value, but there are cases where smaller mid-market issuers have, we’re talking like 75% authorization rates, 50% authorization rates on merchants. Which can be incredibly painful from the merchant’s perspective.

And II think there’s an interesting question to be had of, if you are a PSP or a merchant or anyone on the acquiring side broadly, does integrating with these systems, it doesn’t stop you from doing the other stuff, but there’s always a choice. And I do think there’s a question of the existence of these systems will not actually help the long tail of banks who make up thousands and thousands and thousands of financial institutions. You can make sure that Cap One cards are authorized pretty well, but they’re probably at 99.5% already.

So I think it is an interesting question of are these solutions of the future, but is it this exact medium of data exchange owned by a single financial institution? Because really from a merchant perspective, you’re solving a problem for one. Lots of dollars be moved there, but does it solve the total problem, which is like some bank in Idaho who made a mistake and suddenly none of your customers in Idaho can actually process a payment.

Drew Edmond: Yeah, I think it’s a scalability question to a certain extent, right? From both angles, right? If I’m a PSP, I think Worldpay had talked about their partnership with Capital One and they’re sharing information and things like that. Say, okay, great. So Capital One. 1 out of 4,000, you know?

Oban MacTavish: Yeah.

Drew Edmond: And how much work did it take? I don’t know, how much work did it take to get that going? And if you have 4,000 of these integrations, do we need almost like a gateway or a protocol?

And it also begs the question, like Mastercard has 3DS data only protocol. There are some protocols that exist out there. I don’t know if it’s Mastercard specific, sorry. But the 3DS data only protocol is available, but no one seems to use it that I’m aware of. Maybe that’s not true. Maybe you have other insights into that. But where should the messaging happen, I guess is the question?

Oban MacTavish: It’s an interesting one, right? I don’t work at one of these big banks and I have a lot of respect for what they’ve done, but you do wonder, right? Because if you open an API and you’re a bank, and you’re asking, come one, come all, Stripe, Adyen, et cetera.

Suddenly you’re getting, let’s say it’s as successful as they’d like and let’s ignore the long tail, every major tech enabled PSP, payment service provider, all these folks, they all show up. Now you’re having to sift through, we’re talking, 10, 20, 30, 40 different perspectives of all of this data and I think it creates an interesting. What I find so fascinating about this is that instead of potentially leveraging something like the network products, like the 3DS data only, or 3DS broadly, the banks have sort of said, Hey, this doesn’t work.

Well, it seems like that, they’re voting with their dollars. I shouldn’t say that on a podcast, but you know. Their perspective is maybe we’re going to look at a different, we’re going to try to find a different way to do this. The question is, is it going to be hubris or is it going to be, I guess, realistic expectations, but broadly, banks are not known to be the most tech enabled people, and they’re taking on a big technical challenge of how do we parse through all of these different data streams across all of these different transactions and figure out which ones are real, who’s trying to send us garbage via this rail that you’re now opening up. And I think it creates a really big question in my mind.

In some ways that’s the purpose of the networks, right? The idea is you have the centralized body who’s like, make sure there’s not garbage coming in and you’ve got to kick bad guys off. So now Cap One owns that for their data sharing? And if they get to a scale problem and they say, Well, it’s too much work. It doesn’t matter, the proportion of their payments volume that each of these individual actors makes up is actually super, super small.

So it creates a real challenge where you say, Okay, do I can keep scaling this? Can I cost effectively scale this given the sort of auth rates are sitting at already and the tech problem of onboarding these new partners? I don’t know how familiar you’re with the rewards universe and the centralization that happened where like you have these big platforms who became ad networks, essentially like the Cardlytics of the world and now a lot of these banks are trying to own their own card linked offers. And there’s just so many problems with owning it.

I find it really fascinating because if I had to tie a bow on it, I fundamentally believe data sharing is the solution as we move to this sort of like next wave of optimization. The question is where does that data sharing occur? I don’t know if it could be owned by any one party and no one seems to want the network to own it. So we’re kind of in a weird spot.

Drew Edmond: It’s like the main question, right? It’s kind of the million dollar question, million dollar, maybe the trillion dollar.

Oban MacTavish: Trillion dollar question maybe. The reality is we are exploring opportunities in this space and obviously I’m going to pat myself on the back, but if I’m going to be realistic about these things, it’s a massive question and it’s super unclear today, and I don’t know if we’re going to have an answer in the near term future of who could own this and how does this play out?

Because I think the big banks are betting that they can own it. I don’t know if you’ll see in the same way Stripe and the sort of the payment side is saying, We want to do a one to many thing. So then you have these weird, both sides are saying, we want this to integrate to our spec. Come pull Stripe Radar from us. And Cap One is saying push Stripe Radar to us. And you have these two people, these two sides, the innovators here, who are both sort of taking very similar strategies. I don’t know where it’s going to end up to be honest.

Drew Edmond: Well, it’s a great point because are we pushing out like a fraud score, like trust us, trust us on this transaction. Or give us the data, we want to make this decision ourselves because we have additional data that we want to pull in and add to it and we don’t just necessarily want to put all our eggs in your basket of your risk engine, essentially.

Oban MacTavish: Totally.

Drew Edmond: No matter how good it is.

Oban MacTavish: And who in the right mind on the bank side would trust that, right. There’s been, I mean, trusted MIDs have a very clear, you can plot the efficacy of that as it rises and then just tanks. It’s a known problem. And banks are like, Well, it’s weird. It starts out super effective and slowly the line gets moved because economic incentives. It is one of those things that I am on the lookout for either a network solution or even a startup solution.

The question is, how can we move towards this? But these things happen so slowly that I almost feel like if you look at the big financial institutions, we’re going to need a couple cycles of this-

Drew Edmond: Mm-hmm.

Oban MacTavish: -to happen before anyone sort of accepts that maybe you need a vendor, maybe you have a network solution, because it whiplashes around a little bit.

Drew Edmond: Absolutely. I want to go back a little bit to thinking about the lens of an issuer and how they think about merchants. I talk about this through this concept of merchant integrity, because I think it’s really critical and you’ve touched on elements of it already in our conversation where you as a merchant aren’t static, right? For an issuer looking at a particular transaction or even if they had a lot of the data that you’re able to provide them, you can see across MIDs and locations. That still isn’t static, right? Because that payment operations team that’s optimizing things or the consumer behavior changes that are happening. All these things are going to evolve over time. Your payment mix, maybe you’ve added a new business line and you’ve added a new MCC, maybe you just onboarded a new kind of retry logic partner that’s all of a sudden hammering banks with new approval attempts.

And that looks totally different from what you were doing before. Chargeback rates are going to rise and fall, the fraud notifications that you’re getting, all these things change the patina of what you look like as a merchant to an issuer. I always wonder what issuers kind of see, and I think, to your point, in some cases, very little.

And you’re able to help paint more of that picture to say, Hey, this thing happening over here, that’s actually the same exact merchant that’s happening over here. So talk a little bit about what you’ve learned from issuers on, how they look at it, how that’s changed after using Spade.

Oban MacTavish: I think what I would say, I also feel like it’s important for me to say that taking some of people from the big banks I think would be super interesting. We have a pretty longitudinal view. We talk to a lot of different sizes of banks and I think that gives you empathy to the each one’s different problems, but it also means my depth of knowledge is more limited there.

Broadly what we see when we talk to financial institutions is that it falls into a couple buckets. There’s the least sophisticated folks who are, unfortunately like, if you end up on a block list, you might never get off, period. Full stop. There’s some list of MIDs they have blocked over the last, 20, 30 years. Obviously being slightly hyperbolic there, but that people will live there. And there’s almost nothing you can do to get yourself off other than talking to a person because the reality from the bank’s perspective, if you build this list of bad things, you’re like, Okay, we know fraud has happened. It’s really hard to prove that this new thing that looks a lot on the same MID is is not fraud. Because they have to open it back up. And currently someone’s closed the gate and said, No, we’re not letting that MID in.

And I think for the least sophisticated banks, it’s usually very cumbersome. They don’t have a very evolved view of what a merchant looks like. They’re like, Well this is a bad MID, block it. They operate in these MCCs and very clear black and white things. Like if its velocity is too high, bad. If the dollar amount’s too big and the MCC looks like this, bad. And then they rely on broadly models that come out of the FICO Falcon, it’s probably one of the biggest. And then the network risk scores are the big ones too. It’s quite a simple view of these things and oftentimes they might even be calling up a vendor to get a new rule created. That’s how low tech these things are.

As you reach the middle bucket of banks, these are banks who probably own fraud themselves. They have a platform they leverage or they can make rules, make strategies, maybe run a model. They usually have a little bit more of a sophisticated view of merchants. Many of them will track chargeback rates on specific MIDs for their own card population. One of the challenges there is it’s sort of backwards looking, so you only know something is bad when a bad thing has happened to you, which is I think something Spade likes to solve is saying, Hey, that’s a bad actor, the first time they walk in your door versus Hey, this is a bad actor once you’ve lost a huge amount of money on the fraud loss side, or enormous amounts of dispute or sort of calls from your customers.

And from their perspective, I think they’re almost like somewhat more susceptible to some of the strategies. Retries, rotating MIDs, changing your MCC codes. They might invest even in a relationship with some data vendors and things like that. Maybe it’s baked into their platform.

And then you reach the highest end where we’re talking, you know what, maybe the top 10 banks, top 5 even look somewhat different. These are incredibly sophisticated fraud teams. They run multiple models inside the auth flow. They’re almost certainly leveraging their own model, training it on their own data. And then they might leverage the sort of network risk scores, FICO as an input into that because they’re very effective at what they do.

But they’re running their own models in parallel and they’re usually leveraging step up and things like that. And that’s where I think ironically, it’s like this weird situation where sometimes some of the strategies people think they’re doing work really well on the middle, where it’s like just sophisticated enough to know that this is a new MID and they should treat it differently, but not so sophisticated that they’re like, wait, you’re rotating MIDs. That means you’re bad.

There’s a weird crossover point where sometimes some of the strategies we think work that work on the plurality of banks can get picked up by some of these models, which is why you see these weird moments where suddenly your auth rate is tanking is because we’re like, Wait a second, this is a weird pattern of behavior. So I think there’s a weird scale.

And I think one of the things we really get excited about is I don’t just want to work with big banks. We want to work with every bank and whether that be directly selling to them. I mean, the word democratize is somewhat overused, but I think there’s some truth in saying, why is it that the tools that are available to JP Morgan Chase looks so different from this mid-sized issuer who also would love to stop scams and to authorize more, generate more revenue when they actually probably care a lot more about their card program from a proportion of their revenue, depending on their mixes. Broadly, banks see very little, but as the sophistication increases, they’re usually leveraging more and more data sources and also leveraging the data they sit on, like their history of their customer’s behavior with a merchant usually represented by a MID. And that’s sort of where that sort of sliding scale sits and how they view merchants broadly.

Drew Edmond: I would think that someone that had worked at a top five bank and knows the ins and outs of these sophisticated models would spin off and go sell that to smaller banks and say, I’ve got a product here.

Oban MacTavish: I mean, totally. I think there’s two problems. Well, you know, maybe three.

Drew Edmond: At least two.

Oban MacTavish: At least two. Let’s start with three or two. It’s that to even run a model, you need a platform to run the model in the auth stream. If you are an old enough bank or a small enough bank, you are leveraging a core that doesn’t let you do it. Period. Full stop. You are incapable of intervening.

Drew Edmond: We could stop there. That be big enough, you know.

Oban MacTavish: Yeah, exactly. And that’s just one of the hurdles. And then you can find these mid-market banks who have real time control, but they’re so ingrained in their core provider or their platform where even leveraging an external model is essentially impossible.

Like an ROI perspective, right? Let’s say this data vendor comes in like, Hey, use our data in your model. They’re like, Hey, it’ll cost us eight months of a developer time for our three developers to try to do this. That’s just never gonna happen. I think one of the biggest hurdles that to overcome any of these challenges is the fact that most banks are on really, really old infra.

And the ability to intervene, the ability to even compute some of these models is incredibly limited. Which is why I think if you look at it, most banks leverage, it’s either an internal model completely or they leverage one of the network ones. because they essentially get it for free, right? You sign up for Mastercard, you know Mastercard is integrated with all the processors. You set a rule that says, if Mastercard says this is super risky, block it.

Drew Edmond: Right.

Oban MacTavish: Which is also why I think you can see if Mastercard decides you’re risky as a business, you’re not just going to experience challenges authorizing one Mastercard, it is likely you’re going to see it across everyone because this same model is being leveraged by every bank, at least in some small part.

Drew Edmond: Right. Let’s start to wrap it up. I think this has been an amazing conversation. And we could probably go on for a long time, but I would love to just end with your view on Spade’s focus right now. What you’re focused on, what’s your grand vision for Spade over the coming years that you’re building towards, to the extent you want to reveal it.

As you continue to approach this problem, I think we’ve hit on a lot of interesting areas and potential opportunities. I’m curious just how you’re thinking about positioning yourself.

Oban MacTavish: If I really zoom out, one of the things that I always think about is that we’re helping issuers. really take advantage of their massive corpus of data, one of our unique value propositions. They’re able to actually enrich your data in real time in the auth stream.

And we do that for over 80% of our customer base today. When I think about the big, exciting problems that we’re excited to be tackling is that we think that banks need all of the best information they could get to make really informed, to solve really hard problems, period.

There’s numerous hard problems that banks have to solve every day, and one of the big ones is authorization and we’re really committed to not only generating Spade proprietary data to help them do that, but also partner with people who have way more informed opinions about some of these transactions.

That’s one of the reasons we’re working with and trying to talk to every PSP, everyone on the merchant side to say, Hey, you have really high quality data about these businesses. You have strong opinions, you have risk scores, you have checkout data. Banks would love to have it, and not just Cap One. The reality is every bank would really love to have access to this data. And we fundamentally believe that our goal is to say, Hey, if you can partner with us to help distribute your data, we can help get into the hands of numerous issuers who would love to leverage it.

And when I think about what we’re building at Spade is that, you know what, there’s authorization problems that every single bank, there’s numerous data partners, and there’s also just a whole corpus of problems we can help our banks and our customers solve. And it’s just about saying, Hey, how can better data help these people solve problems? And we’re going to bring that data to them in whatever medium they need it and whoever that happens to come from.

Drew Edmond: Fantastic. Well, Oban, this has been a fantastic conversation. I really thank you for joining me on the episode.

Oban MacTavish: Of course. It was great to chat. Always fun to talk payments, especially when it’s not in Money 20/20 by the Starbucks.

Drew Edmond: That’s right. Well, what we do on this podcast, we definitely talk payments on Payments on Fire. All right. Thanks everybody. Talk you later.