Schema Markup for Financial Websites: Which Types to Use and Why

By Yamm Labs · Updated October 2026 · 13 min read

The ticket in this sprint says “Add FAQ schema to all product pages”, and it was copied from an SEO audit written three years ago. Your developer has the plugin ready. Before anyone merges it, look at what Google shows today: it cut FAQ rich results back to a narrow set of government and health sites in August 2023, and it retired the feature in May 2026. Schema markup for financial websites still earns its keep, but the useful work has moved to entity, product and date markup that machines use to confirm the facts on your page.

What you need before you start on schema markup

Schema markup is code in a page that labels its facts in a shared vocabulary, schema.org, so a search engine or an AI assistant can read “this number is the annual percentage rate” without guessing. Google lists JSON-LD as its recommended format in its general structured data guidelines. JSON-LD is a block of script that sits apart from the visible layout, and this guide assumes it throughout.

Set expectations with leadership early. Google’s guidance on AI features in Search says there is no special schema.org structured data you need to add to appear in AI Overviews or AI Mode. Markup does not buy a place in an AI answer. It helps a machine confirm that the rate, name and date it found in your text are the ones you meant. For a bank or an insurer, that matters most where a wrong number turns into a complaint or a compliance query.

Collect five inputs before a developer writes a line:

1. An owner in digital or SEO who maintains the markup templates and runs the audit.
2. A compliance reviewer who already approves product page copy and will approve the markup values as well.
3. The registered legal name of each entity, exactly as it appears on regulator filings and approved advertisements, plus the trade name and the logo file.
4. A product register: every live product page, the CMS field that holds each rate and fee, and the date each rate took effect.
5. Access to the CMS templates, Google Search Console and a staging site where markup can be tested before it ships.

The fourth input decides the project. If your rates live in a PDF rate card that someone retypes into pages, fix that first. Markup that copies a retyped number gives an engine two places to read the same wrong figure.

Tag every URL in the inventory by kind: corporate pages, product pages, content pages and, if you run a branch network, branch pages. Each kind gets different structured data.

Phase 1: your entity markup belongs on one page and uses the registered name

The first thing an engine has to settle is who you are. Google’s Organization structured data guidance recommends placing this markup on the home page or on a single page that describes the organisation, such as the About page. It does not need to repeat on every URL.

1. Choose the entity type. On schema.org, FinancialService sits under LocalBusiness and lists four subtypes: AccountingService, AutomatedTeller, BankOrCreditUnion and InsuranceAgency. A bank uses BankOrCreditUnion. An asset management company, an NBFC, a broker or a payments company has no dedicated subtype, so it uses Organization or FinancialService and explains the business in the description field. Because FinancialService is a kind of local business, keep it for pages that describe a place, such as a branch, and use Organization for the group itself.
2. Fill the identity fields from the register, never from memory. Put the registered name in legalName, the trade name in name, short or older names in alternateName, the logo in logo and your official profiles in sameAs. Google lists identifier fields such as iso6523Code and says a Legal Entity Identifier goes there with the 0199 prefix. Add the customer care number, grievance email and registered address, but only where a visitor can see them on the same page.

Here is the regulator-driven decision in this phase. IRDAI’s 2024 policyholder protection regulations require an insurer’s advertisement to show its registered name along with its trade name or logo, prominently. If your ads and pages pair a short brand with the full company name, the markup should pair them the same way: the short brand in name, the company name in legalName. An engine that meets both names together in markup and on ads has less reason to treat them as two companies. Banks and fund houses work under their own advertising rules, and the same principle holds: the markup mirrors the approved lockup.

One more decision belongs here. A bank, its securities arm and its insurance joint venture are separate legal entities with separate licences. Give each its own Organization block on its own About page, connect them with parentOrganization or subOrganization, and never describe a subsidiary’s regulated business inside the parent’s block. An assistant asked “who issues this policy” should find the insurer, not the bank that distributes it.

SIGNALNewsletter by Yamm Labs

The next piece, straight to your inbox.

New writing on BFSI brands, B2B and influencer marketing, and AI search.

Email *

Subscribe

Subscription form is not available at the moment

One click to unsubscribe. Privacy policy

Phase 2: product pages need a FinancialProduct type whose numbers match the screen

Product pages carry the facts customers ask engines about. schema.org’s FinancialProduct has three fields of its own that a regulated page cares about: annualPercentageRate, interestRate and feesAndCommissionsSpecification. Its subtypes are BankAccount, CurrencyConversionService, InvestmentOrDeposit, LoanOrCredit, PaymentCard and PaymentService. LoanOrCredit adds amount, currency, loan term, grace period, required collateral and loan type, and has two subtypes of its own, CreditCard and MortgageLoan.

