A valid Reg E denial reason is a finding, drawn from the bank's own records, that no error occurred: most often, for a claimed unauthorized transfer, that the customer made or authorized it. The denial reasons that fail are usually true facts doing a job they cannot do alone. A known device, a merchant the customer has used before, a recipient he has paid, a late report, a PIN he cannot account for, a missing affidavit, a careless habit: each has been rejected as the basis of a denial by the CFPB, by Federal Reserve examiners or by the regulation's own commentary. Botminds' First-Party Fraud Detection, software for investigators who handle likely false claims, strikes such reasons before a person sees a proposed denial. This page sets out the seven, in the regulators' words, and what holds instead.
Seven denial reasons that do not carry a denial, and what was said about each
1
2
3
4
5
6
7
What are valid reasons to deny a Reg E claim?
A denial is valid when a reasonable investigation shows no error occurred, and the bank can say why in writing. For a claimed unauthorized transfer, that usually means one of three findings in 12 CFR 1005.2(m): the customer started or authorized the transfer; someone he had given the card or phone to made it before he revoked their authority; or he, or someone acting in concert with him, made it "with fraudulent intent". For other errors, it means the transfer was correct as made.
What makes a finding valid is how it is built. The EFTA puts "the burden of proof is upon the financial institution to show that the electronic fund transfer was authorized", and Federal Reserve examiners suggest compliance teams sample denied claims and test whether each investigation actually met that burden (Consumer Compliance Outlook, 2025). That standard is rarely met by one fact. It is met when several independent records point the same way and the signs of a genuine claim have been looked for and not found.
Grounds that can hold, and the records that carry them
| Ground for the finding | Rule | Records that typically carry it |
|---|---|---|
| The customer made or authorized the transfer | 1005.2(m); burden on the bank, 15 U.S.C. 1693g(b) | Registered device and sign-in with no takeover signs, network or location, chip-and-PIN or biometric use, the customer’s own pattern with the recipient |
| A person he gave the access device to made it, before any revocation | 1005.2(m)(1); comment 2(m)-2 | The customer’s own account of who had the card or phone, the date of any notice to the bank |
| Fraudulent intent by the customer or someone acting in concert | 1005.2(m)(2) | All of the above, plus records that contradict each thing the customer said |
| The transfer was correct as made | 1005.11(a) | Payment instructions, settlement and the customer’s own authorization of that amount |
"The customer has done business with this merchant before"
A customer's earlier purchases from a merchant are not, alone, evidence that he made the disputed one. That is the finding the CFPB published in 2021: examiners found institutions "denied claims solely because the consumers had previously conducted business with a merchant", and one closed investigations and told consumers to take the claim to the merchant first (Supervisory Highlights 24). The CFPB's EFT FAQs record the same failure in a 2019 enforcement action, where a bank "summarily denied error disputes if consumers had prior transactions with the same merchant" without considering what the consumer said.
The reason the shortcut fails is simple. A fraudster with stolen card details buys where the details work, and a merchant the cardholder uses is one place they work. The history is worth reading as context; it cannot stand in for the device, location and authentication records that say who made this purchase.
"The customer has paid this recipient before"
The P2P version of the same shortcut was cited in the CFPB's January 2025 order against Block, Inc., which runs Cash App. Where a consumer "had previously transacted with the recipient", the company would at times deny refunds, "only relying on the presence of this factor in determining that these transactions were authorized." Block consented without admitting or denying the findings.
Earlier payments to a recipient are strong context. In the fictional sample claim used across this series, the customer had paid the recipient 14 times since March 2025, each time between $680 and $760, with the memo "rent split". But a fraudster inside an account can send money to anyone in its payee list, so the history only becomes evidence of authorization alongside records that show who was in the account. The sample bank added "prior dealings with the recipient, alone" to its list of reasons that may never carry a denial.
"The payment came from a device we know"
A device the bank knows is the most tempting single reason, and the same order rejected it. The CFPB found that the company "would at times deny requests for refunds, only relying on the fact that the claimed unauthorized activity was from a device that “regularly accesses the account” or a “known device,” and on that basis incorrectly concluded that the transactions were authorized."
A known device rules out one kind of fraud, a stranger on new hardware, and leaves others open: remote access tools, a phone taken or borrowed in the household, a session hijacked after a scam call. That is why the sample's agents look for the genuine claim before proposing a denial, and why the stated limit sits beside the proposal: Face ID cannot rule out someone in the customer's household holding his phone.
One returned denial, one proposed denial, two payments
"He cannot explain how his PIN was compromised"
The customer does not have to solve the fraud. In 2014 the CFPB reported a violation where, despite the consumer providing "details of the theft of a debit card and subsequent unauthorized PIN-based transfers", the claim "was denied based on the fact that the customer was unable to explain how his PIN was compromised." The same report says a bank "cannot deny an error claim on the basis of a consumer failing to provide additional information".
The burden runs the other way. If the bank believes the PIN was not compromised, its records must show it: the card read chip and PIN at the customer's usual ATM, with no lost-card report, no earlier failed PIN attempts and no other unexplained use. The customer's inability to explain a theft is not a record.
Can a bank require a police report or an affidavit first?
No. It may ask for a signed statement, but it cannot wait for one before investigating or deny because one never came. The commentary says a bank may not hold up the start or the end of an investigation while it waits for the statement (see Reg E training), and in 2022 the CFPB reported: "Where consumers did not submit an affidavit, the institutions denied the error claims without investigating the merits of the error claims" (Supervisory Highlights 26). It added that a bank "cannot require a consumer to file a police report or other documentation as a condition of initiating or completing an error investigation."
Federal Reserve examiners list the same family of conditions: asking a consumer to visit a branch, to try the merchant first, to submit "a notarized affidavit", or saying "the consumer must file a police report" (Consumer Compliance Outlook, 2025). The sample's intake agent is built so that it can neither reject a claim nor ask for a police report.
Can a bank deny a claim for negligence?
No. The Official Interpretation is explicit: "Negligence by the consumer cannot be used as the basis for imposing greater liability than is permissible under Regulation E", and behaviour such as "writing the PIN on a debit card or on a piece of paper kept with the card, does not affect the consumer's liability for unauthorized transfers" (comment 6(b)-2). The CFPB repeats it in its EFT FAQs.
Sharing is different from carelessness. A customer who hands his card and PIN to a relative has furnished an access device, and that person's transfers fall outside the definition of unauthorized until he tells the bank otherwise (1005.2(m)(1)). A customer tricked into reading a code to a caller posing as the bank has not, in the CFPB's reading, furnished anything. The investigator's question is never "was he careless?" but "did he give this person authority?"
Can a bank deny a Reg E claim for late reporting?
Not the whole claim, in most cases. Reporting late changes the customer's liability tier under 12 CFR 1005.6(b), $50, $500 or more, and the bank has to establish that the later losses would not have happened with a timely report. Federal Reserve examiners warn that some institutions wrongly treat the 60-day notice window as the end of the liability limits, which in fact still cover transfers made before the 61st day (Consumer Compliance Outlook, 2025). Extended travel or hospitalisation extends the windows.
The sample shows how easily lateness creeps into a denial. In its September review, the agents found that one fintech partner's customers reported later than the bank's own, a median of 9 days against 3, and that one denial of $164.00 rested on reporting time. Without it the evidence was moderate, so the claim was reopened and payment proposed. The arithmetic of the tiers, with the regulation's own worked examples and a calculator, is in the Reg E liability calculator.
Reasons struck from proposed denials before a person saw them, one month
The month's review: the outlier, the reasons struck, the overrides
Can a bank deny a claim because of prior disputes?
Not on that basis. We found no published regulator finding on earlier claims as such, but the rule leaves little room: the investigation concerns this transfer, the burden is to show this transfer was authorized, and a list of earlier claims says nothing about who started it. The commentary's list of what an investigation may review is about the account and the transfer, such as the account's recent transaction history and where the payee sits relative to the customer's home, not about the customer's dispute history.
Earlier claims can also mislead. In the sample customer's history, one of his three earlier claims was plainly genuine: he had cancelled the payment in writing a month before it was taken. A denial that leaned on "four claims in six months" would have counted that one against him. The sample bank keeps earlier claims on the screen as context and for a possible referral, never in a reason or a letter; it was the most common reason its fairness review struck, 14 times in a month.
Before anyone signs a first-party denial
- Name the ground in Reg E terms.
Authorized by the customer, furnished access device before revocation, or fraudulent intent. Not "suspicious".
- List the records that carry it, each with its source.
If one record is doing all the work, it is probably one of the seven reasons above.
- Show the search for a genuine claim.
New device, reset, failed sign-ins, scam contact, SIM change, lost phone: each with a result.
- Strike the reasons that cannot carry it.
Earlier claims, prior dealings alone, negligence, reporting time inside the rule, a missing police report or affidavit.
- State what the records cannot rule out.
A household member with the phone, a shared network. Ask the customer before deciding.
- Compare with similar claims.
A denial that differs from how similar claims were decided needs a reason that can be written down.
- Have a second person check it.
Someone who did not prepare the decision, reading the same records.
What the denial letter has to say instead
The letter states the finding and the evidence, not the suspicion. Regulation E requires a written explanation of the findings and a note of the customer's right to the documents the bank relied on (12 CFR 1005.11(d)(1)), and the 2014 examination report cited standard letters that left the right to documents out. In the sample, the letter lists four findings in plain words and never mentions earlier claims or fraud. What a no-error file has to contain, letter included, is in Reg E documentation; a customer's view of a denied card claim is in why card disputes get denied.
Questions people ask
Is "authorized by the customer" a valid denial reason?
Yes, when the bank's records show it. The EFTA puts the burden on the bank to show the transfer was authorized, so the letter has to explain the findings, such as the device, sign-in and location records, and tell the customer he can ask for the documents relied on.
Can a bank deny a Reg E claim because the customer shared his PIN?
It depends who he shared it with and why. A customer who gave his card and PIN to a relative furnished an access device, so that person's transfers are not unauthorized until he revokes their authority. Writing the PIN on the card is negligence, which cannot increase his liability, and a PIN read to a caller posing as the bank was obtained by fraud, which makes the transfers unauthorized.
What happens to denials that rested on a forbidden reason?
They have to be corrected, and examiners look for all of them, not only the one that surfaced. In its Summer 2021 report the CFPB described institutions finding and repaying every consumer whose claim had been wrongly denied because of earlier dealings with the merchant.
Can a customer challenge a Reg E denial?
He can ask for the documents the bank relied on, which it must provide in an understandable form, and he can bring new information. Once the bank has fully complied with 12 CFR 1005.11 he cannot reassert the same error under the regulation, but he can complain to the bank or its regulator.
Can a bank deny a claim because the customer didn't file a police report?
No. The CFPB's EFT FAQs answer the question directly: a bank must begin its investigation promptly on an oral or written notice and may not hold it up while waiting for anything more from the customer.