Section 314(b) Fraud Information Sharing for Banks

Section 314(b) information sharing gives eligible, registered financial institutions and qualifying associations a conditional safe harbor for exchanging information to identify and, when appropriate, report activity that may involve terrorist financing or money laundering. FinCEN’s June 2026 guidance confirms that this can include information related to suspected fraud and other specified unlawful activities, including consumer scams, attempted transactions, money-mule activity, and relevant cyber indicators.

In practice, that clarification matters because fraud rarely stays inside one bank.

For example, a sending institution may see a manipulated customer and an unusual payment. A receiving institution may see a new account, rapid funds-out activity, shared devices, or several unrelated victims paying the same recipient. As a result, each institution holds only part of the evidence. Lawful, secure, and timely connections make the wider network clearer.

However, permission to share does not automatically create an effective operating model. Even so, banks still need defined authority, verified counterparties, secure communication, careful documentation, data-quality controls, analytical discipline, and clear rules for using shared information.

Accordingly, this guide explains how fraud, BSA/AML, investigations, payments, analytics, legal, privacy, and risk teams can build a practical Section 314(b) information-sharing process—from deciding whether an inquiry is appropriate to governing the intelligence that comes back. Although the guide focuses on banks, other eligible institutions with qualifying anti-money-laundering programs and certain associations may also participate.

Editorial note: This article is educational and analytical. It is not legal advice. Financial institutions should interpret Section 314(b), SAR confidentiality, privacy obligations, record retention, account action, and cross-border sharing with their legal, BSA/AML, privacy, information-security, and regulatory partners.

Quick Takeaways

FinCEN’s June 12, 2026 guidance expressly confirms that qualifying information about suspected fraud may be shared under Section 314(b).
A participating institution does not need to identify specific fraud proceeds being laundered before the safe harbor may apply.
Attempted activity may qualify, including attempts to induce another person to transact through a money-mule scheme.
Institutions may share information in real time and may use verbal, written, or electronic methods when security and confidentiality requirements are satisfied.
Section 314(b) does not authorize disclosure of a SAR or information that would reveal that a SAR exists.
Shared intelligence should be treated as evidence with provenance and confidence—not as an unexplained blacklist.
Data analysts can help prioritize cases, normalize identifiers, resolve entities, analyze networks, track outcomes, and measure whether information sharing produces better decisions.
Success is not simply the number of requests or SARs. It includes useful responses, new entities discovered, faster intervention, better-supported no-SAR decisions, enhanced SARs, reduced false links, and prevented or recovered losses.

Who This Guide Is For

Specifically, this guide serves:

Fraud strategy and fraud operations teams
BSA officers and AML investigators
Financial-crime data analysts and data scientists
Payment-risk and scam-prevention teams
Money-mule and recipient-risk investigators
Cyber-fraud and account-takeover teams
Legal, privacy, information-security, and compliance partners
Model-risk, operational-risk, audit, and governance teams
Executives responsible for fraud loss, customer harm, or financial-crime risk

For related coverage, visit the EdEconomy Financial Crimes hub and Banking Fraud hub.

What Changed in FinCEN’s 2026 Section 314(b) Guidance?

First, Section 314(b) is not new. The USA PATRIOT Act created the voluntary information-sharing framework more than two decades ago. Instead, the important 2026 change is the clarity with which FinCEN connected the framework to fraud.

Specifically, the current FinCEN Section 314(b) Fact Sheet, issued June 12, 2026, explains that fraud offenses can be specified unlawful activities for money-laundering purposes. Therefore, information sharing may fall within the safe harbor when an institution suspects that information involves fraud and the other participation requirements are satisfied.

FinCEN also states that an institution does not need to identify specific fraud proceeds being laundered before the protection may apply. That addresses an important operational hesitation: fraud investigators do not always have to wait for a completed movement of criminal proceeds before authorized collaboration begins.

In addition, the updated guidance confirms that institutions may share information about attempted activity. FinCEN specifically references attempts to induce others to transact, such as in a money-mule scheme.

Likewise, the Federal Reserve’s SR 26-3, the OCC’s Bulletin 2026-30, the FDIC’s July 2026 communication, and the NCUA’s July 2026 announcement each reinforced the updated framework for their respective audiences.