The table below maps common Indian product pages to a type. The last column is the fact the page has to state in visible text before the markup can repeat it.

Two gaps in the vocabulary are worth knowing. schema.org’s FinancialProduct subtypes include no insurance policy type, so a plan page uses the parent FinancialProduct and relies on provider to name the insurer. And none of these types has a field for fund returns, which suits a regulated brand: past performance changes daily and SEBI’s advertising rules govern how it is shown, so it stays in the approved, visible table.

1. Map each product page to one type from the table and fill only the fields the page states in visible text. Google’s general guidelines say not to mark up content that is not visible to readers of the page. If the APR lives only in a downloadable PDF, either bring it onto the page or leave annualPercentageRate out.
2. Bind every number to one source. The rate the customer reads, the rate in the JSON-LD and the rate in your Key Facts Statement template should all be rendered from the same CMS field, with an effective date stored beside it. Nobody types a rate into a markup template, ever.

The APR field is where most lenders get this wrong. RBI’s rules on the Key Facts Statement require lenders to give retail and MSME term-loan borrowers a statement that includes the annual percentage rate before the loan contract is signed. For commercial banks, the rule now sits in RBI’s November 2025 Responsible Business Conduct Directions. schema.org defines annualPercentageRate as the yearly cost of borrowing including fees. If a loan page says “rates from 10.5%” and the markup puts 10.5 in annualPercentageRate, you have told a machine the starting rate is the all-in cost. Put the headline rate in interestRate, and fill the APR only when the page shows one worked out the way your KFS works it out.

Take a hypothetical lender whose rate table moves from 10.50% to 10.75% on the first of the month. The page template reads the table, so the page updates at midnight. The JSON-LD was typed into a plugin field eighteen months ago, so it still says 10.50%. An assistant that trusts the markup can quote the old rate for weeks, and the screenshot reaches your grievance desk before it reaches your SEO team. The fix is architectural: one field, two outputs.

Leave ratings out. Do not add aggregateRating or review markup to product or organisation pages. Google’s review snippet documentation does not list FinancialProduct or Service among the types it supports, and it treats reviews that an organisation controls about itself as self-serving and ineligible for stars. A star rating in markup is also a testimonial claim, which your compliance team would have to approve like any other.

If the markup and the page can disagree, sooner or later they will.

Phase 3: articles need dates and breadcrumbs, and FAQ markup no longer earns a rich result

Guides and explainers need less markup than product pages, but two fields carry weight. Google’s Article structured data guidance recommends author, datePublished, dateModified, headline and image, and it allows the author to be a Person or an Organization. For a regulated brand the useful one is dateModified: a reader, and an engine, needs to know when a tax-saving or rate explainer was last checked.

1. Add Article markup to every guide, calculator page and explainer. Set dateModified to change only when the content changes, never on every cache purge or plugin update, so the date means something. Match headline to the visible H1. Set the author to the brand, or to a named reviewer whose credentials appear on the page. Add BreadcrumbList markup so the page’s place in the site, say Home, Loans, Personal loans, Guide, is explicit.
2. Make the FAQ decision on the record. In August 2023 Google said FAQ rich results would be shown only for well-known, authoritative government and health websites. Its Search Central changelog then recorded the deprecation of the FAQ rich result in May 2026, saying the feature would no longer appear from 7 May 2026, and the removal of its documentation on 15 June 2026. HowTo rich results went earlier, in September 2023. Our call: stop adding FAQPage markup to new pages, leave valid existing blocks alone, and keep the visible question-and-answer text, which engines still read as ordinary content.

The visible questions are the part worth your time. A page with a plain question as a heading and a two-sentence answer under it is easy for any engine to quote, whatever markup sits behind it. Our GEO and AEO FAQ for financial brands is built that way, and it is a fair model for a product FAQ.

Phase 4: validation needs two tools and a compliance read

A green tick proves less than teams assume. Google says it does not guarantee that structured data will appear in search results, even when it passes its tests. Validation has to prove three things: the code parses, the vocabulary is right, and the values match the approved page.

