Understanding Bank Reliance Frameworks

Bank reliance is a legal principle that grants a regulated institution the ability to rely on the work of another. For example, when one federally regulated financial institution has already done the work of verifying a customer's identity through steps like identity document capture and review, biometrics capture and review, and liveness check, then a second institution should be able to skip those steps instead of repeating them for themselves.

The SOLO Network operationalizes bank reliance for compliance steps across a full customer lifecycle, extending the infrastructure past just identity verification. The result is a ‘fast pass’ like experience for customers that allows their provider to skip all of the verification steps that were previously completed at another institution to their new provider’s standards.

Customers receive a streamlined experience, while accountability for customer-reported facts and between institutions scales with auditable, evidence backed trust.

Reliance is not a new concept or a regulatory workaround. It has been expressly authorized in the Customer Identification Program rule since 2003, with recent regulatory clarifications reinforcing its place in the compliance infrastructure of banks and fintech, specifically when applied as a networked solution.

This overview details the history of bank reliance and how the laws are leveraged within the SOLO network for banks and fintechs to compliantly rely on the work of others.

Foundational Laws & Applications

Bank reliance was established as a framework in 2003 via CIP Reliance, initially used by banks to trust each other’s work on identity verification checks of shared customers.

CIP Reliance

31 CFR §1020.220(a)(6) permits a bank to rely on the performance by another financial institution — including an affiliate — of any procedures of the bank's CIP, provided three conditions are satisfied:

1. Reasonableness. The reliance must be reasonable under the circumstances.
2. Regulated counterparty. The other institution must be subject to a rule implementing 31 U.S.C. §5318(h) and regulated by a federal functional regulator.
3. Written contract. The other institution must enter into a contract requiring it to certify annually that it has implemented its AML program and that it (or its agent) will perform the specified requirements of the relying bank's CIP

In practice, CIP Reliance has been used almost exclusively in bilateral relationships where a contract already existed for other reasons:

• Affiliate relationships, where a holding company's bank and broker-dealer subsidiaries rely on each other's onboarding, and the contractual plumbing is internal.
• Introducing broker–clearing broker arrangements, where the clearing agreement is the natural home for the annual certification.
• Sponsor bank–fintech partnerships, where a partner program agreement governs who performs which verification step.

Regulatory Clarity & Intended Use

If bank reliance has been permitted since 2003, why has it not become a commonly shared practice?

Because of the most common bilateral dynamics, the assumed contracting burden of reliance has been a limiting factor to bank reliance adoption at scale. Bank to bank reliance outside of individual partnerships, specifically, are few and far between. The result is fragmented, individual cases of reliance but a financial services ecosystem that largely repeats the same duplicative checks for individual customers.

Regulators have previously shared that a key barrier is that no one has built the connective tissue that allows for scale outside of these bilateral agreements.

The CIP rule anticipated institutions relying on one another. It did not anticipate that the contracting mechanism would become the binding constraint, and it did not prescribe a form for that contract — the text requires only that the institution "enter into a contract," with no requirement that the contract be bilateral.

In remarks about the agency’s work on shared identity, former FinCEN Director Gacki called identity verification processes "a network business" rather than a partnership play. CIP Reliance already established that bank reliance is permissible. What has been emphasized recently is that the agencies are describing the outcome they want in terms that a bilateral arrangement cannot deliver.

On April 10, 2026, FinCEN issued a notice of proposed rulemaking to reform AML/CFT program requirements under the BSA, with the FDIC, OCC, and NCUA issuing a parallel joint NPRM the same day. The proposal moves compliance away from process-driven technical requirements toward demonstrable outcomes, and it expressly names digital identity among the innovations that can help an institution show program effectiveness, stating that institutions responsibly experimenting with such technologies will not be penalized for doing so.

In February 2026, FinCEN granted exceptive relief from certain repeat beneficial-ownership verification requirements, acknowledging in a narrow context the principle reliance generalizes: re-performing verification that was already performed correctly does not make the system safer.

Additionally, FinCEN has long encouraged institutions to register for the §314(b) program and to form associations for voluntary information sharing in the context of fraud, an explicit endorsement of network-level structure over one-off bilateral enrollment. As recent as June 2026, they further clarified their endorsement of networked collaboration for such a case.

