Cameron [00:00:05] Welcome everyone to state of identity. I’m your host, Cameron Ambrosi. Joining me this week is Reed McGinley, Stempel co-founder, and CEO at Stytch. Reed, welcome to the podcast.

Reed [00:00:16] Thanks for having me on today.

Cameron [00:00:18] Exciting. Well, I should say I’m always excited for every episode of State of Identity, but always exciting when we have unicorns in the house, you know, mythical creatures, always fun to be around. Congratulations on raising that big Series B round that put you officially in that unicorn club. But before we get into all of that, I always like to ask my guests to walk us through a little bit of their career journey. You know, what are those unique pathways, those routes that they found to kind of entering this digital identity space that I find fascinating enough to have started a podcast about and dedicated my career to? So would you mind walking us through like a little bit of your background, how you came to co-found Stytch and where some of that inspiration came from to enter the space?

Reed [00:01:07] Yeah, absolutely. Is definitely a bit of a circuitous route to ending up in digital identity, although I would imagine many people would probably describe the journey to identity that way. So I graduated from college at Duke University back in 2015, and actually, after that I went to Germany for a year to do a Fulbright where I was teaching English. And after that, I’d say, is when I actually kind of started down a little bit more efficiently what I thought my career path in business would be. I joined Bain and Company. I’ve moved back to the United States once my Fulbright was done, and then I pretty quickly discovered that I did not find management consulting that interesting. I felt like I was learning a lot, but didn’t quite find it as compelling to be able to hand down these recommendations to large or 500 orgs and then watch how they kind of sat on the shelf for months or years. And so I was interested in startups and tech generally, but I did not have a science background from college, had not interned at any tech companies and ended up just getting a very random cold outreach from what was then a small fintech company and now is a very large fintech company called Plaid. While I was working out at Bain, who had an opening on their go to market and business team, and my now wife, then girlfriend at the time had been moving, planning on, moving out to San Francisco to start law school anyways. And so I figured it would be a great opportunity to kind of start pursuing something. The tech space that I found more interesting. What I didn’t expect and what ultimately became kind of my obsession while working at Plaid was the idea of kind of digital identity and authentication. Once I realized both how pivotal it was to Plaid Sport Business Model, which is how can you connect your bank account to thousands of fintechs like Coinbase, Robinhood, Trouville, Venmo, etc. and a core underpinning to how you think about connecting those bank accounts and allowing that data to flow between those applications is obviously there is the secure aspect of how can you actually authenticate who you are and share the sensitive information. But there’s also in the digital world, really large convenience factor that needs to be taken out of a place into into consideration to ensure that you’re not introducing unnecessary drop off or friction for users. And so I ended up working on the product team at Plaid, specifically on the authentication products for how you and bank accounts for the last couple of years in my time of plaid. Before starting Stytch and I’d say that’s really where I both got interested in identity authentication, but also kind of appalled by the current state of how we predominantly authenticate ourselves online with usernames and passwords. And so that was really kind of the circuitous route to starting Stytch.

Cameron [00:04:00] When you really boil it down, you know, it is a cliche, and I think one that I reference quite a bit in this podcast, but this notion of the lack of a true identity layer as the original sin of the internet and you know, much like in that a biblical tale, it’s one that has kind of, you know, the effects have continued to compound over time. And in many ways, you know, you’re seeing companies like the Plaid’s of the world building this incredible infrastructure. Next generation solutions to these problems that are set to have a tremendous impact on both enterprises and consumers alike. And then you go back to this choke point of, oh, and by the way, it’s all anchored on username and password, which everybody hates and for good reason. You know, it’s it’s hard for brands to remember. It’s easy for machines to crack. Resetting them is both a pain cost. The enterprise is a ton of money. Is a prime attack vector again for threat actors, just, you know, compounding misery all around. And yet here we are in twenty twenty two and you know, I don’t even know how many passwords are in my password manager. I think it’s upwards of 250 300, the average consumer still well north of 100. And you know, it feels like the password is the final boss zombie in the, you know, Romero horror flick that just does not die. We’re hitting stakes into it. Silver bullets, napalm it. It just keeps surviving and metastasizing across all of these applications. You know what has been your approach in founding Stytch o try and kind of be that, you know, that magic stake that we can drive into the heart of the password and maybe kill this thing once and for all?

