FinCEN 314(a) information sharing: what to search, what to report, what to record

A FinCEN 314(a) information request arrives without warning and it carries a deadline. A federal law enforcement agency asks FinCEN to canvass financial institutions about a named subject, FinCEN distributes the subject list, and every institution that receives it searches its records and answers. The information sharing programme created by section 314 of the USA PATRIOT Act is one of the few obligations that reaches every part of a payment firm at once: onboarding files, the transaction store, and in a cross-border business, the settlement leg itself.

This article covers how a 314(a) request works, what a firm must search and report, how voluntary 314(b) sharing differs, what changes when the settlement leg runs on a public blockchain, and the evidence a reviewer expects to find. It is general information, not legal advice.

What is a FinCEN 314(a) information request?

Section 314(a) of the USA PATRIOT Act, implemented at 31 CFR 1010.520, lets a federal law enforcement agency ask FinCEN to canvass financial institutions for records on a subject it certifies is suspected of money laundering or terrorist financing. FinCEN batches those inquiries and sends them through its secure system to a contact each institution has designated. The institution searches its records. If it finds a match, it reports the fact of the match to FinCEN, and the requesting agency follows up directly with legal process.

Two features surprise firms that have not handled one. First, the request is not a subpoena and does not compel the production of documents. It asks whether a relationship or a transaction exists. Second, the request is confidential. The firm may not tell the subject, and may not use the list for purposes the rule does not permit, which are limited to responding, assessing its own risk and deciding whether to file a suspicious activity report.

The request is also not a sanctions listing. A name on a 314(a) list is not blocked property. Freezing a balance or closing an account because a name appeared is a mistake, and it tips off the subject that the enquiry exists.

Which firms must respond, and what must they search?

The obligation reaches banks, credit unions and money services businesses, among other categories of financial institution. Scope matters more than size. 31 CFR 1010.520 requires a search of current accounts, any account maintained during the preceding 12 months, and any transaction conducted outside an account during the preceding 6 months, with a response due within 14 days of the date the request was transmitted.

That last category is the one cross-border payment firms underestimate. A business client that sends a payment without holding a balance has conducted a transaction outside an account. If the sender, the beneficiary, a beneficial owner or a party named in the instruction appears on the list, that is a match. A firm whose index covers only its own customer table, and not counterparty and beneficiary records, will report nothing in a case where a match existed.

Negative results are not reported. Only matches go back, which means an empty response leaves no trace in the system and carries no evidence of its own. The search still has to be documented inside the firm, because that record is the only thing a reviewer can test.

What does a positive match actually require you to do?

The response itself takes minutes. The work sits around it. The sequence below is what a reviewer expects to see in a firm that handles these requests well, and each step is written so that it leaves evidence.

• Receive and log every request. Record the transmission date, who retrieved it and the due date, so the 14 day clock is owned by a named person rather than noticed late.
• Search the full scope. Query customers, beneficiaries, counterparties, authorised signatories and beneficial owners, across both accounts and standalone transactions.
• Use matching that tolerates variation. Exact string matching misses transliterations, reversed name order and shortened corporate names, so apply the same fuzzy logic the screening engine already uses.
• Review candidate hits before reporting. A reviewer confirms or clears each one with a written reason, so the response is a decision rather than a dump of near matches.
• Report only confirmed matches, and only to FinCEN. Do not contact the subject, and do not close, freeze or restrict anything because a name appeared on a list.
• Decide separately whether a suspicious activity report is warranted. A match is one factor to weigh with the rest of the file, neither a reason on its own nor a reason to wait.
• Keep the evidence. Retain the search parameters, the systems queried, the result set, the reviewer decisions and the response, under the same retention rule as other records in the AML programme.

A 314(a) request tests two things at once: whether a firm can find a name anywhere in its records, and whether it can show, a year later, exactly how it looked.

How does 314(b) information sharing differ from a 314(a) response?

Section 314(b) runs the other way. It is voluntary, it operates between financial institutions rather than with the government, and it exists so that two firms each holding half of a pattern can compare what they see. A firm that wants to use it files a notice with FinCEN, renews that notice annually, and may then share information with another institution that has filed its own, within the limits the rule sets.

Those limits are narrow. Sharing is permitted for the purpose of identifying and reporting activities that may involve money laundering or terrorist financing. FinCEN's 2020 fact sheet on section 314(b) confirmed that a participant may share even where it has not identified the specific underlying crime, and that an entity formed by several institutions may carry out sharing on their behalf. The safe harbour does not extend to sharing for unrelated commercial purposes, or to sharing with a counterparty that has no notice on file.

In practice that means two checks before any conversation. Verify that the other institution is a current participant, and confirm the purpose in writing. For a cross-border payment firm the value is high, because the sending institution, the correspondent and the payout partner each hold a different fragment of the same payment, and no one of them sees the whole chain.

What does a stablecoin settlement leg add to the search?

Nothing in section 314 mentions blockchains, and that is the point. The duty is to search the firm's records for a named subject. If part of the payment settled as a stablecoin transfer, the records of that transfer are the firm's records, and so are the wallet addresses it touched.

Three consequences follow. Wallet addresses belong in the searchable index next to names and account numbers, because an enquiry may identify a subject by an address. A stablecoin leg usually sits in the transactions conducted outside an account category, which carries the shorter lookback, so the index has to reach it. And the ledger makes the trail checkable: once a payment is identified, the record of where the value moved is permanent and timestamped, which shortens the follow up when the agency serves legal process.

Travel Rule data helps without discharging the duty. The originator and beneficiary details carried in an IVMS101 payload are a good source for a name search, and our guide to IVMS101 sets out what that payload holds. It is a separate obligation, and nothing identifying should ever be written to a public chain to make internal searching easier.

What evidence does an examiner ask for?

The file is narrow and predictable, which makes it easy to keep and obvious when missing. Expect to be asked for the point of contact registered with FinCEN and the record of who holds that role now. Expect the log of requests received, with transmission dates and due dates. Expect, for a sample of requests, the search parameters used, the systems queried, the candidate hits, the decision on each and the response sent.

Expect the written procedure, including the matching standard and the path from a confirmed match to the suspicious activity report decision. Expect evidence that the people who run the search have been trained on it. And if the firm participates in 314(b), expect a current notice and a record of each sharing event showing that the counterparty was verified first.

Two failures are common, and they are opposites. A firm searches only its customer table, so it answers honestly and still misses a match sitting in the beneficiary records. Or it searches properly and retains nothing, so a year later the work is invisible and therefore, to a reviewer, did not happen. One owner, one documented search and one retained result fix both.

Where StableNet fits

StableNet, built by SpendTheBits, is a cross-border B2B payment and settlement platform for banks, credit unions, licensed money service businesses, exchange houses and remittance fintechs. Settlement runs in regulated stablecoins such as USDC and USDT on public blockchains and completes in minutes with on-chain auditability, and because the platform is ISO 20022 native, with pacs.008 customer credit transfers, pacs.009 interbank legs, pacs.002 status reports and pacs.004 returns tracked end to end by UETR, the parties to a payment and the settlement that followed sit in one searchable record rather than in separate systems. KYB and KYC onboarding, KYT, sanctions and PEP screening, FATF Travel Rule data in IVMS101 form, a compliance workbench and a tamper-evident audit trail sit alongside the payments themselves, so a name search can reach customers, counterparties, beneficiaries and wallet addresses together, and the result can be evidenced afterwards.