None of these grant new authority. Together they describe a supervisory posture in which shared, evidenced, reusable verification amongst a group of institutions is the expected direction rather than an exception to be justified.

Bank Reliance’s Role Today

Bank reliance is increasingly relevant in the bank and fintech ecosystem. The growing scale of banking partnerships alongside further directives from the agencies to adopt more auditable, collaborative approaches to verification work, especially as it pertains to identity and fraud prevention, reinforce its importance.

In 2003, the sponsor bank model did not exist. The case for bank to bank verification was far more static and sparse. Now, there are thousands of bank and fintech programs, ranging from embedded finance relationships to full service sponsor banking, including lending, deposits, cards, and more.

The sponsor bank x fintech dynamic concentrated the problem of isolated reliance agreements. A single sponsor bank may support dozens of fintech programs, each onboarding customers, each running verification, each generating evidence that lives in a different vendor stack in a different format despite the fact that the bank holds the regulatory obligation for all of it across every program.

Under CIP Reliance, the sponsor bank is always the legal furnisher of a KYC or KYB attestation, even when the underlying verification was performed by its fintech partner. The rule requires the relied-upon institution to be a BSA-regulated bank, so the obligation cannot be delegated away. The sponsor bank bears the accuracy, dispute-investigation, and correction duties for every certificate issued under its name.

Reliance is a framework sponsor banks are already obligated to participate in. What has not yet existed in practical application is a consistent, interoperable and auditable record of that reliance that creates an industry wide structure for reliance at scale. Such a framework would need to account for both individual banks discrete standards and process steps, and a universally recognized, auditor accepted artifact for continued oversight.

How the SOLO Network Leverages Bank Reliance

SOLO has been in active dialogue with FinCEN since early 2026 to help address the problem of banks operating their identity verification processes in silos in support of our network of sponsor banks and fintechs.

Those discussions produced the Reliance Pilot, launched June 2026 and publicly announced August 5, 2026, in which SOLO and a group of participating banks are operationalizing the CIP Reliance framework at scale. FinCEN, the OCC, and the FDIC are observing the pilot and have provided input on the contractual structure, the step-level reliance model, and the grading standards — including identifying NIST Identity Assurance Level 2 (IAL2) as the applicable assurance framework for evaluating CIP verification completeness.

The primary purpose of the pilot is to align banks and fintechs with regulator clarity on how a networked solution for bank reliance would operate beyond the bilateral agreements previously contained to just identity verification and fraud prevention.

Three workstreams have run under observation since the Pilot’s kickoff:

Policy translation

SOLO has worked with each participating bank to map its existing CIP procedures to discrete, auditable substeps — for KYC: document capture, biometrics, liveness, address verification, and identity corroboration; for KYB: business ID verification, business ownership and control, and business risk and compliance — documenting where procedures differ across institutions. This mapping sits on a shared ontology, the data model that makes heterogeneous bank programs interoperable without requiring any institution to change how it performs verification.

From these policies, SOLO maps a bank’s steps into a structured certificate: a set of bank-grade attestations, data, and verification artifacts that is exchanged through the network to satisfy reliance requirements.

Furnishing integration

Participating banks and their fintech partners have begun furnishing verification data, which requires mapping source systems and vendor outputs to the shared model, integrating each data provider, and validating ingestion, schema enforcement, and per-submission attestation against live records. The architecture accepts data in any format from any source. The result is interoperability without imposed uniformity.

Policy, data, and verification work auditing and grading

Each certificate is evaluated on three independent axes:

• Record type — what kind of verification artifact it is.
• Completeness — whether all expected verification steps were performed, graded against IAL2.
• Validation stage — how thoroughly SOLO has independently verified the furnisher's claims. Runtime validation digitally reconciles each certificate against the workflow that produced it (confirming, for instance, that the biometric and liveness checks a bank's policy requires were actually executed). Process validation confirms, through human or agent review, that the steps a bank claims to perform exist in its real onboarding workflow.

The resulting per-certificate grade is surfaced to participating banks in the network, which set their own acceptance thresholds.

The results of this pilot are official regulatory observation of the business model and coordination of bank and fintech engagement. It is not a no-action letter and not a formal safe harbor. What the pilot produces is not permission for reliance— permission already existed — but shared understanding between regulators, banks, and fintechs of what permissible execution of legal frameworks look like.

