Sep 9, 2026
© SOLO FINANCE INC. 2026
Solutions
© SOLO FINANCE INC. 2026
Today’s version of KYC stores and moving documents. A SOLO KYC credential moves a conclusion instead, allowing for full reliance on the work that was done without the need for exposing customer identities.
Learn more about
Fintech and banks have experienced three large scale identity failures in the past four weeks alone.
Revolut confirmed that it released customer KYC files — passport and license copies, verification selfies, addresses, dates of birth, transaction histories — to a fraudster emailing from a legitimate government agency's mail domain. Jack Henry, whose core systems run more than 1,600 banks and credit unions, disclosed that attackers reached personally identifiable information belonging to customers of fewer than ten of its client institutions, and declined to pay the extortion demand. And a dark web marketplace began advertising searchable scans of more than 153 million US and Canadian driver's licenses, prompting an FBI investigation; reporting traced the likely source to IDScan.net, an identity verification vendor whose own marketing tells bank clients it saves an image of every ID it scans.
These three companies were each subject to a different attack path. They were all made vulnerable by one shared industry practice around stored and reusable KYC: proving a customer was verified means producing the physical documents and data that verified them.
As demand grows for reusable and shared KYC, present day practices, such as those exploited in the examples above, put customers and the institutions performing KYC in a vulnerable position.
This article is about the alternative: KYC credentials issued through the SOLO network. Credentials are a reliance artifacts that let a fintech or bank fast pass a customer who has already been verified, without needing to store or gain access to any identity documents themselves to do so.
Every KYC vendor in the market sells reuse. Almost all of them implement it the same way. The sequence:
When that chain runs across five platforms the consumer's passport exists in five places. Each hop adds a storage location, an access-control surface, a set of employees who can be socially engineered, and an independent breach-notification obligation. The industry calls this reducing friction. This may be true for the front-facing customer application, however it is structurally still replication that makes security liability and risks compound.
The replicated material is also permanent. A compromised password is invalidated the moment it's disclosed. A passport number, a date of birth, a home address, and a verification selfie cannot be rotated. Their value to an attacker doesn't decay — it compounds, as each new breach lets more records be correlated against the last. Within days of the Revolut notification, parties claiming to hold the files were posting ID copies and selfies publicly and issuing ransom demands.
Data breaches aside, document storage and transfer as part of standard KYC is poor product architecture on its own terms, for two reasons.
The relying party inherits evidence and still has to derive a conclusion. Platform B receives a passport image and someone else's score. It does not receive a decision it can act on, so it re-runs its own checks against the file it just accepted. It has taken on the storage, the liability, and the notification obligation without removing the work around verification.
None of the verification work in each transfer is bound to a readable standard. There is no machine-readable statement of what policy was applied, which institution applied it, under whose written program, or whether the subject still satisfies it today. Platform B is trusting a file and a number. When an examiner asks what standard the reused verification met, there is no answer. The work is rerun.
A certificate is a signed attestation that verifications were performed to the same bar of greater than an institution’s current policy requirements, with the workflow evidence and artifacts to support those claims. KYC steps like document capture and review, biometrics capture and review, liveness checks, and address verification may all be included in a KYC certificate as a reliance record.
A fintech or bank can use a KYC certificate to ‘fast pass’ their customers at onboarding. Instead of re-performing the same KYC checks, they can rely on the work that another fintech or bank has done, when that work meets or exceeds their own policies.
KYC Certificates contain the following:
The subject. A durable identifier for the person or entity that was verified, stable across relying parties, independent of any document number.
The claim set. The attested facts, expressed as satisfied conditions rather than raw files. Not a document image but government-issued identification examined and authenticated. Where a relying party needs a specific answer — US person, sanctions-clear, entity in good standing, beneficial ownership established — it receives that answer and an audit trail of how the conclusion was made.
The policy reference. The certificate clearly names the standard it was issued against, pointing to the furnishing institution's written CIP program. Each verification artifact is audited and graded against the standard before it becomes available to another fintech or bank.
Other models of reusable KYC do not have an equivalent, and it's the one that converts a certificate from a convenience into an auditable artifact. A relying party can examine what was required, what was checked, and under which examined program — without examining the customer's documents. So can a regulator.
The provenance chain. Which institution furnished the attestation, when, and against what class of evidence. Verifiable without the raw files being present.
Validity state. Issuance time, current status, and the conditions under which the certificate is revoked.
Customer consented data. A customer may choose to share additional supporting personal information, like specific personal address, identity document number, issuing state, phone number, date of birth, etc. The customer remains in control of who receives what pieces of their information, with alerts and controls for each new party that may want access.
No images. No document numbers in transit. No selfie. The evidence stays where it was collected, with the institution that has an obligation to hold it and an examined program governing how. Documents and files only need to be shared within the context of a secure regulatory examine, eliminating the need for documents to be shared and stored with multiple providers unnecessarily.
A consumer verified at Platform A arrives at Platform B. Platform B wishes to use the KYC that was already performed to avoid running duplicate checks on the customer. The chart below compares what that workflow looks like with a document-based reusable KYC vs. the SOLO KYC certificate product.
| Document Transfer Based Reusable KYC | SOLO KYC Certificate | |
|---|---|---|
| Documents transmitted | Passport image, selfie, extracted fields | None |
| New copies created | One per relying party | Zero |
| Relying party's own checks | Re-run against the received file | Verify signature and policy match |
| Basis for the decision | A vendor score, currently not FCRA compliant unless the issuer is a consumer reporting agency (CRA). | A querier’s own standard, auditable against their policy and supported by SOLO’s obligations as a CRA. |
| Status accuracy | Frozen at collection | Current, monitored and consistently updated across a network of 240+ programs |
| If the determination changes | No mechanism | Revoked everywhere |
| Consumer's exposure after five reuses | Five copies in five jurisdictions |
Reusable identities only work if a fintech or bank if the path that produces it is sound and auditable against one’s own policy requirements. Four mechanisms do that work in the SOLO network to issue certificates that can be audited, and therefore fully relied upon.
01. Declare. The furnishing institution defines its current KYC policy — what it requires at each step — and attests to its adherence to it. Output: a stated standard.
02. Index. SOLO catalogues what verification work already exists at the furnisher through the Index Microservice, forming one unique record per customer. No raw files are exposed. Output: a map of available work to query.
03. Audit. The furnisher connects its workflows and orchestration engines to supply verification artifacts. SOLO grades every record against the declared policy — what the institution says it does, measured against what its systems show it did. Documents, raw files, and supporting evidence stay with the originating institution. Output: a graded record.
04. Issue. Where the evidence supports the declaration, a certificate is issued. Attribute checks are returned as zero-knowledge proofs: a cryptographically verified yes or no, never the value that produced it. Proving that a customer presented an unexpired, authenticated government ID does not transmit a scan of that ID — not the front, not the back, and not the infrared and ultraviolet captures that sat beside them in the Nexus listing. Steps that did not clear are never published and must be collected by the querier. Output: a policy-bound certificate.
05. Maintain. A certificate is a live object. SOLO monitors the network of 240+ programs for changes to the underlying work and pushes updates to every permitted subscriber. Where the underlying determination no longer holds, the certificate is revoked and stops verifying everywhere it was presented. Output: current status.
Revocation is the property document transfer cannot replicate at any price. A passport scan sitting in five separate storage buckets cannot be recalled, corrected, or expired. It is out there permanently, in whatever state it was in when it was copied.
Querying a certificate is how a fintech or bank asks the network what KYC verification work already exists for a customer, and whether that work clears its own bar. It runs in four steps.
01. Scope. The querier sets which product lines or programs the policy governs and assigns it to a certificate type. Output: a policy, assigned.
02. Configure. The querier defines its requirements at each step — what it does today, and the limits of what it will accept from another institution's work. A fintech might require that a document was captured and reviewed within the last 90 days, will not expire within the next 90, and was an original upload of a government-issued passport or driver's license. SOLO applies that standard as a filter on every result returned to those programs. Output: a machine-readable, querier-defined standard.
03. Query. The querier supplies a few identifying customer attributes and a lookup key. This is not a check on whether another institution knows the customer; it is a lookup for steps already verified against the standard set in 01 and 02. What returns is the data the workflow needs plus the attestations and artifacts that make it usable: which institution performed each step, how, when, and the evidence produced. Where no single institution has completed every step, SOLO assembles a composite — document capture from one member, address verification from another — provided every piece meets the querier's standard. Output: a policy matched certificate.
04. Integrate. What the workflow does next depends on what came back. The four outcomes are exhaustive:
Output: a routed workflow.
The policy remains a single point of control. Update it once and SOLO applies the change everywhere the Query API is integrated. SOLO does not make any part of the compliance decision, and it does not transfer the raw files underneath. It returns only the workflow records that satisfy the criteria the querier set — reliance without a new copy of the customer's documents.
None of the three failures this month was a security failure. Revolut's controls worked. Jack Henry's production systems were never touched. Customers were exposed because the model itself requires that documents be held and, on request, handed over.
Reusable KYC built on file transfer will keep producing that outcome regardless of how good the vault is, because every new relying party is another copy.
A certificate eliminates the need for a copy. The evidence stays with the institution obligated to hold it, and what moves between institutions is an audited conclusion.
Regulators have pointed in the same direction. In September 2026, FinCEN and the federal banking agencies confirmed that verifiable digital credentials can satisfy CIP, and that the benchmark is the institution's own written program rather than the credential itself.
Banks and fintechs can now adopt credentials with confidence — provided they accept only those that meet their policy, and can prove it. That is what a SOLO certificate is built for. Every result is matched against the querier's configured policy and audited against the furnisher's evidence before it is returned, so the only artifact an institution ever relies on is one that cleared its own standard with the record to show for it.
FinCEN’s decision comes at the end of SOLO’s reusable identity pilot, a 5 month pilot with founding network banks and fintechs resulting in concrete evidence and best practices for operationalizing bank reliance for networked KYC and more for regulated US institutions. Read full findings from the pilot at solo.one/blog, coming soon.
| Once, at origin |
