Two architectures
A traditional provider sits between external sources and the institution. Every institution that asks a question pays to rediscover the same facts. SOLO sits between institutions. The institution that does the verification creates a reusable result; the network preserves it, and other participants reuse it under permission. This is not better data aggregation. It is trust portability: the verification stops dying at the end of a single application.The one-sentence difference
The same idea, said a few ways:- Data providers help you verify a business. SOLO helps you avoid verifying the same business again.
- Providers sell information. SOLO makes verified work reusable.
- Aggregators answer “what data exists?” SOLO answers “what trust already exists?”
Side by side
Every claim above maps to a real mechanism
This is not aspirational positioning. Each contrast is backed by a feature that exists in the API today:What SOLO is not
To avoid the wrong takeaway:- Not another KYB/KYC workflow tool. SOLO does not replace your verification vendors with one more; it makes the verifications already done reusable across the network.
- Not an aggregator with permissions bolted on. The unit of value is a reusable, attributed verification, not a fresh external lookup.
- Not a black box you must trust blindly. The architecture is exposed on purpose — provenance, consent, entitlement, and policy are all visible, because visibility is what makes participants comfortable reusing each other’s work.
Where to go next
Trust assets
How a furnished verification becomes something reusable.
Provenance
Who verified what, when, and on what evidence.
High-level concepts
Networks, entities, consent, products, policies, entitlement.