Can Reusable Identity Fix Fintech’s Verification Problem? - With SOLO Founder Georgina Merhom

WEBVTT
00:00:04.639 --> 00:00:06.000
I'm Katie Perry.
00:00:06.000 --> 00:00:08.560
We've got a great show for you today.
00:00:08.560 --> 00:00:20.640
My 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.000
We're going to get into all of it.
00:00:22.000 --> 00:00:26.079
But Georgina, thank you so much for taking the time to join us today.
00:00:26.399 --> 00:00:27.679
Thank you for having me.
00:00:28.000 --> 00:00:32.159
Now I want to get into sort of the crux of what you guys do.
00:00:32.159 --> 00:00:38.079
Because 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.640
And I do it over and over and over again.
00:00:40.640 --> 00:00:46.880
And you all are really building something special in this space of reusable identity.
00:00:46.880 --> 00:00:48.079
What does that mean?
00:00:48.079 --> 00:00:53.520
Let'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.399
Yeah.
00:00:54.399 --> 00:00:56.799
So you hit the nail on the head with that.
00:00:56.799 --> 00:01:07.120
Every 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.359
It'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.040
And 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.719
So 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.040
And 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.680
The 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.520
It'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.360
I'm fascinated by this.
00:02:25.360 --> 00:02:31.439
I'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.919
And I'm curious, Georgina, was there a particular experience that sparked this idea for you?
00:02:37.919 --> 00:02:46.879
Or 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.879
Um, so I'm a data scientist, and so I think very much architecturally.
00:02:52.879 --> 00:02:59.680
I don't think there was a single aha moment that led to SOLO as it exists today.
00:02:59.680 --> 00:03:01.360
It's been a journey.
00:03:01.360 --> 00:03:12.560
Um, 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.039
And it's collaborative because it has to be.
00:03:15.039 --> 00:03:34.719
I, 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.120
Um, 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.520
So I think it's it was a culmination of all of these things.
00:04:01.520 --> 00:04:06.639
When when I first founded SOLO, we've always been a consumer reporting agency since day one.
00:04:06.639 --> 00:04:12.639
We chose to be a regulated um company versus just you know technical software.
00:04:12.639 --> 00:04:18.000
We started in the customer data collection space before we ever launched the network.
00:04:18.000 --> 00:04:29.519
And 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.240
And about a year and a half in, I started to see persistent identities across our customer base.
00:04:36.240 --> 00:04:52.879
Of, 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.759
And 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.279
I 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.120
You know, the tech is the easiest part of all of this when it comes to customer data.
00:05:25.120 --> 00:05:29.199
But um, yeah, I'm excited to dig more into it with you.
00:05:29.519 --> 00:05:30.399
That's fascinating.
00:05:30.399 --> 00:05:35.600
I 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.199
And 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.399
Why, why take the the regulated the regulated route?
00:05:54.959 --> 00:06:22.399
Being 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.519
And the rest are kind of just score.
00:06:25.519 --> 00:06:37.199
It'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.399
And that problem really frustrated me for many reasons.
00:06:40.399 --> 00:07:03.439
But 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.680
I think we moved so fast on model building and so fast on alternative data models and decisioning.
00:07:09.680 --> 00:07:25.360
And 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.000
So, 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.879
So 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.680
And so the lack of regulated data companies in the space, there's a massive need for it.
00:07:53.680 --> 00:08:07.120
And 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.720
Yeah, 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.319
Sounds intuitive.
00:08:18.319 --> 00:08:24.480
And when we just when we talked before coming on now, not entirely a brand new idea.
00:08:24.480 --> 00:08:28.560
Um, there have been previous sort of attempts in this space.
00:08:28.560 --> 00:08:42.559
I'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.159
That's a really good question.
00:08:44.159 --> 00:08:53.759
And 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.000
I think the challenge in the past has been really three, three core challenges.
00:09:00.000 --> 00:09:03.039
The first one being incentives and economic incentives.
00:09:03.039 --> 00:09:15.600
Open 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.639
And so you run into that a lot with any uh data sharing and verification models.
00:09:20.639 --> 00:09:40.320
I 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.159
Customer data portability is something that is alive and well and happening.
00:09:44.159 --> 00:09:53.279
And 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.000
Our 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.360
So that has been really important in getting us off the ground.
00:10:05.360 --> 00:10:10.720
The 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.519
You 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.600
And 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.720
Um, 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.039
And then the third piece has been around the governance and lack of regulatory clarity around it.
00:10:43.039 --> 00:10:48.480
It'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.159
I think previous attempts have looked more like wallets or closed loop environments.
00:10:54.159 --> 00:11:00.399
So 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.679
Um, 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.080
Uh, 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.720
Or 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.799
It'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.000
Yeah, a lot of a lot of different directions taken.
00:11:46.000 --> 00:11:48.720
And you mentioned the regulatory updates.
00:11:48.720 --> 00:11:54.559
Uh, 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.360
Can 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.000
Yeah, so on September 8th, FinCEN issued FAQs on verifiable digital credentials under SIP policies.
00:12:14.000 --> 00:12:28.720
So 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.120
The only entrenched model on reusable identity in banking, at least in regulated environments, was SIP reliance.
00:12:37.120 --> 00:12:44.720
You 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.399
So 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.600
They can actually just take what this other bank has provided.
00:12:59.600 --> 00:13:13.200
And 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.960
The 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.960
You 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.919
How do you prove it?
00:13:37.919 --> 00:13:39.200
You're taking people's word.
00:13:39.200 --> 00:13:49.200
And 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.799
Um, 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.559
How do you how do you know as sort of the the network operator?
00:14:02.559 --> 00:14:14.799
Maybe 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.559
Before anything ever enters the network, um, there's two questions that SOLO solves for.
00:14:22.559 --> 00:14:27.120
One, how did you verify whatever you verified, right?
00:14:27.120 --> 00:14:35.919
So 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.679
So you might have a bank that is very strict on the type of documentation that they require.
00:14:41.679 --> 00:14:49.200
It 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.519
It might be that they only will take government-issued ID.
00:14:53.519 --> 00:15:00.639
Some other programs, maybe that are lower risk, uh, might be fine with just your SSN.
00:15:00.639 --> 00:15:03.519
And that could be the extent of what they do.
00:15:03.519 --> 00:15:14.159
So 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.919
And 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.600
The second question is did you do what you said you did?
00:15:25.600 --> 00:15:25.919
Right.
00:15:25.919 --> 00:15:50.960
So 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.519
That's a very different uh credential.
00:15:53.519 --> 00:16:10.320
And 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.320
It varies on risk appetites, it varies on use case, it varies on so many different things.
00:16:16.320 --> 00:16:34.080
And 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.240
In 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.679
Um, and that's one of the main blockers why everyone repeats verifications from strap from scratch.
00:16:49.679 --> 00:16:55.279
Banks will repeat verifications from scratch because they don't know if you were verified by another party.
00:16:55.279 --> 00:17:01.919
They don't know if their verification would satisfy um, you know, this context.
00:17:01.919 --> 00:17:06.799
And and it's very hard for banks to trust each other, is what we've learned.
00:17:07.119 --> 00:17:16.480
You 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.160
SOLO isn't, you know, like another KYC vendor, it's almost more like a clearinghouse.
00:17:22.160 --> 00:17:27.839
And you mentioned Visa being one of the the more appropriate comps.
00:17:27.839 --> 00:17:28.960
How does that work?
00:17:28.960 --> 00:17:33.119
How does this how does this line up to sort of how how Visa is operating?
00:17:33.119 --> 00:17:35.759
Uh SOLO in your space, visa in theirs.
00:17:35.759 --> 00:17:37.279
How does that analogy work?
00:17:37.599 --> 00:17:57.039
Yeah, 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.920
And then you have the acceptance layer, right?
00:17:59.920 --> 00:18:07.119
And to be able to accept uh, you know, a credential SOLO manages the policy matching.
00:18:07.119 --> 00:18:13.200
So 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.000
We'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.759
We 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.640
And if it's a match, we are managing the governance, the liability, the economics around that sharing.
00:18:41.839 --> 00:18:46.240
And let's let's kind of put a slightly more concrete lens onto what you're building.
00:18:46.240 --> 00:18:50.319
Because I know you just wrapped up an exciting pilot that involved the Treasury Department.
00:18:50.319 --> 00:18:56.480
Um, 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.359
What question were you trying to answer with it?
00:18:59.359 --> 00:19:03.440
Uh, and why did banks want the regulators observing it?
00:19:03.680 --> 00:19:22.000
The 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.440
Um, the short answer is that the regulation exists for this.
00:19:27.440 --> 00:19:30.559
It's under the Patriot Act in 2003.
00:19:30.559 --> 00:19:39.759
Um, 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.359
Historically, 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.440
With 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.839
And with sponsor banking, you've seen the best and the worst of that, right?
00:20:09.839 --> 00:20:12.720
Sponsor banks for them, this is business as usual.
00:20:12.720 --> 00:20:19.359
They service customers every day that they did not meet by relying on the work of fintech programs.
00:20:19.359 --> 00:20:22.079
And, you know, we've seen consent orders come out of that.
00:20:22.079 --> 00:20:26.400
We've seen um, you know, great programs come out of that as well.
00:20:26.400 --> 00:20:47.359
But 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.200
Um, 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.240
We took a very conservative approach to reusable identity through SIP reliance.
00:21:00.240 --> 00:21:02.960
It was only with BSA-regulated banks.
00:21:02.960 --> 00:21:11.920
Um, 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.119
No one changed their policies whatsoever.
00:21:15.119 --> 00:21:31.200
The 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.319
And 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.720
The 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.680
And to do that, you really need to answer the first.
00:21:59.680 --> 00:22:01.759
Question, you know, what is the policy?
00:22:01.759 --> 00:22:02.880
How was this verified?
00:22:02.880 --> 00:22:14.319
And 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.960
So it was a very informative uh pilot.
00:22:16.960 --> 00:22:21.440
Our capstone is by the time this is released, our capstone will be public.
00:22:21.440 --> 00:22:26.079
And so if anyone's curious about the findings, you can find it on our website.
00:22:26.480 --> 00:22:26.960
Awesome.
00:22:26.960 --> 00:22:27.920
I can't wait to read those.
00:22:27.920 --> 00:22:32.400
And 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.680
And then I'm thinking on the back end, that's got to be so complicated.
00:22:35.680 --> 00:22:51.279
What'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.839
And you're like, hey, come have a seat at the table.
00:22:53.839 --> 00:22:56.319
We want you guys to be a part of this.
00:22:56.319 --> 00:23:06.160
Um, 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.880
Is it is it a tech sort of challenge?
00:23:08.880 --> 00:23:11.440
Is it an adoption challenge?
00:23:11.440 --> 00:23:22.079
Um, 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.359
Yeah, it's two things.
00:23:23.359 --> 00:23:29.839
People 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.079
Everyone wants uh lower friction for the customer.
00:23:34.079 --> 00:23:36.240
That there's never been a question on that.
00:23:36.240 --> 00:23:42.960
It's just about how comfortable am I replacing my own diligence with the diligence of someone else.
00:23:42.960 --> 00:23:53.519
And 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.480
Regulation is definitely not a bottleneck, especially not now.
00:23:56.480 --> 00:24:00.480
It might have been, you know, 10 years ago, but it's definitely not the bottleneck now.
00:24:00.480 --> 00:24:09.200
Uh, 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.880
Um, 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.799
Um, 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.559
And it's also gonna come down to everyone um, you know, uh being incentivized to issue credentials.
00:24:48.559 --> 00:25:03.200
You 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.960
And 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.839
You 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.319
Uh, 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.079
Why would you then potentially help that customer on board at another company, potentially a competitor?
00:25:36.079 --> 00:25:40.079
I think this was probably a similar question plaid got asked back in the day.
00:25:40.079 --> 00:25:46.960
Um, 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.480
I mean, luckily, I can now point to plaid, you know.
00:25:50.480 --> 00:25:54.319
I I don't think plaid had that luxury when when they started.
00:25:54.319 --> 00:25:55.359
So thank you, plaid.
00:25:55.359 --> 00:26:01.519
Um, I my easy answer uh to that is usually look around you, it's already happening.
00:26:01.519 --> 00:26:06.799
You can capture the economics or a data middleman can, but it's already happening.
00:26:06.799 --> 00:26:08.559
There's an inevitability there.
00:26:08.559 --> 00:26:15.200
Two, when you actually look at the behavior of banks um in the past historically.
00:26:15.200 --> 00:26:21.920
Banks have not been averse to data sharing, verification sharing.
00:26:21.920 --> 00:26:23.599
It's called reliance.
00:26:23.599 --> 00:26:26.880
They they do it when the economics make sense, right?
00:26:26.880 --> 00:26:32.400
So uh, you know, a bank will originate mortgages and then go sell that portfolio to another bank.
00:26:32.400 --> 00:26:37.680
It'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.720
Do you want to buy some?
00:26:38.720 --> 00:26:45.519
So I think ultimately as well, uh figuring out economics that make everyone comfortable.
00:26:45.519 --> 00:26:55.440
And, 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.720
And 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.279
The moment has arrived, it's too late.
00:27:07.279 --> 00:27:08.720
Cats out of the bag.
00:27:08.720 --> 00:27:11.359
Thank you, you know, data vendors.
00:27:11.359 --> 00:27:19.920
Um, 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.200
Um, 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.440
And 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.079
But for now it's worked out just on the basis of economic incentives.
00:27:44.480 --> 00:27:52.079
Yeah, 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.640
We just talked about the comfort on the platform level.
00:27:54.640 --> 00:28:06.960
Let'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.839
Um, and also the second step of that, wanting to control their data footprint in their digital presence.
00:28:13.839 --> 00:28:31.680
So 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.400
Yeah.
00:28:32.400 --> 00:28:41.599
I 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.000
Um, you know, uh we monitor cases every day.
00:28:46.000 --> 00:28:57.440
Um, 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.319
And 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.160
It 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.039
Um, and so's model has always been consumer permissioned first.
00:29:27.039 --> 00:29:39.440
Um, 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.519
Where 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.160
And so being able to go to a consumer reporting agency and say, hey, what does everyone have?
00:30:08.160 --> 00:30:18.000
One, 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.960
It's so important and so central to everything that we do.
00:30:22.960 --> 00:30:31.279
And 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.960
It 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.799
And 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.079
And uh we have processes around correcting um, you know, information that maybe is outdated or incomplete.
00:31:04.079 --> 00:31:18.079
Um, 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.640
Yeah, 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.160
I want to turn to AI.
00:31:26.160 --> 00:31:41.680
We 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.839
So 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.359
Um, what does that mean for the identity problem you're solving for?
00:32:01.359 --> 00:32:13.440
And 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.680
Yeah, I would, I definitely think so.
00:32:15.680 --> 00:32:19.039
Personally, I don't know how much of a market it is just yet.
00:32:19.039 --> 00:32:27.039
In 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.400
But 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.240
And that needs to be done um, you know, throughout the lifecycle of a customer.
00:32:52.240 --> 00:33:05.039
We 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.680
Um, and so agency cannot be point of in time when it comes to agentic commerce.
00:33:11.680 --> 00:33:20.640
It 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.240
It's definitely an accelerant.
00:33:22.240 --> 00:33:25.119
I'm, you know, I hope the market moves uh fast.
00:33:25.119 --> 00:33:30.640
I think there's a lot to figure out with liability, economics, revocation, um, and governance.
00:33:30.640 --> 00:33:39.279
But 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.880
Uh, 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.079
They got the governance right, they have a chargeback layer.
00:33:58.079 --> 00:34:04.160
Um, the consumer feels safe knowing that they can dispute and correct things.
00:34:04.160 --> 00:34:15.039
And 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.960
Yeah, and I think I think you're right.
00:34:16.960 --> 00:34:32.159
It 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.119
And 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.800
So 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.000
I want to turn to kind of looking ahead for SOLO.
00:34:56.000 --> 00:35:02.559
We we've talked about sort of the origins and more contemporary, you know, the Treasury Department pilots.
00:35:02.559 --> 00:35:11.360
Um historically, focus was heavily on banks, now opening the network to non-bank issuers.
00:35:11.360 --> 00:35:17.760
Tell 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.920
Um, I mean, candidly speaking, we've always wanted to and we've always had demand for it.
00:35:23.920 --> 00:35:31.519
And 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.199
The lack of regulatory guidance around it was uh one of the reasons we slowed down on it.
00:35:37.199 --> 00:35:49.039
But 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.960
I 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.719
I 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.960
Uh, it's a consumer permissioned graph.
00:36:28.960 --> 00:36:34.639
Um, 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.880
So 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.880
Yeah, 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.960
And 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.760
You know, clear gets me on an international flight.
00:37:07.760 --> 00:37:10.880
Clear also provides me access to an office building.
00:37:10.880 --> 00:37:21.519
And 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.239
I 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.199
So it sounds like there's a lot of exciting things ahead.
00:37:31.199 --> 00:37:35.679
Um for people listening in, I only have you for a couple more minutes.
00:37:35.679 --> 00:37:43.599
Um, 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.039
Um, 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.239
I 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.960
I can issue a cryptographic credential saying I'm the princess of the world, right?
00:38:20.960 --> 00:38:31.119
I 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.679
You 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.559
Uh, my bet personally is that every bank is going to be a sponsor bank to some degree.
00:38:42.559 --> 00:38:46.400
Um, and and banking will look much more modular than it does now.
00:38:46.400 --> 00:38:49.280
I think it banking won't be like a destination.
00:38:49.280 --> 00:38:54.880
I 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.400
But 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.119
Um, so you know, my my word of the year is uh assurance.
00:39:14.480 --> 00:39:15.199
Love it.
00:39:15.199 --> 00:39:19.360
Um and yeah, really fascinating what you're building in reusable identity.
00:39:19.360 --> 00:39:27.119
I 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.360
Where 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.639
Our website is SOLO.
00:39:34.639 --> 00:39:40.079
So we're at SOLOapi.
00:39:40.079 --> 00:39:44.079
If you put that in the URL, you should find us.
00:39:44.079 --> 00:39:45.920
We're pretty active on both.
00:39:46.239 --> 00:39:48.079
All right, we'll make sure to tag those.
00:39:48.079 --> 00:39:51.199
Georgina Merholm, founder and CEO of SOLO.
00:39:51.199 --> 00:39:52.800
Thank you so much for joining us.
00:39:52.800 --> 00:39:56.159
You'll have to drop by when you have some more updates to share with us.
00:39:56.480 --> 00:39:57.519
I definitely will.
00:39:57.519 --> 00:39:58.559
Thank you.