Reed [00:05:50] It’s probably helpful if I maybe I’ll take a quick step back and just explain a little bit of some of the authentication products I was working on over my last year at Plaid, as I think that gives really good context into how we’re thinking about the kind of wedge points to replace the password. So one of the things that will be clear to you and probably to many listeners, is that passwords pose a lot of security issues, as you’d mentioned around kind of them being cracked, but also users reusing passwords across different accounts. So if your target account gets breached now, theoretically, your Coinbase or your chase account might be in danger as well. That’s obviously a big issue is kind of the security side. The other side of the coin that we saw firsthand at Plaid was that the conversion and UX considerations and shortcomings of passwords. If you think about what Plaid does, Plaid customers are, you know, large fintechs like Coinbase, Robinhood, Venmo, where they embed Plaid software into their application so that a user can connect to their bank account. And the highest point of friction required in connecting that bank account is the user remembering their password and entering it into that authentication experience. And so while we always dealt with a lot of the security and fraud issues around passwords and had to build a lot of in-house solutions to prevent bot attacks, credential stuffing, etc., we also had a very direct insight into just how much user drop was created by introducing passwords to a flow because we would see a really large double digit percentage of users that would drop off because they forgot their password. And for us, that was something that we tracked very closely because Plaid only makes money when you successfully connect a bank account to Coinbase or Venmo. And so that was directly hitting Platt’s bottom line and revenue figures. And so that’s a little bit of the context and kind of the frustrations we were seeing with passwords, which weaves into what I was focusing on over the last year, which was a question that we always thought about at Plaid, which was, you know, what kind of bang our heads against the wall and say, is there a way to replace passwords in the bank account authentication space? And if you think about it, one way that you can do this is kind of similar to what Shopify Pay has been doing for recognizing users across different Shopify merchant accounts or websites where they’ll try to passively recognize user and then give them a lower friction form of authentication because they’ve seen them before, such as an SMS one time passcode, and then allow that to fill their credit card information and their shipping information, et cetera. And so we’re asking ourselves the same question apply to Is there a way for us to recognize you when you go from Coinbase to Venmo to square cash or Robinhood and make sure that we’re not requiring you to go to that same high friction method of creating an account or signing into an account? And I think part of that process to us internally, at least, was examining a lot of the assumptions of passwords and why they’re used as the predominant authentication source and whether it was good wisdom that we use passwords or whether. It was just, you know, people have become kind of predisposed to always rolling out that solution without thinking about whether there are better ones available to them. And I think the deeper we dug, we did a lot of research into what our pass order account recovery process is and what a companies rely on for that. And it was very clear to us that virtually every company actually has the concept of passwordless access, even if they don’t think about it as such, because virtually every company has a password reset process where you have a way to get into the account if you forget your password and we’ll send you the email verification where you click on it, you’re asked to create and confirm a new multi condition password. Then it locks you out and says, Now reproduce your username and your new password. And for us with that kind of demonstrated was we as a society and online have already decided a solid way to access an account. If you cannot remember, your password is to allow them to verify email access. And so I think that was really like the first kernel of the idea of what are the alternative access points where if we allowed a user that either doesn’t have a password or forgets their password to access this website without the need to reset a password or even create one, what would that look like? And that’s where we started exploring the idea a Stytch of kind of creating a suite of APIs and products that allow you if you’re building an app or website to just allow the user to completely skip the password process entirely and allow our user to log in with their email or their phone if they’re on mobile or their biometric, that’s tied to the device. And what we find is it really depends on the different vertical or company what makes the most sense for their user demographic, but that there are these alternative access points which can be both easier to use and more secure because you don’t subject yourself to password reuse or password cracking risks in process.

Cameron [00:10:58] Can you talk a little bit about this developer centric approach you’ve taken in terms of your go to market strategy? Know, I think that has remained one of these somewhat intractable problems we’ve seen in this search. To replace the password is it’s a, you know, this common standard that is used across all these industries. And we’ve seen players that have developed, you know, alternatives struggle to get deployment. You know, we’ve seen folks kind of die on this hill of looking to build a consumer wallet, a consumer centric identity app that you have to download. You know, one shared app to then maybe federate a login across applications that’s really, really difficult to do. You hit that fundamental chicken egg problem of I don’t have user adoption on my app, therefore people don’t integrate it to use as a solution, which means I don’t have users compounding. How did you decide to take this developer centric approach and how has the reception been so far?

