USA PATRIOT Act Fintech Duties in Bank Partnership Models

How USA PATRIOT Act Duties Are Divided in a Bank Partnership Model#

A customer has submitted an application, the fintech wants to enable payments, and the bank still needs an identity check. The next action depends on the bank’s approved program: some accounts must wait, while others may open with defined limits during verification. Your product needs to reflect that decision and record who authorized it.

The USA PATRIOT Act added requirements that operate through the Bank Secrecy Act and institution-specific rules. A bank partnership does not give every fintech the same duties. Start with the legal entity, its actual activities, the account relationship, and the applicable bank program.

For example, a fintech may collect onboarding information for a bank while separately conducting activities that bring it within money-services-business rules. The bank’s own regulatory responsibility remains with the bank; the contract assigns execution and oversight between the parties. A software-provider label alone does not settle the fintech’s own obligations.

Before enabling a new account or payment feature:

• Decide where responsibilities and applicable obligations sit across your entity and partner-bank relationships before adding features that increase compliance load.
• Assign clear ownership for core controls and information-sharing decisions.
• Keep audit-ready records from day one so reviews rely on evidence, not memory.

Record which rules apply directly to your entity and which controls you execute for a partner. Have the relevant legal and compliance owners resolve material scope questions for the affected feature before launch; a generic “bank handles compliance” note is insufficient.

For a step-by-step walkthrough, see A Deep Dive into Florida's Money Transmitter License Rules.

Start With the Terms That Drive Real Decisions#

Give each operational term a definition, a current source, an accountable owner, and a record location. Start with the controls the feature actually uses rather than attaching every PATRIOT Act section to every ticket.

Start with the exact PATRIOT Act term in scope#

Section 314(b) is voluntary information sharing by eligible financial institutions and eligible associations under a conditional safe harbor. It is separate from Section 314(a), which routes law-enforcement search requests through FinCEN. An ordinary merchant or software vendor does not become a participating financial institution just because it works with a bank.

Use FinCEN’s current 314(b) resources. The June 12, 2026 fact sheet replaces the December 2020 version. For your operating file, retain current participation evidence and the basis for the proposed exchange, rather than relying on an old “certification” template.

Put BSA and FBAR in the right box#

The Bank Secrecy Act also supports FBAR reporting, but an individual’s foreign-account filing obligation is a separate question from bank onboarding or institutional information sharing. For US persons, financial interest or signature authority and the aggregate foreign-account value determine whether further filing analysis is needed. See FinCEN’s FBAR overview.

If you want a cleaner ownership model for recordkeeping and repeatable evidence handling, see Bank Secrecy Act fintech decisions. The discipline is simple: each recurring term maps to one operational owner and one artifact you can actually retrieve.

The special extension is described in FIN-2025-NTC3. FinCEN separately explains the automatic October extension and maximum-value reporting. Keep the report year and applicable notice in the filing record.

Keep personal FBAR records outside the bank’s CIP and SAR case files unless there is a specific authorized need. A missing personal filing document is not, by itself, a reason to block a customer’s account or delay an institution’s own reporting deadline.

If an unresolved responsibility or missing artifact prevents a required control from operating, restrict the affected feature and escalate to its owner. For a minor documentation gap, record remediation, a due date, and any needed interim control. Retrieval targets are internal operating standards, not universal statutory release conditions.

Decide Your Regulatory Position Before You Add Features#

Decide feature ownership before build starts, because unclear ownership at launch can become a control failure, not just a paperwork issue. Set the operating position first and treat implementation as downstream.

Use one working label per feature, such as direct entity, bank-program fintech, or hybrid split model. Keep labels as internal decision tools, then validate with counsel and partner compliance teams. A practical checkpoint is retrieval. Can you pull the current owner, approval trail, and governing agreement reference immediately?

Keep the decision record in three distinct internal layers so oversight and execution stay separate:

• Key regulators and oversight
• Current regulatory framework assumptions
• Day-to-day AML/CFT and sanctions control execution

If your activities may fall under the FTC Safeguards Rule, assess that separately from bank BSA controls. The FTC’s guide covers financial institutions within its jurisdiction, rather than institutions subject to another regulator’s enforcement authority under the relevant GLBA provision. Covered firms need a suitable written information-security program. Confirm who supervises it, including where a service provider performs work.

Include these fields in the decision log:

