Blog · By industry

AEO for fintech

Published 8 October 2026 · Updated 12 October 2026 · 9 min read

AEO for fintech
Photograph: Sajad Nori / unsplash

The short answer: AEO for fintech is the work of making sure an assistant can fetch your fee and rate pages, read the numbers on them without running JavaScript, tell which legal entity and which country the numbers apply to, and find the same numbers repeated somewhere it already trusts. The hard part is almost never writing. It is that money pages in this sector hide their figures behind components, redirects and legal controls that strip the number out of the answer.

Everything that makes a fintech site careful also makes it quiet. Rates live in a widget. Disclosures sit behind a modal. Compliance asks for data-nosnippet around the APR line. Each decision is defensible on its own, and together they produce a page an engine can reach but cannot quote.

The number is the citation, and the number is usually missing

An assistant answering "what does a payment gateway charge in India" or "which account has no foreign transaction fee" needs a figure it can attribute. If your page does not serve that figure in the HTML, a retrieval pass that does not run JavaScript has nothing of yours to quote, and the figure it does quote comes from wherever else it found one. We have not tested which engines render JavaScript before extracting, and some may; treat the no-JavaScript fetch below as a floor, not as a model of any particular engine.

We checked this on 8 October 2026. Seven fee and pricing pages from well known payment and brokerage companies were fetched with curl, no browser, no JavaScript execution, with ChatGPT's search user agent in the request. Four of the seven returned a percentage fee inside the server-rendered text. Three did not: one pricing URL redirected across to a different domain entirely, and two returned shells whose figures only appear once the client-side components mount. Seven pages is a sample, not a census, and it was chosen by hand rather than drawn at random, so it supports no industry rate at all. What it does show is that the failure is real and cheap to find: the run took four minutes, and you can repeat it on your own site before lunch.

The check itself:

`` curl -sL -A "Mozilla/5.0 (compatible; OAI-SearchBot/1.4)" yoursite.com/pricing \ | sed -e 's/<[^>]*>/ /g' | grep -oE '[0-9]+(\.[0-9]+)? ?%' ``

If nothing comes back, your rate does not exist as far as a retrieval pass is concerned. This is the fintech version of the generic access problem described in AEO by industry: where the work differs, and it is the one that costs the most here, because in this sector the number is the whole answer.

Blocking the wrong bot is not the same as blocking all of them

OpenAI documents four agents and they do different jobs. Three of them matter here; the fourth, OAI-AdsBot, visits only pages submitted as ads. GPTBot gathers content for model training. OAI-SearchBot is the one that supports ChatGPT search, and OpenAI's own documentation states that a site opted out of OAI-SearchBot will not be shown in ChatGPT search answers, while remaining eligible to appear as a navigational link. ChatGPT-User fetches a page when a user's action requires it, and is not used to decide what may appear in search.

Legal teams in regulated companies tend to hear "AI crawler" and ask for all of them to be disallowed. The outcome of that request is specific, at least for OpenAI's agents: by OpenAI's own description the training block does not affect whether you are shown in ChatGPT search, while the search block does. Other engines document their agents differently, so the per-agent decision has to be made per engine rather than once. Those lines belong in separate conversations.

The same day, 8 October 2026, we fetched robots.txt once from twenty four fintech domains we picked by hand across India, Europe, Brazil and the United States. That is a convenience sample of a single day, not a survey of the sector, so read the counts below as an illustration rather than a rate. Twenty two responded. Two of the twenty two named any AI user agent at all. One of those two allowed them explicitly; the other grouped thirteen agents together with an allow, and also published a content signals line setting search, ai-input and ai-train to yes. Cloudflare documents those three categories as separate permissions covering search indexing, real-time answers and model training. The other twenty are governed by whatever their wildcard group says, which in each case named no AI agent.

Silence in robots.txt tells you only that the file says nothing; it does not tell you what the edge actually serves, and a WAF rule shipped by an infrastructure team can make the decision where nobody looks for it. We did not test whether these domains in fact serve AI agents, only what their robots.txt declares.

Jurisdiction is a fact, and you have to publish it

"Best high yield savings account" has no single correct answer, because the correct answer depends on where the reader banks. Assistants resolve that ambiguity with whatever context they have. When your page does not state the country, the regulator, the licensed entity and the eligibility rule, those facts are not available to condition an answer on, and whatever the engine does instead is not something your page decided.

Write those facts into the page body, not only the footer disclaimer: the entity that holds the licence and its registration number, the market the rate applies to, and who may open the product. An engine that can read them has something to condition its answer on. One that cannot will reach for a source that does.

This is the same class of problem as the one in AEO for healthcare, with the compliance in mind, where the regulated claim and the quotable sentence have to be the same sentence. Fintech has it slightly easier, because the numbers are public by law.

