Should a bank or regulated financial site publish an llms.txt file?

Yes, but its job is narrower than on a SaaS site. A financial site does not need the file to sell anything — it needs it so an assistant answering "what does this bank charge for a wire", "who do I contact about fraud" or "does this broker support Roth IRA transfers" lands on the page you would have handed a compliance reviewer, instead of a third-party comparison table. In our October 6, 2026 check of 19 financial domains, only four served a real plain-text file — Stripe, PayPal, Coinbase and Plaid. The regulated answer is: publish the file, keep every number behind a link, and let the linked page carry the current rate, fee and disclosure language.

What must never appear in a bank's llms.txt file?

Anything account-specific, credential-adjacent or promotional. Keep out online-banking and login routes, account-opening funnels with tracking parameters, customer identifiers or support case numbers, internal fraud, KYC or risk-scoring rules, employee or branch-operations runbooks, unapproved marketing claims, and any rate, APY, APR, fee or bonus figure that is not frozen for a year. Rates and promotions have their own disclosure regime and their own review cycle; an index file does not. The test is the same one you would apply to a public web page: if a reviewer would have to approve the sentence before it could be published, it does not belong in a file that ships on every build.

Should the file list every product page on a large financial site?

No — list the entry point for each product family and let the linked hub fan out. A bank can have thousands of product, rate and help pages; a curated file names the checking, savings, card, mortgage, investing and small-business hubs plus the fee schedule and disclosures index. Where a section genuinely needs depth, use a subpath file: a root file for the public site, /docs/llms.txt for developer documentation, and a separate file for investor relations if it is a distinct audience. Because a file covers the URLs under its own path and the most specific file wins, Plaid runs plaid.com/llms.txt next to plaid.com/docs/llms.txt and plaid.com/docs/llms-full.txt.

Finance · October 2026

llms.txt for Banks, Brokerages and Fintech

Money is the vertical where a wrong number costs the most and where the compliance team has the final word on every sentence. Here is what 19 financial domains serve today, the six buckets a regulated site actually needs, and the one rule that keeps the file out of trouble: state what is durable, link what changes.

What 19 Financial Hosts Serve Today

We fetched /llms.txt from this server on October 6, 2026 with a generic user agent and redirect following, across payments companies, retail banks, brokerages, a data vendor and consumer finance publishers.

Response	Count	Examples
`200`, `text/plain` — a real file	4	stripe.com (69.9 KB), paypal.com (40.1 KB), coinbase.com (7.3 KB after a 302 to `www`), plaid.com (353.4 KB)
`200`, but no file behind it	2	schwab.com — 501 bytes of `text/html` holding an access-denied notice and a reference number; barclays.co.uk — 302.2 KB of HTML after three redirects
`403` or `400` (edge block)	4	revolut.com (872.8 KB HTML error page), fidelity.com and robinhood.com (both an `AccessDenied` XML body from object storage), ramseysolutions.com (`400`, empty body)
`404`	9	chase.com, bankofamerica.com, wellsfargo.com, vanguard.com, hsbc.com, wise.com, monzo.com, nerdwallet.com, morningstar.com — the last one answering `404` with `Content-Type: text/plain` and a zero-byte body

Two patterns are worth naming. First, the edge block is now the most common non-404 response: four hosts refused the request outright, and a bot-allowlist rule that admits a named crawler but not a generic one can leave a published file unreachable by exactly the clients it was written for. Second, a 200 proves nothing — Schwab's 501-byte HTML notice is indistinguishable from success to a status checker and useless to a model. Read the body, not the code.

Why Regulated Sites Hesitate

On most sites the fear is wasted effort. On a financial site the fear is a claim. A rate, an APY, a bonus, a fee waiver or the phrase "bank-grade security" all carry a review obligation, and an index file is easy to edit outside that process. PayPal's live file shows how one company handled it: a version header (Last Updated: February 28, 2026, Version: 1.0.4) and a disclaimer block stating that the file follows "a proposed standard for machine-readable LLM guidance" and that not every product is available in every country, with a note to swap the /us/ path segment for a local one. That is the honest middle ground: date the file, scope it, and describe rather than sell.