• Feature or product surface and selected model label
• Legal-entity roles and partner roles
• Named owners for control execution and escalation
• Governing contract artifact and version
• Open perimeter questions for counsel with target decision dates
• Latest sign-off record and timestamp

For each line item, include retrieval handles: named owner, approval record, and contract or governing document reference. This helps make the log audit-ready evidence rather than a planning note.

If a required control has no accountable owner, resolve that gap before enabling the affected activity. Document lower-impact gaps and their remediation dates rather than stopping unrelated releases. For the distinction between agency roles and user obligations, see What Is FinCEN for Freelancers and FinTech Users.

Map PATRIOT Act Sections to Your Product Surfaces#

Map sections to the actual account and funds flow. The table below uses FinCEN’s PATRIOT Act overview; implementation still depends on the current rules, any applicable order, and the covered institution’s program.

A section number explains the source of a control. It does not establish that every fintech feature falls within that control. Keep the applicability decision alongside the operational instruction.

Check the implementing rule and program#

For each relevant row, record the covered entity, customer or account type, applicable rule or order, and partner-program requirement. For Section 311, check the measure that actually applies to the named jurisdiction, institution, transaction class, or account type. For Section 312, distinguish foreign correspondent and covered private-banking relationships from ordinary cross-border merchant payments.

Update the map when an entity, corridor, account relationship, rule, or partner agreement changes. Escalate unresolved questions that could change a required control before the affected feature launches.

Keep each row operational#

Each row should work like a repeatable operating instruction: trigger, accountable owner, required artifact, escalation path. Clear role assignments can make retrieval and handoffs easier across product, legal, and partner teams. For accountability discipline, see The Role of the BSA/AML Compliance Officer in a U.S. FinTech Company.

A reviewer should be able to locate the governing artifact, confirm its version, and identify the next decision owner. Use source links and dated applicability notes rather than an old slide or an unattributed “per counsel” comment. Set retrieval targets that match the bank’s review needs.

Common failure modes to watch for: section tags spread through tickets before evidence is validated, and ownership gets assigned to team labels instead of named people. Both patterns can slow escalation, including partner-bank review cycles.

Run the pre-release checkpoint the same way every time#

Before each release cut, run one checkpoint: every row must include document ID, version date, accountable owner, and latest approval timestamp. That is the minimum for a current, attributable, reviewable section map.

Keep implementation material separate from legal authority. Secondary materials can support case-review design and operational handoffs, but they should not be the only basis for section mapping decisions.

Do not defer a gap that prevents compliance with a required control. Restrict the affected release until the control works or a lawful, authorized alternative applies. A missing administrative timestamp or stale label may instead call for documented remediation; assess its effect rather than treating every field defect as a legal prohibition.

Build a Defensible Account Opening Checkpoint#

For bank-partnered onboarding, use the bank CIP requirements, rather than a broker-dealer rule. The bank’s written, risk-based procedures govern required identifying information, verification, records, and what happens when it cannot form a reasonable belief that it knows the customer’s true identity. Verification may occur within a reasonable period after opening; the program defines permitted use while it is pending and when to refuse or close an account.

For a typical covered customer, required identifying information includes name, address, date of birth for an individual, and an identification number. A US person generally needs a TIN. A non-US person may use a permitted alternative such as a passport number and country of issuance. Do not demand an individual’s date of birth from a company as if it were a person.

Use explicit decision states#

Ambiguity here can create audit risk, so use clear states and avoid soft-approved language in product copy and ops notes.

Bind each state to specific permissions, not a vague activation flag. If the bank requires a check before money movement, keep that action unavailable until the check passes. A policy-permitted opening during verification is not unrestricted approval, and an internal exception cannot override a legal restriction.

Capture evidence like you will defend it later#

Do not store only the final status. Keep an evidence packet that shows why the status exists and when it should be revisited under your policy.

• What was collected: information used for identity verification.
• What was checked: identity-verification and list-check steps, execution time, and result.
• What was decided: decision owner, timestamp, and approval method, automated or human.
• When to recheck: policy-based trigger for refreshing time-bound evidence.

Sample recent decisions, including limited-use and rejected cases. Check the verification result, restrictions, deadline, reviewer, and follow-up outcome. The bank CIP also distinguishes retention clocks: identifying information generally remains for five years after account closure, while verification descriptions and results remain for five years after the record is made. Store what the rule and policy require, with controlled access.

