Skip to content

Replace repetitive workflows with reusable network memory.

  • Book a consultation
  • Fast Pass
  • Issue Credentials
  • Model Building
  • Query API
  • Index Microservice
  • Collect SDK
  • Furnish API
  • Documentation
  • Company
  • Blog
  • Templates
  • KYC Certificates
  • KYB Certificates
  • Confirmed Fraud Attributes List
  • Known Bad Actor List
  • Fintechs
  • Sponsor Banks
  • Banks
  • AI Builders
  • Account Opening & Onboarding
  • Fraud Prevention / BSA & AML
  • Financial Assessment
  • Terms of Service
  • Privacy Policy
  • Trust Center

Products

  • Fast Pass
  • Issue Credentials
  • Model Building

Platform

  • Query API
  • Index Microservice
  • Collect SDK
  • Furnish API
  • Documentation

Resources

  • Company
  • Blog
  • Templates

Templates

  • KYC Certificates
  • KYB Certificates
  • Confirmed Fraud Attributes List
  • Known Bad Actor List

Solutions

  • Fintechs
  • Sponsor Banks
  • Banks
  • AI Builders
  • Account Opening & Onboarding
  • Fraud Prevention / BSA & AML
  • Financial Assessment

Legal

  • Terms of Service
  • Privacy Policy
  • Trust Center

© SOLO FINANCE INC. 2026

What we do

  • Fast Pass
  • Model Building
  • Issue Credentials

Reliance Products

  • KYC Certificate
  • KYB Certificate
  • Confirmed Fraud Attribute List
  • Known Bad Actor List
View All

Platform

  • Query API
  • Index Microservice
  • Furnish API
  • Collect SDK
  • Documentation
NewsWhy 100+ community banks backed SOLO

BY INDUSTRY

  • Fintechs
  • Sponsor Banks
  • Banks
  • AI Builders

BY USE CASE

  • Identity Verification
  • Fraud Prevention / BSA & AML
  • Financial Assessment
  • Ongoing Monitoring

Case Study

The Conversion Scorecard: How SOLO Optimizes Conversion Across the Industry

Output:Pre-Filled UISteps Skipped

Explore

  • Company
  • Blog
  • Templates
  • Data P&L
Georgina M.Founder & CEO

LEARN

How SOLO works
network member examples

Explore

SOLO’s Open Banking Network

Book a consultation
  1. Blog

CIP Reliance Pilot Capstone Report

CIP reliance pilot findings

Oct 28, 2026
SOLO Reliance Pilot Capstone Report
SOLO Team
by SOLO Team

Share

Table of contents

  • Reliance already exists
  • Pilot objective
  • How SOLO addresses findings
  • Regulatory alignment
  • Existing frameworks satisfy
  • Where banks can start
  • Full Capstone

Download Capstone

Read the full findings from SOLO's CIP Reliance Pilot

Related articles.

SOLO's Graph QL
BlogSep 28, 2026

SOLO Network Releases GraphQL for Reusable Verification & Customer Permissioned Data

Scorecard for Business Banking Fintechs Ranked on Conversion
BlogSep 17, 2026

Business Banking Conversion Scorecard: Full Rankings (Updated)

diagram of how a KYC credential prevents duplicate ID document storage
BlogSep 14, 2026

KYC Credentials: Proof Without the Passport

In Q1 2026, SOLO launched a pilot with sponsor banks and their fintech partners to operationalize CIP Reliance at network scale. CIP Reliance is the provision of the 2003 Customer Identification Program Rule that lets one bank rely on identity verification another bank has already performed.

Reusable identity only works if the bank relying on it can confirm the work was actually done. Validating verification performed by someone else is the precondition for reusing it, and that is what the SOLO Network was built to do.

The pilot proved three things. The SOLO Network satisfies all three regulatory requirements for CIP Reliance as written. Its architecture closes the visibility gap that has kept reliance across the industry informal and hard to examine. And no new legislation or rulemaking is needed to run CIP Reliance at scale.

