You Have a Gold Star. Can I Rely on Your Work?

Alex Johnson wrote this week about a new proposed fintech standard-setting organization, and contrasted it with what we've been building at SOLO, the reliance network we operate across 11 sponsor banks and 240 fintech programs. Several people have asked me what I think about the proposal and how it relates to SOLO.

The FDIC is working with the major banking and fintech trade associations to stand up an independent standard-setting organization, an SSO, that would define baseline risk management standards for fintechs and other third parties that partner with banks, and certify individual firms against those standards through independent assessors.

The FDIC is expected to provide seed funding. Participation would be voluntary. Certification may provide a valuable signal, but it would carry no safe harbor. Banks would remain fully responsible for safety, soundness, and oversight of their third-party relationships.

The basic pitch is intuitive: create a shared set of standards, certify the companies that meet them, and make partnerships easier. A bank sees the stamp, trusts the program, moves faster.

That sounds reasonable. It is also the wrong model for the problem that actually needs solving, and I say that as someone who has spent the past year in the rooms where this is being worked out.

My team and I have been on the recent AFC calls and following the effort closely because our banks and partners keep asking us where we land. What struck me is that the sharpest skepticism is not coming from people who dislike standards. On one of those calls, a banker, someone who would actually be relying on these certifications, stopped to ask the obvious question: why are we trying to standardize whether a fintech is "good" or "bad"?

A verdict on whether a company is trustworthy is not something one institution can hand another and expect to hold up to the scrutiny of a regulatory exam.

This model, while potentially helpful in some aspects, does not get to the root of what bank and fintech partnerships need: real reliance on one another.

Gold Stars Don't End Resets. Evidence Does.

A list of "good" partners may appear to make trusted collaboration easier. It fails to acknowledge why trust hasn't historically been shared in the first place.

A seal of approval, which is what the SSO proposes, is a judgment. Reliance is an operation.

In the real world, failure does not usually come from obviously bad companies doing obviously bad things. The damage comes from one or two missing steps inside otherwise credible programs.

Think about the failures this industry has actually lived through. The programs at the center of them were sophisticated. Well-funded. Well-branded. Backed by name investors and partnered with real banks. Every one of them would likely have made a reasonable trusted list. Some of them have actually helped write the standards. The stamp would have been on the wall right up until the moment the loss hit the balance sheet.

The opposite is also true. Firm-level certification is binary and programs are not. A flaw in one part of a program does not mean every piece of underlying work that the firm performs is worthless. Some evidence may still be reliable. Some verification steps may still be valid. A whitelist can only add or remove the whole company. Evidence lets you keep what holds and resolve what does not.

So "is this a good fintech?" is almost always the wrong abstraction. Good enough for what? Under whose policy? For which product? For which customer? At what point in time?

A bank may use an approved mark to screen potential partners for initial conversations, which can be genuinely valuable for resource planning. But it would not deliver a case-by-case record of what judgments that partner made, how, and through which methods. And the bank would still be liable for every single customer, certification or not.

To be fair to the effort: I understand what the SSO is trying to do. If most banks' baseline requirements overlap, standardizing that overlap could get everyone eighty percent of the way there. That is a rational goal. The problem is the level at which it is being bundled. A fintech is not uniformly good or bad. It might have excellent CIP, mediocre transaction monitoring, and a complaints process held together with tape. Requirements attach at the operational level, to BSA, to CIP, to identity, to the actual work, and a firm-level certificate averages all of it into one pass or fail. You know the company passed. You do not know which of your requirements that covers.

There is a precise analogy for what a certificate can and cannot do: it is SOC 2 for fintechs. A SOC 2 report tells you controls existed and operated during the audit period. It does not tell you whether a specific record was handled correctly, which is why banks receiving SOC 2 reports still pull samples. Certification is a design-effectiveness claim, refreshed maybe once a year. Reliance is a transaction-level claim: was this customer verified, when, how, under what policy. Those live at different altitudes, and no amount of strengthening the certificate closes the gap.

