Tommy Nicholas, CEO & Co-Founder of Alloy on fighting fraud

Enjoying our podcasts? Don’t miss out on future episodes! Please hit that subscribe button on Apple, Spotify, YouTube, or your favorite podcast platform to stay updated with our latest content. Thank you for your support!

The anti-fraud space has really heated up this past 12 months as fraud attempts have been on the rise and bad actors have become more sophisticated. Often, it can feel like an increasingly difficult battle to win, but there is reason for optimism.

My next guest on the Fintech One-on-One podcast is Tommy Nicholas, the CEO and Co-Founder of Alloy. Tommy lays out in exceptional detail and with great passion why there is reason for optimism today. He also provides a blueprint for how banks and fintechs should be approaching their anti-fraud efforts. This is the third and final interview in the series I conducted at Fintech Meetup.

In this podcast you will learn:

• The inspiration and motivation for the founding of Alloy.
• A description of their product offerings.
• Why it was so difficult to build their products.
• How fraud attacks have changed over the last 12-18 months.
• How new fintechs develop their fraud protocols.
• How to avoid the death spiral to zero good customers.
• The role social media has had in increasing first party fraud.
• What is leading to an increase in fraud attempts recently.
• The types of fraud he is seeing today and how it is preventable.
• Details of the newly announced Alloy for Embedded Finance.
• How it will transform bank-fintech partnerships.
• The luck they have had in the timing of this launch.

Read a transcription of our conversation below.

Peter Renton  00:01

Welcome to the Fintech One-on-One podcast. This is Peter Renton, Chairman and co-founder of Fintech Nexus. I’ve been doing this show since 2013, which makes this the longest running one-on-one interview show in all of fintech. Thank you so much for joining me on this journey.

Peter Renton  00:27

Before we get started, I want to highlight another podcast that I always listen to. Fintech Takes by Alex Johnson should definitely be on your fintech playlist. Alex is personable, a great interviewer, and one of the smartest people in all of fintech. I love his regular features like the Not Investment Advice shows he does with Simon Taylor, his monthly recaps with Jason Mikula, his deep dive shows with Kiah Haslett, and the top notch guests he has on the show from time to time. Check out Fintech Takes on your favorite podcast platform.

Peter Renton  01:04

This is the third and final interview in our series of podcast recordings conducted live at Fintech Meetup in early March. I’m delighted to welcome Tommy Nicholas, the CEO and co-founder of Alloy. Now Alloy is a super interesting company, really focused on the fraud compliance space. Tommy goes into detail about the founding of the company. the problem that he saw when he and his partners founded Alloy. We talk about the different components of what they offer, we talk about Alloy for embedded finance, Tommy explains exactly what that means. And, you know, the difficulty in sort of producing that product and and how it’s going to work now in the markets. We also talk about the state of embedded finance and banking as a service today, and much more. It was a fascinating discussion. Hope you enjoy the show.

Peter Renton  02:06

All right. Welcome to the podcast, Tommy.

Tommy Nicholas  02:08

Hey, thanks for having me.

Peter Renton  02:09

My pleasure. So why don’t we kick it off? Just give the listeners a little bit of background about yourself. What have you done in your career to date?

Tommy Nicholas  02:18

Well, so I’ve really only done one thing in my career, which is I started a company called Alloy. And I actually, I like to answer the question that way, because people do always ask, Hey, what’s your background? You know, and the reality is, I’ve been working on fraud prevention, AML, decisioning, and credit decisioning for the last nine years, and then prior to that really was doing a few smaller things that inspired that journey. And that’s really what I’ve done. I’m very fortunate to have co-founders who have maybe done other things in their careers, and have other experiences, but I’ve really just been focused on helping financial services companies deploy risk decisioning for about a decade. And that’s my career in a nutshell.

Peter Renton  02:58

Okay, okay, so then, what was it that really led to, what was your motivation? What was the inspiration, for the founding?

Tommy Nicholas  03:07

