A 314(a) positive match is an account the bank holds or has held in the past twelve months, or a transaction outside any account in the past six, that belongs to a person or business named on FinCEN's 314(a) list: the same subject, shown by identifiers such as a date of birth, a Social Security or employer number or an address, not merely a similar name. It is a rare event, well under one search in a thousand, and the hard part is the near-miss: the look-alike that a careless search reports and a strict one wrongly discards. Botminds' FinCEN 314(a) Requests is an agentic solution that lays each possible match out identifier by identifier, proposes confirm or rule out, and leaves the decision to a BSA analyst. Whether any search, ours included, catches true matches and rejects near-misses is something a bank can test with planted names.
The examples come from a fictional sample credit union, Norrell Federal Credit Union, and its sample list of 412 subjects. The test design later on the page is ours; the counts of matches and the timings come from FinCEN, linked where they appear.
Positive matches are rare, and each one costs minutes to hours
64,259
positive responses to 314(a) requests in fiscal 2025, from 13,887 institutions
0.07%
of record searches on federal requests in 2024 ended in a confirmed match (0.07–0.08%)
75
positive results per federal request, out of about 102,721 responses each
2 h 15
the upper end of FinCEN's estimate to verify an ambiguous match; a clear one takes 2 to 5 minutes
What is a 314(a) positive match?
A positive match is an account or transaction the bank can tie to a named subject, within the windows the rule sets. The regulation's test is that the bank "identifies an account or transaction identified with any individual, entity, or organization named in a request" (31 CFR 1010.520(b)(3)(ii)). The account can be current or closed within twelve months; the transaction must be outside an account and within six. A subject who was a customer three years ago and left is not a positive match, however perfect the identifiers.
The rule also tells the bank what it has to work with. Law enforcement must give FinCEN "enough specific identifiers, such as date of birth, address, and social security number, that would permit a financial institution to differentiate between common or similar names". The list is built for exactly the comparison an analyst makes: name against name, then identifier against identifier, until the record is either the subject or someone else.
How many 314(a) matches are reported? About 0.07% of searches
Few. In fiscal 2025, FinCEN's 1,065 requests named 6,883 subjects and drew 64,259 positive responses from 13,887 institutions, by FinCEN's Year in Review. Measured per search, the rate is tiny: for federal requests in calendar 2024, FinCEN's paperwork notice puts it at "between 0.07 and 0.08 percent", about 58,700 confirmed matches from 78.6 million record searches, or roughly 75 positives for each request sent to some 102,721 subject searches across institutions.
The rarity changes how a search should be judged. A tool that reports no match on 999 subjects out of 1,000 is right on almost all of them by doing nothing. The questions that matter are about the one: did the search find it under the name the customer actually uses, and did it keep the 30 look-alikes around it from either being reported or being thrown away without a reason?
On the sample list, 1,118 look-alikes narrowed to one match by day 4
What identifiers confirm a 314(a) match?
Two strong identifiers that agree, with nothing that conflicts, are what most procedures treat as a confirmation. Strong means hard to share by chance: a full date of birth, a Social Security number or its last four digits, an employer identification number, a passport or driver's licence number. Weaker ones, a city, a street name, a year of birth, support a match but rarely make one alone. A name, however unusual, is a reason to look, never a reason to report.
A name alone against a name with identifiers: what each lets an analyst say
A name match only: Someone with a similar name has, or had, a relationship with the bank.
A name with two strong identifiers: The same person or business, by facts that are hard to share by chance.
A name match only: Tomasz Wrobel, not a member, bought a $9,400.00 official check with cash; the list gives no identifier in common.
A name with two strong identifiers: D. Kenneth Whitcomb: date of birth and SSN last four match subject 147 exactly.
A name match only: Look closer: open the log entry, compare any identifier it holds, ask the requesting agency if needed.
A name with two strong identifiers: Confirm with reason codes; a second person approves the reply.
A name match only: Not until resolved. A name-only hit is not a match.
A name with two strong identifiers: Yes, within the two-week window.
A name match only: Never on a name alone; that is how true matches are lost.
A name with two strong identifiers: Not applicable: it goes to a person as a proposed confirm.
Close, differ, missing: reading a possible match
A possible match is easiest to judge when every identifier is laid out in a row with a verdict: match, close, differ or missing. Close is the category that hides true matches. A name that uses a middle name as the first, an address that appears in the customer's history rather than on the current record, a business suffix written differently: each is "close", and each is how real people appear in bank records.
Subject 147 on the sample list shows the pattern. The list gives WHITCOMB, Darnell Kenneth, also known as Ken Whitcomb, born February 11, 1979, SSN ending 4417, of Manchester, New Hampshire. The member is D. Kenneth Whitcomb of Concord. Date of birth and SSN last four match; the name is close (middle name as first); the address is close (Manchester until August 2019, in the address history); the list gives no other ID. Two match, two close, none differ, one missing: the match explainer proposes confirm at 0.96, and the analyst confirms with the reason codes for date of birth and SSN.
A possible match in FinCEN 314(a) Requests: the subject and the member face to face
What is a false positive 314(a) match, and what is a false negative?
A false positive is a record reported, or proposed, as the subject when it belongs to someone else; a false negative is the subject's real account or transaction that the search never surfaced or that someone discarded. A false positive is visible and fixable: an analyst sees the conflicting date of birth and rules it out. A false negative is invisible: nothing appears, nothing is reported, and the lead is lost without a trace.
Nobody publishes the rates, not even FinCEN. In its 2025 notice, FinCEN asked the industry "in what proportion do query results from a Respondent FI's automated search identify a potential match to a Section 314(a) Request subject that is ultimately determined to be a false positive?" and whether there are "ever instances where an automated search does not yield a match but a Respondent FI identifies this as a false negative". A bank that wants to know its own rates has to measure them, and the only practical way to measure a false negative is to plant a true match and see whether the search finds it.
In practice, FinCEN expects that financial institutions are unlikely to report a positive match without conducting at least some research.
FinCEN, 314(a) paperwork renewal notice, September 2025
Do you report partial 314(a) matches?
No: a bank reports a subject once it has identified an account or transaction with that subject, and resolves a partial match before deciding. Resolving can mean opening the account file or the imaged identity document, comparing an identifier the list gives with one the record holds, or asking. The rule lets a bank put questions about the scope or terms of a request to the contact the request names, whether at the law enforcement agency, FinCEN or the requesting Treasury component, and FinCEN's estimates allow for ambiguous matches that "necessitate communication with the Section 314(a) Request's LEA or FinCEN point of contact".
What a bank should not do is report a name-only hit to be safe. A positive response tells an investigator that the bank holds something on the subject; a wrong one sends the investigator, and possibly a subpoena, to an innocent customer. The opposite error is no safer. Ruling out a look-alike because the list's city differs from the customer's current address throws away the case where the subject moved. The rule-out reason should be a conflicting strong identifier, written down.
Test it with planted names: a seeded test for any 314(a) search
A planted-name test measures a search the way an examiner cannot: by knowing the answer in advance. The bank builds a test list of fictitious subjects, plants records for some of them in a copy of its systems under the variations real customers produce, adds near-misses that must not match, and runs the search blind. Because the subjects are invented, the test carries none of a real list's confidentiality limits and can be shared with a vendor, an auditor or a board committee.
A planted-name test set: twelve cases, and what each should produce
| Planted case | What it tests | Expected outcome |
|---|---|---|
| QUIMBY, Teodoro Ramon on the list; "Teodoro R. Quimby" in the core, same DOB and SSN | The plain case | Confirm |
| Same subject held as "T. Ramon Quimby" on a loan | Middle name used as first, initial only | Possible match; confirm on DOB and SSN |
| "Ted Quimby" on a safe deposit lease, SSN last four only | Nickname, partial identifier | Possible match; confirm or ask for information |
| VARGA-OKAFOR, Ilse on the list; "Ilse Okafor" in the core, same DOB, address in history | Hyphenated surname split | Possible match; confirm on DOB and address history |
| BRIGHTWATER PALLET CO LLC on the list; "Brightwater Pallet Company" with the same EIN | Business suffix and abbreviation | Confirm on EIN |
| A real-looking "Ilse Varga" with a different DOB and SSN | Near-miss that must not be reported | Set aside or ruled out, with the conflicting identifiers named |
| "T. Quimby", walk-in official check, cash, no identifiers in common with the list | A name with nothing to compare | Sent to a person; never confirmed or discarded automatically |
| Quimby's savings account closed 11 months before the posting | Closed account inside the window | Confirm |
| Quimby's checking account closed 13 months before the posting | Closed account outside the window | Not reported |
| Walk-in wire from Brightwater Pallet 5 months before the posting | Non-account transaction inside the window | Confirm |
| Walk-in wire from Brightwater Pallet 7 months before the posting | Non-account transaction outside the window | Not reported |
| DOB entered as 11/02 instead of 02/11, SSN matches | A keying error on one identifier | Possible match; a person decides |
Scoring the planted-name test: both kinds of error
Score the test in three columns, not one. Of the planted true matches, how many did the search surface as possible matches, and under which variant did any go missing? Of the near-misses and out-of-window records, how many were wrongly proposed, and how many were set aside with the right reason? And of the ambiguous cases, did each reach a person rather than being decided by a threshold? A search that finds every plant but proposes every near-miss for confirmation is as broken as one that is quiet.
Running a planted-name test on a 314(a) search, step by step
- Write the expected outcome before the run
For every planted case, the answer your written procedure requires; disagreements surface in the procedure, not the tool.
- Plant in a copy, in every source
Core, loans, boxes, wires, monetary instrument and cash logs: a test that only plants in the core only tests the core.
- Use the variations your customers produce
Middle names, initials, nicknames, split surnames, suffixes, keying errors, closed accounts near the window edge.
- Run blind, as a normal list
The people deciding should not know which subjects are planted, or the test measures attention, not method.
- Score misses, wrong proposals and routing separately
Recall on true plants, rejection of near-misses with a named reason, and every ambiguous case reaching a person.
- Re-run whenever the rules change
New name rules, a new threshold, a new source or a system migration: the last result no longer describes the search.
- Keep the test with the program records
The test list, the expected outcomes and the scored result are evidence that the search was tested, for audit and examination.
How FinCEN 314(a) Requests handles a possible match
FinCEN 314(a) Requests is built so that the two errors are visible. Its search builds name variants for every subject, so the middle-name and nickname cases surface; its set-aside rule removes a look-alike only where a date of birth or an SSN or EIN exists on both sides and every one conflicts, never on a name alone; and an analyst re-checks a sample of what was set aside on every list. Each possible match arrives as one sentence with every value cited, such as "Angela M. Russo, member since 2016: born 1990 against 1958 on the list; SSN last four differ", proposed for rule-out at 0.98.
The agents propose; they never confirm or rule out. A confirm proposal needs two strong identifiers, the analyst decides with reason codes, deciding against the agent's proposal asks for an override code, and the BSA Officer approves each reply. Name rules, the set-aside rule and the thresholds are versioned settings, and each change is tested on the year's lists before the BSA Officer approves it, which is where a planted-name test belongs. What happens after a confirm is set out in how to report a 314(a) match to FinCEN, and the receipts that prove the lists with no match in 314(a) record retention requirements.
FinCEN 314(a) Requests: each possible match written as one sentence, with a proposal
Questions people ask
What should you do with a 314(a) match?
Report it to FinCEN through the secure portal within the request's time frame, then decide internally whether the relationship needs a review. The FFIEC manual says a bank should not use a list appearance as the sole basis to open or keep an account, and is not required to file a SAR solely because a subject's accounts were found.
How do you confirm a 314(a) match?
Compare identifier by identifier: name, date of birth, Social Security or employer number, address and history, other IDs. Confirm when strong identifiers agree and none conflicts, record the reasons, and have a second person approve the reply; FinCEN's estimate allows up to two hours and fifteen minutes for a hard case.
Does a 314(a) match mean the customer is a criminal?
No. A list names people law enforcement reasonably suspects on credible evidence, and the FFIEC manual notes that lists are not updated or corrected if an investigation is dropped, a prosecution declined or a subject exonerated. FinCEN calls the program lead information only.
Can a business be matched on its EIN alone?
An employer identification number that matches exactly is a strong identifier, and with a name that agrees it is usually enough to confirm. Check for a conflicting address or a different business under a similar name before deciding, and record which identifiers the confirm rests on.
Should a confirmed subject be checked against earlier lists?
It helps an investigator and costs little. The sample credit union's screen shows, for each possible match, whether the person appeared on any earlier list that year; a subject named on several lists is worth noting in the internal referral, though not in the reply to FinCEN unless the request asks.