So the SSO and SOLO are solving different layers. The SSO addresses partnership formation: can I onboard this fintech without nine months of vendor diligence? That is a real cost, and the certificate may genuinely reduce it. Transaction-level reliance is a different question: can I rely on this specific completed verification for this specific customer? A firm-level judgment has no customer-level content. The certificate may lower the cost of starting a relationship. It cannot lower the cost of serving a customer. And the resets happen at the second layer.

This is why banks and fintechs perform the same work over and over. A customer proves who they are to one institution, then proves it again to another, even when the first institution is known to be trustworthy. A business submits the same ownership documents to five banks. Every bank diligences the same technology providers. Every institution independently collects, verifies, and evaluates information that someone else verified yesterday.

The system works because everyone repeats the work.

That is incredibly expensive. More importantly, it does not survive where financial services is headed.

We are moving away from a world in which every financial relationship begins with a customer opening an interface, choosing an institution, and filling out an application. Increasingly, the interface will be an agent or a conversation. You'll say: I want to buy this house. Move my company somewhere that will pay more on our deposits. Find me the best working-capital facility. The infrastructure underneath that interaction will have to determine which institutions can serve you and what those institutions need to know, potentially before you have ever interacted with them.

One day, a bank will need to serve a customer it has never met, based partly on work performed somewhere else.

That future requires reliance.

Reliance is not a strange concept in banking. Sponsor banking already depends on different parties performing work that other parties rely upon.

So the question is not whether reliance will exist. The question is: what exactly should we be able to rely on? A seal of approval, or the evidence underneath?

The question our pilot was built to answer.

When the SOLO network designed the reliance pilot, we wrote the problem down in one sentence:

How do you serve a customer you have never met by relying on work you did not do?

That is the question. Not "which fintechs are good." Not "who belongs on the list." How does an institution take work performed somewhere else, by someone else, under someone else's policy, and get comfortable enough to put its own charter behind a decision? It is the question our banks and partners have been asking us directly for the past year.

Sit with it for a minute and you realize a gold star cannot answer it. A trusted list tells you that someone, at some point, judged a company acceptable, against a standard that is not your own. It tells you nothing about the specific work in front of you. What was actually performed? When? What evidence supports it? Was it done under a policy that satisfies my requirements? Would that evidence hold up when my examiner asks for it?

A gold star answers: who is this counterparty?

It does not answer: what was done, and does it satisfy my policy?

We have seen what happens to stamps of approval that get separated from the work underneath them. LEED plaques hang in lobbies of buildings that perform no better than their neighbors. "Certified organic" covers wildly different farming practices. Once a stamp becomes the product, the incentive is to earn the stamp, not to do the work.

Financial services should understand this better than any industry, because we have already lived the most expensive version of it. In the mid-2000s, the major ratings agencies made one single, standardized judgement — the FICO Score — the primary determining factor in their mortgage-backed security grade assignments. Two loan tranches could have had wildly different profiles on the basis of loan-to-value ratio, negative amortization allowance, or income sourcing, but still wind up with the same letter grade because their median FICOs were comparable. Banks that bought those securities by just looking at the letter grade and not peering into the underlying loan quality looked fine...until they weren’t.

The ensuing credit crunch was a failure of assuming trust on a flawed judgment instead of the actual evidence.The rating was the gold standard right up until the collateral it stood for collapsed.

Thankfully the public and private sectors have learned from their mistakes. Ratings agencies have reduced their dependency on a single standard that, while valuable, is not treated as eligible for full reliance. We now have an ever growing supply of alternative data and cashflow-based underwriting tools that can supplement legacy credit scores. It’s also become common for lenders to tailor their underwriting criteria to each specific product rather than adopt an overly standardized, one-size-fits-all approach that can lead to too many high-risk loans and not enough low-risk ones.

When it comes to gold star standards, they have yet to prove they can answer the question: can I serve this customer I’ve never met by relying on work someone else did first?

Two compliant programs, two different standards.

A universal trust judgment can and will break, even when everyone does everything right.

Imagine a household-name fintech operating a credit card program. The bank supporting that program has a customer verification policy appropriate for that product, that customer population, that risk appetite, and that regulatory context. Assume the program follows the policy perfectly.

Now another bank wants to rely on that customer's existing verification to originate a term loan.