Yeah, I actually think you just said that really well. You said, What was your motivation and your inspiration? And they’re actually not exactly the same in the, or at least I’ll pretend there’s a distinction between those two to make two different points. Let’s, you know, at least I’ll do that. Because you know, 10 years ago, I think two things were apparent to me and my co-founders, Laura and Charles, and also some of the other members of the founding team. The first was that we cared a lot about the financial services landscape becoming more digital and personalized and sort of nationalized in the sense, not nationalized in terms of like becoming part of the state capacity, but what I mean by that is, you know, as we were seeing lending products, deposit products, investment products, everything that you know, every way you move money, store money, be lent money, invest money, become available to all consumers and small businesses nationwide, you just saw that fees went down, experience was better, people had better sort of financial outcomes when financial services became digital, national, available 24/7. You know, all of the stuff that we talk about in fintech. So that was part of the inspiration. That doesn’t have that much to do with starting a risk decisioning company, but it’s why I was drawn to the industry. It’s why, it’s honestly why I cared to spend time thinking about what is missing in this ecosystem that would make it better? Like, you know, you kind of have to become obsessed with the problem to find an interesting nugget in the problem. And that’s how I became obsessed with financial services, digital financial services, generally. What inspired Alloy specifically was working in payments for a brief period of time, and observed that as you launched any digital product that was going to onboard customers, and then allow those customers to transact effectively in a digital format, I was surprised to learn that making decisions about whether you should onboard those customers, and should allow them to transact from a compliance, fraud and credit perspective, was something that you were expected to effectively build from scratch. If somebody submits an account application for a digital banking product 10 years ago, and even to some extent, now, the expectation was the bank or fintech that built that product was going to go do a huge amount of work to go figure out, can we automatically say yes or no to that customer, prospective customer? And if we can’t, what are we going to do about that? There wasn’t an expectation that you would simply buy a system that could manage that process for you on the technical and integration and sort of back office level, like there was for payment processing. You wouldn’t expect to go, get into payment processing and go integrate into Visa, MasterCard, Discover, Amex, you know, the Star Network, and then go build the processing rails, like nobody would expect you to do that, because you would buy a processor, or you would buy an issuer, or you know, like, that’s kind of how the payments landscape work. But the risk landscape whole, like full stop, did not work that way. And it particularly didn’t work that way for fully online, you know, highly available, digital financial services products. And then the other thing, just to sort of lastly, I’ll say about the inspiration of that journey was, it wasn’t like people weren’t working on credit products, fraud products, AML products. There was lots of fraud products, AML products, and credit products that existed or were coming out. There was the credit bureaus, and then a tons of alternative credit data sources. There were legacy fraud vendors and a ton of new fraud vendors coming out, there was the legacy AML sanctions providers and new sanctions providers, there were lots of signals, products, you know, this’ and thats that people could apply to fraud, compliance and credit, but there wasn’t a system that was, you would expect to just buy, install, and then configure to actually make the underlying decisions, do the orchestration of steps to the user. And that felt like a huge gap to us. And so we started Alloy, and then that turned out not to be a particularly easy thing to do. But, you know, nine years later, it’s going pretty well.

Peter Renton  03:23

So then maybe describe that, like, is it now as a plug and play type system yet? Or like, maybe you could just describe the product I think, before we go any further.

Tommy Nicholas  07:15

I think it was the founder of Nvidia said this recently, when somebody asked like, if you could start Nvidia again, would you do it? And he was like, Oh, my God, if I knew how hard this was gonna be, I would definitely not start the company again, even though it’s gone well, for me, I think it was Nvidia.

Peter Renton  07:31

It was, I remember seeing that.

Tommy Nicholas  07:31

