A query against the SOLO network enables a fintech or bank to pre-fill all the customer’s data that already exists, and fully skip the verification steps for a customer when they were previously performed by another network participant.
Test the Query API for fintech and banking products.
The SOLO network is composed of sponsor bank and fintech programs. When a consumer or a business completes a data verification step at any program in the network, and the sponsor bank attests to the work that was completed, other participants may query that customer’s record to skip the steps that were already performed — provided the completed work meets the querying institution's own policy standards.
Querying enables:
Querying runs through a headless API, integrated wherever you orchestrate onboarding.
This demo walks through an example of how querying works using the KYC certificate for an account opening workflow.
| KYC Certificate: data product that looks for work previously completed in line with each step of a querier’s KYC policy. Used to skip those steps in a new application or customer onboarding.
To prompt a KYC query a fintech or bank would provide three inputs: the customer's first name, last name, and a lookup key, typically the last four digits of their social.
SOLO returns the data already collected on that customer that the workflow needs in addition to the attestations and verification artifacts that make the data usable: which institution completed each KYC step, which steps they completed, how each was performed, when it was performed, and the evidence produced in the process.
A query is not a check to see if a network participant knows of a customer. It is a policy matched lookup that returns a package of both data and auditable records for full reliance on the work already done.
A fintech or bank will create a querying policy before running any queries. The policy acts as the filter applied to everything the network returns for a workflow.
For fintechs joining SOLO through a sponsor bank, the policy will be pre-configured so it is in line with sponsor’s CIP and KYC requirements. If joining directly, a fintech or bank may configure their own.
To create a policy,
Within the policy, each step is configured individually.The institution is describing what it does today, and the limits of what it will accept from another institution's work. Fintechs may connect their orchestration platforms, decision engines, and policy workbooks to have this preconfigured for them to review.
For example, a fintech may define that they require identity document capture and verification to be collected within the last 90 days. It must be reviewed within the last 90 days and may not expire within the next 90 days. The document itself must be an original upload of a government issued passport or a driver's license.
Once saved, the policy governs every result at each step of KYC. If a participant or group of participants in the network has performed their checks according to these configurations, that work is returned and those steps can be skipped.
In production the query executes wherever SOLO is integrated, most often the institution's orchestration engine. The defined First Name, Last Name, and Lookup Key inputs are used to query the network.
Results are filtered against the policy criteria set in steps 01 and 02.
Each attribute returned carries the attestations attached to it: which institution completed the step, which steps were completed, how each was performed, when it was performed, and the evidence produced.
Often no single institution completed every step in the policy. One fintech may have handled document capture to the required standard; another may have handled address capture and verification.
SOLO takes the qualifying pieces from those different network members and combines them into a single certificate that fits the querying institution's policy and product.
In each case, the querying institution can see exactly how that work was performed, the methods they’re relying on, and the verification artifacts compared against its own policy as an auditable certificate. In practice, the reliance letter an institution would need to produce for a BSA examiner.
The response can be fed anywhere downstream, including the customer application UI.
With the certificate in hand, the fulfilled steps are removed from a customer’s application.
For a consumer, that means no selfie check and no leaving the room to retrieve an ID. For a business owner, it means not hunting down an office lease, not locating formation documents, not finding an EIN letter, and not verifying the same beneficial owners for an additional time.
It is essential to note that reliance in the SOLO network does not rest on a furnisher's word.
All data and attestations furnished to SOLO pass through auditing and grading before any certificate is published. It is not enough for a furnisher to report that a liveness check ran: SOLO audits each workflow, observes it running against the configurations the furnisher declared, and audits the furnished data against what those policies said would happen.
Every step a policy clears is a check the institution does not pay to run a second time, and a screen the customer never has to complete — lower verification spend at the top of the funnel, fewer applications abandoned at the bottom.