Do not remove required controls to improve conversion. Improve guidance and reviewer capacity, and use only alternatives the bank has adopted lawfully. FinCEN’s 2025 TIN orders permit banks under the specified regulators to obtain TIN information from a third party while otherwise complying with CIP. Separately, the applied-for-TIN provision requires confirming the application and obtaining the TIN within a reasonable period under the bank’s procedures. Neither alternative means “TIN optional.”

Set SAR and EDD Escalation Rules Early#

Set SAR and EDD escalation rules before alert volume spikes, or case handling will drift and your audit trail will weaken. Name decision owners early, define required case-file artifacts, and keep the process consistent when speed pressure rises.

Use the covered institution’s SAR rules and current FinCEN guidance, including the October 2025 SAR FAQs. A fintech’s analyst may gather evidence for a bank, but the filing decision and responsibility must match the actual entity and approved program. Not every alert is a SAR, and suspicion need not be proof of a crime.

Tie SAR to observable behavior#

Escalate from observed activity and documented facts, not instinct or shorthand labels. For workflow ownership, keep identity-and-expected-use records distinct from monitoring-and-escalation records when activity no longer aligns with the baseline.

Keep ownership explicit in every escalated case: one accountable owner, one backup, and a file that records what was seen, when, by whom, and why the case was escalated or closed. At minimum, capture the alert or case ID, timestamp, owner, records reviewed, and rationale. If a second reviewer cannot reconstruct the decision later, the file is incomplete.

Avoid broad labels like "unusual" or "high risk" without tied evidence. Those labels do not show what contradicted expected activity or why the case moved forward, and they make threshold tuning harder under queue pressure.

If an exchange relies on 314(b), confirm eligibility, current participation, permitted purpose, safeguards, and the other party’s participation before sending. An exchange using another lawful route needs the controls for that route. Do not apply 314(b) as a blanket prerequisite to every external communication.

Start EDD with a documented handoff process#

Start EDD with a documented handoff, not chat fragments or memory. Keep the checklist simple. Common case-file items include:

• Risk question associated with the escalation
• Additional evidence requested and what was received
• Remaining contradictions or gaps
• Final decision and next review condition if the account stays active

The risk question can define scope. Evidence tracking should show both what was requested and what was actually received, including partial, stale, or missing responses. Contradictions and gaps should be stated directly, with clear treatment in the disposition.

If you need a repeatable operating model for higher volume, Enhanced Due Diligence in FinTech That Holds Up Under Real Case Volume goes deeper on evidence design and staffing tradeoffs.

Use current sharing guidance in the EDD handoff. Do not wait for every EDD question to be answered before escalating an urgent issue or meeting an applicable SAR deadline. Record outstanding evidence and arrange follow-up separately.

Keep reporting deadlines separate from the investigation sequence#

For routine cases, use triage, analyst review, an authorized disposition, retained records, and later rule tuning. Urgent escalation or mandatory restrictions may occur at the start. Track the applicable reporting deadline independently; additional evidence requests, EDD, or a 314(b) response do not reset it. Keep customer-facing messages separate from confidential SAR decisions.

Run recurring internal quality reviews to confirm similar fact patterns are handled consistently and closed files include required artifacts. When queues grow, do not weaken escalation gates. Increase reviewer capacity, improve triage quality, and reduce alert noise.

Sample closed files for case ID, owner, rationale, evidence log, disposition, retention location, and the basis for any external exchange. If a proposed 314(b) exchange fails its participation or purpose check, stop that sharing path and escalate. Continue other required controls and reporting on schedule, using an authorized alternative route where available.

That same documentation discipline matters in other compliance workflows. For a related onboarding and escalation topic, read What Is a Politically Exposed Person and How to Decide Next Steps.

Use Section 314(b) Without Creating Privacy Exposure#

Section 314(b) is a conditional sharing route. FinCEN’s June 2026 fact sheet permits information about suspected possible money laundering or terrorist activity, including qualifying fraud concerns, without requiring proof of specific laundered proceeds. Keep that purpose distinct from marketing, general commercial data exchange, or an unrestricted customer dossier.

This is a control choice to make now, not after policy changes. Bank-fintech data-transfer arrangements can be governed by different legal frameworks, and rule changes can create confusion or conflicting incentives. Your process should work under current conditions without assuming future expansion.

Set internal gates before sharing#

For an exchange relying on 314(b), check both the safe-harbor conditions and your internal controls:

Keep financial-crimes and privacy review in the same decision#