The four following components are the documented pieces of what the pilot has clarified from regulators for bank compliance, BSA/AMK, and risk teams assessing their participation in bank reliance through a networked solution like SOLO.

1. The written-contract requirement can be satisfied multilaterally by network participation agreements.

§1020.220(a)(6)(iii) requires parties participating in bank reliance to enter into a contract. It does not require that contract to be bilateral. A single multilateral network agreement, under which each participant's execution creates contractual privity with every other participant on identical terms, reinforced by an annual institutional certification and a per-submission attestation, satisfies the prong rather than requiring individual contracts for each bank x fintech transaction of reliance.

2. Individual institutions may keep their own reasonableness determination.

Reliance is not outsourced judgment, and nothing about the framework requires a bank to accept another institution's risk appetite. Each relying bank maintains its own written reliance policy reflecting its own reasonableness determination.

In the SOLO infrastructure observed in the Reliance Pilot, each bank configures which reliance verifications and methods their CIP policy will accept, per step, including freshness and lineage requirements. The network returns only matches meeting their stated criteria, or returns nothing.

3. Banks may see the work leading to reliance, not just the conclusion of a check or verification.

Reliance built on a pass/fail flag from an unnamed process is the leap of faith previously adopted by CIP reliance agreements. Instead, SOLO’s model enforces reliance built on a step-level certificate as an evidence based judgment.

The compliance officer would see which substeps were performed, by which method — mobile live capture versus file upload for document capture, for example, not merely "document capture: complete" — when, by which BSA-regulated institution, and how thoroughly SOLO independently validated the claim.

That work is made auditable after the fact: furnishers must produce evidence supporting their attestations on request, acknowledged within three business days and produced within ten, with audit rights and enforcement consequences behind the SLA.

4. The scope limits are explicitly defined, which is what makes the framework safe to adopt.

• A KYC or KYB Certificate cannot be used as the basis for declining an applicant. Certificates help satisfy the identification obligation. They are not underwriting or credit-decisioning inputs. A bank that sees something concerning in a certificate may route the applicant to manual review or request additional documentation — but an outright decline on that basis is not permitted.
• Certificates exclude sanctions and OFAC screening. Every bank screens independently. Reliance does not extend to sanctions obligations, and no participant is invited to assume otherwise.

Additionally, the Reliance Pilot is under observation to receive affirmative guidance from regulators that reliance per customer may be networked for an individual process step, like identity verification. Multiple banks may each hold a discrete step of the process that, together, may be combined to fully satisfy a policy stage. No bilateral arrangement can perform a cross-furnisher coherence check. That capability only exists at network level, which means centralization here is not a convenience, it is the source of an enhanced diligence control that did not previously exist anywhere and can be applied to fraud screenings, financial screenings, income & employment verifications, and more.

Eligible Use Cases for Bank Reliance in the SOLO Network

The primary application of bank reliance, and SOLO’s initial pilot products, is identity verification. Specifically, KYC and KYB.

The types of checks eligible for reliance is dependent upon the legal framework the verification work sits under, not by any one network's product design. Three regimes govern reliance, and each carries a different eligibility rule about who may furnish and what the resulting record legally is.

Three questions determine where any new verification step lands:

1. Is the work a CIP procedure? If yes, CIP Reliance applies and the furnisher must be a bank subject to a §5318(h) rule and regulated by a federal functional regulator. If no, reliance still works — but on FCRA footing alone, and the furnisher restriction falls away.
2. What is the record legally? Reliance instruments for identity work are simultaneously consumer reports, which brings permissible purpose, dispute, and adverse-action obligations. Information shared under §314(b) is statutorily not a consumer report, and carries none of them.
3. Can the step be decomposed and evidenced? Reliance requires the relying institution to see what was performed, by whom, and when. Work that cannot be broken into auditable substeps cannot be reliably relied upon, whatever framework permits it.

Identity: KYC and KYB

The primary application, and the subject of the Reliance Pilot. Certificates are structured attestations of completed verification work, decomposed so the relying bank sees the discrete steps rather than an opaque verdict which are matched to their own process.

