Deposits · August 2026
Fifth Third's site returns the same error page for every request
An AI agent ran five ordinary deposits tasks on the public pages of Fifth Third Bank and scored what each page delivered.
Run 6 August 2026 · five tasks · public pages, logged out · Bank
15/100
Mystery Agent score
Deposits · rank 24 of 25
Savings rate
15Automated reader declined
Checking comparison
15Automated reader declined
Fee schedule
15Automated reader declined
Routing number
15Automated reader declined
Application page
15Automated reader declined
Summary
- Fifth Third's error page names a real customer service phone number and a reference number a caller can quote directly.
- The branch and ATM directory on a sibling subdomain loaded with real, distinct content, showing one Fifth Third property serving pages normally.
- Investigating why the main domain serves one static error page for every path would open its rate and fee content to readers.
Task by task
Each task is scored out of 100 on completion, answer quality and how directly the answer was reached. Each note describes what the page delivered, with a link to the page the answer was found on.
Task 01Savings rateAutomated reader declined15 out of 100
An automated reader requested the homepage and a savings account page and received an identical 16,105 byte fallback page on both, with no rate, APY, or product content of any kind in the response.
Task 02Checking comparisonAutomated reader declined15 out of 100
Requesting the checking account page, an automated reader received the same site-wide fallback file rather than product content, so no fee, waiver term, or differentiator text could be read for any checking tier.
Task 03Fee scheduleAutomated reader declined15 out of 100
The guessed fee schedule URL returned the identical 16,105 byte fallback file served for every other path tested, leaving the automated reader with fallback text rather than schedule figures in this run.
Task 04Routing numberAutomated reader declined15 out of 100
A guessed routing number page returned the same fallback page as every other path, so no routing digits appeared anywhere in the text the automated reader received.
Task 05Application pageAutomated reader declined15 out of 100
A plain request to the application page returned 16,105 bytes and 386 visible characters, all of it generic error wording naming a support phone number and a reference number, with zero input fields present.
Every path on the main site returns the same message: Oops, Something went wrong, alongside a real support phone number.
The application page
What the account opening page states to a reader that runs no scripts.
16,105Bytes delivered
386Characters of visible text
0Form fields in the first response
After scripts runWhat an applicant needs
Strengths and opportunities
What is working
- The fallback page itself is a genuine, well-formed piece of customer service: it names a real support phone number (1-800-972-3030) and gives a reference number an agent or a human caller could quote back to a live representative.
- The separate locations.53.com property, which handles branch and ATM search, loaded cleanly and quickly with real content, showing that Fifth Third runs at least one public page that serves distinct, working HTML to this kind of request.
- The consistent, byte-identical response across every path is itself informative rather than random breakage. A single predictable fallback is easier for an operations team to diagnose and fix than scattered, inconsistent failures would be.
Opportunities
- Publishing a real llms.txt file at www.53.com/llms.txt, distinct from the general error fallback, would give agents a documented, sanctioned entry point instead of a guessed one.
- Investigating why www.53.com and 53.com return a static AkamaiNetStorage error page for every path, including robots.txt and sitemap.xml, is a near-term opportunity: whatever edge rule or origin issue is producing this fallback is currently withholding rate pages, fee schedules, routing numbers, and the application application page from any automated reader, not just this one.
- Once the underlying page-serving issue is resolved, mirroring the plain-HTML approach used by locations.53.com for savings rates, checking comparisons, and the fee schedule would let deposit answers travel the same reliable path that branch search content already does.
Access
The edge policy declined the automated reader on some paths, and that response is recorded as delivered. Publishing an llms.txt file would give agent traffic a documented entry point.
Back to the deposits leaderboard · Read the report · How the study works