What Information May Be Relevant?

Notably, FinCEN does not prescribe one fixed data set. Its guidance discusses information concerning individuals, entities, organizations, countries, transactions, attempted transactions, and related activity.

For example, the OCC highlights:

Video-surveillance footage
Cyber-related information such as IP addresses
A newly added payee followed by a large transfer
Multiple accounts using the same or similar identifying information
Login activity from geographically distant locations

Depending on the case and the institution’s approved procedures, relevant underlying information could also include customer and account identifiers, transaction timing, payment direction, devices, contact information, recipient relationships, or investigative context.

Still, institutions should not share every available field. FinCEN’s guidance does not impose a BSA-specific limit on the type, medium, or amount of information exchanged, but other applicable laws and institutional controls still matter. Therefore, a sound process asks what information is relevant, proportionate, authorized, protected, and permitted for the inquiry.

Section 314(b) Is a Conditional Safe Harbor, Not Open Data Sharing

At first glance, the phrase “safe harbor” can sound broader than it is. Section 314(b) protection depends on satisfying the program’s conditions.

According to FinCEN, participating institutions or associations must register, verify that the other party is also a registered participant, protect the security and confidentiality of shared information, and use that information only for permitted purposes.

The current registration instructions are on FinCEN’s Section 314(b) information-sharing page. FinCEN’s June 2026 fact sheet directs institutions to request access to the Financial Industry Portal and use its 314(b) functionality.

This is an important freshness point. FinCEN formally rescinded its December 2020 fact sheet on June 12, 2026. Institutions should use the current FinCEN instructions rather than relying on an older operational summary.

Permitted Uses of Shared Information

The current fact sheet identifies three broad permitted purposes:

Identifying and, when appropriate, reporting activity that may involve terrorist financing or money laundering, including activity potentially constituting a specified unlawful activity such as fraud.
Determining whether to establish or maintain an account or engage in a transaction.
Assisting with compliance under applicable anti-money-laundering requirements.

Consequently, these limitations affect system design. For that reason, data received for a controlled financial-crime purpose should not silently become a general customer attribute available for unrelated marketing, pricing, or operational uses. In addition, systems should preserve the source, permitted purpose, access restrictions, and review status with the information rather than separating the data from its authority.

When Section 314(b) May Help—and When It Does Not

Ultimately, the first control question is not simply whether another institution has useful information. It is whether the proposed exchange fits a permitted Section 314(b) purpose and whether the participants satisfy the program’s conditions.

Situation	Practical assessment
Several customers send scam payments to the same external recipient	A focused inquiry may help identify related fraud, money-mule activity, or movement of suspected proceeds.
A payment attempt fails, but the identifiers connect to a suspected mule scheme	Attempted activity may still be relevant; a completed transfer is not always required.
An institution needs to decide whether to open, maintain, or close an account	The safe harbor includes information used to determine whether to establish or maintain an account or engage in a transaction.
A team wants to reuse shared intelligence for marketing, pricing, or an unrelated business purpose	That use falls outside the program’s stated purposes and should not be treated as protected by Section 314(b).
The counterparty’s current participation has not been verified	Do not rely on the safe harbor until verification is completed through FinCEN’s process.
A message would reveal that a SAR exists	Do not send it, except for the limited discussion and sharing permitted among institutions considering or filing the same joint SAR.

Moreover, Section 314(b) is voluntary, and no single exchange is mandatory merely because it could qualify. Institutions still need a documented decision process for when to request, respond, escalate, or decline.

Section 314(b) and SAR Confidentiality

Above all, teams must preserve the distinction between a SAR and the underlying information.

Specifically, FinCEN’s guidance states that Section 314(b) does not authorize institutions to share a SAR or disclose information that would reveal that a SAR exists. However, underlying facts, transactions, customer information, and documents may be shareable when the Section 314(b) conditions and other applicable requirements are satisfied.

FinCEN also explains that participating institutions considering or having filed the same joint SAR may discuss and share that joint SAR among themselves. This limited allowance does not authorize disclosure to institutions outside the joint-filing group or eliminate the general rule protecting SAR confidentiality.

