Many banking, financial services and insurance (BFSI) firms believe their customer data is compliant. But when a regulator asks them to prove it, their confidence starts to crack.
Proof is not the same as a policy sitting in a governance folder. Regulators want something more specific than that.
For a particular customer and decision, firms need to show:
- Which record was trusted, and why it was used for a particular decision
- Where the data came from, and who owned it
- Which data and control supported the decision, and who approved any exceptions
Most compliance teams can describe their processes in detail. But few can produce that supporting evidence quickly, for one customer, one decision and one point in time.
Having a policy is not the same as being able to demonstrate that it was applied consistently, and that difference is where many BFSI firms get caught out. The rules are in place, but they don’t have a fast, defensible way to show that they follow them.
Here is a simple way to test whether your firm can produce that evidence quickly and consistently.
Can your customer data withstand regulatory scrutiny?
If a regulator asked you for proof about one customer and one decision, could your team answer within minutes, or would you spend weeks chasing that customer across systems that were never built to talk to each other, reconciling names and addresses that do not match before you could even begin?
Answering quickly comes down to two things:
- One trusted version of that customer, instead of several conflicting ones
- A visible trail showing where the data came from and who approved it
Many firms still struggle to produce both quickly and consistently, particularly when supporting data is spread across multiple systems.
What are regulators asking for right now?
Different regulatory frameworks place different obligations on BFSI firms, but several share a growing emphasis on governance, accountability and demonstrable evidence.
- Consumer Duty and the FCA, requiring firms to assess, understand, and evidence the outcomes received by retail customers
- GDPR, requiring firms to understand what personal data they hold, why it is processed, how long it should be retained, and how individual rights are supported
- DORA, requiring financial firms to strengthen ICT risk management, operational resilience, and oversight of critical technology providers
- The EU AI Act, introducing governance, transparency, and risk management obligations for certain AI systems used in financial services.
None of this is new territory. What has changed is how much detail regulators expect on demand.
When that regulator points at one customer and asks for the reasoning behind one decision, you must be able to connect the outcome to the data, controls, and approvals that supported it.
How do disconnected systems create compliance blind spots for BFSI companies?
Every system in a BFSI firm captures customer data for a different business purpose.
For example, a core banking platform may record an account, a CRM a relationship, a policy administration system a contract, and a claims platform an event or loss. Each of them updates its own version on its own schedule, using whatever a customer or colleague typed in at the time.
Over months and years, those records drift apart. Nothing forces them to agree with each other, and nothing tells anyone which version to trust.
The result can be several versions of the same person or organization, with different addresses, identifiers, roles, and relationships spread across systems that were never designed to reconcile them.
What goes wrong during a KYC refresh, for example?
- The core banking system lists an address from three years ago
- The CRM has a newer one
- The onboarding platform names a different legal entity for the same beneficial owner, because a form was completed by someone else at a different point in the relationship
Each record may have been valid in its original context, but together they present a conflicting and incomplete picture. Before the review can begin, the team must establish whether the records represent the same party, which source is current, and which information should be trusted.
That is when you can no longer answer a regulator in minutes.
Why does AI make weak customer data an even bigger compliance risk?
An AI model treats whichever customer record it receives as fact. It makes a decision within milliseconds, whether that decision is:
- A credit line
- An onboarding approval
- A suitability check
- A fraud flag
- A claims decision
- An underwriting referral
- A customer vulnerability assessment
Unless conflicting or outdated records are identified and governed upstream, they may be processed with the same apparent confidence as trusted data. An unreliable record can therefore influence decisions quickly and at scale.
Increasingly, firms must be able to explain not only how a model performed, but also which data supported its output, where that data came from, and what controls were applied.
- Manual errors may remain isolated or be detected one case at a time
- Automated processes can repeat the same data problem across a much larger population
The test I mentioned earlier applies here, too. But here the problem runs at machine speed. A firm that could not answer for one customer in minutes now has a model repeating that same unproven decision across thousands of customers before anyone notices.
Why can strong compliance policies still be difficult to prove?
Many BFSI firms already have detailed policies, data governance frameworks, and documented controls.
The problem appears when it is time to prove the policy was followed:
- For one customer
- On one day
- For one decision
The real test is whether the data, controls, and approvals behind a decision were captured and retrievable at the moment someone asked for it. Most firms test whether policies and controls exist but may be less prepared to test how quickly the supporting evidence can be assembled for a real customer or decision.
And that is the real challenge.
McKinsey’s recent research on AI data readiness reaches a similar conclusion from a technical angle: AI does not lower the bar on data quality, but it raises the cost and the speed of getting it wrong. The same research found that only 7% of companies have fully scaled AI across their organizations. Largely because the underlying data was not ready to support it.
How BFSI firms can make compliance evidence easier to produce
Solving it starts with treating trusted customer and party data as shared infrastructure.
Customer Experience Data Cloud, the customer data solution built on STEP, Stibo Systems’ trusted intelligence platform, gives BFSI firms a governed master data foundation that can help BFSI firms connect identities, apply transparent rules, and retain evidence of how trusted records were created. The solution:
- Applies transparent matching and survivorship rules, helping firms understand why records were linked and which values were selected
- Tracks lineage, showing where each piece of customer data came from and when it last changed
- Manages relationships and hierarchies across customers, accounts, policies, organizations, brokers, and related parties
- Supports stewardship and exception workflows so significant identity decisions can be reviewed rather than remaining hidden inside system logic
Firms including Royal London already run their customer data this way. The ones that pass a regulator’s question can answer instantly, every time it is asked, regardless of how much documentation sits in a folder.
FAQs
What is the difference between a CRM, a data lake and a governed identity layer for compliance purposes?
A CRM records interactions with a customer. A data lake stores and analyzes raw data. Neither is built to decide which version of a customer record is correct, or to make that decision explainable, which is what a governed identity layer is designed to do.
When does the EU AI Act apply to BFSI firms using AI in customer decisions?
The EU AI Act becomes fully applicable in August 2026, with specific obligations for high-risk AI systems, which covers many AI-driven credit, onboarding, claims, and underwriting decisions in BFSI.
Does a governed identity layer replace the need for a data governance program?
No. It gives a governance program something to enforce. Policy sets the rules; the identity layer is what makes those rules checkable against a real customer record.
Can a firm be compliant on paper but still fail an AI audit?
Yes, and this is becoming one of the more common gaps regulators are finding. Documented policy shows intent. An AI audit tests whether the data behind an actual decision matches that intent, which is a different question entirely.
What happens to legacy customer data created before current rules applied?
Legacy data does not get an exemption. If it still feeds a customer decision today, a regulator can still ask for proof behind it, regardless of when the record was originally created.
How often should a firm test whether it can produce this evidence?
There is no fixed regulatory interval, but leading firms treat it like a fire drill, running the test internally on a live customer scenario rather than waiting for a regulator to run it first.
