WEBVTT
00:00:04.639 -->
00:00:06.000I'm Katie Perry.
00:00:06.000 -->
00:00:08.560We've got a great show for you today.
00:00:08.560 -->
00:00:20.640My guest is Georgina Merholm, founder and CEO of SOLO, and they're trying to change all the way identity it works and how it's shared across different platforms.
00:00:20.640 -->
00:00:22.000We're going to get into all of it.
00:00:22.000 -->
00:00:26.079But Georgina, thank you so much for taking the time to join us today.
00:00:26.399 -->
00:00:27.679Thank you for having me.
00:00:28.000 -->
00:00:32.159Now I want to get into sort of the crux of what you guys do.
00:00:32.159 -->
00:00:38.079Because it seems like every time I open a financial account, I'm being asked to sort of prove who I am.
00:00:38.079 -->
00:00:40.640And I do it over and over and over again.
00:00:40.640 -->
00:00:46.880And you all are really building something special in this space of reusable identity.
00:00:46.880 -->
00:00:48.079What does that mean?
00:00:48.079 -->
00:00:53.520Let's tee that up that concept before we get into the specifics of what you're building at SOLO.
00:00:54.079 -->
00:00:54.399Yeah.
00:00:54.399 -->
00:00:56.799So you hit the nail on the head with that.
00:00:56.799 -->
00:01:07.120Every time a consumer or a small business goes to a financial institution, but even outside of financial services, they have to reintroduce themselves.
00:01:07.120 -->
00:01:19.359It's a lot of burden on the customer to reprove who they are, but on the actual receiver of the information, they also go through the burden of verifying information about that customer.
00:01:19.359 -->
00:01:29.040And that is a very redundant process that happens across the industry today that has no way of moving from one institution to the other.
00:01:29.040 -->
00:01:52.719So what SOLO has built is essentially a verification network across financial services that makes it so that once a verification is completed and SOLO has validated that it's been completed up to a certain standard, it can be reused with the customer's agency and permission at a different institution to skip that process entirely.
00:01:52.719 -->
00:02:01.040And we've started with identity, but the same infrastructure can enable everything from income verification to account verification and beyond.
00:02:01.040 -->
00:02:13.680The closest analogy, I guess, is a TSA pre-check of, you know, we've validated it once and it can be reused if it meets the accepting institutions standard.
00:02:14.479 -->
00:02:23.520It's such a common uh problem, I guess, or challenge that people experience and might just assume, oh, this is just the way it has to be.
00:02:23.520 -->
00:02:25.360I'm fascinated by this.
00:02:25.360 -->
00:02:31.439I'm really fascinated by by products that are solving for these pain points along the way of the financial system.
00:02:31.439 -->
00:02:37.919And I'm curious, Georgina, was there a particular experience that sparked this idea for you?
00:02:37.919 -->
00:02:46.879Or what kind of what point did you think, you know, there's gotta be a better way, a better architecture for all of this uh that led to creating SOLO?
00:02:47.680 -->
00:02:52.879Um, so I'm a data scientist, and so I think very much architecturally.
00:02:52.879 -->
00:02:59.680I don't think there was a single aha moment that led to SOLO as it exists today.
00:02:59.680 -->
00:03:01.360It's been a journey.
00:03:01.360 -->
00:03:12.560Um, you know, I started my career as an open source intelligence analyst in cybersecurity, and the way that data collection works in that industry is very collaborative.
00:03:12.560 -->
00:03:15.039And it's collaborative because it has to be.
00:03:15.039 -->
00:03:34.719I, you know, also founded a lending company during COVID and through being on the other side of putting customers and they were freelancers and small businesses through the uh pain of verifying and and going through an application and providing all the documentation we needed to get comfortable making a loan to them.
00:03:34.719 -->
00:03:57.120Um, you know, I obviously experienced the pain on the other side of uh, you know, funnel loss, bad conversion, bad unit economics, potentially even fraud, and being, you know, needing to incur so much cost to verify an applicant and have that be uh not something that they could ever reuse after you know going through that process.
00:03:57.120 -->
00:04:01.520So I think it's it was a culmination of all of these things.
00:04:01.520 -->
00:04:06.639When when I first founded SOLO, we've always been a consumer reporting agency since day one.
00:04:06.639 -->
00:04:12.639We chose to be a regulated um company versus just you know technical software.
00:04:12.639 -->
00:04:18.000We started in the customer data collection space before we ever launched the network.
00:04:18.000 -->
00:04:29.519And so we were supporting uh lenders and banks in bringing customer information in, so just onboarding infrastructure, application infrastructure, and automating that as much as possible.
00:04:29.519 -->
00:04:36.240And about a year and a half in, I started to see persistent identities across our customer base.
00:04:36.240 -->
00:04:52.879Of, you know, we we had gotten it down to as short of a you know a time as we could with within one application, within one institution, but I was still seeing that same small business or that same consumer complete the same process in two different uh environments.
00:04:52.879 -->
00:05:09.759And so we went to our customers and some of the banks on our cap table and we we we pitched this as you know, what if we were to all start sharing verification across the network and actually turn you guys into the data providers?
00:05:09.759 -->
00:05:19.279I mean, we've had to overcome so much from you know regulatory challenges to governance to compliance to economics to make this actually work.
00:05:19.279 -->
00:05:25.120You know, the tech is the easiest part of all of this when it comes to customer data.
00:05:25.120 -->
00:05:29.199But um, yeah, I'm excited to dig more into it with you.
00:05:29.519 -->
00:05:30.399That's fascinating.
00:05:30.399 -->
00:05:35.600I love I love you spelling, it's almost like a pattern recognition that you're sitting there looking at it all and identifying.
00:05:35.600 -->
00:05:51.199And you mentioned something I just want to ask real quick before we go into the next question, um, the deliberate decision to to be regulated versus sort of just focusing on the tech, perhaps obvious to you building in that moment, but how how did that decision come about?
00:05:51.199 -->
00:05:54.399Why, why take the the regulated the regulated route?
00:05:54.959 -->
00:06:22.399Being on the lending side and and just even in over the last kind of three to five years, if you look at all the data companies in the space and you look at the average workflow, whether it's for account opening or for lending or for decisioning on on ongoing servicing, there's there's only one or two FCRA compliant models that exist in the industry.
00:06:22.399 -->
00:06:25.519And the rest are kind of just score.
00:06:25.519 -->
00:06:37.199It's like we we have an industry full of FICO scores and not enough bureaus that are responsible and liable for the track record that exists on a consumer and business.
00:06:37.199 -->
00:06:40.399And that problem really frustrated me for many reasons.
00:06:40.399 -->
00:07:03.439But even as a consumer and business, the fact that decisions can be made about me as a consumer, and I have no right to understand what that model knows about me, be able to correct it if it has outdated information, I think is one of the biggest broken pieces of infrastructure in our industry today.
00:07:03.439 -->
00:07:09.680I think we moved so fast on model building and so fast on alternative data models and decisioning.
00:07:09.680 -->
00:07:25.360And no one really cared to get the track record right from a governance perspective, where the consumer and the business owner have agency and rights over their record and where everyone can contribute to it.
00:07:25.360 -->
00:07:32.000So, you know, this this is stuff that usually you wouldn't see day to day outside of things going wrong.
00:07:32.000 -->
00:07:46.879So a consumer being rejected for rent or an account being closed because a fraud vendor said they were high risk when really it was, you know, they were traveling and the IP address maybe did change, but there's an explanation.
00:07:46.879 -->
00:07:53.680And so the lack of regulated data companies in the space, there's a massive need for it.
00:07:53.680 -->
00:08:07.120And uh, you know, we've taken on that burden and gladly so, because we we think it's missing critical infrastructure that gives consumers and businesses just more rights over their track record.
00:08:07.759 -->
00:08:16.720Yeah, I love I love the idea of data rights, and we get into that in a little bit, but talk about reusable identity and some of the concepts you're sharing.
00:08:16.720 -->
00:08:18.319Sounds intuitive.
00:08:18.319 -->
00:08:24.480And when we just when we talked before coming on now, not entirely a brand new idea.
00:08:24.480 -->
00:08:28.560Um, there have been previous sort of attempts in this space.
00:08:28.560 -->
00:08:42.559I'm curious what what those previous attempts toward building this sort of uh architecture looked like and and what had stopped those from becoming sort of a more standardized architecture or infrastructure here in the US?
00:08:42.879 -->
00:08:44.159That's a really good question.
00:08:44.159 -->
00:08:53.759And and usually, you know, we have to overcome a lot of PTSD with with all the trials that have happened in the industry on reusability.
00:08:53.759 -->
00:09:00.000I think the challenge in the past has been really three, three core challenges.
00:09:00.000 -->
00:09:03.039The first one being incentives and economic incentives.
00:09:03.039 -->
00:09:15.600Open banking has gone through so much to just get to where it is today because banks are not uh always willing to make uh customer data available to their competitors.
00:09:15.600 -->
00:09:20.639And so you run into that a lot with any uh data sharing and verification models.
00:09:20.639 -->
00:09:40.320I think the inevitability of it and the timing where now this is considered business as usual and it's happening whether you know participants actively participate or not, I think also has just made this um more timely because it's it's we're not fighting from ground zero.
00:09:40.320 -->
00:09:44.159Customer data portability is something that is alive and well and happening.
00:09:44.159 -->
00:09:53.279And so just overcoming a bit on that has been uh important, and and many players have walked so that SOLO can run in that regard.
00:09:53.279 -->
00:10:02.000Our incentive structures also so that anyone that does publish data or verifications to the network retains most of the economics around that.
00:10:02.000 -->
00:10:05.360So that has been really important in getting us off the ground.
00:10:05.360 -->
00:10:10.720The second uh kind of problem is, you know, when you're launching a network, there's always a cold start problem.
00:10:10.720 -->
00:10:15.519You have to get all these, all the data supply in, and then you have to get the queryers.
00:10:15.519 -->
00:10:27.600And so our approach to that has been working with sponsor banks that sit on both sides of uh the market, where you know, our average sponsor bank has 10 million uh households that they've verified.
00:10:27.600 -->
00:10:36.720Um, and they are also the governance backbone behind some of the largest fintechs in the country that have the highest verification volumes every day.
00:10:36.720 -->
00:10:43.039And then the third piece has been around the governance and lack of regulatory clarity around it.
00:10:43.039 -->
00:10:48.480It's very timely that we're talking today because uh, you know, there's been a lot of progress around that.
00:10:48.480 -->
00:10:54.159I think previous attempts have looked more like wallets or closed loop environments.
00:10:54.159 -->
00:11:00.399So if you trusted the vendor, you would trust that if they verified it before, you can inherit that verification.
00:11:00.399 -->
00:11:07.679Um, and and that was kind of adopted as the standard and never really took off as a model outside of maybe some sub.
00:11:07.679 -->
00:11:22.080Uh, I think is probably the the closest example I can think of where they really penetrated one industry and then um, you know, kind of became the the issuing and acceptance authority of reusable identity in crypto at the very least.
00:11:22.080 -->
00:11:36.720Or other attempts have looked like a wallet, which is very nice when you issue something back to the customer, but it's not very usable if no one has built the acceptance layer for whether they can trust that issued credential or not.
00:11:36.720 -->
00:11:42.799It's a graveyard of of uh of these projects, and there's obviously we've studied them very closely.
00:11:43.120 -->
00:11:46.000Yeah, a lot of a lot of different directions taken.
00:11:46.000 -->
00:11:48.720And you mentioned the regulatory updates.
00:11:48.720 -->
00:11:54.559Uh, for people listening at home, I know I know there was been some exciting news uh and updates from FinCEN.
00:11:54.559 -->
00:12:03.360Can you for someone who's not in the weeds, uh what happened, what changed, and and how does that impact what you're building?
00:12:03.679 -->
00:12:14.000Yeah, so on September 8th, FinCEN issued FAQs on verifiable digital credentials under SIP policies.
00:12:14.000 -->
00:12:28.720So um, up until this point, SIP or customer identification programs at banks were very uh dependent on documentary or more traditional ways of verifying a customer.
00:12:28.720 -->
00:12:37.120The only entrenched model on reusable identity in banking, at least in regulated environments, was SIP reliance.
00:12:37.120 -->
00:12:44.720You know, up until up until recently, banks could trust each other's work under the Bank Secrecy Act.
00:12:44.720 -->
00:12:56.399So if one bank has verified Katie and they have a reliance agreement with another bank, the second bank doesn't actually have to go it puts KT through the same SIP.
00:12:56.399 -->
00:12:59.600They can actually just take what this other bank has provided.
00:12:59.600 -->
00:13:13.200And up until this point, SOLO has operated um with only BSA-regulated banks so that if one bank has verified a customer or information about a customer, the next bank can fast pass it.
00:13:13.200 -->
00:13:32.960The recent regulatory update actually makes that much more flexible because it means anyone can issue verifiable credentials with the caveat of the accepting party will have to make sure that it still meets their policy, which is something that we have always been uh prepared for and built for.
00:13:33.120 -->
00:13:36.960You know, the natural question when you're explaining this is kind of like, well, how do you know?
00:13:36.960 -->
00:13:37.919How do you prove it?
00:13:37.919 -->
00:13:39.200You're taking people's word.
00:13:39.200 -->
00:13:49.200And I know you mentioned you have a really kind of rock solid approach to actually verifying sort of these steps and making sure everything is clicking and up to standards.
00:13:49.200 -->
00:13:58.799Um, so maybe that that might be kind of top of mind for people as you're talking about, okay, this this party checked one person, you know, now it's going over here.
00:13:58.799 -->
00:14:02.559How do you how do you know as sort of the the network operator?
00:14:02.559 -->
00:14:14.799Maybe you could walk us through sort of how what what the rigor is that SOLO um applies there and how how you make sure that you sort of have trust into all of those steps.
00:14:15.120 -->
00:14:22.559Before anything ever enters the network, um, there's two questions that SOLO solves for.
00:14:22.559 -->
00:14:27.120One, how did you verify whatever you verified, right?
00:14:27.120 -->
00:14:35.919So every bank has its own SIP and CDD policies, which determine what is acceptable or reasonable for them.
00:14:35.919 -->
00:14:41.679So you might have a bank that is very strict on the type of documentation that they require.
00:14:41.679 -->
00:14:49.200It might be as specific as, you know, we will only take utility bills and bank statements to confirm someone's address.
00:14:49.200 -->
00:14:53.519It might be that they only will take government-issued ID.
00:14:53.519 -->
00:15:00.639Some other programs, maybe that are lower risk, uh, might be fine with just your SSN.
00:15:00.639 -->
00:15:03.519And that could be the extent of what they do.
00:15:03.519 -->
00:15:14.159So in order to trust someone else's work and make sure that it also fulfills yours, SOLO first needs to understand what is it that you actually did to verify that person?
00:15:14.159 -->
00:15:21.919And so we actually connect at the workflow level so we can see the workflow run on exactly what was verified.
00:15:21.919 -->
00:15:25.600The second question is did you do what you said you did?
00:15:25.600 -->
00:15:25.919Right.
00:15:25.919 -->
00:15:50.960So one is a policy question, the second is a workflow question, and that reconciliation, validation, and assurance is very important for us to issue a credential because a credential for Katie that was done by just checking Katie's SSN is very different than a credential that was issued after Katie uploaded her ID and did biometrics and uh, you know, they verified with DMV.
00:15:50.960 -->
00:15:53.519That's a very different uh credential.
00:15:53.519 -->
00:16:10.320And so SOLO is prepared for a world where everyone is a credential issuer, but we need to validate exactly what happened during the verification so that we can match the credentials to the right accepting institutions because those will vary, right?
00:16:10.320 -->
00:16:16.320It varies on risk appetites, it varies on use case, it varies on so many different things.
00:16:16.320 -->
00:16:34.080And going back to your question on why this has not uh taken off in the past with other attempts, the vendor-controlled uh closed loop credentials assume that everyone has to do the same thing and everyone has to trust the same vendor.
00:16:34.080 -->
00:16:44.240In SOLO's model, it's just about understanding what it is that was done, validating it and clearing it against your own policy.
00:16:44.240 -->
00:16:49.679Um, and that's one of the main blockers why everyone repeats verifications from strap from scratch.
00:16:49.679 -->
00:16:55.279Banks will repeat verifications from scratch because they don't know if you were verified by another party.
00:16:55.279 -->
00:17:01.919They don't know if their verification would satisfy um, you know, this context.
00:17:01.919 -->
00:17:06.799And and it's very hard for banks to trust each other, is what we've learned.
00:17:07.119 -->
00:17:16.480You mentioned clearing, which I think is an important word there because I remember when I was first reading up on you guys, like, oh, maybe this is like a KYC thing, but it's really not.
00:17:16.480 -->
00:17:22.160SOLO isn't, you know, like another KYC vendor, it's almost more like a clearinghouse.
00:17:22.160 -->
00:17:27.839And you mentioned Visa being one of the the more appropriate comps.
00:17:27.839 -->
00:17:28.960How does that work?
00:17:28.960 -->
00:17:33.119How does this how does this line up to sort of how how Visa is operating?
00:17:33.119 -->
00:17:35.759Uh SOLO in your space, visa in theirs.
00:17:35.759 -->
00:17:37.279How does that analogy work?
00:17:37.599 -->
00:17:57.039Yeah, when we talk about being Visa for verification or customer permission data sharing, we're really talking about there being issuers of data that can be verification vendors, that can be banks, that can be fintechs, that can be anyone that's diligenced a customer that SOLO has vetted and validated what they've done.
00:17:57.039 -->
00:17:59.920And then you have the acceptance layer, right?
00:17:59.920 -->
00:18:07.119And to be able to accept uh, you know, a credential SOLO manages the policy matching.
00:18:07.119 -->
00:18:13.200So if you think of uh the clearinghouse or visa, you know, we are not doing the KYC ourselves.
00:18:13.200 -->
00:18:24.000We're not checking with Secretary of State, we're not doing any of those uh, you know, very hard things that the data aggregators have done an amazing job at and that the banks leverage.
00:18:24.000 -->
00:18:33.759We are essentially just matching and auditing the data and verifications that come in against what is required in that point of time.
00:18:33.759 -->
00:18:40.640And if it's a match, we are managing the governance, the liability, the economics around that sharing.
00:18:41.839 -->
00:18:46.240And let's let's kind of put a slightly more concrete lens onto what you're building.
00:18:46.240 -->
00:18:50.319Because I know you just wrapped up an exciting pilot that involved the Treasury Department.
00:18:50.319 -->
00:18:56.480Um, I know you can't speak to all the specifics, but at a high level, what was this pilot all about?
00:18:56.480 -->
00:18:59.359What question were you trying to answer with it?
00:18:59.359 -->
00:19:03.440Uh, and why did banks want the regulators observing it?
00:19:03.680 -->
00:19:22.000The long story short on what we were trying to answer with the pilot, um, and it was really like the million-dollar question of the pilot is how can a bank service a customer they have not met by relying on work they did not do?
00:19:22.000 -->
00:19:27.440Um, the short answer is that the regulation exists for this.
00:19:27.440 -->
00:19:30.559It's under the Patriot Act in 2003.
00:19:30.559 -->
00:19:39.759Um, SIP reliance allows for one bank to use the verification work of another bank to skip that process for an end customer.
00:19:39.759 -->
00:19:55.359Historically, that's worked for um, you know, deposit marketplaces, uh, loan syndication, um, a lot of backdoor activity rather than at the point of onboarding, being able to skip steps to make a customer's life easier.
00:19:55.359 -->
00:20:05.440With um sponsor banking, embedded financing, and now AI, that's just becoming a much more common way that banks operate.
00:20:05.440 -->
00:20:09.839And with sponsor banking, you've seen the best and the worst of that, right?
00:20:09.839 -->
00:20:12.720Sponsor banks for them, this is business as usual.
00:20:12.720 -->
00:20:19.359They service customers every day that they did not meet by relying on the work of fintech programs.
00:20:19.359 -->
00:20:22.079And, you know, we've seen consent orders come out of that.
00:20:22.079 -->
00:20:26.400We've seen um, you know, great programs come out of that as well.
00:20:26.400 -->
00:20:47.359But sponsor banking really has uh proven that this is both within the regulatory, existing regulatory framework, um, and gave us a very uh you know closed environment where we could operationalize the governance of operations that happens outside of a bank to rely on on one another.
00:20:47.359 -->
00:20:55.200Um, and so our banks went to their examiners and their prudential regulators and asked for this to be um observed.
00:20:55.200 -->
00:21:00.240We took a very conservative approach to reusable identity through SIP reliance.
00:21:00.240 -->
00:21:02.960It was only with BSA-regulated banks.
00:21:02.960 -->
00:21:11.920Um, we started with their SIP policy and looking at what each bank is comfortable with when it came to customer identification.
00:21:11.920 -->
00:21:15.119No one changed their policies whatsoever.
00:21:15.119 -->
00:21:31.200The first thing we did was look at how their fintech programs were onboarding customers based on a SIP policy and how do we make that more auditable for them so that it can then be shared across a network, right?
00:21:31.200 -->
00:21:44.319And the findings were uh, you know, quite uh informative to how we ended up building out um a lot more of the network's infrastructure auditing layer, acceptance layer.
00:21:44.319 -->
00:21:56.720The guidance issued follows a lot of what we found, which um you know says it's it's okay for you to use verifiable credentials as long as it meets your own policy.
00:21:56.720 -->
00:21:59.680And to do that, you really need to answer the first.
00:21:59.680 -->
00:22:01.759Question, you know, what is the policy?
00:22:01.759 -->
00:22:02.880How was this verified?
00:22:02.880 -->
00:22:14.319And the second question is like if a banks or fintech or a vendor says they did it, we need to prove that they did it to get comfortable reusing that work and not starting from scratch.
00:22:14.319 -->
00:22:16.960So it was a very informative uh pilot.
00:22:16.960 -->
00:22:21.440Our capstone is by the time this is released, our capstone will be public.
00:22:21.440 -->
00:22:26.079And so if anyone's curious about the findings, you can find it on our website.
00:22:26.480 -->
00:22:26.960Awesome.
00:22:26.960 -->
00:22:27.920I can't wait to read those.
00:22:27.920 -->
00:22:32.400And I really appreciate you simplifying that because when you were explaining it, I'm like, oh, I follow this.
00:22:32.400 -->
00:22:35.680And then I'm thinking on the back end, that's got to be so complicated.
00:22:35.680 -->
00:22:51.279What's what you've built behind the scenes to sort of abstract that complexity and make sense of all those inputs, and then to you know, invite the regulators to be there as part of it, which I thought was interesting because a lot of people in our space blame the regulators for slowing things down.
00:22:51.279 -->
00:22:53.839And you're like, hey, come have a seat at the table.
00:22:53.839 -->
00:22:56.319We want you guys to be a part of this.
00:22:56.319 -->
00:23:06.160Um, so if if regulation is not really the bottleneck, what needs to happen for sort of the vision you have for what you're building to accelerate even farther?
00:23:06.160 -->
00:23:08.880Is it is it a tech sort of challenge?
00:23:08.880 -->
00:23:11.440Is it an adoption challenge?
00:23:11.440 -->
00:23:22.079Um, what what if you know, added or removed would really help accelerate things for for SOLO's business and um others who are building towards a similar vision?
00:23:22.400 -->
00:23:23.359Yeah, it's two things.
00:23:23.359 -->
00:23:29.839People need to get comfortable accepting others' verifications, which has been the really big heavy lift that we have worked on.
00:23:29.839 -->
00:23:34.079Everyone wants uh lower friction for the customer.
00:23:34.079 -->
00:23:36.240That there's never been a question on that.
00:23:36.240 -->
00:23:42.960It's just about how comfortable am I replacing my own diligence with the diligence of someone else.
00:23:42.960 -->
00:23:53.519And having that infrastructure that audits all the verification that comes in and reconciles it against your policy is really like the technical solve around this.
00:23:53.519 -->
00:23:56.480Regulation is definitely not a bottleneck, especially not now.
00:23:56.480 -->
00:24:00.480It might have been, you know, 10 years ago, but it's definitely not the bottleneck now.
00:24:00.480 -->
00:24:09.200Uh, you know, up until this point, SOLO on purpose operated in kind of a closed environment with just sponsor banks and BSA regulated banks.
00:24:09.200 -->
00:24:28.880Um, and you know, we're very excited to now invite the rest of the industry to both be uh, you know, issuers of credentialed work that they've done and go through the process of auditing their own verification and turning that into credentials that they can earn on and be a provider to the rest of the industry.
00:24:28.880 -->
00:24:40.799Um, but it's really gonna come down to whether you know a fintech can trust the work of another fintech based on all of the plumbing that SOLO has has done to make that possible.
00:24:40.799 -->
00:24:48.559And it's also gonna come down to everyone um, you know, uh being incentivized to issue credentials.
00:24:48.559 -->
00:25:03.200You know, I'm seeing a lot of companies that are announcing uh credential issuance as part of their product, and it makes me very excited uh because it's uh, you know, at the end of the day, like it the enemy of SOLO is redundancy.
00:25:03.200 -->
00:25:12.960And so if you've done the verification and have packaged it in a way that can be audited and reused, like we want as many, we want everyone to be an issuer on the network.
00:25:13.519 -->
00:25:21.839You started alluding to sort of the economics of this, and you know, we've been talking high-level, you know, wouldn't it be great if for the end user, but for the business?
00:25:21.839 -->
00:25:28.319Uh, if you're a bank or a fintech, you spent a lot of money, time, resources verifying your customers.
00:25:28.319 -->
00:25:36.079Why would you then potentially help that customer on board at another company, potentially a competitor?
00:25:36.079 -->
00:25:40.079I think this was probably a similar question plaid got asked back in the day.
00:25:40.079 -->
00:25:46.960Um, but how do you sort of um how do you respond to sort of that that economics uh question?
00:25:47.359 -->
00:25:50.480I mean, luckily, I can now point to plaid, you know.
00:25:50.480 -->
00:25:54.319I I don't think plaid had that luxury when when they started.
00:25:54.319 -->
00:25:55.359So thank you, plaid.
00:25:55.359 -->
00:26:01.519Um, I my easy answer uh to that is usually look around you, it's already happening.
00:26:01.519 -->
00:26:06.799You can capture the economics or a data middleman can, but it's already happening.
00:26:06.799 -->
00:26:08.559There's an inevitability there.
00:26:08.559 -->
00:26:15.200Two, when you actually look at the behavior of banks um in the past historically.
00:26:15.200 -->
00:26:21.920Banks have not been averse to data sharing, verification sharing.
00:26:21.920 -->
00:26:23.599It's called reliance.
00:26:23.599 -->
00:26:26.880They they do it when the economics make sense, right?
00:26:26.880 -->
00:26:32.400So uh, you know, a bank will originate mortgages and then go sell that portfolio to another bank.
00:26:32.400 -->
00:26:37.680It's very normal for a CFO of a bank to call up another CFO of a bank to say we have too many deposits.
00:26:37.680 -->
00:26:38.720Do you want to buy some?
00:26:38.720 -->
00:26:45.519So I think ultimately as well, uh figuring out economics that make everyone comfortable.
00:26:45.519 -->
00:26:55.440And, you know, this might be very purist of me, but the SOLO approach is we want to incentivize everyone to just service the customer wherever that customer originated and came from.
00:26:55.440 -->
00:27:04.720And so um, you know, there's an inevitability in the fact that customer data portability and verification portability is already here.
00:27:04.720 -->
00:27:07.279The moment has arrived, it's too late.
00:27:07.279 -->
00:27:08.720Cats out of the bag.
00:27:08.720 -->
00:27:11.359Thank you, you know, data vendors.
00:27:11.359 -->
00:27:19.920Um, but the second piece is just making the economics work for every party has been at the core of everything that SOLO does.
00:27:19.920 -->
00:27:27.200Um, because we want to incentivize everyone to um, you know, service and help the customer pass through a fast pass.
00:27:27.200 -->
00:27:39.440And if it means paying them as a data vendor, if it means uh having reliance agreements across the network, um will you know iterate as more members join.
00:27:39.440 -->
00:27:44.079But for now it's worked out just on the basis of economic incentives.
00:27:44.480 -->
00:27:52.079Yeah, and with that the network model, there's a lot of people parties, you need to sort of keep happier, make sure they feel comfortable.
00:27:52.079 -->
00:27:54.640We just talked about the comfort on the platform level.
00:27:54.640 -->
00:28:06.960Let's talk about the comfort for you know the end users who, you know, increasingly people are increasingly caring about who has their data, how are they using it, how is it being shared?
00:28:06.960 -->
00:28:13.839Um, and also the second step of that, wanting to control their data footprint in their digital presence.
00:28:13.839 -->
00:28:31.680So for the end user, um, you know, how would you kind of talk through what this looks like for them, or maybe why this model is actually beneficial for somebody who is more um diligent about tracking and managing their own data?
00:28:32.000 -->
00:28:32.400Yeah.
00:28:32.400 -->
00:28:41.599I mean, the reason SOLO decided to be a consumer reporting agency on day one is to give consumers agency of their track record.
00:28:41.599 -->
00:28:46.000Um, you know, uh we monitor cases every day.
00:28:46.000 -->
00:28:57.440Um, and I personally speak to consumers and small businesses every single day that um are victims of having decisions made about them using data that they didn't even know existed.
00:28:57.440 -->
00:29:08.319And increasingly I have learned that what consumers and business owners really care about is it's not privacy in the traditional term.
00:29:08.319 -->
00:29:22.160It is fear of something out there being used against them, which is basically a loss of agency, is what consumers really uh it comes down to, at least, at least in our experience.
00:29:22.160 -->
00:29:27.039Um, and so's model has always been consumer permissioned first.
00:29:27.039 -->
00:29:39.440Um, and I think you know, most data aggregators in the space also operate the way SOLO does as a network, in terms of you ask the customer if it's okay to move their data from one place to another.
00:29:39.440 -->
00:30:01.519Where I think we have uh weaknesses in traditional models that where SOLO has actively uh fixed um is with traditional uh data sharing, if it's API based, even if it's customer permissioned, it's usually you you permission at the point where the data is transferred, and then it kind of just enters a void and the customer forgets who has what.
00:30:01.519 -->
00:30:08.160And so being able to go to a consumer reporting agency and say, hey, what does everyone have?
00:30:08.160 -->
00:30:18.000One, to be able to just know when you're applying for things like what's being used to make decisions about you, but more importantly, to correct it or revoke it.
00:30:18.000 -->
00:30:22.960It's so important and so central to everything that we do.
00:30:22.960 -->
00:30:31.279And so uh, you know, customer permission for us, it's not just like a mechanism to get the data when we act on behalf of the customer.
00:30:31.279 -->
00:30:44.960It is really, it is, it is a full life cycle of how helping the customer um, you know, have agency over their information and how it's used to make decisions about them.
00:30:44.960 -->
00:30:56.799And so with all of our uh, you know, customers, we issue the adverse actions, we go through the appropriate mechanisms to have customers understand why decisions were made and and what information was used.
00:30:56.799 -->
00:31:04.079And uh we have processes around correcting um, you know, information that maybe is outdated or incomplete.
00:31:04.079 -->
00:31:18.079Um, and you know, so as a personally a very important uh, you know, part of why I founded the company and and and why it's more important to me than just you know um verification sharing as a commercial offering.
00:31:18.480 -->
00:31:24.640Yeah, it's it's interesting to hear that being a through line from the even the earliest iterations of of the company.
00:31:24.640 -->
00:31:26.160I want to turn to AI.
00:31:26.160 -->
00:31:41.680We you kind of touched on it a little before when you were talking about how like increasingly uh people uh onboarding people they've never met, or even in the future, perhaps an agent they they've never uh met or credentialed.
00:31:41.680 -->
00:31:55.839So it seems like we're going from you know a place where the questions, oh, is that person who they say they are, to did that person authorize this agent thing, bot whatever it is, to do something on their behalf?
00:31:55.839 -->
00:32:01.359Um, what does that mean for the identity problem you're solving for?
00:32:01.359 -->
00:32:13.440And um, does that, I guess, is that going to be agentic commerce, agentic finance, is that potentially going to be an accelerant for what SOLO is building down the line?
00:32:13.680 -->
00:32:15.680Yeah, I would, I definitely think so.
00:32:15.680 -->
00:32:19.039Personally, I don't know how much of a market it is just yet.
00:32:19.039 -->
00:32:27.039In terms of in terms of volumes, we're playing obviously paying close attention and from an infrastructure perspective, very prepared for it.
00:32:27.039 -->
00:32:48.400But uh, if nothing else, agentic commerce makes consumer agency much more um uh critical as infrastructure because the the consumer is not just uh needing to permission access to an account, but um, they need to authorize uh a representative, whether that's an agent or another human.
00:32:48.400 -->
00:32:52.240And that needs to be done um, you know, throughout the lifecycle of a customer.
00:32:52.240 -->
00:33:05.039We can't repeat the same mistake we made with open banking, where we permission access and then it goes into a black hole and the customer forgets what they've authorized, what they've consented to.
00:33:05.039 -->
00:33:11.680Um, and so agency cannot be point of in time when it comes to agentic commerce.
00:33:11.680 -->
00:33:20.640It has to be persistent and a customer needs to be able to revoke access as quickly as they um, you know, issue it.
00:33:20.640 -->
00:33:22.240It's definitely an accelerant.
00:33:22.240 -->
00:33:25.119I'm, you know, I hope the market moves uh fast.
00:33:25.119 -->
00:33:30.640I think there's a lot to figure out with liability, economics, revocation, um, and governance.
00:33:30.640 -->
00:33:39.279But all the more reason we need uh a network to manage all of the credentialing of both, you know, agents and verifications.
00:33:39.279 -->
00:33:54.880Uh, because at the end of the day, when you look at why visa or the clearinghouse are so core to financial infrastructure, it's really they you can, you know, you can have so many innovators in the space, whether it's stable coins or or newer networks, but they they got one thing right.
00:33:54.880 -->
00:33:58.079They got the governance right, they have a chargeback layer.
00:33:58.079 -->
00:34:04.160Um, the consumer feels safe knowing that they can dispute and correct things.
00:34:04.160 -->
00:34:15.039And so um, you know, uh it's it's why we've bet on a network model and think that um agentic commerce, if nothing else, actually requires more of those uh controls.
00:34:15.519 -->
00:34:16.960Yeah, and I think I think you're right.
00:34:16.960 -->
00:34:32.159It seems like it feels like we keep having conversations about agentic commerce, but then you look at the usage and the survey data, and it seems like people are generally getting more and more comfortable with agents doing things on their behalf, but the barrier when it involves their money is much higher.
00:34:32.159 -->
00:34:43.119And so sort of there's that trust um layer, but that that would seem to ladder into something like you're building at SOLO where you know that that trust is part of the equation.
00:34:43.119 -->
00:34:52.800So we'll see how how quickly we start allowing agents to make purchase for purchases for us, but it seems like trust will be a big part of driving consumer adoption.
00:34:52.800 -->
00:34:56.000I want to turn to kind of looking ahead for SOLO.
00:34:56.000 -->
00:35:02.559We we've talked about sort of the origins and more contemporary, you know, the Treasury Department pilots.
00:35:02.559 -->
00:35:11.360Um historically, focus was heavily on banks, now opening the network to non-bank issuers.
00:35:11.360 -->
00:35:17.760Tell us why, you know, now and into the future, that is such an important evolution for the company.
00:35:18.079 -->
00:35:23.920Um, I mean, candidly speaking, we've always wanted to and we've always had demand for it.
00:35:23.920 -->
00:35:31.519And and and our highest demand has been from fintechs and and crypto companies, but also data aggregators wanting to work with SOLO.
00:35:31.519 -->
00:35:37.199The lack of regulatory guidance around it was uh one of the reasons we slowed down on it.
00:35:37.199 -->
00:35:49.039But now that you know we have clear uh guidance to work off of around credentialing, uh we're very excited to open up the network for everyone.
00:35:49.039 -->
00:36:10.960I think the biggest thing is um the biggest thing for us has been building out robust infrastructure that, you know, if a bodega does in-person verification and we've audited how they do in-person verification, it can carry the same strength as if a bank did in-person verification.
00:36:10.960 -->
00:36:26.719I think getting to that point obviously took us as long as it did, but um we're very excited to now go broader and uh we've released uh our shared customer graph with the industry, and they'll be able to both furnish and query from it.
00:36:26.719 -->
00:36:28.960Uh, it's a consumer permissioned graph.
00:36:28.960 -->
00:36:34.639Um, you know, everything that we've rolled out to sponsor banks is now going to be available to the rest of the industry.
00:36:34.639 -->
00:36:50.880So it just hopefully means uh much more mass adoption and scaling um faster uh without losing any of our risk and governance controls that we that we built very closely with, uh both regulators and the regulated industry uh and banks.
00:36:51.360 -->
00:36:58.880Yeah, I know you it's it's interesting because what you're building is so unique, but there are kind of analogies people can grasp, whether it's the PLAD model or Visa.
00:36:58.880 -->
00:37:04.960And when you were just talking the bodega example, you know, my mind, not not the same type of business, but clear.
00:37:04.960 -->
00:37:07.760You know, clear gets me on an international flight.
00:37:07.760 -->
00:37:10.880Clear also provides me access to an office building.
00:37:10.880 -->
00:37:21.519And so, like, what is how do you create this standard across multiple use cases that um is familiar to the end user and trusted at all levels?
00:37:21.519 -->
00:37:28.239I think that's a really fascinating uh challenge and model that you're building, specifically within within your space.
00:37:28.239 -->
00:37:31.199So it sounds like there's a lot of exciting things ahead.
00:37:31.199 -->
00:37:35.679Um for people listening in, I only have you for a couple more minutes.
00:37:35.679 -->
00:37:43.599Um, people, I mean, these are topics that touch literally every single company and and most of the operators that that follow TWIF.
00:37:43.599 -->
00:38:07.039Um, what are some of the trends, themes uh uh coming out of either your space or your company and what you're building at SOLO that you think in the next call it six, 12 months, if you're building in fintech, if you're working at a bank, um when it comes to digital identity, what are sort of the most important things people should be paying attention to?
00:38:07.440 -->
00:38:16.239I think tokenizing processes and not just um over, I think anyone can issue a cryptographic signature saying whatever they want.
00:38:16.239 -->
00:38:20.960I can issue a cryptographic credential saying I'm the princess of the world, right?
00:38:20.960 -->
00:38:31.119I think assurance is a very, very big topic that we talk about every single day, whether it's with regulators or banks or fintech companies.
00:38:31.119 -->
00:38:37.679You know, I think uh collaboration is going to be a very big pillar uh in the next couple of years.
00:38:37.679 -->
00:38:42.559Uh, my bet personally is that every bank is going to be a sponsor bank to some degree.
00:38:42.559 -->
00:38:46.400Um, and and banking will look much more modular than it does now.
00:38:46.400 -->
00:38:49.280I think it banking won't be like a destination.
00:38:49.280 -->
00:38:54.880I think it's just gonna be services that that are offered um, you know, wherever the customer is.
00:38:54.880 -->
00:39:08.400But having assurance is important for industry collaboration and for identity assurance and for us to not keep repeating work that has been previously done.
00:39:08.400 -->
00:39:13.119Um, so you know, my my word of the year is uh assurance.
00:39:14.480 -->
00:39:15.199Love it.
00:39:15.199 -->
00:39:19.360Um and yeah, really fascinating what you're building in reusable identity.
00:39:19.360 -->
00:39:27.119I learned a lot for people who want to follow the journey of SOLO, especially when you mentioned this, the results of the pilot, other exciting news.
00:39:27.119 -->
00:39:33.360Where are the best uh places for people to stay up to speed with everything you guys are working on and rolling out?
00:39:33.679 -->
00:39:34.639Our website is SOLO.
00:39:34.639 -->
00:39:40.079So we're at SOLOapi.
00:39:40.079 -->
00:39:44.079If you put that in the URL, you should find us.
00:39:44.079 -->
00:39:45.920We're pretty active on both.
00:39:46.239 -->
00:39:48.079All right, we'll make sure to tag those.
00:39:48.079 -->
00:39:51.199Georgina Merholm, founder and CEO of SOLO.
00:39:51.199 -->
00:39:52.800Thank you so much for joining us.
00:39:52.800 -->
00:39:56.159You'll have to drop by when you have some more updates to share with us.
00:39:56.480 -->
00:39:57.519I definitely will.
00:39:57.519 -->
00:39:58.559Thank you.