Reed [00:11:58] I think you raise a great point there, where a lot of the attempts to go passwordless in the past have been kind of predicated on that consumer angle, where convinced the user to download this external app and then use this application with that app as kind of the access point. And to your point, it’s really hard to gain adoption across a multitude of apps and websites with that approach, because you’re effectively trying to convince that app that they need to tell their user when they’re in the midst of a signup process, that they have to go back to the App Store and download a third party, which is just not something many companies will even tolerate or consider. And so for us, I think having seen the things that didn’t work and trying to garner passwordless adoption in the past, coupled with the fact that we are coming from a very developer centric company, my co-founder was an engineer at plot as well, which is how we knew each other and we both worked on authentication products. We definitely were already inclined to thinking about what is the developer pain point that if you solve that and make it easier for them to build authentication and, you know, as a kind of side effect or side benefit, you also give them the benefit of being able to build lower friction and more secure authentication. That felt to us like a much more compelling distribution wedge than trying to convince a million 10 million, 100 million users to bootstrap a network of a consumer app. And so for us, I think the thing, though, that probably pushed us over the edge towards that strategy was our previous experience with other authentication providers and the developer pain points that we had experience there. While at Plaid, we had for some authentication products evaluated at companies like Or0 and Okta, who are now actually one company after they acquired. We have used Magneto s as product for some things, and we found in many cases off your own Okta. We’re not nearly as flexible as we needed them to be on an API level in order to do what we wanted. And in many other ways, cometo was, you know, a very frustrating developer experience to work with. And that coupled with the fact that when my co-founder Julianna left Vlad, she went to a company called Very Good Security, which is another developer experience company and one of the projects she worked on there was actually ripping out Auth0 from their developer dashboard login and replacing it with an in-house system because they’ve run into a lot of flexibility issues with OR0. And so I think kind of the amalgamation of those different pain points with other authentication companies was kind of the aha moment for us that there’s not truly a stripe for authentication that’s been built in this market. There are very successful authentication companies, but our our viewpoint was you could make it much easier and more flexible authentication experience for developers. That would be the highest likelihood way of actually growing mass passwordless adoption. And so that was generally what went into our calculus.

Cameron [00:15:08] And in terms of the I guess we can call them modalities for the purposes of this conversation. Your current product offerings, whether it’s, you know, an email magic link, whether it’s OFTH or SMS or other channels that you know, consumers are using to move beyond the password alongside your customers. Has anything surprised you in terms of the volumes you’ve seen and and how your developer community is interacting with the product? Anything that caught you by surprise in terms of how once consumers started kind of moving through your experiences where there was a difference in what you expected versus what the market is kind of showing you in terms of what consumers are preferring?

Reed [00:15:50] One of the things that’s been interesting to see is how, how popular it’s been to give the user the option of what’s more convenient to them, whether that’s, for example, email or SMS verification. And so kind of taking a quick step back. I would put authentic password loss authentication methods into a couple of different buckets. There are communication verification methods, right? So you can verify someone’s email ownership or you can verify their phone ownership. And then there are also device ownership verification methods, such as verifying that somebody has access to the Google Authenticator app or doing a Face ID or Touch ID. While those are biometrics, they’re actually welded to the device. So it’s also a device authentication. And the reason I just mention that as background is, what’s really interesting is we’ve seen it become really popular for our customers to give users the option for their primary authentication factor of whether it’s email or phone number verification. And the reason for this is is that many of our customers both have a mobile presence and a desktop presence. And what they generally find is that their user profile who they might have John Doe that has both an email and a phone number on file with the app. They’ll predominantly choose phone number as their login method when they’re on mobile because they get the autofill features of that six digit code with iOS and Android. And when they’re on desktop, it’s actually more likely that they’ll choose the email verification method. And so I think actually a company that had done this before we were actually founded was Square Cash. Does this or the Cash App, if you’re trying to log in to that service, it allows the user to choose whether they want to log in with email or phone. And so what I’ve found to be really interesting is that that combination has become very popular for developers. And then we’ve seen kind of on there still use cases for where you do two factor with password authentication, whether it’s a really secure crypto or fintech app. There, we’ve seen the growth of web often, which is a popular biometrics method for allowing users to to verify themselves on a web browser biometrically. But I’d say the most popular thing that we’ve seen is kind of the coupling of SMS or email to give users the option of what’s more convenient at any point in time when they’re trying to access a resource.