Give financial-crimes and privacy/security owners a shared escalation path, with urgent coverage and a record of the decision. A bank partnership does not remove the bank’s own applicable obligations. A foreign recipient or cross-border transfer may raise other legal requirements that 314(b) does not resolve.

Identity records can include sensitive personal data. Use the identification fields relevant to the customer type and approved program, rather than assuming every customer needs an SSN. Protect credentials and raw documents, limit access to authorized roles, and retain records under the applicable schedule.

Handle Cross-Border and Partner-Bank Risk Edges#

Treat higher-risk cross-border corridors as launch-gated programs, not speed-driven rollouts. If product, compliance, and partner-bank owners cannot document exposure labels, decision ownership, and escalation paths, pause launch.

CIP is one part of a bank’s BSA program. Review the actual institutions, accounts, counterparties and jurisdictions in the proposed flow. A cross-border payment is not automatically a correspondent or private-banking account, and a prior corridor’s approval does not settle a different program’s requirements.

Map exposure labels to real product paths#

Map who opens and maintains each account, who owns the funds at each step, and whether another institution obtains access through the relationship. Distinguish ordinary customer payments from a foreign institution’s correspondent relationship or a covered private-banking account.

Compare domestic and cross-border launch burden#

Domestic, lower-complexity onboarding may be simpler to coordinate. In practice, cross-border corridors can need more partner alignment, more review steps, and tighter escalation handling before and after go-live.

For higher-risk corridors, set one internal go-live gate as an operating control, not a legal standard:

• Documented controls by corridor and partner role, with named owners.
• Staffed escalation coverage, including backup decision owners.
• Tested incident-response process with written outcomes.
• Launch memo listing open legal or policy questions and closure owners.

Run a pre-launch verification and an early post-launch review. If pressure rises, add review capacity or narrow rollout scope instead of weakening the gate.

Bind Control Decisions to Product Permissions#

If a control does not change product behavior or leave a durable record, it can break down when pressure rises. Turn each compliance decision into a product state change with an audit trail to reduce the risk of funds moving while status is still unclear.

Keep sanctions states separate from ordinary review holds. An administrative hold may be cleared by an authorized reviewer under policy. OFAC-blocked property remains frozen unless a lawful authorization or exemption permits the action; internal sign-off alone does not release it. Rejection and blocking also have different meanings. Check the applicable program and OFAC licensing guidance before moving funds.

Preserve the decision history during retries and callbacks. Prevent duplicate actions, identify late or out-of-order events, and make permission changes through an authorized transition. Do not freeze an account forever in “approved”: new facts can require reopening a case or restricting activity. Append the new decision without overwriting the earlier record.

Before release, use a risk-based checkpoint: assess controls against your products, services, customers, entities, transactions, and geographic locations, and document gaps.

Use sanctions exposure as a governance trigger: identify the applicable prohibition, authorization, decision owner, and remediation. Do not build escalation policy around an old fixed penalty amount; statutory authority and the facts of the violation matter. Keep the current legal basis in the case record.

If a failed control creates a material risk of prohibited movement, restrict the affected action, reconcile the event chain, and escalate promptly. Resume only when the applicable legal conditions and authorized program checks are met. Do not reroute a blocked transaction through another provider.

Related: Money Transmission Modernization Act and State Licensing Decisions.

Keep an Audit-Ready Evidence Pack From Day One#

An audit-ready evidence pack turns your event trail into records your team can retrieve quickly and trust under pressure. If you cannot assemble a complete case file quickly, treat that as a control gap.

Define one minimum pack and use it consistently. Assign an owner for each evidence type and set internal retrieval targets your team can actually meet.

For a covered institution receiving Section 314(a) requests, document the designated contact, search owner, and positive-match response owner. FinCEN’s current fact sheet describes biweekly notifications and a two-week response window from the posting date; follow the instructions for the particular request.

Capture posting date, identifiers and search scope: accounts over the preceding 12 months and covered non-account transactions over the preceding six months. Record the search and any positive response. Under the stated process, no reply is required when there is no match; that does not mean the search can be skipped.

Treat Section 314(a) output as investigative lead information only, and document any subpoena or other legal-process follow-up separately.

Run retrieval drills on one recent case and one older case, verify chain completeness from intake through final reporting, and log retrieval time.

Consider a recurring attestation signed by ops and compliance leads confirming controls are active, not just documented. Missing logs are a red flag, and missing sign-off should trigger follow-up.

