Financial services is one of the most competitive search categories on the planet. Banks, fintechs, insurers, and comparison sites are all fighting for the same queries. Now AI search engines like ChatGPT, Perplexity, and Gemini are answering finance questions directly, and most financial brands are not even in the running for those citations.
The reason is simple: AI models rely on structured, machine-readable signals to decide which products and providers to surface. If your pages are just blocks of marketing copy with no structured data, the model has to guess what you offer. It will often pick a competitor that made it easy instead.
FinancialProduct schema is one of the clearest signals you can give. It tells AI engines exactly what kind of financial product you offer, what it costs, who it is for, and what the terms are. Done properly, it positions your pages to be cited when someone asks an AI assistant for the best savings account, business loan, or insurance product in your category.
What FinancialProduct Schema Actually Is
FinancialProduct is a type defined in the Schema.org vocabulary. It sits under the Product hierarchy and is specifically designed for financial offerings. The schema has several subtypes that map to common product categories:
- BankAccount - for current accounts, savings accounts, and similar deposit products
- CurrencyConversionService - for FX and money transfer services
- InvestmentOrDeposit - for ISAs, bonds, and investment products
- LoanOrCredit - for personal loans, mortgages, and credit products
- PaymentCard - for credit cards and debit cards
- PaymentService - for payment processing and wallets
Using the correct subtype matters. An AI model parsing your schema wants to know what kind of product it is looking at, not just that it is "financial." Specificity is the whole point.
The schema is implemented as JSON-LD, typically in the <head> of your page or just before the closing </body> tag. Google, Bing, and the large language models that power AI assistants all parse this markup when crawling and indexing your pages.
The Properties That Actually Move the Needle
Not all FinancialProduct properties carry equal weight. Some are required for basic validity. Others are the ones that give AI models enough detail to cite you confidently. Here is a breakdown of the most important ones.
Core identification properties
Start with the fundamentals. Every FinancialProduct implementation should include:
name- the product name as it appears on your site, e.g. "FlexSaver Easy Access Account"description- a clear, factual description of what the product does and who it is for. Aim for 2 to 4 sentences. Avoid marketing fluff; write it as if explaining to a customer who has never heard of youurl- the canonical URL of the product pageprovider- the Organisation or LocalBusiness that offers the product. Nest a fullOrganizationentity here withname,url, andlogo
Financial detail properties
This is where most implementations fall short. AI models want specifics. Include as many of these as apply:
annualPercentageRate- the APR as a number. For loans and credit products, this is one of the first things a user asks aboutinterestRate- the gross interest rate, distinct from APRfeesAndCommissionsSpecification- a text field or URL pointing to your fees page. Even a brief summary helpsamount- for loan or credit products, the available amount range using aMonetaryAmountentitycurrency- the currency the product operates in, using ISO 4217 codes (GBP, EUR, USD)loanTerm- for LoanOrCredit subtypes, the term as aQuantitativeValuewith a unit (e.g. months or years)loanRepaymentForm- specifies how repayments work, using aRepaymentSpecificationentity
Trust and eligibility signals
AI assistants do not just recommend products; they recommend products that seem credible and appropriate. Help the model understand who can apply and that you are a legitimate provider:
eligibleRegion- the geographic area where the product is available. Use country codes or region namescategory- a short text label for the product type, e.g. "personal loan," "business savings account"awardorreview- if your product has won industry awards or carries aggregate ratings, include them. Pair this with AggregateRating schema on the same page for maximum impacttermsOfService- a URL to your full terms. This signals transparency, which matters to AI models evaluating trustworthiness
A Practical JSON-LD Example
Here is a working example for a personal loan product. You can adapt this for any LoanOrCredit subtype:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LoanOrCredit",
"name": "Personal Loan",
"description": "Unsecured personal loans from £1,000 to £25,000 with fixed monthly repayments and no early repayment fees. Available to UK residents aged 18 and over.",
"url": "https://www.example.co.uk/personal-loans",
"provider": {
"@type": "Organization",
"name": "Example Finance Ltd",
"url": "https://www.example.co.uk",
"logo": "https://www.example.co.uk/logo.png"
},
"amount": {
"@type": "MonetaryAmount",
"minValue": 1000,
"maxValue": 25000,
"currency": "GBP"
},
"annualPercentageRate": {
"@type": "QuantitativeValue",
"value": 9.9,
"unitText": "APR"
},
"loanTerm": {
"@type": "QuantitativeValue",
"minValue": 12,
"maxValue": 60,
"unitCode": "MON"
},
"feesAndCommissionsSpecification": "No arrangement fees. No early repayment charges.",
"eligibleRegion": {
"@type": "Country",
"name": "GB"
},
"category": "Personal Loan",
"termsOfService": "https://www.example.co.uk/personal-loans/terms"
}
</script>
Notice that the description is factual and specific. It includes the loan range, the repayment structure, and the eligibility criteria in plain language. That is not accidental. AI models pull from descriptions to build their cited summaries, so the better your description, the more accurately you will be represented.
How to Implement This on Shopify and WordPress
Most financial brands using Shopify or WordPress do not have native FinancialProduct schema support out of the box. Here is how to add it without breaking anything.
Shopify
On Shopify, the cleanest approach is to add your JSON-LD directly to the relevant page template using a {% raw %}{{ page.title }}{% endraw %} Liquid block, or better, to the theme's page.json section. If you are on a custom theme, you can create a new section file and include it via your template. Avoid plugin-generated schema for financial products; most plugins are built for retail products, and the output will be incorrect for FinancialProduct types.
WordPress
On WordPress, you can add JSON-LD via a custom plugin or directly in the page template using wp_head hooks. If you are using a schema plugin like Rank Math or Yoast, be aware that neither currently supports FinancialProduct natively. You will need to add a custom schema output. Use the "Custom Schema" feature in Rank Math (available on the Pro plan) or add the script block manually via a code snippet plugin.
At FlinnSchema, we handle implementations like these as part of our Automations and Implementation service, particularly for clients in financial services where accuracy and compliance considerations make manual implementation the safer choice.
Common Mistakes That Kill Your AI Visibility
Most FinancialProduct schema implementations that fail do so for predictable reasons. Here are the ones we see most often.
Using the generic Product type instead of a subtype
Marking up a savings account as a plain Product gives AI models no meaningful signal. Always use the most specific subtype available. BankAccount, LoanOrCredit, and PaymentCard are all far more useful than the generic fallback.
Omitting the APR or interest rate
Finance queries are almost always rate-sensitive. "What is the best easy access savings rate right now?" is a classic AI search prompt. If your schema does not include the rate, you will not be cited in rate comparisons. Include it even if it is a representative rate.
Writing vague descriptions
Descriptions like "We offer great personal loans with excellent customer service" are useless to an AI model. Write descriptions that include the actual product features, amounts, terms, and eligibility. Think of it as writing a product data sheet, not a tagline.
Not pairing with Organisation schema
FinancialProduct schema in isolation is weaker than it needs to be. AI models are much more likely to cite a product from a provider they have already established as a known, trusted entity. Make sure your site has a well-formed Organization entity, ideally on your homepage or an About page, and that the provider field in your FinancialProduct schema references that same entity.
Measuring Whether It Is Working
Tracking AI citation performance is still an evolving discipline. A few practical approaches:
- Run target queries in ChatGPT, Perplexity, and Gemini directly. Search for your product category and location ("best personal loans UK 2025") and note whether your brand appears. Do this before implementation and again 4 to 6 weeks after
- Monitor your Google Search Console for rich result impressions. While Google does not yet show a FinancialProduct rich result in the traditional sense, structured data presence does influence how your pages appear in AI-powered features like SGE
- Use a tool like FlinnSchema's free AI Visibility Audit to check whether your schema is valid and whether your pages are being read correctly by AI crawlers
- Watch for referral traffic changes from AI sources. Perplexity and some ChatGPT browsing citations do pass referral data through to analytics
The timeline for results varies. Schema changes can be picked up within days for frequently crawled sites, but AI models update their knowledge at different frequencies. Give it 6 to 8 weeks before drawing conclusions.
What to Do After FinancialProduct Schema Is Live
Schema is not a one-and-done task. Financial products change, rates change, and eligibility criteria change. Any time a material detail about your product changes, your schema needs to be updated. Stale schema can actually harm your credibility with AI models if the data they retrieve does not match what users find on the page.
Beyond keeping it current, think about the broader picture of AI readiness. FinancialProduct schema is one piece of a larger structured data strategy. If you want to see how this fits into a complete approach to AI search visibility, the What We Do Differently page explains how we think about layering schema types to build a coherent, machine-readable picture of a business.
Financial brands that get this right early will have a real advantage. AI search is already directing high-intent users to specific products. The question is whether those users find you or your competitors.
Frequently Asked Questions
Does FinancialProduct schema work for insurance products?
There is no dedicated Insurance subtype in the current Schema.org FinancialProduct hierarchy. For insurance products, you can use the parent FinancialProduct type and set the category property to describe the product clearly, for example "home insurance" or "life insurance." Pair this with a strong description and provider entity. Schema.org does evolve, so it is worth checking for new subtypes periodically.
Will FinancialProduct schema help with Google rich results?
Google does not currently display a dedicated rich result for FinancialProduct schema in the way it does for recipes or events. However, the structured data still influences how Google's AI-powered search features interpret and present your content, and it is a clear signal for third-party AI models like ChatGPT and Perplexity that actively parse Schema.org markup when generating citations.
How do I handle products with variable rates?
Use a QuantitativeValue with a minValue and maxValue for the rate range, and note in the description that the rate shown is representative. This is both technically accurate and more useful to AI models than omitting the rate entirely. For products where the rate changes frequently, consider including the date it was last updated using the dateModified property on the page-level schema.
Do I need separate schema for each product page?
Yes. Each distinct financial product should have its own JSON-LD block on its own page. Do not try to describe multiple products in a single FinancialProduct schema block; that approach confuses AI parsers and dilutes the signal for each individual product. If you have a category page listing multiple products, use CollectionPage schema at the page level, then link to individual product pages that each carry their own FinancialProduct markup.