Cameron [00:18:16] And in terms of on the developer side, you know, we’re seeing a lot of trends, at least in the identity space around this notion of orchestration. You know, when you think about onboarding flows to your point, being able to offer consumer multiple pathways to come on board a platform, whether it’s, you know, using document scanning, whether it’s using biometrics, allowing depending on the need and the use case and consumer tolerance for friction, multiple avenues and facilitating kind of seamless transition between those avenues, as well as driving insights, reporting metrics out the back end for those platforms, for those developers to understand what is going on, what their users are wanting and and obviously continue adapting. How are you supporting the developers in terms of passing along some of these signals and understanding what are the threats you’re facing where consumers, you know, having success and getting in and and where some of those roadblocks or drop off rates presenting themselves as that’s something that you offer.

Reed [00:19:23] Yes, to a degree. So there’s definitely more we can do there. But I’ll give a little bit of context on what we’re currently doing. So a lot of this today is kind of custom and kind of the account management process with our developers, where often a fintech will have different authentication needs or best practices that we’d recommend that an e-commerce or a B2B SaaS company. And so one of the things that we’re always happy to do is actually sit down with a developer and walk them through kind of the best practices we’ve seen across their vertical and give them a recommendation of the two or maybe three authentication options that they should provide their users. That’s one thing that we’d love to figure out a way to scale that more appropriately than it being kind of that live conversation. And we’re doing a little bit more on our website right now to actually create some bi vertical recommendations of what you would use with the different authentication methods. So I think that’s one way we can start to do that, but I think there’s even more we can do. There’s some things that we actually do from the product itself to create guardrails or slight recommendations to help developers as well. So, for example, with a menu of different authentication options, one of the things we want to help developers avoid is creating what we call log in soup. Or I don’t know if you’ve come across us in the wild, but occasionally a land on a website where it gives you like 10 different options. It’s like signing with Google or Microsoft or Facebook or. Netscape or not, Netscape is I don’t think that I lost, obviously, but signed in with some pretty random things that I would not imagine more than maybe one or two or three percent of their users would even select. And so one of the things we do with our if you if you use our front end SDK rather than our direct API, which both are available to developers, we’ll actually cap the number of authentication methods you can put in that primary authentication option for users to for. So you could do something like three off options and an email Magic Link option, or you could do email, Magic Link, SMS and sign in with Google or Sign with Apple. But what we like to do is try to help give you guardrails to avoid, you know, creating that log in to problem. And so that’s one thing that we start to do. But I think to your question of how do you then help someone that’s integrated, identify what’s most popular and what is converting best, maybe any tweaks they should make. The first big products we released here is actually just in the last couple of weeks. We created a visual layer of user management so that you can identify the most popular authentication methods that your users are choosing, as well as do a lot of other interactions with your users. The next thing that we want to do on top of that is actually giving you much more granular data metrics and reporting so that you can see where people and users drop off in your sign up or your login flows. So I think there’s still a lot more we can do there, but we’ve started to release products that are aimed at that element

Cameron [00:22:21] in thinking about the future. Love to ask my guests for for crystal ball predictions, which I think we can get to in a minute here. But before we get to that, you know, I remain hopeful that we will have some form of a passwordless future that can be created for users kind of across their lifecycle. I think one of the challenges we see now is, you know, for all of these applications that are integrating your platform. You know, there may be a password lurking underneath somewhere that might be a weak point. Still, like if it’s email, Magic Link or or WhatsApp or an oath that’s coming through Facebook, for example. Unfortunately, those guys are are still relying on passwords. I think, you know, with your web offline integration, for example, and with some of the stuff that, for example, FIDO Alliance is doing, we may get to a point where you can use an actual device binding to kind of replace that password at the root level so that even, you know, solutions like yours that might rely on email or off don’t drill down to a password somewhere along the line. Now the flaw in that is I would consider your recovery seed to also be a form of a password, which right now they’re they’re telling you well to protect your account. In the event your device takes a bath or it gets smashed or lost or stolen, you need a recovery seed to be able to get back in. If you can’t prove who you are with that device, we bounce securely. You know, what are your thoughts on on where we’re going longer term to get past passwords across the ecosystem beyond just what you’re doing, which is is fantastic and and really, really powerful. But how can we finally kill the password for good, maybe even up to and including some form of recovery seed?

