Short answer: you implement entity resolution in finance through a versioned registry that separates brand, legal entity, product, plan, market, issuer, distributor and servicing entity. Then you map source owners, lifecycle, aliases and the relationships between these entities. Structured data reflects the result, not creates it. Google documents Organization and Product structured data, but does not publish a universal entity-resolution score.
Precondition 1: Define the actual entities
Before the CMS or schema, determine what types of entities exist: organization, legal entity, public brand, product family, product, plan/tier, market, partner, issuer, and servicing entity.
Don't compress these roles into a single 'brand' if they have different responsibilities.
Precondition 2: stable IDs and aliases
Each entity has a stable internal ID, canonical name, aliases and effective dates. The rebrand need not create a new entity if the underlying identity has not changed.
Use aliases for current, historical, regional and legacy-supported.
Precondition 3: source-owner map
Rates, fees, terms, eligibility, disclosures, product features and servicing instructions may have different owners. It links each material field to the source owner and dependent pages.
Step 1: first-party audit
Inventory product pages, plan pages, pricing, terms, legal pages, FAQs, calculators, comparisons, help and partner pages. For each write down the entity IDs, market, canonical, owner and lifecycle.
Step 2: classify failure modes
P0: legal/product identity mistake with material impact. P1: market, plan, terms or lifecycle stale. P2: external profile conflict. P3: cosmetic variation.
Step 3: Build the registry
Preserves entity_id, entity_type, canonical_name, aliases, parent relation, product relations, market, owner URL, lifecycle, effective dates and last_verified.
Step 4: Model the relationships
It explicitly defines:
- brand -> legal entity;
- legal entity -> product;
- product -> plan;
- product -> market;
- issuer -> product;
- distributor -> product;
- servicing entity -> product;
- product -> successor/replacement.
Step 5: correct owner truth
Resolves contradictions between product page, terms, pricing and help. Don't start with external profiles while the first-party truth is unclear.
Step 6: deal with market and jurisdiction
The same product may have different conditions in the markets. Keep market as the base dimension and don't reuse global values unless they are truly global.
Step 7: deal with rebrand and acquisition
Version aliases and relations. Keep historical truth without rewriting all the old documents as if the new brand had always existed.
Step 8: partner and white-label
A partner can distribute the product without being the issuer or contractual owner. It preserves the type relation and explains which name appears publicly on each surface.
Step 9: structured data
Organization and Product markup must reflect visible content and real relationship. Schema does not fix a product page that mixes plans or markets.
Step 10: publication gate
A product comparison, explainer or landing page does not go live if the entity ID, market, owner and lifecycle are unknown for material claims.
Step 11: lifecycle triggers
Rate update, product launch, plan retirement, market exit, merger, rebrand and servicing migration open automatic or procedural review tasks.
Step 12: QA regression
After migration or template change, check entity IDs, canonicals, redirects, structured data, product-market relations and links on a layered sample.
How do you treat products retired but still serviced
Use distinct states: active, retired_new_sales, legacy_serviced, replaced, historical. A page may remain necessary for existing customers without being presented as a current offer.
How do you deal with mergers
A merger can change legal entity, public brand and servicing at different times. Keep effective dates on relation edges and does not force artificial synchronization.
How do you treat products with different issuers and distributors
It shows internally who is issuing, who is distributing and who is serving. The external copy must reflect only the relationships relevant to the user, but the registry preserves the complete model.
How do you deal with missing data
Use unknown, not applicable, external unresolved. The absence of a field should not be filled in by inference just for uniformity.
How do you treat external profiles
Select critical profiles by buyer journey. Keep control status and expected state first-party. A stale external profile does not change the internal truth.
Acceptance criteria
The implementation passes the gate when:
- priority entities have stable IDs;
- aliases have status and dates;
- product-market relations are explicit;
- source owners are defined;
- issuer/distributor/servicing are distinct where it matters;
- P0/P1 first-party conflicts are closed;
- structured data reflects the page;
- publication gate prevents new conflicts;
- lifecycle triggers work;
- regression QA can reproduce the verdict.
Rollback and limitations
Keep registry snapshot and relation map. If a consolidation merges non-equivalent products or deletes a relevant historical alias, revert to the committed version and fix the taxonomy.
Entity resolution does not guarantee ranking, rich results or AI citations. It demonstrates clarity, consistency and operability.
How do you measure
Identity conflict rate, product-market consistency, relationship integrity, owner coverage, lifecycle lag, propagation latency and regression rate.
Maturity criterion
The system is mature when product and market changes propagate predictably, P0/P1 are rare, and a reviewer can reconstruct ownership and relationships from evidence without assumptions.
Claim ledger
- FACT/EVIDENCE: Google documents Organization and Product structured data.
- PRACTITIONER GUIDANCE: financial entity resolution must separate brand, legal entity, product, plan, market and servicing roles.
- INFERENCE: stable IDs and relation governance can reduce ambiguity and migration debt.
- NOT PROVEN: a universal entity-resolution score or direct effect on AI ranking/citations.
Conclusion
Entity resolution in finance is a system of identity and ownership. The mature implementation makes explicit who the entity is, what product it offers, in what market and in what period, then keeps these relationships correct as the business changes.
Sources reviewed
- Google Search Central, Organization structured data: https://developers.google.com/search/docs/appearance/structured-data/organization
- Google Search Central, Product structured data: https://developers.google.com/search/docs/appearance/structured-data/product-snippet
- Google Search Central, canonicalization: https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