Should the second bank be able to say: the first program is known and certified as trusted, therefore we'll accept its work?

No.

Not because the first program did anything wrong. Because its policy was not written for the second bank's context. The term lender may require different documents. Different verification methods. Different recency. Different evidence. Different controls.

Both institutions can be operating perfectly. Their requirements can still be different.

Trusting the source does not make the work fit for a different purpose.

SOLO didn't invent this framework. Examiners did.

The easiest way to understand why certification falls short is to look at how examinations already work.

Examiners do not hold every institution to one universal standard. They examine you against your own policy, your own risk profile, your own product set, your own customer population. Two institutions can both be compliant and still operate under genuinely different standards. That is supervision by design.

And when there is a problem and an examiner is sitting across the table, the question is never "was this party certified?" The question is always the same. What did your policy require? What did you actually do? Show me the evidence.

Nobody has ever survived an exam by pointing at someone else's reputation. "They were on the trusted list" does not close a finding. Documented, evidenced, attributable work does.

That is the difference between writing up general best-practice guidelines and having actually lived inside examinations.

This is not theory for us. We work with banks that are preparing for examination, and we see the consequences of one bad onboarding decision across an entire portfolio. We have audited and graded actual workflows against CIP policies, seen the delta firsthand, and in some cases have not been able to publish reliance certificates because of it. Nothing in that work suggests a regulator will ever accept a gold star in place of oversight. The proposed SSO’s own term sheet says as much: there is no safe harbor, and banks remain fully responsible. Read that carefully. The certification body tells you up front that the certification will not protect you.

So SOLO was not designed from a whiteboard theory of what reliance should look like. It was designed from what the examination process already demands. We built the network to answer the questions examiners actually ask, because those are exactly the questions a receiving institution has to answer when it relies on someone else's work.

We atomized the problem to solve it.

There were at least three possible approaches. We could decide certain institutions were trusted and make their work reusable. We could write one universal standard and require everyone to meet it. Or we could go one level deeper and make the underlying work and evidence reusable.

We chose the third.

Instead of transferring a blanket judgment about the source, SOLO breaks the work underneath that judgment into its components. What did the originating institution's policy require? What was actually performed? What evidence demonstrates that it happened? When was it performed? And then, separately: what does the institution trying to rely on that work require?

Suppose Bank A requires A + B + C. Bank B requires A + B + C + D.

Bank A may have done everything perfectly. That is useful. Do not throw the work away. Reuse A, B, and C.

But do not pretend that because Bank A is trusted, D suddenly exists. Resolve D.

That is the difference between transferring a judgment and transferring work.

Notice that even a bank that takes the certificate seriously ends up doing this anyway. To rely on a certification operationally, the bank has to break the SSO's standards into requirements, map them to its own policy, and identify the deltas. That mapping is the work. The certificate assumes it away. We built the thing that does it.

It is also why SOLO does not require institutions to standardize how they perform verification. We standardize how completed verification is represented, evidenced, audited, and independently evaluated. The receiving institution remains responsible for determining whether that work satisfies its own compliance and risk requirements.

Put simply: a seal of approval says to rely on trusted parties. SOLO says to rely on evidence of completed work. We tell you exactly what was done, under whose policy, and what evidence proves it. You decide whether that satisfies your requirements. Nobody has to operate the same way.

The regulators already named the standard. It wasn't a new SSO.

Before anyone mistakes this for an argument against standards, understand: we run a reliance network. Nobody would benefit more from everyone agreeing to work the same way than we would. When we launched the SOLO network, plenty of people, including the CFES leadership, told us this would be impossible without standards as a prerequisite, that ending repeat verification was a fantasy until every bank and fintech ran the same process.

But when we started working with regulators and asked what completed verification work should be graded against, nobody named a new industry body. Nobody said wait for a consortium to draft something. The answer was NIST.

The standards already exist. NIST IAL2 for digital identity and CIP. FDX for open banking data. Metro2 for liabilities. These are not term sheets or working groups. They are mature, publicly maintained standards that industry groups and examiners recognize and institutions already build against. Every piece of work in the SOLO network is graded against them today.