Reed [00:24:13] It’s a great question, and I really like this topic because I’ve found there really different opinions on it and all of them very interesting. I think you’re absolutely right and thinking through. When you think about kind of the root of trust with like an email verification to sign with Google or sign in with Apple or just a magic link, there is still a password with that service provider of Google or Apple iCloud. You just to the user, it feels mostly passwordless because you’re already in a locked in state on that device. And so it is a really interesting question of what how could we actually see that password fall away? One thing I would note is that even before those passwords fall away, that in itself, if we can get to fewer routes of trust than having to proliferate passwords across accounts, that will still be a very large improvement to what the current internet holds for us, where we’re storing memories secrets across hundreds of different application servers. But I do think to your question of then, how do we take the next step and ultimately discard passwords entirely? I think some of the companies that are in really interesting positions that I’m paying a lot of attention to are both Apple and Google. You know, obviously they’re such massive businesses outside of the role that they play in authentication that it’s hard for me to know externally how much of a focal point this is there at those organizations. But I will say that Apple in particular has been paying a lot of lip service to the idea of what passwordless authentication could look like, using the device binding as the primary way that you authenticate yourself. And I think to me, there are some interesting pieces around yes, binding you to your mobile device and your laptop device, making those two different methods so that you could recover one with the other. I have not seen a particularly convincing argument for how you could ultimately get rid of seed recovery phrases entirely, because even if you know you have a backpack that has your phone and your laptop in it and that’s stolen, you’re still going to be, as you mentioned and kind of that state where you need to figure out a way to reconstitute your account. And so I think there are some interesting ideas I’ve seen actually in the Web3 world that I’m not particularly convinced of one that will become the eminent method. But I’m paying a lot of attention to some of the research and innovation there, where, for example, there’s a, you know, a web wallet called Argent that has pioneered some of these social recovery methods so that you can actually allow that seed rather than a seed phrase. You can reconstitute an account with trusted people like your wife or your family member. I still have some real concerns about trusting another individual person in order to recover your accounts, but those are the types of things I’m at least interested in because I haven’t found a singular silver bullet for how you ultimately completely eradicate seed phrases at that single account. I think to me, there’s a pretty good argument for how you get to single accounts like an Apple or Google or Stytch or one password world where there’s only one or a couple master passwords in your life that you need to memorize and secure. But beyond that, I have not found a super convincing argument for how you could completely eradicate those seed phrases at the core level. I’m curious, though, actually, if there’s anything you’ve come across in this podcast or outside of it that you’re paying a lot of attention to today.

Cameron [00:27:50] No, I mean, I think as evidenced by the question one of the areas of intense, you know, interest in and speculation on my part. I think if you didn’t surface this social recovery mechanism, I think that’s one of the ones that is the most interesting to me. Kind of almost, you know, maybe crowdsourcing is the wrong word, but building this wallet of trusted identities who can effectively vouch for you, you know, going back to kind of the origins of trust in communities, which is essentially the only thing you really have as a token of your trust is your name and your face, and your reputation would would hinge on that and kind of proving who you were in new communities by saying, OK, do you recognize my face? Do you recognize my name? OK, well, none of you do. But here’s this one guy who I know who you also know he is my, you know, certificate almost, if you will, that that now we are going to trust each other because of this shared connection. But you know, to your point. You know, the phrase turtles all the way down comes to mind. You know, you’re never going to get rid of passwords in in some sense because even if you move to, let’s call it a biometric, well, what is the biometric really OK? It is an algorithm that’s taking an abstraction of points on your face, running them through. Typically, some sort of hashing process, taking that result, storing it in a table. And then when you try and authenticate yourself with your face instead of a password, just the hash value of that calculation is your password. It’s still in a database somewhere in the same hash value that a regular password or recovery seed might be. So in some sense, we’ll never escape passwords in that regard. Been in in another to your point, if we can get to a place where rather than three hundred and fifty credentials, I have one credential similar to how I manage, you know, my my one password archive. Now the difference being, I have a central point of recovery. Like if I get compromised now, I’m going to go individually to each of these sites and try and change my credentials out. If you can get that to OK, it’s almost it’s through Google. And I think that, you know, something has gone wrong and I can go in and just immediately with a click the button, say, I am revoking all access across everywhere that I have federated my identity too. So really excited for the future. I think we will get there. And I think to your point, like the more ability we have to get people off of the in analogies previously in this podcast, I kind of refer to the cybersecurity threat environment as like the jungle floor, if you will. And if you’re doing something pretty low security, like reusing all of your passwords, sharing your email account password with your bank password and 50 other low security forum sites you’re a member of on the internet, it is not going to take a nation state threat actor, the panther of the jungle, if you will, to get you killed. Like some fire ants, random rats like low, who you know, low skill, low threat actors are going to be able to get to you. But if we can just get everybody off the forest floor to the point where really what you’re worried about again is those Panthers Nation-State Caliber well-funded, well-financed opponents who are going to be specifically targeting people not just, you know, script kiddies and credential stuffing. I think for the average person, that’s going to be more than enough to really protect them from all but the most black swan of cybersecurity events.