Therefore, banks should design procedures that make these distinctions clear to investigators and analysts. A case-management export, analyst comment, model feature, or dashboard label can inadvertently reveal SAR status even when the underlying transaction could otherwise be discussed.

Why Cross-Bank Fraud Information Matters

Fraud actors exploit institutional boundaries.

For example, a victim’s bank may see the customer journey, warning interactions, device behavior, payment initiation, and claim. The recipient bank may see account opening, inbound concentration, rapid dispersion, cash withdrawal, digital-asset movement, or downstream beneficiaries. Another institution may see a shared phone number, device, address, or business entity.

Within each organization, the activity may appear incomplete or only moderately suspicious. Together, those institutional views may form a recognizable network.

That is especially relevant to:

Authorized push payment scams
Business email compromise
Money-mule networks
Account takeover
Investment and relationship scams
Impersonation scams
Synthetic or manipulated identities
Funnel accounts and rapid funds movement
Coordinated attempts that fail at one institution and move to another

EdEconomy’s guides to money mule detection, receiver risk scoring, and payee verification and recipient intelligence examine this receiver-side problem in more depth.

A Practical Section 314(b) Fraud Information Sharing Workflow

In practice, a mature Section 314(b) fraud information sharing process connects investigation, authorization, exchange, analysis, action, and governance.

Step 1: Identify a Qualifying Investigative Need

The process should begin with a case or pattern that may benefit from external information. Common triggers might include:

Several customers paying the same external recipient
Suspected fraud proceeds moving quickly to another institution
Repeated external counterparties in scam or account-takeover cases
Shared identities or devices across unrelated internal accounts
An attempted payment or new-payee event that appears connected to a known scheme
Missing context that prevents an investigator from resolving a case

Analytical rules may prioritize these cases, but an authorized function should determine whether a Section 314(b) inquiry is appropriate.

Step 2: Verify Participation and Authority

Before information is shared, the institution should verify the other party’s current participation using FinCEN’s approved process. A Section 314(b) notice is effective for one year, so each institution should track its expiration date and renew annually before continuing to rely on the safe harbor. It should also confirm that the employee sending the request is authorized under internal policy.

The process should capture evidence of verification, the authorized sender, the recipient, the date, and the purpose.

Step 3: Prepare a Focused Request

In practice, a good request explains the suspected pattern without turning the exchange into an uncontrolled data dump.

It should provide enough context to help the other institution search effectively. At the same time, it should remain proportionate to the investigative need. Specifically, a useful request separates observed facts from inferences and asks specific questions rather than requesting everything associated with a person or account.

A practical request structure

Field	What to capture
Authority and verification	Confirmation that both parties are current participants and the sender is authorized
Investigative purpose	The suspected fraud, laundering, or related activity and why the exchange may help
Known facts	Relevant dates, amounts, rails, identifiers, and observed behavior
Questions	The specific relationships, transactions, or activity the recipient is being asked to assess
Handling	Approved channel, urgency, permitted use, and any internal sensitivity classification
Response linkage	Internal case ID and the contact authorized to receive the response

Step 4: Exchange Information Securely

FinCEN allows verbal, written, or electronic information sharing when the relevant requirements are met. Therefore, the institution should determine which approved channel fits the sensitivity and urgency of the case.

For example, high-risk design failures include personal email, uncontrolled attachments, excessive copying, unrestricted shared drives, and downstream systems that lose the original permitted-use restrictions.

Step 5: Analyze and Corroborate the Response

Importantly, an external response is a lead, not automatic proof.

Instead of treating the response as a verdict, investigators and analysts should compare it with internal evidence, assess match quality, document uncertainty, and determine whether it changes the case.

Step 6: Make and Document the Decision

Depending on the evidence, the result could support enhanced review, recipient controls, transaction action, account decisions, a SAR assessment, a joint SAR discussion, recovery activity, law-enforcement coordination, or closure with no further action.

Notably, FinCEN explains that added context can also support a determination that no SAR is required when it resolves activity that initially appeared suspicious.

Step 7: Feed Validated Intelligence Back Into Controls

Once confirmed, patterns may inform fraud rules, recipient monitoring, graph features, typology libraries, investigator training, customer warnings, or KRI reporting. However, reuse should follow governance, permitted-use, validation, privacy, and model-risk requirements.

