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. The point 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
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 primarily a lookup service. The unit of value is a reusable, attributed verification furnished by a participant.
- Not a black box you must trust blindly. Provenance, consent, entitlement, and policy are all visible through the API, 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.