Reed [00:31:32] Yeah, I think that makes a lot of sense. And one of the other things that kind of brought to mind is I wouldn’t be surprised if the world we end up at five to 10 years from now is that, as you mentioned, that, you know, long lists have proliferated. Three hundred and fifty passwords actually can gets condensed into a singular core account like your Apple account or Google account. And yes, you’re maybe still signing in with that. And that’s where the root of trust is coming from. I wouldn’t be surprised if there’s a framework there where there are some users that decide they’re actually willing to. They don’t want an account recovery process in a traditional sense. Like, for example, say that you lose all of your information to try to get into Coinbase. The nice thing about that versus the traditional crypto wallet is that there’s probably still a pretty robust account recovery process through support. Or you could reconstitute that. I could see a world where you have a fork in terms of options users, where some people will have a more traditional like account recovery method that’s focused on identity verification around like identity documents, other context. And there might be another, you know, more tech savvy users, some of the users that are using things like password managers today, where they are using kind of some unique seed phrase to reconstitute their account if they lose that password. I could see that being one outcome. I’m not sure how likely that is, but I could see us building two different paths for depending on the savviness of the user and whether they want a true remote account recovery process or something that only they could control.

Cameron [00:33:04] Again, I couldn’t agree more, and I’m really excited about your prospects in and what Stytch’s is bringing out to the broader developer community because I think a lot of why we have seen the world take the shape it has is because these types of questions are not top of mind for developers, right? They’re trying to scale whatever it is they’re building. They are not digital identity experts. They’re focused on what their product does now, you know, as an identity head, as a weirdo in the space, of course, I am going to be immediately thinking about, well, digital identity touches everything and everyone should be thinking about it. But I also know enough to know that’s instinctively, you know, not how most people have. Most businesses are thinking about it. They’re thinking about whatever it is, is the core of what value they are providing, like connecting riders with drivers on my platform, delivering groceries, enabling, I don’t know, secure messaging or or whatever the application may be. And the more platforms like Stytch that emerge that make it super, super easy, low cost and low engineering effort, more importantly, to get best in class password list authentication integrated. I think you’re going to see the worm turn, so to speak, and you will see consumers that start making decisions with their feet regarding, Hey, oh, this platform is making me create a username and password. I don’t want to do that. I want to, you know, have a user experience where it gives me a magic link and I’m in and it’s going to be table stakes to be a competitive platform that you are respecting people’s cybersecurity needs and and moving them away from these technologies that we know are just not up to snuff in this modern world.

Reed [00:34:56] I couldn’t agree more. I feel like I should bring you to VC pitches in the future.

Cameron [00:35:00] Hey, we’re certainly available. And you know, I wouldn’t have a podcast if I didn’t love talking about this sort of stuff. I do want to be cognizant of your time here. We’re reaching the end of our road. But I would be remiss to not put that Magic Crystal Ball question to you. So I understand you can see into the future. I would love to get your crystal ball guesses for what we can expect to see in this space over the next one to three years. To preface this with no wrong answers, a bit of fun we like to have, but I do think it’s it’s really cool to see how all my different guests have responded to this question.