Keep a known-unknowns register for perimeter questions and pending legal interpretations. Track owner, next decision date, interim control, and impact if interpretation changes.

Execute a 30/60/90 Day Buildout for a Lean Team#

Treat this 30/60/90 plan as an internal execution cadence, not a statutory timer. Do not advance a phase until controls are validated in practice and evidence is retrievable without cleanup.

Before launch, resolve the affected program’s required controls even if this internal buildout is still in progress. Test CIP collection, verification timing and permissions, the applicable SAR handoff, and any 314(a) or voluntary 314(b) workflow the institution uses.

For the first phase, sample ordinary and exception-path onboarding. For the second, use a safe test case to distinguish a 314(a) search response from a voluntary 314(b) exchange and check urgent escalation coverage. In the third, retrieve recent and older records without backfilling, then track failures to closure.

Record pass or fail, owner, evidence location and remediation date for each sampled control. Restrict a launch that depends on a failed required control; address lower-impact defects under a documented plan. The internal phase schedule never extends a regulatory deadline.

Spot Red Flags Before They Become Expensive#

Costs can rise quickly when ownership is unclear, alerts keep aging, and sensitive data moves without a clean record. Treat those as immediate operating risks, not minor process issues. If you cannot name the owner and retrieve the evidence quickly, treat the control as not ready.

Monitoring needs reliable customer context and transaction records. Outdated tools, excessive false positives and fragmented data can leave reviewers unable to explain a disposition. Sample cases to check the alert’s relevance, evidence examined and next action. A risk label alone does not establish a reporting duty or a reason to block funds.

Name primary and backup owners#

Ownership is vague between teams. Fix it with an owner register for each key control: primary owner, backup owner, partner contact, and required evidence artifact. If ownership is shared but not explicit, treat it as unowned and escalate. A quick verification check is simple: pull one live case and confirm the reviewer can identify who owns the alert, who can approve the disposition, and where the supporting record lives without asking around in chat.

Without explicit ownership, work can sit in limbo, handoffs become verbal, and the record may not show whether a review was completed. Record the decision and next owner in the case file so a partner-bank reviewer can reconstruct the handoff.

Track alert age and decision quality#

Set case states and required notes for triage, escalation and closure. Prioritize urgent cases and approaching reporting deadlines, with backup coverage. A sampled case should show what triggered review, which transactions were examined, who made the decision, and when it was recorded.

False positives can consume reviewer capacity while substantive cases age. Review alert quality and closed-case rationale, including contrary evidence and unresolved questions. Reducing queue counts is useful only if the team still meets deadlines and makes supported decisions.

Protect shared information and case records#

Sensitive data is shared outside approved channels. Restrict sharing to approved channels and keep access logging complete, including who accessed what and when. Unlogged sharing is difficult to evidence during review, and it gets worse when teams start sending screenshots, exported files, or customer details outside the case record. If you rely on approved channels, make sure the case points to the exact location of the shared material and the approver tied to that action.

Where source-of-funds or counterparty questions remain unresolved, record the facts and the next step without circulating a complete customer file by default. Separate underlying transaction evidence from confidential SAR material and use the authorized sharing route.

Use a regular proof check: sample cases end to end and compare ownership, transaction context, disposition notes and access history. Include one case with a pending evidence request and one with an urgent escalation. The test is whether the original record explains the decision without retrospective additions.

Confirm the Operating Split Before Launch#

Before launch, confirm which entity owns each required control and how product permissions reflect its decisions. One routine approval, one limited-use case and one urgent escalation can expose gaps that a policy document misses.

Check required identification data, lawful collection alternatives, verification timing and record retention against the bank’s current CIP. Keep unresolved checks visible with owners, deadlines and permitted actions, rather than calling every pending account fully approved or automatically prohibited.

Document the bank’s oversight and the fintech’s execution duties under the actual agreement. A clear operating split helps reviewers locate records and reduces the chance that each party assumes the other handled a required action.

For Section 314(a), retain the search and response trail under the request’s instructions. For Section 314(b), retain participation checks, purpose, safeguards and the sharing record. Keep these workflows separate from SAR confidentiality and its specific exceptions.

When expanding to another country, bank or account model, revisit the rules and agreement for that affected flow. Resolve material applicability questions before enabling it, preserve lawful restrictions, and track administrative gaps under a named remediation owner.