Compliance reviews increasingly hinge on evidence, not policy alone. Regulators and supervisors increasingly expect financial services firms to demonstrate how they monitor customer outcomes, manage operational and data risk, and govern regulated decisions, including decisions supported by AI.
That does not mean every regulation requires a historical customer master record to be produced on demand. It does mean firms need sufficiently reliable evidence to explain the data, controls, and accountability behind a material customer outcome or decision.
For banks and insurers with customer and party data fragmented across multiple systems, assembling that evidence can be slow, manual, and incomplete. The risk is not simply that records differ; it is that the firm cannot readily establish which identity and context informed a decision.
Read on to learn what regulators increasingly expect firms to evidence, and how banks and insurers can prepare before a review begins.
What customer data must support during regulatory scrutiny
Consumer Duty, General Data Protection Regulation (GDPR), the Digital Operational Resilience Act (DORA), Financial Conduct Authority (FCA) and Prudential Regulation Authority (PRA) supervisory expectations, and the EU AI Act do not impose identical requirements. Together, however, they increase the focus on data quality, governance, resilience, traceability, and accountability.
During a review, a firm may need to establish how customer data supported a particular outcome, process, or decision.
In practice, responding confidently to regulatory scrutiny often depends on being able to show:
- Where relevant customer data originated
- How and when it changed, and which source prevailed
- Which controls, stewardship actions, and approvals were applied
- Which version and relationship context informed the outcome or decision
A written policy describes the intended control environment. Lineage and audit history provide evidence of how controls were applied to a particular record at a particular point in time.
The emphasis varies by market:
- UK firms face pressure through FCA requirements such as Consumer Duty, alongside broader FCA and PRA expectations for data governance and operational resilience
- EU firms must consider GDPR accountability and data accuracy, DORA's ICT and data resilience requirements and, for in-scope high-risk systems, the AI Act's requirements for data governance, documentation, recordkeeping and oversight
- US firms encounter related expectations through customer identification and KYC, AML and sanctions compliance, fair lending, privacy and model risk requirements, depending on the activity and regulator
Different areas of focus create a common operating challenge: Banking, financial services, and insurance (BFSI) firms need trustworthy data and defensible evidence.
What happens when your customer looks like four different people
The same person can appear as a retail banking customer, mortgage borrower, policyholder, company director or beneficial owner across different systems. Each system holds a version created at a different time and for a different purpose.
Effective sanctions screening and KYC refresh rely on resolving these versions and relationships accurately. When identity is fragmented, a financial crime or sanctions review can become a manual reconciliation exercise across banking, mortgage, wealth, and insurance systems. Each system may show a different name, address, ownership link, or risk classification for what should be one customer or party.
When that happens, the compliance team faces three questions:
- Which record is the trusted one?
- How are the customer's relationships and accounts connected?
- Was the screening run against the complete picture, or a partial one?
Party context matters as much as identity. Financial institutions need to understand which accounts a customer controls, which businesses they own, which policies they hold and how individuals, legal entities, and intermediaries are connected.
Without a governed identity layer, answering these questions consistently can be slow and difficult. Every unresolved identity or relationship weakens the firm's ability to defend a decision or a screening result.
Why your CRM or data warehouse alone may not solve the customer identity problem
Most firms already run a CRM and a data warehouse. Both are essential, but neither necessarily provides the governed identity resolution, matching, survivorship and relationship management needed to establish a persistent, trusted customer identity across source systems.
- CRM systems are primarily designed to manage customer interactions and engagement
- Data warehouses consolidate data for analytics and reporting
Neither is designed to answer the narrower identity question: Do these records represent the same person or organization, which sources should prevail, and can that decision be explained?
A governed identity layer complements CRM and data platforms by providing persistent customer and party identity, relationship context, and transparent rules that downstream processes can reuse.
Why AI turns customer data into an even harder compliance question
AI and advanced analytics are increasingly being applied across processes such as onboarding, fraud detection, customer service, claims, and elements of credit and risk assessment. AI does not replace the regulatory obligations surrounding those processes. For in-scope high-risk use cases, it can add requirements around data governance, documentation, recordkeeping, and human oversight.
When a regulator reviews one of these decisions, the scrutiny moves to:
- Which customer and party data the system used, and from which sources
- Whether that data was sufficiently accurate, complete, and relevant at the time
- Which controls, owners, and human oversight were applied to the output
Automation magnifies fragmented data. A wrong, outdated or incorrectly resolved record can influence many downstream decisions before the pattern is detected.
Master data management (MDM) alone does not make an AI system compliant. Governed, traceable customer identity can, however, provide trusted context and evidence for the data feeding AI-enabled decisions.
Without that foundation, an AI-driven decision inherits the same weakness as a human one, built on a record no one can fully vouch for.
What to check before your next audit
Most compliance programs test whether customer data looks right, but few test whether it can be defended, how it was selected, governed, and used.
Before the next audit, KYC refresh, or review of an AI-enabled decision, ask a more demanding question:
For one customer, at one point in time, can you reproduce the identity and relationships used, trace key values to their source, and show which controls and exceptions were applied?
If the answer takes weeks of manual work across systems, the risk sits in the evidence gap between policy and operational data.
How Stibo Systems helps BFSI firms prove customer identity
Stibo Systems governs customer identity through MDM, powered by STEP, our trusted intelligence platform. It:
- Resolves customer and party records using configurable deterministic and probabilistic matching
- Applies transparent merge and survivorship rules to determine trusted values
- Models relationships and hierarchies across individuals, legal entities, accounts, policies, intermediaries, and related parties
- Connects customer and party data with other governed domains, such as product, location, and supplier data
Configurable workflows, validation rules, stewardship, access controls, lineage, and audit history help firms understand how master data changed, who changed it, and which controls were applied.
STEP acts as an operational trust layer. It does not replace CRM, data platforms, GRC tools or model governance; it supplies them with consistent identity and relationship context, making evidence easier to retrieve without reconstructing a record's history after a request arrives.
Regulation will continue to evolve, but the operational question is durable: Can the firm show which customer and party data it trusted, how that trust was established, and where it was used?
BFSI firms that can answer clearly are better positioned for regulatory scrutiny and responsible AI at scale.
Not sure what your customer record is actually made of? Download our ebook, Meet Your Frankenstein Customer, to see how patchwork records form and what it takes to replace them with one governed, defensible view of the customer.
Frequently asked questions
What is the difference between data governance and customer data lineage?
- Data governance sets the rules, who owns which data, how it should be classified, and what quality standards apply
- Data lineage is the record of what happened to a piece of data over time: where it came from, when it changed, and who changed it
A firm can have strong governance policies and still lack lineage needed to demonstrate how those policies were applied to specific data.
What is the difference between deterministic and probabilistic matching?
- Deterministic matching uses predefined rules to link records based on exact or strongly defined attribute combinations, such as customer identifiers, account numbers, or combinations of name and date of birth.
- Probabilistic matching scores the likelihood that two records represent the same person based on a combination of fields that are similar but not identical, such as name, address, and date of birth.
BFSI firms typically need both deterministic matching for high-confidence links and probabilistic matching to catch the harder cases where identifiers are missing or inconsistent across systems.
What does a regulator look at during a data-focused examination?
A data-focused regulatory review may require a firm to demonstrate how customer data supported a particular outcome, process, or decision. The regulator is looking for information on which record was used, where it came from, whether it was the most current version at the time and who had access to change it.
Does better customer data lineage help with anything beyond compliance?
It tends to. Firms that can trace customer identity across systems typically also see fewer duplicate records, faster onboarding and fewer false positives in sanctions screening by improving the consistency and completeness of the customer data they rely on.
How long does it take to become audit-ready for customer data?
This varies by firm, depending on how many systems hold customer data and how fragmented those records already are.
Firms with a single core banking or policy administration system typically move faster than those managing customer identity across several legacy platforms built at different times.