Reed [00:35:42] Definitely. So I’ll actually pick up on one of the last comments you made, which is. And, you know, analogy, we also bring from our plaid days that we are starting to see with password based authentication as well. So I think the first thing I’d add to this crystal ball is I don’t even think it’s that controversial just because the US, we’re kind of seeing it play out in real time where you see the early adopters of companies that want to provide both a better user experience but also want to have better security posture have already started going passwordless. And those are cutting edge companies like Square Cash, Monzo, Bank, Media, Slack, Revolut, cetera. And so you see a lot of these kind of very tech savvy companies that have already started adopting this posture for authentication. And what we’re noticing and the reason I can draw an analogy to what we saw Plaid is a lot of the one of the big innovations that Plaid had is the way that you would authenticate your bank before cloud is that you would go grab your checkbook and you’d find the account and routing number. You’d enter it on a website. You’d wait two to three days for micro deposits. So in one sense and seven cents to hit your bank account, then you’d come back to the original application and you’d say, here are the amounts that hit my bank account. Now, you know, I have access to that bank account and you can allow me to make this payments or do some other action within this app with my financial account. And so the reason I use that as an analogy is what we found at Plaid from the early days was the tech savvy companies that were trying to unseat a competitor or legacy competitor. So these are companies like Venmo or Robinhood, where they’re really early adopters of Plaid because they saw there was a UX arbitrage opportunity where they could provide a significantly better UX to those users. And they also were going to improve conversion so that they could lower their acquisition cost, improve lifetime value of users by making it a better experience. And what was interesting over the last couple of years before I left plaid is you started seeing how it became table stakes. I like that term that you used as larger legacy banks actually started replacing the way that you sign up for a bank account where instead of you having to go find your checkbook, you now use something like a plaid or plaid competitor in order to sync your bank automatically. And so I think we’ll see a similar thing in the past with the space where we’re already starting to see a lot of what I would probably normally term legacy banks that are showing a real interest in moving past this. I still think they’re going to be slow to roll this out in most cases, but I’d say the interest is there. So I think we will see that start to happen where the tech-savvy innovating companies are adopting passwordless. And then over the next two to three years, you’ll start seeing these companies you would have expected to be 10 years away are really more like two to three years away. And so that’s maybe one of the main predictions I would mention. And then I think the other piece on the crystal ball where we’re paying a lot of attention to is that you are seeing some different paradigms in how authentication could work with a web free movement. And I hesitate to say that it will all be adopted because there are some pretty large UX issues today with the way that seed phrases work, with the fact that the passwords you use with a MetaMask or phantom are really local only so they don’t even share the portable characteristics user users become familiar with. But they are interesting in the sense that it’s effectively one logged in session on your browser that you can carry across different sites. And so I think Web three is interesting in that I think we’ll start to see a lot of the kind of interesting experimentation which sometimes looks totally crazy. And in other times, is actually just a more interesting paradigm for how to approach us. And I expect to see a couple interesting things pop up there that may become more adopted in a Web two framework. So regardless of whether you’re even touching crypto, you might have some Web3 influence on the way that a user thinks about signing up or logging into an account. And so those are probably those are the main things I would call out in the crystal ball today. Absolutely love it.

Cameron [00:40:02] Very keen to, you know, circle back a year from now and and check in on those, I think I share your excitement for the possibilities of Web3 in the identity space. You know, I’ve been bullish on kind of some of the elements of science and related technologies. I think some of the UX barriers and you know, not to to beat a dead horse regarding the notion of like a recovery seed, but hopefully smoothing some of those rough edges off the notion of there is no central authority or any trusted place to do recovery other than the individual user maintaining that recovery seed or kind of they lose their whole account, but love the vast opportunities that these frameworks open up in terms of how you can, you know, share identities, share attributes in a secure and trusted way. So definitely something to to keep our eye on. Reed, thank you so, so much for joining us. I know your time is at a premium, but it was such a great conversation. If you can’t tell, I’m geeking out over here fanboy style before we do go. Shameless plug opportunity for folks listening who want to get involved, reach out to you. Understand how they can get Stytch up and running in their platform. What’s the best place for them to go?

Reed [00:41:22] They can go to stytch dot com. That’s a city wide TC. And then there are two options. If you’d like to talk directly with us and with myself, we have an option to talk to the health expert, and we’re happy to have a consultative process with you. But we also, you know, being developer at first minded in terms of if you don’t want to talk to anyone at all and just want to get up and running with the API, you can also sign up and be making your first API call in under a minute by just going through the self-serve process.

Cameron [00:41:51] Love it. It’s all about those choices. Reed, thank you so much. Best of luck. Not that you would seem to need it, but I suppose every little bit counts and thank you again for your time. It was really, really great.

Reed [00:42:04] Thanks. Yeah. And thanks so much for having me on. I really enjoyed the conversation.