The dual legal designation is what makes the model work: these records are simultaneously FCRA consumer reports and CIP Reliance instruments. That allows accuracy duties to sit with the furnishing bank, transmission and consumer-file duties with the network operator as a CRA, and the reasonableness determination with the relying bank — each obligation resting where the party can actually discharge it. Because certificates are consumer reports, every query carries a permissible-purpose attestation under FCRA §1681b, and consumers retain the full FCRA rights framework.

Financial Crime and Fraud: §314(b)

Section 314(b) provides a safe harbor for institutions sharing information with one another to identify possible money laundering or terrorist activity. Like CIP Reliance, it is voluntary, long-standing, and underused for a related reason: the sharing has historically happened one bilateral relationship at a time.

FinCEN's June 12, 2026 updated Section 314(b) Fact Sheet — which replaced the December 2020 version — resolves three questions directly relevant to operating it at network scale. Fraud offenses are confirmed as specified unlawful activities within the safe harbor, so fraud information sharing is expressly covered. Real-time sharing is permitted. And, an institution may share with any other registered participant even absent an existing relationship with the subject, which the receiving institution may use in deciding whether to establish or maintain an account.

Most significantly for a networked reliance structure like SOLO’s: FinCEN states that the organization forming and operating a §314(b) association need not itself be a regulated financial institution under the BSA. The association model is not a workaround of the bilateral norm — it is the structure the rule contemplates, now with the operator question answered in writing.

Because §314(b) information is statutorily excluded from consumer report status, watch list data sits in a legally separate file from certificate data, outside FCRA dispute and adverse-action procedures, with confidentiality obligations under §1010.540(b)(4). This is why §314(b) is a parallel framework rather than an additive one: CIP Reliance layers on top of FCRA, while §314(b) runs alongside on its own footing.

Where the Framework Reaches Next

Authorized agent and phone number verification are already designated as reliance certificate categories under published Standards. Both are CIP-adjacent, high-volume, and almost never portable today — authorized agent verification is a persistent business-onboarding bottleneck, and phone number verification stales quickly enough that per-step freshness configuration does real work.

Ongoing due diligence and periodic refresh is upcoming. CIP governs onboarding; the recurring cost sits in re-verification. The same infrastructure reliance needs at onboarding — freshness windows, provenance, graded completeness — is what a refresh cycle needs, and a bank that can see which steps are stale knows precisely what to re-perform.

FinCEN's February 2026 exceptive relief on beneficial-owner verification at each account opening points the same direction, as does the April 2026 proposed program rule's placement of ongoing CDD within the internal policies, procedures, and controls pillar.

Bank Reliance in the SOLO Network FAQs

If a customer skips verification steps, is CIP still being performed?

Yes. 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 does not move. The rule permits a bank to rely on another financial institution to perform "any procedures" of the bank's CIP. What leaves your onboarding flow is duplicated work. What stays is your responsibility for the outcome. 31 CFR §1020.220(a)(6)

Is reliance all-or-nothing, or can it apply to individual steps?

Step by step. The rule sets an outcome standard — a reasonable belief that you know the customer's true identity — and expressly contemplates documents, non-documentary methods, or a combination. It does not require that one entity perform every element. This is less novel than it sounds. Banks have assembled CIP across multiple vendors for two decades. What changes is where the components come from, not the fact that they are assembled. 31 CFR §1020.220(a)(6), (a)(2)(ii); 68 Fed. Reg. 25090, 25099, 25103 (2003)

Can reliance draw on work from more than one institution?

Yes. If three of six steps were completed at one participating bank and three at another, the record can reflect both. Whether that makes an identity better verified or merely more completely described is a separate and real question — see below. 31 CFR §1020.220(a)(6)

Which institutions can actually be relied upon?

The institution must be subject to a rule implementing AML program requirements and regulated by a federal functional regulator — the SEC, CFTC, OCC, FDIC, Federal Reserve, or NCUA. A broker-dealer qualifies; it has its own CIP rule and an SEC relationship. A money transmitter or a crypto exchange does not, regardless of how good its verification work is, because it fails the regulator prong. FinCEN is not a federal functional regulator for this purpose. This is an entity-level question, not a brand-level one. The same corporate group may contain entities on both sides of the line. 31 CFR §1020.220(a)(6)(ii); 31 CFR §1010.100(r); 31 CFR §1023.220; 31 CFR §1022.210