How Data Analysts Support Section 314(b) Fraud Information Sharing

Within this operating model, data analysts can make the process more targeted, measurable, and explainable. They should not replace the legal or investigative decision. Instead, they can improve the quality of the evidence and the efficiency of the workflow.

Prioritize Cases With Explainable Signals

Analysts can identify cases where cross-institution information is most likely to matter. Useful signals may include:

First-time recipient combined with unusual payment size
Many-to-one payment concentration
Rapid inbound-to-outbound movement
Dormant-to-active account behavior
Shared devices, IP addresses, phone numbers, emails, or addresses
New digital access followed by recipient creation and payment
Repeated attempts after a rejection
High-risk recipient exposure across multiple customers
Connected claims or confirmed fraud outcomes

Teams should document and test the prioritization logic. It should not rely on an opaque vendor score that investigators cannot interpret.

Create a Controlled Data Structure

Unstructured messages are difficult to search, measure, retain, and govern. Analysts and data engineers can define a standard record for each request and response.

Data group	Illustrative elements	Analytical purpose
Case metadata	Case ID, typology, request date, urgency	Connect the exchange to an approved investigation
Entity identifiers	Name, date of birth, address, phone, email	Support controlled entity matching
Account references	Approved account identifiers and institution	Locate relevant internal or external relationships
Transaction details	Date, amount, rail, channel, direction	Reconstruct the movement of funds
Digital evidence	IP address, device, login geography	Identify shared infrastructure or access patterns
Behavioral signals	New payee, velocity, dormancy break, rapid funds-out	Describe the suspected pattern
Investigative context	Reason for inquiry and question being asked	Prevent context-free interpretation
Governance metadata	Authority, participant verification, source, permitted use	Preserve provenance and control evidence
Outcome	Actionable, inconclusive, no match, confirmed link	Measure effectiveness and improve future triage

This is a design framework, not a recommendation to share every listed element in every case.

Resolve Entities Carefully

Cross-bank analysis often depends on entity resolution: determining whether records from different systems refer to the same person, account, business, device, or recipient.

Analysts may use exact matching, normalized matching, controlled fuzzy matching, shared attributes, device linkage, temporal patterns, and network relationships. However, every method can produce false links.

A shared address may represent a household, apartment building, shelter, business, or mail service. A shared IP address may represent a corporate network, carrier NAT, public Wi-Fi, or VPN. A recycled telephone number can connect unrelated people. Therefore, match confidence should reflect the quality, number, independence, and timing of the supporting attributes.

Use Graph Analytics to Reconstruct the Network

Graph analysis is well suited to information spanning institutions because it represents relationships directly.

Possible nodes include customers, accounts, recipients, devices, IP addresses, phone numbers, email addresses, businesses, and cases. Edges can represent payments, shared identifiers, device access, common ownership, or investigative associations.

The graph should preserve source, time, confidence, and direction. It should also distinguish an observed fact from an inferred relationship.

For a deeper technical discussion, see EdEconomy’s guide to graph analytics for account-takeover fraud.

Preserve Provenance and Confidence

Shared information should not become an unexplained binary fraud flag.

A stronger design stores:

Source institution or approved association
Date received
Related case or request
Permitted purpose
Verification status
Exact data element or relationship received
Internal corroboration status
Confidence level
Decision and action taken
Review or expiration date
Correction history

This allows investigators, validators, auditors, and governance teams to understand why an external signal affected a decision.

Section 314(b) Fraud Information Sharing KPIs and KRIs

Leaders should measure the program for usefulness, speed, quality, and control—not just activity.

