Overview

The SOLO Network is a shared data network for identity, compliance, and financial verification. Banks and other institutions furnish verified data about consumers and businesses into networks they belong to, and query that data back — under explicit, auditable rules about who can read what, and why. Instead of integrating with dozens of verification vendors one at a time, you connect to SOLO once and work with standardized products — a KYC certificate, a KYB certificate, screening lists — inside a network of participants you already trust. Every read is gated by the subject’s consent, shaped by the network’s policies, and limited to the fields you are entitled to see.

​

How the network works

Every interaction with the API is one of two operations on a product:

1. Furnish — contribute verified data about a consumer or business into a network. Other participants can then query it, subject to the network’s rules.
2. Query — read consolidated data about an entity from the network. A query requires a consent_id proving the subject agreed, and returns only the fields the network’s policy exposes and you are entitled to read.

The product catalog covers the core verification workload of a bank: KYC certificates consolidate identity-verification outcomes for consumers, KYB certificates do the same for businesses, and two screening lists — a bank-specific bad-actor list and a cross-bank financial-crimes watch list — answer targeted risk questions. Before committing to a billable query, you can run a non-billable coverage check (POST /v1/products/check) to see whether the network holds enough data about a subject to make the query worthwhile. The rules sit in the network itself: roles define what each participant can do, policies define what each product reads and writes, and entitlement defines what each participant sees. High-level concepts walks through the full model. The API itself is plain REST: JSON request and response bodies, standard HTTP status codes, and a single versioned prefix (/v1) for every public endpoint. Errors follow one consistent envelope — see Errors — so the handling code you write for your first endpoint works for all of them.

​

Where to start

Most organizations play one or more of three roles in a network. Find yours and follow its path.

​

Network governors

You operate a network: you decide which products it offers, what each product is allowed to read and write, and who participates. Start with Networks to understand the trust boundary you are administering, then define the rules of the road with querying and furnishing policies — POST /v1/networks/policies/querying and POST /v1/networks/policies/furnishing create the policy shells, and the PUT .../{policy_id}/configuration endpoints author the per-field selections. The Join a network quickstart shows the participant side of what you are governing.

​

Furnishers

You contribute data: KYC or KYB outcomes your institution has already verified. Start with the Furnishing overview to learn how contributed data is validated and stored, then run the Furnish an entity quickstart to push your first record through POST /v1/products/kyc_certificate/furnish. High-volume furnishers can ingest files through POST /v1/file-upload/ingest or automated SFTP delivery instead of per-record API calls.

​

Queriers

You consume data: you want a consolidated KYC certificate or a screening-list answer for an entity you are onboarding. Start with the Querying overview to see how a query resolves across network, policy, and consent, and read Consent — you must record consent and obtain a consent_id before any query. Then run the Query a product quickstart, which takes you from POST /v1/consent/consumer to POST /v1/products/kyc_certificate/query end to end.

​

Environments

The API is served per environment. All public endpoints sit under the /v1 prefix and require a bearer token (see Authentication). Two endpoints are available without authentication for monitoring: GET /health returns {"status": "healthy"}, and GET /version reports the supported API versions and build information. Build against sandbox first: it mirrors production behavior — including consent enforcement, policy evaluation, and the full error model — without touching live data, so your integration is exercised end to end before you switch base URLs.

​

Next steps