© SOLO FINANCE INC. 2026
Solutions
© SOLO FINANCE INC. 2026
Configuring querying policies allows you to rely on verification steps already completed at another bank when they satisfy your requirements, without changing your existing workflow or lowering your compliance standards.
Test the Query API for fintech and banking products.
The SOLO network is composed of sponsor banks 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 standards.
Banks and fintechs define their standards for acceptable work by creating a querying policy. This acts as a filter for data and verification artifacts delivered back to them from the network, which allows a querier to rely on verification steps that were already completed without changing their existing workflows or lowering standards.
This demo walks through an example of how to configure a querying policy for a KYC certificate used in 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.
Additional certificates available in the SOLO Network include Income & Employment Verification, Asset Verification, and Verified Business Financials, among others.
A fintech or bank will create a querying policy before running any queries. For fintechs joining SOLO through a sponsor bank, the policy will be pre-configured so it is in line with the sponsor’s policy requirements. If joining directly, a fintech or bank may configure their own.
To create a policy,
Policies can be configured for any certificate available in the SOLO network.
What SOLO Does
The querying policy is created to be a single point of enforcement of a policy across potentially many programs as required by the querier. Once the querier defines a scope for their policy, SOLO will automatically apply this standard for any verifications returned from the network to those products or programs to ensure their compliance.
Next, the querier will configure the individual steps of their policy. For KYC, this will be their requirements around capture and review of Identity Documents, Biometrics, Liveness Check, Address Verification, and Identity Corroboration.
By configuring these steps, the institution or fintechs is describing what it does today, and the limits of what it will accept from another institution's work.
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.
Policy steps can be automatically configured by connecting one’s orchestration platforms, decision engines, and policy workbooks. The querier will have a chance to review and edit each step before signing off on the policy.
What SOLO Does
All data furnished to SOLO must have a defined furnishing policy, with attestations from the furnisher of completion of every step and verification artifacts as auditable proof. The querying configurations enable SOLO to deliver matches from the network that meet or exceed the compliance thresholds of a bank or fintech. The level of configurability on both sides enables interoperability of verification work without forcing a single standard or vendor stack for reliance.
After configuring their policy steps, a querier would run a test query.
A query is not a check to see if a network participant knows of a customer. It is a lookup for the steps that have been verified against the standards defined by steps 1 and 2 and returns a package of both data and auditable records for full reliance on the work already done.
To prompt a query a fintech or bank would provide a few simple inputs, typically a few identifying customer attributes and a lookup key. Lookup key varies per data product, reference documentation and template pages for specific certificate requirements.
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 policy step, which steps they completed, how each was performed, when it was performed, and the evidence produced in the process.
The querier will then be able to review the API response against each step of the query to see what was returned vis a vis their requirements.
In production the query would execute wherever SOLO is integrated, most often the institution's orchestration engine.
What SOLO Does
01 Data Audit and Grading. All data and attestations furnished to SOLO pass through auditing and grading before any certificate is published and before it’s shown as a result for a querier. 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.
02 Assembles Composite Certificates In the case no single institution has completed every step in the policy, SOLO will take the qualifying pieces from different network members and combines them into a single certificate that fits the querying institution's policy and product.
One fintech may have handled document capture to the required standard; another may have handled address capture and verification. Provided all of the querier’s standards are met, those steps will be combined into a single certificate response.
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.
It is essential to note that reliance in the SOLO network does not rest on a furnisher's word.
If a full policy response is received to fulfill all of a querier’s querying policy steps, their workflow may be rerouted to immediately skip the steps for the customer on the front end application and move straight to account opening.
If data attributes but not all policy steps are returned by the query, attributes can be sent to the front end experience to pre-fill those fields of an application.
If discrete steps of a policy are fulfilled, like document capture and address verification, but not all steps, then the workflow may be rerouted to skip that step in the front end. The customer or a vendor of the querier’s choice may then be prompted to complete the other steps.
In the event no steps and no data attributes are found from the network, the querier will have the option to select their fallback choices.
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.
What SOLO Does
Ongoing, the querying policy will act as a centralized point of management for a bank or fintech’s policy. The querier may update configurations in one place, and SOLO will automatically apply that filter everywhere the QueryAPI is integrated.
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.
Querying enables:
No. The relying institution's CIP is satisfied by another institution's performance of the procedures rather than by repeating them. Nothing is waived, and the obligation doesn't move.
The precise language matters. The CIP rule permits a bank to rely on another financial institution to perform "any procedures" of the bank's CIP. What gets removed from your onboarding flow is duplicated work. What stays is your responsibility for the outcome.
Law: 31 CFR 1020.220(a)(6) SOLO: SNAP §5.1, §5.5
For CIP reliance products, always the BSA bank. A fintech program's name may appear on a certificate for transparency, but it carries no furnishing responsibility and cannot.
Where a non-bank participant submits the query, it does so on behalf of a sponsor bank. That bank is the relying institution for purposes of the CIP rule, it is the legal user of the certificate, and the query-time attestations bind it.
Law: 15 U.S.C. §1681s-2; 31 CFR 1020.220(a)(6) SOLO: SNAP §4.5, §5.2, §2.4
Different steps decay differently, so one freshness rule can't cover them. A document has an expiry date; an address goes bad silently and without notice.
Furnishers may specify shorter windows, and so may you in your querying policies. The shortest applicable window governs.
Law: 31 CFR 1020.220(a)(3); 15 U.S.C. §1681c SOLO: CRA Policy §8.8, §7.2.2
There are three conditions that must hold for cross-bank Reliance to be permissible.
First, Reliance must be reasonable under the circumstances.
Second, the institution you're relying on must be subject to an anti-money-laundering program rule and regulated by a federal functional regulator.
And third, there must be a contract, plus an annual certification from that institution that it has implemented its AML program and will perform the specified elements of your CIP.
On the SOLO Network, the second and third conditions are structural. Every BSA bank furnishing certificates certifies annually that it has a CIP complying with §1020.220, an AML program complying with §5318(h) and §1020.210, that it accepts FCRA §623 accuracy and dispute obligations for everything it furnishes, and that the work reflected in its certificates was performed under that program. The first condition is yours, and it can't be delegated.
Law: 31 CFR 1020.220(a)(6)(i)–(iii); 31 U.S.C. §5318(h); 31 CFR 1020.210 SOLO: SNAP §5.3, §5.5
A bank is not held responsible for another financial institution's failure to fulfil the bank's CIP responsibilities, provided the bank can establish that its reliance was reasonable and that it obtained the required contracts and certifications.
That protection is conditional, and the conditions are the work: reliance that was reasonable under the circumstances, and documentation showing it. This is why the querying policy configuration matters and why we won't let a certificate stand in for it.
Law: 31 CFR 1020.220(a)(6); 68 Fed. Reg. 25090, 25103 (2003) SOLO: SNAP §5.5, §5.6
No. We structure, validate, and transmit verification work, and we return only records that satisfy the criteria you set in your querying policy. The decision and the accountability stay with you.
Law: 31 CFR 1020.220(a)(6)(i) SOLO: SNAP §19, §5.5; CRA Policy §6.3
Every element traces to its originating furnisher and furnishing event. We retain records sufficient to identify the furnisher for each attribute, the values furnished, the dates of furnishing and report generation, query activity, the input method used to resolve each query, and dispute submissions and determinations.
The consumer report is retained as its own artifact, separate from the file. For each query we hold the exact record of what was delivered, to whom, on what date, and on whose behalf — not merely the underlying data as it stands today. That distinction matters when an examiner asks what you were shown at the moment you made a decision.
Law: 31 CFR 1020.220(a)(3); 15 U.S.C. §1681g SOLO: CRA Policy §7.2.3, §7.3, §3.1; SNAP §15.1, §15.4, §7
Through the API at whatever layer already holds your onboarding data, typically your KYC orchestration engine, or by secure batch file transfer if you'd rather not integrate at all. There's no requirement to change vendors or standardize your workflow.
Certain products require affirmative consumer notification and acknowledgment before a query, and consumer-provided collection involves an interface element by design.
Law: 15 U.S.C. §1681b SOLO: SNAP §8.4, §8.5; CRA Policy §6.3