As the pilot concluded, regulators moved in the same direction.Upon the official conclusion of SOLO’s pilot in September 2026, FinCEN and the federal banking agencies issued guidance that makes the bank's own CIP standard the benchmark for accepting verification performed by someone else. That is the principle the SOLO Network was built on.

Banks already rely on others. They just can't see the work.

Formal CIP Reliance has been available since 2003, but it is rarely used, and mostly between pairs of banks. Reliance in the broader sense is everywhere. Sponsor banks rely on fintech partners to onboard customers. Lenders rely on dealers and brokers. Banks hire identity verification vendors to run parts of their CIP.

The SOLO CIP Reliance Pilot revealed that, in practice, none of these arrangements satisfy what the CIP Reliance provision intended. In each one, the bank stays fully responsible for work it did not perform. It typically holds a partner's contractual promise to follow the bank's CIP, and perhaps a periodic review, but not a record of which steps were performed for a given customer, by what method, and with what result.

The cost of that blind spot has been rising. Recent enforcement actions against sponsor banks repeatedly cited weak oversight of identity and BSA/AML controls applied to fintech partners' customers.

Formal reliance has stalled for the same reason. A bilateral reliance contract gives the relying bank a certification, not evidence, and every bank must diligence every counterparty on its own. Whether the work is done by a fintech partner or another bank, SOLO’s CIP Reliance Pilot revealed that reliance has failed where the work couldn't be seen or checked.

What the pilot tested

SOLO entered 2026 with the contractual foundation for CIP Reliance already in place: the SOLO Network Agreement for Participants (SNAP), a single multilateral agreement and participation dynamics designed to meet all three regulatory prongs. The pilot examined how banks’ partner programs perform CIP today, to identify where reliance breaks down and confirm the SOLO Network closes those gaps.

Sponsor banking was the natural proving ground. It is where the institution that bears the CIP obligation and the party that performs the verification are already separate, and where that separation is hardest for the bank to see into. SOLO compared sponsor banks' examiner-approved CIP policies with the onboarding workflows their fintech partners actually ran.

The review confirmed what recent enforcement actions suggested. Across the industry's existing partner programs, what a bank's CIP policy requires and what is executed on its behalf can diverge: a step skipped, or performed with a lower-assurance method than the policy specifies. These gaps were not policy failures. They came from how onboarding flows and vendor stacks get configured in practice, and a contract alone cannot reveal them.

This finding confirmed the core design principle of the SOLO Network. Reliance built on a counterparty's word that "CIP was completed" carries the same blind spot. Reliance that works at scale has to show the evidence, record by record. The SOLO Network was designed to address just that.

How the SOLO Network closes the gap

SOLO built its validation layer as the answer to reliance's historical failures. Every Certificate carries evidence of how the work was performed, and SOLO independently checks it, so the relying bank can reuse that verification instead of trusting a promise. The pilot's findings shaped that layer, and it is now permanent Network infrastructure.

Every KYC and KYB Certificate on the Network is broken down into its verification substeps (document capture, biometric comparison, liveness, address verification, identity corroboration), and each substep records its data source, method, and attestation basis. On top of that structure, the Network adds three layers of assurance that informal reliance lacks.

  • Independent verification of execution. SOLO confirms that the steps a furnishing bank claims to have performed were actually performed. For new onboardings, SOLO observes each substep as it runs and compares its own record field by field against what the bank attests. For older records, SOLO uses tiered validation: reviewing existing audits, re-verifying samples through its own vendors, or confirming the original evidence is still held.
  • Standardized provenance grading. Each field is classified on two objective axes: how the value was verified (self-attested to authoritative source) and what backs it (unattested to independently audited). Certificates are also mapped to NIST IAL2 so any bank can read them on a common scale. SOLO measures; only the relying bank and its examiners decide what is sufficient.
  • Accountability when work doesn't hold up. SOLO can audit furnishers on a scheduled or triggered basis, with evidence due within ten business days. SOLO indemnifies relying banks for legal losses from good-faith reliance on a Certificate, and a separate indemnity covers losses from confirmed furnisher misconduct.