Metric	What it measures	Why it matters
Request volume	Number of outgoing and incoming inquiries	Shows adoption, but not value by itself
Response rate	Share of requests receiving a response	Identifies participation and counterparty gaps
Median response time	Time from request to usable response	Measures support for time-sensitive intervention
Actionable-response rate	Responses that materially change a case	Measures practical utility
New-entity discovery rate	Previously unknown relevant parties found	Measures network expansion
Confirmed-link rate	Proposed matches corroborated internally	Tests entity-resolution quality
False-link rate	Matches later determined to be incorrect	Monitors customer and analytical risk
SAR enhancement rate	Cases where sharing adds useful SAR context	Measures reporting value
No-SAR decision support	Cases resolved without a SAR after added context	Captures efficiency and better judgment
Prevention or interdiction value	Loss avoided before completion	Measures proactive impact where attribution is supportable
Recovery value	Funds recovered or returned with sharing support	Measures post-event benefit
Control-compliance rate	Exchanges meeting verification and documentation standards	Tests safe-harbor process discipline
Data-quality exception rate	Incomplete, stale, conflicting, or unusable responses	Identifies structural data problems

Teams should segment these measures by typology, payment rail, product, request direction, response time, and outcome. Otherwise, a high-value use case can disappear inside an institution-wide average.

For a broader measurement framework, see Fraud Analytics KPIs for Banking Teams and Fraud KRI Governance in Banking.

Key Risks and Controls for Section 314(b)

Information sharing can improve detection, but weak implementation can create new risk.

Risk	Example	Control response
Unverified participant	Information sent before confirming current registration	Require verification evidence before release
Excessive disclosure	Entire case file sent when a narrow set of fields would answer the question	Apply relevance, proportionality, and approved data-minimization standards under bank policy and other applicable law
SAR disclosure	A case note reveals that a SAR was filed	Separate SAR status from shareable underlying facts
Permitted-use drift	Shared data becomes available to unrelated business functions	Enforce purpose-based access and downstream restrictions
False entity match	Common IP or address treated as proof of fraud	Require corroboration and confidence standards
Stale intelligence	Old external information drives current action	Apply effective dates, review dates, and expiration rules
Missing provenance	A risk flag cannot be traced to its source	Store source, case, time, authority, and evidence
Automated overreach	External signal automatically blocks an account	Require defined decision logic and appropriate human review
Inconsistent taxonomy	Fraud and AML teams classify the same scheme differently	Maintain shared typology definitions and mappings
Uncontrolled analytics	Analysts extract shared data into unrestricted workspaces	Use approved analytical environments and monitored access

Section 314(b) Fraud Information Sharing Needs a Shared Operating Model

Section 314(b) sits between traditional organizational structures.

Fraud teams understand scams, claims, customer journeys, payment warnings, and rapid intervention. AML teams understand suspicious-activity reporting, financial trails, typologies, and BSA governance. Data analysts connect transactions, entities, devices, recipients, and outcomes. Legal, privacy, and information-security teams define safe boundaries. Operations teams execute customer, payment, and account actions.

The program is likely to underperform if one function owns it in isolation.

A practical responsibility model could assign:

Function	Primary responsibility
BSA/AML	Program governance, SAR boundaries, regulatory alignment
Fraud investigations	Case initiation, fraud context, time-sensitive escalation
Data analytics	Prioritization, matching, network analysis, measurement
Legal and privacy	Interpretation, permitted-use boundaries, complex cases
Information security	Secure exchange, access controls, monitoring
Payment operations	Holds, recalls, returns, recipient or account action
Model risk and validation	Review of automated scoring or model use
Audit or independent testing	Control design and operating-effectiveness assessment

Each institution should tailor ownership to its structure and risk profile. The important point is that decisions, approvals, handoffs, and evidence requirements are explicit.

What Should Banks Implement First?

Banks do not need to begin with a cross-industry machine-learning consortium. A controlled foundation comes first.

1. Establish the Governance Baseline

Confirm current registration and points of contact
Define authorized employees and approved counterparties
Document permitted purposes and prohibited uses
Establish SAR-confidentiality controls
Approve communication channels and retention treatment
Define escalation and legal-review triggers

2. Standardize the Workflow

Create request and response templates
Capture participant verification
Define urgency categories and service expectations
Connect exchanges to internal case IDs
Standardize outcomes and dispositions
Train fraud and AML investigators

3. Build the Analytical Layer

Prioritize cases using explainable signals
Normalize identifiers and data fields
Add entity-resolution confidence rules
Create controlled network views
Store provenance and permitted-use metadata
Monitor false links and data-quality exceptions

4. Measure and Improve