The Six Buckets a Financial Site Needs

Products and services — one hub link per family: checking and savings, credit cards, mortgages, loans, small business, wealth and investing.
Rates, fees and disclosures — the fee schedule, the rate page and the terms index, linked, never transcribed.
Security and fraud — how to report fraud, how to freeze a card, how the bank contacts customers. This is the highest-intent question an assistant gets about a bank, and it is the answer you most want to control.
Regulatory and investor relations — annual report, filings, ESG or Pillar 3 disclosures, privacy notice. For a listed company this is a separate audience and often a separate file.
Help and education — help centre, fee explanations, financial literacy hub, complaints procedure.
Developer and partner docs — API references, OpenAPI specs, sandbox and status page, usually as a subpath file.

The structure itself is the same one a SaaS file uses. What changes is the ordering: security and disclosures move up, pricing copy moves out.

Numbers That Rot

Every figure with a review cycle behind it should be a link. That covers interest rates and APYs, APRs, monthly fees and minimum balances, sign-up bonuses, transfer limits, branch and ATM counts, credit-card welcome offers and ratings. A curated index that names "3.75% APY" is wrong on the next rate decision and, worse, quotable in a customer conversation with no disclosure attached. Keep the durable facts — what the product is, who it is for, which regulator supervises the entity, which country the entity is licensed in — and link the rest. The general exclusion checklist covers the credential, staging and internal-path categories that apply here too.

Root File, Subpath Files, and the Size Question

Coinbase points its file at developer documentation on a different host and says so in the summary; Plaid runs a root file plus documentation files for two separate product lines. If your site is both a bank and a platform, that split is the right shape:

# Site root — public products, help, security and disclosures
https://example.com/llms.txt

# Developer documentation — API reference, guides, sandbox
https://example.com/docs/llms.txt
https://example.com/docs/llms-full.txt

# Optional: investor relations, if it is a distinct audience
https://example.com/ir/llms.txt

Size is the other regulated-site problem, because product catalogues are large and exports are cheap. Plaid's 353.4 KB root file is closer to a documentation dump than an index — the link titles read like Index.html and the page list is machine-generated. Curated files in this set sit between 7 KB and 70 KB. If yours is heading past six figures, the size and token budget guide gives the split decisions; and a file that is large is also the one where content type and caching matter most.

Verify Delivery, Not Just Format

Financial sites sit behind CDNs, WAFs and bot rules, which is why the checks that decide the outcome are delivery checks. Run all three:

# 1. Is it a file, or is a gateway answering with HTML?
curl -sI https://example.com/llms.txt | grep -iE "^(HTTP|content-type|location)"
curl -s https://example.com/llms.txt | head -1     # should be: # Example Bank

# 2. Does the status survive a crawler user agent? (403 to you may be 200 for them)
curl -s -o /dev/null -w "%{http_code} %{content_type} %{size_download}\n" \
  -A "OAI-SearchBot" https://example.com/llms.txt

# 3. Every listed URL should answer 200 without a redirect chain
curl -s https://example.com/llms.txt | grep -oE "https://[^)]+" | while read u; do
  printf "%s %s\n" "$(curl -s -o /dev/null -w '%{http_code}' -L "$u")" "$u"
done | grep -v "^200"

Then score the structure in the llms.txt checker — links, summary slot, duplicate targets — and build the first draft from your product and help sitemaps with the generator. Deleting the rate tables, offer pages and login routes the import will happily pull in is the part that protects you.

Status codes, content types, byte sizes and file contents referenced were captured from this server on October 6, 2026 using a generic user agent and redirect following. Edge bot rules and published files change without notice, so re-check your own paths rather than treating this table as current configuration for any organization named. A 403, a 404 or a 200 tells you nothing about the body until you read it.