That’s kind of how I feel about trying to do what we do in risk decisioning. Because our goal, because it was really, really hard. And now we’ve done it, but like, I don’t think I understood how hard it was. And I might have been more intimidated by the task had I known. So thank God, I didn’t know because we just had to keep going at it. And the reason it’s really, really hard to do what we do, is because the end output of a deployment of Alloy needs to be basically two things. The first is you have to be able to say, I have a system, one system in which I can configure and show that I’ve made risk decisions. So there can’t be two systems. That requirement is a really, really big requirement. Because it means that there can’t be an exception to oh, well, I can’t do that in Alloy. I can’t, well, I can make this kind of decision, but not that kind of decision. So I have this system that makes the AML decision, and this system that makes the fraud decision, and then you just look at both systems to know, to know what the ultimate decision is. If you end up in that state, you don’t actually have what’s called a decision system of record, where you can go and show yourselves for analytics purposes, regulators for regulatory purposes, on and on and on, how you decided whether to allow a customer through the door, or to make a particular transaction. So you have to have a unified decision system of record. And the second thing is that system has to be future proofed. Meaning, if once we’re done with the implementation of something like Alloy, and specifically Alloy, we have to be able to say we’re not constantly in implementation where if we want to change something, add a data source, add an authentication method, change a configuration, change a rule, add a model, remove a model, anything across the entire fraud, compliance, and credit stack, we can’t say, Well, now we go back to our engineers, and they go configure stuff in the system. It has to be, no we click buttons in Alloy, and then we deploy whatever the change we’re looking to do is. Those are two really high bars. They sound somewhat simple, but they’re actually massively high bars. Because, again, there can’t be almost any exceptions to have, you know, the system of record and to the future proofed nature of that system. And so I’ll give you an example of what makes that problem really, really tricky. Everybody talks about data sources in fraud prevention, credit, etc. Let’s go ingest some data sources. There’s these data feeds out there in the ether, in the cloud somewhere, we’ll figure out how to connect to them over HTTP or whatever, we’ll suck that data in, we’ll build attributes and we’ll let you kind of like run with building models on top of all of those attributes. That’s a hard problem in and of itself, because you need, these are regulated data sources, so you have to get certified to connect to something like Experian, TransUnion, Equifax, even GLBA data source, is all regulated. So that’s hard maintaining, you know, constant uptime, never down connections to a data feed in general, whether it’s an API or another type of feed is actually challenging. And I could go on, so that’s just hard. A lot of people know that that’s a somewhat hard problem. But that’s a hard, that’s a type of hard problem that internet software companies, B2B software companies, grapple with at scale, all the time, integrating lots of different sorts of third party APIs, there’s entire companies that actually just work on that problem. So that is a somewhat well understood problem. So if you were starting Alloy, and you thought that was the only really, really hard problem to being, you know, complete, and future proofed, you’d say that’s a hard problem we’re tackling, but it’s actually not even close to the only problem that you have to solve. Because most and increasingly sort of in an accelerating fashion of the data, that sort of, quote unquote, data that you actually want to collect to make fraud, compliance and credit decisions. And this is, in particular true of fraud and credit decisions, has a consumer facing component. Meaning, if you want to collect income data from a consumer permissioned, you know, aggregator like, you know, Plaid, Finicity, Trustly, whoever it is, they have to log in to their bank, there’s a thing that happens, you say, Oh, we’re gonna need to verify your income, choose your bank, login to your bank. So there’s a front end component to that, it’s not just going and pulling a data feed, it’s showing the user something, and that is most acute in authentication steps. Oh you need to do, you need to take a selfie, we’re gonna need to do biometrics, we’re going to, you’re going to need to show a document, show another document, show a different document, turn it over, right? So it’s not just that you have to go be able to connect out to all of these different data sources and say, Oh, I was calling Experian yesterday, I’m going to call TransUnion today, that’s a hard enough problem, you also have to be able to say, I was doing verification in a probabilistic way. Only sometimes did we ask our customer to show a passport or driver’s license or whatever it is. And I have to actually be able to get the user to do that. How do you make that technologically future proofed such that if I decide tomorrow that I want to change how I do document verification, or phone verification, or something that requires a consumer interaction, I still am just clicking a button and switching how I do that, that is an extraordinarily hard problem that even I didn’t recognize we were going to have to solve when we started the company. And you can just kind of go on and on and on with all of these things. And I think a lot of folks who think about building decisioning systems kind of back off at the data source part, they go, all the rest of those problems, including how manual teams operate, how you interact with the end customer, how you do the sort of long tail of critically important and acceleratingly important problems, that’s kind of on you customer, you just get all that together, and then you send us that data, and we’ll display it and let you write rules and models on it, that doesn’t really work. That only really works for very large enterprises that are extraordinarily competent, and have really, really large, and again, competent product and engineering teams that want to spend time constantly working on these problems. I don’t know almost any very large, super competent, highly motivated companies that actually want their engineers working on these sort of back office problems. And so what’s a little bit, what I don’t think I totally recognize we would have to do, but is different about us, is this deep commitment to completeness and future proofness, no matter how hard the problem we encounter happens to be. And I think maybe it was only even over the last year that I started to feel, even though we have 500 customers, almost all of them extremely happy doing successful things with us, it was only maybe over the last year I started to feel like we really might have completeness and future proofness solved. And that’s a really exciting time for us. It’s also a time of a lot of, you know, constant difficult work, which is invigorating, but certainly challenging.