So the gap in financial services was never a missing standard. The gap was infrastructure: nothing existed that let one institution evaluate another institution's completed work against those standards and against its own policy.

That is what we built instead of waiting for uniformity. Banks and fintechs have different regulators, different examiners, different risk tolerances, different operating models, different policies. If interoperability required uniformity, the 11 sponsor banks and 240 fintech programs in our network would have had to redesign their verification workflows before a single customer could benefit. That prices in a decade. The resets are happening now.

So SOLO determines compatibility instead of requiring uniformity. Internally we call it organ donor matching. We compare the verification steps completed at one institution against the receiving institution's own policy, graded against the standards that already exist. If the work satisfies the requirements, the bank relies on it without changing its workflow or lowering its bar. Different processes. Compatible requirements. No reset for the customer.

We did not need a new standards body for any of this. We needed NIST, which was already there, and infrastructure, which we built.

Remember what this is all for.

It is easy to get lost in the architecture debate and forget the point.

The point is more collaboration. Right now, collaboration between institutions is expensive because every relationship starts from zero. Every partnership begins with months of diligence someone else already performed. Every new product means re-verifying customers who have been verified a dozen times. The cost of starting over is a tax on every partnership, every product, and every customer relationship in this industry. Reliance is how we stop paying it.

The point is fewer restarts. For institutions and for people. A small business should not have to reconstruct its ownership structure for the fifth bank this year. A consumer should not have to prove their identity from scratch because they wanted a better savings rate. A community bank should not need a nine-month diligence process to work with a fintech that eleven other banks have already examined top to bottom. Every restart is work the system already did, thrown away.

And the point is preparing for what is coming. The internet trained us to visit websites. Mobile trained us to download apps. AI is training us to simply state what we want.

A customer just has to say it: I want to buy this property. Move my business deposits somewhere that pays more on them. Find my daughter her first credit card. And underneath those sentences, infrastructure goes to work. It determines which institutions can serve you. It presents each one with what is already established: here is what we know, here is who established it, here is the evidence, here is when, here is the policy under which the work was performed. Each institution answers with what it requires. The system determines what transfers and what remains to be done. What remains gets done once, and then it too becomes portable.

The bank on the other end may have never met you. It does not need to have met you. It needs to be able to evaluate the work, evidence in hand, against its own requirements, exactly as it would in an examination.

In that world, a consumer is not forty fields on an application. A business is not a folder of PDFs submitted for the fifth time. A financial relationship does not begin with reconstruction. It begins with recognition.

Context remains local. Evidence becomes portable.

That is the architecture reliance requires. We are making decisions today about the trust infrastructure financial services may operate on for decades. The goal should not be a better list of who the industry has decided is trustworthy. It should be to make the underlying work sufficiently transparent, structured, attributable, and portable that trust does not have to be inherited at all.

Don't standardize the judgment. Standardize the evidence. Make the work portable. Preserve the context. Let each institution make its own decision.

The future is not: assess once, trust everywhere.

It is: complete the step once. Verify it was done the way they said it was done. Reuse it wherever it meets your requirements.

This is not a thought experiment.

There is no shortage of people who can produce standards documents, checklists, and certification frameworks. Those may be useful as signals. They may even help narrow who you want to consider as a partner. But they do not solve the hard problem.

That is not a whiteboard exercise. It is not a branding exercise. It is not a thought experiment.

It is a do experiment.

And if you read all of this and thought, "Oh my God, this sounds impossibly hard to operationalize," welcome to SOLO. That is exactly what we built. Taking different policies, breaking them down into their underlying requirements, understanding what work was actually performed and what evidence supports it, and then evaluating that work against the requirements of a completely different institution, without forcing either institution to change how it operates. Reliance is easy to describe. Making reliance actually work is incredibly hard. That's the infrastructure we built SOLO to provide.

One last thing, for the people building the SSO: we are big fans of standards. We grade against them every day. And if the industry one day agrees to work the same way, that agreement will still need to be operationalized. Someone will still have to break the standard into requirements, verify the work was performed, and move the evidence between institutions. A standard without that infrastructure is a document. So consider this a hand raised. Consensus may take years. Whenever it arrives, we are here, and the reliance network will already be running.