1. Validate on staging, then get the compliance read. Run every template through Google’s Rich Results Test, which reports what Google can use for its own features, and through the Schema Markup Validator at validator.schema.org, which checks the vocabulary for every type, including the financial product types Google ties to no search feature. Then send compliance the plain-words value sheet for sign-off and file it with the release.
2. Audit monthly and on every rate change. A small script fetches each product page, extracts the JSON-LD values and the visible rate, compares both with the rate table, and logs any mismatch. Read the structured data reports in Search Console in the same sitting, and run the audit again the day any rate changes.

The audit is the step teams drop after launch. Markup decays quietly: a CMS upgrade strips a field, or a campaign microsite adds its own Organization block with a different name. None of this shows on the page, so only a scheduled check finds it.

The eight steps at a glance: owner, time and the record to keep

Timings below are typical practice in our work for a lender or insurer with a few dozen product pages. They are planning figures, not benchmarks, and no regulator sets them.

How long schema markup takes and who signs off

Plan four to eight weeks from inventory to the first audit, as typical practice. Step 4 sets the pace. If rates already sit in one CMS table, binding them is a template change. If they sit in PDFs and hand-edited pages, step 4 becomes a small data project.

Sign-off splits four ways. The SEO lead owns the templates and the audit. Each product owner signs the numbers for their product. Compliance signs the value sheet, the same way it signs page copy. IT or security signs any script change on the templates, because JSON-LD is still a script block on a page that may sit under a strict content security policy.

Your compliance team will ask what the markup claims. Here is a version you can paste: “The structured data on our pages repeats facts already shown and approved on the same page: entity names, product names, rates, fees and dates. It adds no claim, rating or return figure. Rates are read from the same source as the page text, and a monthly audit logs any mismatch, with the log kept by the SEO lead.” This is general guidance, not legal advice; your compliance team decides. If you want a team to run the build and the audit, that is the work our AI visibility practice for BFSI brands does.

How to tell your schema markup worked

Judge the work on accuracy first and visibility second. Accuracy you can measure exactly. Visibility in AI answers you can only approximate, and anyone who claims to attribute an AI citation to markup alone is guessing.

• Every template passes the Schema Markup Validator with no errors, and the Rich Results Test shows the breadcrumb and article items you expect.
• Two audits in a row find no mismatch between the markup, the page and the rate table.
• Search Console’s structured data reports show valid items rising as templates roll out, and no new errors after a release.
• A fixed set of questions, put to the main AI assistants once a month, returns your current rate and attributes the product to the right legal entity.

The last check is a proxy. Keep the questions identical each month, date the answers and watch the trend. Our AI search and GEO service runs this kind of probe for financial brands; any team can run a smaller version with a spreadsheet.

What to do when a schema markup step fails

Most failures trace back to one of five causes, and each has a direct fix.

• The validator flags a property on the wrong type. Check the hierarchy on schema.org. The APR field belongs to FinancialProduct and its subtypes, so it cannot sit on an Organization block.
• The audit finds a rate mismatch. Fix the source and let the page and the markup follow. Editing the JSON-LD by hand reopens the gap you closed in step 4.
• Compliance rejects a value. Remove the field. Every schema.org property is optional, and a missing field costs less than a wrong one.
• Two Organization blocks appear on one page. A theme and an SEO plugin often both output one. Switch one off so each page states one entity, once.
• Search Console reports a structured data manual action. Google says this removes the page’s eligibility for rich results without changing how it ranks in web search. Remove any markup that describes content readers cannot see, then request a review.

A sixth case is not a failure. The Rich Results Test may show nothing for a valid LoanOrCredit or InvestmentFund block, because it reports only types tied to a Google feature. Check those blocks in the Schema Markup Validator and move on.

People also ask

Does schema markup help a bank appear in AI Overviews?

Not directly. Google says no special schema.org structured data is needed to appear in its AI features. Markup helps an engine confirm the names, rates and dates in your visible text, which matters when a wrong figure would reach a customer.

Should a financial website still use FAQ schema in 2026?

Not for a rich result. Google limited FAQ rich results to well-known government and health sites in August 2023 and recorded in its changelog that the feature would stop appearing from 7 May 2026. Keep the visible questions and answers, which engines still read, and stop adding new FAQPage blocks.

Which schema type should an insurance company use?

Use Organization on the About page, with the registered name in legalName and the trade name in name. schema.org has no insurance policy type, so plan pages use FinancialProduct with the insurer as provider, while InsuranceAgency suits branch or agency location pages.

Can JSON-LD carry interest rates that change often?

Yes, if the markup reads the rate from the same source as the visible page and both update together. If the rate is typed into a separate plugin field, leave it out of the markup until the template can read it from the rate table.