Peter Renton  14:22

Right, well, let’s go to the other side of this equation. And that’s the fraudsters themselves, because they’re at the same time innovating and trying new things and different attack vectors. Maybe just look over the last, you know, 12 to 18 months, it feels like, you know, there’s a lot of activity in the anti fraud space, because there’s new things coming out, particularly with generative AI and all of the things happening there. So maybe just spend a little bit of time talking about how fraud attacks have changed over the last 12 to 18 months.

Tommy Nicholas  14:54

So the first thing I actually will talk about there is the game theory, sort of, maybe it’s not game theory, this might be like the use of the word ironic. It might be just misusing it systemically, I’m not sure. But I think it’s the game theory of how fraud fighters in financial services sort of go about the lifecycle of dealing with fraudsters. And here’s the kind of problem everybody is constantly faced with. The first thing is you, when you launch a financial services product, immediately you’re subject to fraud attacks, because every checking account can be attacked by fraudsters, every credit card can be attacked by fraudsters, it doesn’t matter how small or big your institution is, how big or small your fintech is, you’re subject to fraud attacks. So the first thing that happens is you launch a, you launch a checking account or credit card or a brokerage account, it doesn’t matter what it is, there’s some way that you can use that account to commit fraud. And usually, it’s in the form of somewhere along the way, hacking, or stealing access to an external account to that, whatever the new account is, funding or paying off or moving money into the new account, and then saying, you or the person whose account you compromised, says, I didn’t actually do that. And then now you have used, let’s say, it’s a credit card to buy a bunch of stuff, the money that you use to pay off the credit card, or the or fund the debit card and checking account gets charged back to wherever it came from, and you have the stuff and then you also have the money, or the person whose money you stole has been made whole. So that’s just you know, you’re gonna get defrauded, if it’s possible. So you undergo a fraud attack. And then what happens? Well, now you have a dataset of customers that didn’t defraud you, and customers that did defraud you. So what do you do? You go and say, we’re going to have to go and figure out how we would have stopped the customers that defrauded us. And so then you go and like, for example, well, if you do not have a system that has achieved completeness, and future proofness, you’re probably first thing you’re gonna do is you’re gonna say, Well, what can we do with the data or whatever it is that we already have, for whatever reason, whether it’s looking at application data, or the KYC data that we implemented, because we knew we at least had to do that, whatever it is, and you go and do, maybe you do some statistical analysis in Excel, maybe you have a real data science team, they do data science, like whatever it is, maybe you just guess actually, more likely, you just guess, and you come up with some rules or models or tweaks to how you onboard customers that has the following quality, it will decline most or all of the fraudsters, and it will decline as few good customers, but more than zero, good, certainly more than zero, usually way more than zero good customers. So you’re gonna stop most or all the fraud, and you’re gonna decline some good customers. Great. So now we leave that alone. And then we get defrauded again. And we repeat that cycle. If you extrapolate just that process out to happen over and over and over again, this really unintuitive thing. Well, maybe it’s intuitive, I guess I just wasn’t intuitive to me, but it’s probably intuitive to other people, this really bad thing happens, which is that eventually, over time, you actually don’t know who the good customers in your population are. Because that thing I just said at the end of implementing the new rule or model is you decline some nonzero number of good customers, that population of good customers you’re declining, you will never again know if they’re good customers, you will always suspect them as fraudulent. Because your model and your rules labels them as fraudulent now, and they’re declined. So they, they don’t get to show you whether they’re fraudulent or not. And I’m oversimplifying, but effectively, this is a death spiral to zero good customers, like if you do that long enough. So then, well, people sort of recognize that at some point, and then they go and look to external news, they’re gonna implement new stuff, maybe they’ll get a new data source that they expect is more precise, they’ll get a new authentication technique that they expect is more effective, they’ll do various different things to try to get to a better outcome. If you do that, if you do go and source better tooling, early enough, in this process, you never get too deep into the death spiral, because you have sort of good, you know, tools that are actually effective. But if you do it late in the death spiral, you actually never sort of get your way out, because you’ll never be able to prove to your boss or to the teams that are all freaked out about the fraud attacks you’ve been under, that we’re gonna go approve some of this population, we were declining before, and I promise they’re probably going to be good. Like, it’s actually very difficult to make that case. And so that’s why having one system that’s totally complete, so you know if you make a change in it, you know that that change is self-contained. You don’t have some other audit system you have to update, some other analytic system you have to update, and that is future proof, meaning we can immediately respond to a fraud attack and insert new tools into it without getting even more than 20 minutes into this death spiral, is so important. The reason I’m saying that about the changing fraud landscape is right now, I think you just mentioned, that we’re in a moment of what feels like a lot of conversation. Part of the reason that we’re in that moment, is because fraud attacks, the level of fraud pressure that’s pushed itself onto financial services companies over the last three years, has gotten to a little bit of a fever pitch. And I think people are more confused by what’s actually going on than they’ve ever been, by far. We know this, and we noted this, and Alex Johnson was really kind enough to write this in on his blog recently. And he said it better than me. So just, I think, go read that, I think would be my suggestion. But effectively, we now see in our fraud surveys, that our customers and prospects, and just everyone in the industry increasingly labels the fraud that they’re experiencing as first party fraud, meaning they’re effectively claiming, I think this is just somebody, I think we just have a bunch of people who showed up one day and decided I’m going to commit fraud in my own name. And I’m just, that’s what I’m gonna do. Maybe TikTok convinced me to do that, or, you know, whatever it is, that’s what people sort of suspect is going on, but for a whole bunch of reasons. And that is, one of the reasons they suspect that is that definitely is something that’s on the rise. Sort of people are, there’s been a large effort to normalize committing fraud amongst certain populations, especially on social media. And there’s like sort of fraud social media, you know, talking to each other about how to commit fraud and how to do it, and all sorts stuff like that. So that is a real trend. But the main reason that people say, Oh, I’m just, the only fraud, I’m experiencing an all time high in fraud attacks, and I think it is all first party fraud, is really, the way that fraud labeling works is once you’ve run out of ideas about what the fraud might be, you say it’s first party fraud, it’s like the default in the waterfall. And it just does not add up at all, it’s not even possible that it’s gotten easier to commit identity theft fraud, sort of scam fraud, you know, tricking people into committing fraud and to create synthetic identities, all of this stuff has gotten easier. And yet all of the fraud we’re seeing is not in that bucket. It’s in the, you know, no, no, the average American just got more fraudulent just over the last three years, they just ratcheted it up the fraud meter, and they’re all out here committing fraud. There’s no way that that describes, you know, the current state of things. And so as a result, people don’t have necessarily a clean understanding of what it would take to actually stop, you know, fraud at scale. What I like to tell people, though, is that we’ve deployed over 500 fraud prevention programs at banks mostly, about half banks, half non-banks, and there are a lot of them that have good approval rates and low fraud rates. So it can be done. You know, why would it be that they would have those results, and you can’t achieve those results? Well the answer, it sort of goes back to, this is why I always start with the sort of like, I don’t know, the system of how fraud evolves at an organization, the real answer is, folks haven’t made the technology investments, because they haven’t been able to justify the ROI, because they’re just convinced, they’re convinced they’re not in a death spiral, but they are in a death spiral. And there’s no sort of real organizational way to get out of that without finding a trusted third party or just taking a leap of faith on, I think these things will work if we were to go open the funnel on one hand, close the funnel on the other hand, you know, try to approve some more of these good customers and try to decline more, while still trying to decline more of the fraudsters. So that’s how I sort of summarize the state of fraud and financial services.