On the relying side, a bank configures Querying Policies that encode its own examiner-approved CIP standard. SOLO returns a Certificate only if it meets that standard, and only from institutions the bank has chosen to enable.

Regulators have since arrived at the same principle

Since SOLO built this infrastructure and ran its pilot on operationalizing CIP reliance through it, two regulatory developments have reinforced the approach SOLO chose:

FinCEN's digital credential FAQs (September 2026). FinCEN, jointly with the staffs of the Federal Reserve, FDIC, NCUA, and OCC, issued FAQs on verifiable digital credentials under the CIP Rule. Where a non-government third party issues a credential, the bank must ensure the third party "uses the same level of authentication as the bank or credit union itself would use." In other words, the bank's own CIP standard is the benchmark. That is precisely how the SOLO Network's Querying Policies already work: the relying bank's own standard, applied to substep-level evidence, decides what it accepts. (Our breakdown of the guidance.)

The OCC and FDIC unsafe-or-unsound practices rule (August 2026). The final rule defines an unsafe or unsound practice as one contrary to prudent operating standards that, if continued, is likely to materially harm the bank. A gap between a bank's stated CIP and what is actually performed on its behalf can now fall within that definition. That raises the value of exactly what the Network provides: a continuous, record-level view of whether CIP is executed as written.

Both developments point to the same conclusion the pilot reached: reliance should be measured against the bank's own standard, using evidence of the work rather than a promise that it was done.

No new rules required

The pilot concluded that the three CIP Reliance prongs from 2003 are technology-neutral and structure-neutral. They require that reliance be reasonable, that the relied-upon institution have an AML program and a Federal functional regulator, and that a written contract with annual certification be in place. Nothing in them requires a bilateral relationship, and the pilot showed a multilateral network such as SOLO’s can meet all three.

RequirementHow the SOLO Network meets it
Reliance is reasonableEach bank's Querying Policies encode its own examiner-approved CIP standard; only matching verifications are returned
Relied-upon institution has an AML program and Federal functional regulatorOnly regulated BSA Banks can furnish for CIP Reliance; fintech work is furnished through the sponsor bank
Contract with annual certificationSNAP binds every participant; each furnisher signs an Annual Institutional Certification plus a Per-Submission Attestation by a BSA Officer with every furnishing

Banks that prefer to build reliance one counterparty at a time can do so under the same agreement, enabling institutions individually. FinCEN has carried the same three-prong structure, unchanged, into its proposed CIP rules for investment advisers and stablecoin issuers.

Where banks can start

Most banks already rely on verification performed by others. The real question is whether they can show that what their CIP requires is what actually gets done. The SOLO Network offers five layers of participation, which a bank can adopt in any order and at its own pace:

  1. Monitor its own programs. SOLO connects to a sponsor bank's fintech onboarding flows and confirms, as each onboarding happens, that every step the bank's CIP requires was performed. The bank gets a continuous record to show its examiners.
  2. Reuse verification across its own programs. A customer verified in one of the bank's programs doesn't need to be re-verified in another.
  3. Use non-CIP SOLO Products. Fraud and bad-actor lists, income and employment verification, and consented pre-fill, all governed by FCRA.
  4. Accept digital credentials. Under the September 2026 FAQs, a bank can use a SOLO-issued credential as one of its own verification methods, to the extent its CIP permits.
  5. CIP Reliance with other banks. Furnish or query KYC and KYB Certificates with the banks it has enabled, with every Certificate independently verified, graded, matched to the relying bank's own policy, and backed by SOLO's indemnification.

The end state is verification performed well once, validated, and reused thereafter. As more account opening is initiated by software agents, and as smaller banks look for ways to compete for customers verified elsewhere, that kind of reliance shifts from a convenience to a requirement.

Read the full Capstone

The full report covers the provisions behind each regulatory prong addressed by SOLO Network participation, SOLO's data verification and grading methodology, and the annual and per-submission attestation forms required to create reliance products other banks and fintechs may rely upon. Download the full capstone report below.