Who is the legal furnisher of relied-upon work?

For CIP reliance, always the BSA-regulated bank. A fintech program's name may appear for transparency, but it carries no furnishing responsibility and cannot. Where a non-bank participant submits a query, it does so on behalf of a sponsor bank — and that bank is the relying institution for purposes of the CIP rule, the legal user of the record, and the party bound by the query-time attestations. 15 U.S.C. §1681s-2; 31 CFR §1020.220(a)(6)

How old can relied-upon work be?

Different steps decay differently, so a single freshness rule cannot cover them. A government photo ID has its own expiration date; an address goes bad silently. Biometric verification ages faster than SSN verification. Sanctions and PEP screening is not eligible for reuse at all. In practice each step carries its own default window, furnishers may specify shorter ones, and relying institutions may specify shorter ones still — with the shortest applicable window governing. 31 CFR §1020.220(a)(3); 15 U.S.C. §1681c

What does my institution need in place before it can rely?

Reliance is not self-executing. You need a written reliance policy describing the verification step categories, vintages, and lineages you will accept. You need those criteria configured so they operate at query time, and they must reflect your own reasonableness determination rather than anyone else's. And you keep your own records: description of the documents, the methods and results of non-documentary verification, and the resolution of any discrepancies. 31 CFR §1020.220(a)(3), (a)(6)(i)

What exactly would I show an examiner?

Four things, and they are not interchangeable. The network agreement and the furnishing institution's annual certification — these are the contract and certification the rule requires. Your own written reliance policy and (in SOLO) a configured querying criteria — this is your reasonableness determination, documented. The reliance record itself — method and result for each step, and which institution performed it. And your own record of what you relied on for that customer. The record is evidence. It is not the authorization. 31 CFR §1020.220(a)(3), (a)(6)(iii)

Can I decline an applicant based on relied-upon work?

No. A decline on that basis is not permitted. If a reliance record does not satisfy you, the answer is to run your own procedures — which you are always free to do. Reliance removes duplicated work; it does not create a basis for turning someone away. 15 U.S.C. §1681m

Does the network make any part of the compliance decision?

No. The SOLO network structures, validates, and transmits verification work, and returns only records satisfying the criteria the relying institution set. The decision and the accountability stay with that institution. 31 CFR §1020.220(a)(6)(i)

If I rely on another institution's work and it turns out to be wrong, what happens to me?

The rule anticipates this. 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 reliance policy matters, and why no record can stand in for it. 31 CFR §1020.220(a)(6); 68 Fed. Reg. 25090, 25103 (2003)

Do I have to take the furnishing institution's word for it?

Not in a well-built framework. Reliance should rest on four independent layers: schema validation at ingestion, so non-conforming data is rejected rather than released; annual institutional certification that the furnisher's CIP and AML programs meet the standard for reliance; a per-submission attestation from an authorized officer that the specific records were produced under those programs; and audit rights with real consequences, including an obligation to produce underlying evidence on request within defined timeframes and termination for repeated substantiated failures. 15 U.S.C. §1681e(b), §1681s-2

Does combining steps from different institutions make an identity better verified, or just more completely described?

Two institutions independently verifying the same fact is corroboration — genuinely stronger evidence than either alone. Different institutions verifying different facts is concatenation, which is a more complete description of a person but not a better-verified one. Errors do not cancel across concatenated fields; they accumulate. Anyone claiming that six single-sourced steps produce six times the confidence is confusing completeness with verification. The framework answer is to grade the difference rather than paper over it, so the relying institution's reasonableness determination can weight it accordingly. 31 CFR §1020.220(a)(6)(i)

What can a consumer do, and how does that affect me?

In SOLO, consumers can obtain their file at any time at no cost and dispute anything in it at no cost. Disputes are forwarded to the furnisher and reinvestigated within statutory timelines. A furnisher's assurance that information is accurate does not settle the matter; without substantiation the information is deleted. Consumer disputes are a detection channel the framework gets for free, and the most reliable way that imposter onboarding at an upstream institution comes to light. 15 U.S.C. §1681g, §1681i, §1681j, §1681s-2