Peter Renton  23:23

So what you’re saying is that you don’t think I mean, there may be more instances of fraud, but it’s not like these instances of fraud are suddenly impossible to catch.

Tommy Nicholas  23:34

Yes. Oh, I’m there. I’m not just saying, but I am declaring, that that is true. There are instances of fraud that are on the rise that I think are very difficult to catch, because I do think there are an increasing number of consumers that are just saying, oh, fraud is one of my options to make money this month, But A, a lot of that is actually catchable and B, that is just not the bulk of the fraud people are seeing. The bulk of the fraud people are seeing are people who are being tricked into or kind of colluded with professional fraudsters, that is detectable, very detectable. People who are using somewhat stolen identities in various different respects, entirely detectable, preventable. Detectable is not really the important thing, preventable. And then people using hybrid synthetic identities, full synthetic identities or variations thereof, are entirely detectable and preventable. And oh, by the way, a lot of true first party fraud is preventable as well. Because the more that people who are committing first party fraud feel that they’re being strongly authenticated in the sense that they won’t be able to deny it was them in the future, the less likely they are to commit first party fraud. So there’ll be a lot of companies that say, oh, there’s no way to stop first party fraud and you say, What have you done? And they said, Well, we haven’t tried anything. Like you know, we were…

Peter Renton  24:55