Snippet controls do exactly what they say

Google's documentation on AI features states that there are no additional requirements to appear in AI Overviews or AI Mode, and no other special optimisations necessary. It does not say anything there about a schema type that helps. What the same page does document is the set of controls that restrict what gets shown: nosnippet, data-nosnippet, max-snippet and noindex.

Here is the failure mode those controls set up. Compliance wraps the APR table in data-nosnippet to stop the rate appearing without its disclosure, and by Google's documented behaviour that text is then excluded from the snippet. Your own page becomes the one source that is both accurate and unquotable, and the figure that gets used instead comes from somewhere that applied no such control. We have not measured how often this happens in the wild; it is a mechanism Google documents, not a frequency we counted.

The fix is not to remove the control. It is to publish a quotable sentence that carries the rate together with its condition, in plain text, outside the protected block, so the quotable unit is already compliant. "As of 8 October 2026, the rate is X per cent APR for customers in Y who meet Z" survives extraction with its caveats attached.

Markup that makes the numbers machine-readable

Google's own page says no additional requirements or special optimisations are needed to appear. Schema still earns its place for a different reason: it states your own numbers unambiguously, so the facts in your markup and the facts in your prose can be checked against each other.

schema.org/FinancialProduct carries annualPercentageRate, interestRate, feesAndCommissionsSpecification and termsOfService, with subtypes for LoanOrCredit, BankAccount, InvestmentOrDeposit, PaymentCard and CurrencyConversionService. Fill them from the same source of truth that renders the page. When marketing updates a rate in the CMS and the JSON-LD still says last quarter's figure, you have published two conflicting claims about your own product, and you no longer control which of them gets quoted. We have no measurement of how engines resolve that conflict.

Freshness, because rates move and answers do not

A repricing is a content event. Your page changes, your markup changes, the comparison tables elsewhere do not, and for some weeks the most repeated version of your rate is the old one. Treat the days after a rate change as a measurement window: re-run the same prompts, record which figure comes back, and note where it was attributed.

Pew Research Center's analysis of 68,879 Google searches made by 900 US adults, collected in March 2025 and published 22 July 2025, found users clicked a traditional result on 8 per cent of visits where an AI summary was shown, against 15 per cent of visits where it was not, with 1 per cent clicking a link inside the summary. That is US desktop behaviour on Google, not a fintech figure and not a measure of any other engine. For a product where the comparison happens before the application, being the named source in that summary matters more than the click you did not get.

Honest limits

Two numbers in this post come from our own fetches on 8 October 2026: seven fee pages and twenty four robots.txt files, both hand-picked, both a single day. They are illustrations of a failure, not estimates of how common it is, and a different set of domains would very likely give different counts. Our fetches also tell you only what a plain HTTP request returns, so where we say a figure was absent we mean absent from that response. We cannot observe what an engine renders or retrieves, and do not claim to. We have no reliable measure of how long a corrected rate takes to replace a stale one across review aggregators, regulator registers and personal finance publishers, because it varies by publisher and we have watched only a few dozen cases. And we cannot attribute a mention in an answer to a funded account, since these surfaces send almost no referrer data.

The sample audit report shows how the evidence is laid out for findings like these, prompt by prompt, so a disagreement can be settled by looking rather than arguing.

FAQ

Is AEO for fintech different from ordinary AEO? The method is the same and the failure points are not. Access, identity and corroboration apply everywhere. In fintech the content is numeric and regulated, which means the quotable unit is a figure plus a condition, and the usual controls around that figure are the thing most likely to remove you from the answer.

Should our robots.txt block AI crawlers? Decide per agent, not per category. A training block and a search block have different consequences. OpenAI's crawler documentation says a site opted out of OAI-SearchBot is not shown in ChatGPT search answers, while remaining eligible as a navigational link. Other engines document their own agents, so make the call per engine.

Do we need FinancialProduct schema to appear in AI Overviews? No. Google's AI features documentation states there are no additional requirements and no special optimisations needed to appear in AI Overviews or AI Mode. The markup is still worth having, because it pins your rates and fees to a machine-readable form that can be checked against the page.

Who should own this inside a fintech company? Somebody with authority over the fee pages and a working relationship with compliance and infrastructure. The split, and why marketing alone cannot carry it, is set out in Who owns AEO inside a company.

Is this just SEO with a new label? Partly, and the overlap is real. The differences are covered in AEO vs GEO vs SEO: what the three terms actually mean.

Sources

Related reading

AEO by industry: where the work differsAEO for healthcare, with the compliance in mindAEO vs GEO vs SEO: what the three terms actually meanWho owns AEO inside a companyAEO for legal servicesAEO for businesses with a service area