3+ Years of failing to fix this Defects

USBANKSUCKS.COM

Exposing the "Default account" bug that drains customer accounts while corporate "Assurance" teams look the other way.

The Video Evidence

Recorded demonstration showing the bug US Bank claims does not exist.

The Defect Logic

US Bank's ignores the explicitly chosen "Primary Account" during the new payee workflow.

1Multiple accounts exist (e.g., 'Checking' and 'Savings')
2User sets 'Checking' as Default Bill Pay account
3User creates a NEW Bill (Payee)
4System incorrectly selects 'Savings' (Lexically First) as the "pay from" account - this is NOT the default account.
5Result: Incorrect account is used, leading to balance-requirement fees.

The Corporate "Response"

DENIED

Internal Reference

CFPB Case #251206-26592082

Date Received

Dec 19, 2025

Forensic Analysis

Non Sequitur (Irrelevant Conclusion)Severity: High

The bank validates that the static 'default account' setting is correct, but uses this as proof to deny a bug report stating that the software dynamically ignores this setting during a specific workflow (creating a new payee). The evidence provided (the setting is correct) does not logically lead to the conclusion (the software works correctly).

Appeal to Ignorance (Argumentum ad Ignorantiam)Severity: Medium

The bank argues that because they were 'unable to find any past cases opened regarding the Bill Pay feature,' the reported defect does not exist. The absence of prior reports is not evidence that a software defect is absent.

Straw Man ArgumentSeverity: High

The bank addresses a simplified argument (checking if the default account is configured correctly) rather than the actual argument (the UI ignores the correct configuration during payee creation). This allows them to easily 'solve' the wrong problem while ignoring the complex bug.

Corporate GaslightingSeverity: High

By stating they 'confirmed your primary account... is set to the checking account' and concluding 'no bank error was found,' the response implies the customer's experience is invalid. It shifts the burden of the software failure onto the user's perception, ignoring the step-by-step technical reproduction provided.

Transcript Excerpt

"...we were unable to find any past cases opened regarding the Bill Pay feature and confirmed your primary account for Bill Pay is set to the checking account ending in 0854. ... regarding your request for a refund... no bank error was found. As a result, your request for any compensation is respectfully denied."

The Critical Failure

The response confirms the "Primary Account" setting but completely ignores the reported behavior: that the system UI overrides this setting during the specific "NEW PAYEE" workflow. By checking the static setting rather than the dynamic workflow, they conveniently avoid acknowledging the bug.

Are you experiencing this too?

Don't let them tell you it's "user error." If your default account settings are being ignored, file a formal complaint with the Consumer Financial Protection Bureau (CFPB) and reference this site.