It’s just impossible.

Tommy Nicholas  24:55

Yeah, it’s just like sort of a priority impossible. Like you know, first principles, there’s no way to stop it. And then yet you have these organizations that have put principled, you know, effective, constantly evolving fraud prevention techniques in place that they’re very committed to as an organization, and they have lower fraud rates and higher approval rates. So something’s going on, you know, it is doable. And then there’s this third factor, which is there are a lot of institutions that just aren’t even sure how many good customers they’re really getting in the first place. So if they end up with like a 20% approval rate, they might just be convinced themselves, well, we just don’t have anyone that wants our products in reality except fraudsters. That’s usually not true, either, but it can sometimes be true, and it’s sort of a complicating factor in that.

Peter Renton  25:36

Right, right. Okay. I want to switch gears a little bit. You just recently, I think it was last week you announced Alloy for embedded finance.

Tommy Nicholas  25:45

Yes.

Peter Renton  25:45

So tell us, what is that?

Tommy Nicholas  25:47

I’m not going to surprise you when I say that I think a lot about the systems of how fraud, compliance and credit policies emerge and like exist in the ecosystem. Because I just spent some absurd amount of time talking about that as it relates to the fraud ecosystem. I think the sponsor bank fintech relationship, as it relates to fraud prevention, and KYC/AML. In particular, sort of less so credit, but more so those two topics, is one of the most interesting things in fintech. And what Alloy for embedded finances is in a nutshell, is a solution to the problem the, about half of the problem that sponsor banks are facing right now in terms of regulatory pressure on, Hey, you don’t actually control or have true oversight in a real like effective way on how your end fintech programs verify their customers, perform CIB/KYC, monitor those customers and ensure, you know, that sanctioned entities and money launderers aren’t doing business on their platforms. And oh, by the way, even if you did have a sort of oversight over that, that oversight is not sufficient because really, you know, you have 10 fintech partners, and they have some number of customers, some of those customers overlap. That’s one customer to you as an institution. And you actually have to figure that out and do something about that. You can’t treat them as two different, Tommy at two fintechs under one sponsor bank is one Tommy, it’s not two Tommys, from a regulatory perspective. So on one hand, that’s one problem that we’re solving. On the other hand, why is it that sponsor banks don’t control or have really effective oversight on all the things I just described? It’s because the fintechs, tech companies deploying embedded finance, let’s instead of saying fintech, like companies, deploying embedded finance, do not want for both practical and actually good reasons to have the way they onboard their customers fully dictated by a third party. And that’s not to say that they don’t, they’re not open to having the requirements for sort of, you need to make sure you’ve done X, Y, or Z. They’re very, everybody, I think generally, if they have any sense, understands that they’re going to have to meet certain requirements. But how they get to those requirements, they do not trust that any particular regulated entity in particular can tell them how to do that. So for example, let’s say, just to use a super simple example, let’s say the requirement is you have to collect and verify a driver’s license for every customer that onboards, that’d actually be a pretty stringent requirement. But let’s just say that that’s the requirement. Well with what vendor are you going to do that with? In what way? Is it going to be the front and the back, with a selfie, without a selfie? What type of liveness detection are we going to do? What does verify really mean when it comes to a driver’s license? There’s, especially given the differences in populations between, you know, Are you serving immigrants that don’t have drive, they may have state ID cards, but they may not have pass, or they may have passports, but they might not have driver’s license, like there’s all sorts of these different nuances. And it’s very unlikely, in fact, it’s impossible for the sponsor banks in United States to have gone and figured out all of those technology problems, they’re not technology companies, they certainly have points of view, they can be amazing advisors on the regulatory matters or what they’ve seen from others, but they’re not gonna go solve those problems. And so on one hand, you have the sort of need for not just oversight, but control on KYC/CIP, and then the monitoring they’re in, but you also have fintechs, are going to fight tooth and nail not to have the sort of exact implementation dictated down, you know, on them. And then let’s add on this other problem, which is that part of the relationship between the sponsor bank and a fintech is assumed to be that there will be technology implementations to serve these customers, which might include things like how do you monitor them for being on sanctions lists? How do you monitor their transactions, like that’s, sponsor banks don’t provide processing and issuing and all of that stuff necessarily, you can use your own issue or processor, so therefore, the data is coming from lots of different places. So it’s understood that there’s this sort of technology partnership between them where the sponsor bank says, you know, we need to make sure you’ve done XYZ, but the technology implementation of that is on you. That again, creates this other problem of well, then how do they actually control and do oversight on that? So in a nutshell, Alloy for embedded finance is a way for everybody from program managers to sponsor banks, the entire ecosystem that isn’t the sort of end program deploying an embedded finance product, to capture all of the things that they need to capture from a oversight perspective. All of the transactions so they can monitor those transactions as one bank, not multiple different programs, all of the CIP/KYC and identity verification programs and policies from their underlying fintechs. So it’s that without needing anybody to go do a big technology implementation other than the fintech, so keeping the who integrates the identity verification APIs, who sends the transactions to be monitored where it belongs, with the fintech, interacting directly with Alloy, but pushing all of the oversight and analytics and all the other stuff that’s needed to the sponsor bank, that’s one. The second thing is it’s a way of allowing sponsor banks, program managers and others who have the sort of ultimate regulatory need to push down not just oversight, but actual control on some subset of those things. So for example, to be able to say, I’m going to push a sanctions decisioning and monitoring workflow using vendors that I’ve chosen and vetted, and the configuration of those vendors exactly how I want them, and the rules for what is and isn’t flagged, on and on and on, I’m going to push that down to all my programs, and it’s just going to be on. There’s just not, there’s nothing that they’re going to be able to do about it, it’s just a requirement, we just are putting this in production. We don’t, there’s nothing between the sponsor, bank program manager or whoever it is, regulated entity, pushing that thing down, but we’re still going to allow, let’s call it identity verification to be something we just monitor, and don’t control. They need to, what this whole ecosystem needs, is to be able to not have it be a technology problem to determine who controls what and who monitors what, and to instead be a discussion about practicality. Who should control what, who has the right incentives, knowledge and staffing to control what, because ultimately when regulators come down, it’s very unnerving to them to see that oversight isn’t really there. They’ve historically done random sampling, send me 10 entities and show me you monitored them. They’re getting away from that, they’re gonna say, show me how you monitor your entire customer base. But what would happen if Russian sanctions hit tomorrow, and you needed to push down a change to how you’re determining sanctioned entities to all your fintechs? Oh, you couldn’t do that? Like that’s, you know, they’re gonna be observing those challenges, but at the same time, they don’t want a sponsor bank, program manager, regulated entity, money transmitter, anybody, to go and say, So we’ve brought all of that stuff in-house, including the technology and oh, by the way, there’s no way we have the staffing to actually manage that. They’re perfectly happy to hear, Hey, we have perfect oversight, we have control where we need it. But we’ve also relying on monitored, trusted, well established and well diligenced third parties to operationalize some of this stuff for us from a technology perspective, which might even include doing some of the manual reviews and investigations. No reason that fintech partners shouldn’t be able to sign up to go take some of that work on, if it still can be monitored, sampled and evaluated by the ultimate regulator. And there’s no, there’s no regulatory construct that says that that shouldn’t be happening. In fact, it’s favored to go and figure out who has the bodies, time and talent to do all of this stuff. As long as again, you have control over what you need to have control over, you have oversight that’s real and not made up. And so Alloy for embedded finance is in a nutshell, you know, a solve for that entire product, problem space. But it’s ultimately, it’s just the Alloy product with this added, sort of really difficult to build it turns out, but thankfully, you know, here we are, this added layer of being able to push the sort of end result of transaction monitoring, KYC/AML, etc, etc, up to an aggregate parent level for whoever it is, usually a sponsor bank that needs to monitor that, and to push down controls back to an underlying account, without needing to go replatform everybody in the ecosystem. It’s just still going to operate the same way it has, which is fintech integrates, technically, with Alloy, sponsor bank has all the buttons they can push, all the analytics they can see, all the deduplication of entities that they need all the, you know, on and on, and on and on. And it’s definitely the thing that we’ve worked on for a very, very, very long time. And when we finally started to be able to actually show that we had customers in production doing this, talk about the way that this would transform the business and operating model of fintech bank partnerships, it’s probably the thing I’ve been the most excited about, because I really do think 18 months from now, whether through Alloy or for building things on their own, the way that embedded finance deployers and the actual regulated entities, sponsor banks and fintech, is that as you know, to use different terms, interact is going to be way more sane, is going to make sense instead of not making sense. And that will be the way that the you know, sort of the drama that it feels like we’re in right now in the embedded finance space, will turn into a productive decade long run of growth for everybody involved. We’re just in a rethinking and replatforming stage of that. But we will get out of it because people have been working on these problems. We’ve, I think, really solved the problem. And it will just be a question of motivation. Not everyone will have the motivation to go do this. But the folks that don’t will just exit the space, and that’s fine. And the ones that do, wil have a soundness and competence about them. If they’re under threat of or under a consent order, they’ll get out of it. And then they’ll be off and running for decades. And so anyway, that’s, that’s what Alloy for embedded finance is, that’s why we’re excited about it, and what we are thinking.