Track response time and actionable outcomes
Measure network discovery and corroboration
Connect results to prevention, recovery, and SAR decisions
Review control exceptions and customer impact
Tune triggers based on validated outcomes

The Future: Privacy-Preserving Collaboration

The 2026 guidance permits electronic platforms when the program’s requirements are satisfied. Over time, that could support more structured collaboration among participating institutions and associations.

Research on privacy-enhancing technologies explores privacy-preserving record linkage, secure multiparty computation, federated learning, and collaborative graph analysis. For example, Privacy Technologies for Financial Intelligence discusses how organizations might match or analyze distributed financial information without disclosing every plaintext value. Research on collaborative AML among financial institutions examines multi-institution analysis while protecting local data.

These approaches are promising, but they are not regulatory shortcuts. A privacy-enhancing technology does not, by itself, establish that a use is authorized, accurate, fair, secure, or protected by the Section 314(b) safe harbor.

EdEconomy Viewpoint

FinCEN’s 2026 guidance closes an important interpretation gap. The larger challenge is now operational.

Banks must decide how a suspected fraud pattern becomes an authorized inquiry, how the other institution is verified, what information is necessary, how the response is protected, how analysts resolve identities, how investigators corroborate the evidence, and how the final decision is measured and governed.

The strongest Section 314(b) fraud information sharing programs will not be the ones that share the most data. They will be the ones that turn relevant cross-institution intelligence into faster, better-supported, and more explainable decisions while preserving security, confidentiality, provenance, and customer safeguards.

Fraud crosses institutions. The control environment must learn how to connect the evidence without losing accountability.

Frequently Asked Questions

What is Section 314(b) fraud information sharing?

Section 314(b) fraud information sharing is a voluntary framework that can provide a safe harbor from liability when eligible, registered financial institutions or associations share qualifying information to identify and, when appropriate, report activity that may involve money laundering, terrorist financing, fraud, or other specified unlawful activity. Participants must satisfy registration, verification, security, confidentiality, and permitted-use conditions.

Can banks share information about suspected fraud under Section 314(b)?

Yes. FinCEN’s June 2026 fact sheet expressly confirms that information related to suspected fraud may be shared when the fraud may constitute a specified unlawful activity and the other Section 314(b) conditions are met. An institution does not need to identify specific fraud proceeds being laundered before the safe harbor may apply.

Can banks share information in real time?

Yes. FinCEN states that participating institutions may share information in real time while activity is occurring. The method may be verbal, written, or electronic, provided the applicable security, confidentiality, verification, and permitted-use requirements are satisfied.

Can a bank share a suspicious activity report under Section 314(b)?

Section 314(b) does not generally authorize a bank to disclose a SAR or reveal that a SAR exists. Underlying facts, transactions, customer information, and documents may be treated differently. FinCEN also provides specific guidance for institutions considering or filing a joint SAR.

What can data analysts do in a Section 314(b) program?

Data analysts can prioritize cases, standardize request and response data, normalize identifiers, support entity resolution, build network views, retain provenance, measure outcomes, and monitor false links or data-quality problems. Analysts should operate within approved legal, BSA/AML, privacy, security, and governance procedures.

Does a shared fraud indicator prove that a customer committed fraud?

No. A shared identifier, device, IP address, transaction, or risk indicator is evidence that must be evaluated in context. Institutions should corroborate external information, assess match confidence, document uncertainty, and avoid treating a single shared attribute as conclusive proof.

Is Section 314(b) participation mandatory?

No. Participation is voluntary. FinCEN and federal banking regulators strongly encourage eligible institutions to consider the program because information sharing can reduce the visibility gaps exploited by fraud and money-laundering networks.

How should a bank measure its Section 314(b) program?

A bank can track response rate, response time, actionable information, new entities discovered, confirmed and false links, enhanced SAR information, supported no-SAR decisions, prevented or recovered loss, data-quality exceptions, and compliance with participant-verification and documentation controls.

Related EdEconomy Guides

Sources and Further Reading

Build Better Fraud and AML Analytics

Join the EdEconomy Fraud Analytics Brief for practical frameworks on fraud detection, AML intelligence, payment risk, money mules, AI governance, and financial-crime analytics.

Subscribe to EdEconomy