Peter Renton  35:55

Yeah, and it’s actually good timing right now, because probably when you started developing this, you didn’t quite know how the atmosphere that was going to be. And clearly, this is, this is a moment in time.

Tommy Nicholas  36:05

It’s extraordinarily lucky, and it genuinely is luck. The reason that we started working on this product, if you can call it, this way of deploying our product was because we had some customers who we just sort of observed. The interactions here are weird and not clean, there’s like three parties involved, all the parties want different things, we’re not really built to do, we weren’t then, really built to do that, it was really supposed to be more of like, one, there’s one customer buying Alloy, and then there’s not supposed to be these other entities involved. And so we were seeing, you know, like, sponsor bank users being added to dashboards as to monitor things. And we said, that’s great, like, 100% amazing, and we have a whole legal construct for being able to do that. But is that how that should work? Like, don’t they want? They don’t want to just be logging into one instance, they want this to be in their instance?

Peter Renton  36:51

Yeah.

Tommy Nicholas  36:52

And how would that work? Well, we certainly can’t ask people to, and would be impractical to sort of have people replatform. So it was very, we just more sort of observed that this was a little bit wonky, started building. We have a lot of the ecosystem RDS customers and partners so we had, we were able to get a lot of feedback. And then maybe it was six months ago, as we’re starting to sort of like implement the first customers here, that we’re going to use the sort of new way of deploying that kind of parent, child, multi, multi entity relationships, we started to really realize that this might be really important, we might need to put some more resources on this. So we’ve been sort of all in on it for we’ve been building 18 months now. And now we’ve been really trying to accelerate that. And, you know, brought a lot of partners on board now to help us kind of take this to the next level.

Peter Renton  37:37

Right. Yeah, that’s important work, because it’s certainly needed right now. But anyway, Tommy, we’re out of time. Thank you so much for joining me on the podcast today.

Tommy Nicholas  37:44

Peter. Thanks for having me.

Peter Renton  37:45

Okay.

Peter Renton  37:46 Well, I hope you enjoyed the show. Thank you so much for listening. Please go ahead and give the show a review on the podcast platform of your choice and go tell your friends and colleagues about it. Anyway, on that note, I will sign off. I very much appreciate you listening, and I’ll catch you next time. B