Why Financial Services Firms Still Struggle with Data Strategy
Banks, insurers, and asset managers sit on some of the richest data sets in the world. Transaction histories, customer behaviour patterns, risk signals, market feeds: the raw material is everywhere. Yet according to a 2024 NewVantage Partners survey, only 24% of financial services firms describe themselves as “data-driven.” The gap between having data and actually using it well remains enormous, and the root cause is almost always the absence of a coherent data strategy for financial services.
Having worked with financial institutions on data programmes, I can tell you the problem is rarely technology. It is governance, organisational politics, and the lack of a clear plan that ties data investments to business outcomes. This guide lays out a practical framework you can actually implement.
What a Data Strategy for Financial Services Should Include
A data strategy is not a slide deck with buzzwords. It is a document that answers five questions:
- What business outcomes are we trying to drive? Revenue growth, cost reduction, regulatory compliance, or customer experience improvement.
- What data do we need to achieve those outcomes? Customer data, transaction data, market data, third-party data.
- Where does that data live today, and what shape is it in? Data inventory and quality assessment.
- Who owns and governs the data? Roles, responsibilities, and accountability.
- What technology and processes move us from current state to target state? Platform choices, integration patterns, delivery roadmap.
If your “data strategy” does not address all five, it is incomplete. For a deeper look at structuring this document, see our full guide on data strategy fundamentals.
The Unique Challenges of Data in Financial Services
Financial services data strategy is harder than in most other industries. Here is why:
Regulatory Pressure Is Relentless
GDPR, BCBS 239, MiFID II, SOX, PCI-DSS, the Consumer Duty: financial firms operate under a patchwork of overlapping regulations that all demand different things from your data. A bank in the UK might need to demonstrate data lineage for regulatory reporting (BCBS 239), prove consent management for customer communications (GDPR), and maintain audit trails for trading activity (MiFID II), all from the same underlying data sets.
This is not an afterthought. Compliance requirements should shape your data architecture from day one. Bolting on lineage tracking or consent management after the fact is expensive and fragile.
Legacy Systems Are Deeply Entrenched
Most large banks run core systems built in the 1980s and 1990s. These platforms were not designed for real-time analytics or API-driven integration. A 2023 Accenture study found that 43% of banking IT budgets go to maintaining legacy infrastructure. That leaves limited room for modern data platforms.
The practical implication: your data strategy must account for a hybrid world where some data stays in legacy systems for years. Trying to rip-and-replace everything at once is a recipe for a failed programme.
Data Silos Are Structural
Retail banking, wealth management, commercial lending, and insurance often operate as separate business lines with separate technology stacks, separate data teams, and sometimes separate legal entities. Breaking down these silos requires executive sponsorship, not just better ETL pipelines.
A Practical Data Strategy Framework for Financial Services
Here is a framework that works in practice, not just in theory. It has four layers:
Layer 1: Business Alignment
Start with three to five specific business priorities. Not “become data-driven” but concrete goals like:
- Reduce customer onboarding time from 14 days to 3 days
- Improve fraud detection rates by 30% while reducing false positives
- Achieve 95% accuracy on BCBS 239 regulatory reports
- Increase cross-sell conversion rates for existing customers by 15%
Each priority should have a named executive sponsor, a measurable target, and a timeline. Without this, your data strategy is just a technology wish list.
Layer 2: Data Governance Foundation
In financial services, data governance is not optional. It is the foundation everything else rests on. Your governance layer needs:
- Data ownership model: Every critical data element has a named business owner (not IT).
- Data quality standards: Define what “good enough” looks like for each use case. Trading data needs near-perfect accuracy. Marketing data can tolerate more noise.
- Classification and access controls: PII, confidential, restricted, public. Map data sensitivity to access policies.
- Lineage and audit trails: Regulators will ask where a number came from. You need to answer within hours, not weeks.
Layer 3: Architecture and Platforms
Your technology choices should follow your governance and business requirements, not the other way around. Common patterns in financial services include:
| Pattern | Best For | Watch Out For |
|---|---|---|
| Cloud data warehouse (Snowflake, BigQuery) | Analytics, reporting, regulatory dashboards | Data residency requirements may limit cloud options |
| Data lakehouse (Databricks) | ML workloads, unstructured data, large-scale processing | Governance tooling is still maturing |
| Hybrid on-prem + cloud | Regulated workloads that cannot leave on-premises | Complexity of managing two environments |
| Event-driven streaming (Kafka) | Real-time fraud detection, market data processing | Operational overhead is significant |
The right answer for most financial institutions is a hybrid approach. Core banking data stays on-prem or in a private cloud. Analytics and ML workloads move to a managed cloud platform. A well-designed API layer connects the two.
Layer 4: People and Operating Model
Technology is maybe 30% of a successful data strategy. The rest is people and process. Financial services firms typically choose between three operating models:
- Centralised: A single data team serves the entire organisation. Works well for firms under 1,000 employees.
- Federated: Each business line has its own data team with light central coordination. Suits large banks with diverse business units.
- Hub-and-spoke: A central platform team provides tools and standards. Business-embedded analysts handle domain-specific work. This is where most large institutions are heading.
Whichever model you pick, you need a Chief Data Officer (or equivalent) with genuine authority. A CDO who reports three levels down from the CEO will struggle to drive cross-business change. For more on this role, see our guide on CDO programmes and career paths.
Data Strategy Priorities by Financial Sub-Sector
Not all financial services firms face the same data challenges. Here is where priorities diverge:
Retail and Commercial Banking
Top priorities: customer 360 views, real-time fraud detection, and regulatory reporting automation. Banks that crack customer data unification typically see 20-35% improvement in cross-sell rates. The challenge is merging data across channels: branch, mobile app, online banking, call centre, and ATM.
Insurance
Top priorities: claims automation, underwriting model accuracy, and customer retention analytics. Insurers are sitting on decades of actuarial data, but much of it is trapped in legacy policy administration systems. The firms making progress are building modern data layers that sit on top of legacy systems rather than replacing them.
Asset Management and Wealth
Top priorities: alternative data integration, portfolio risk analytics, and client reporting personalisation. The competitive edge here comes from speed: how quickly can you ingest new data sources and turn them into investment signals? Firms like Two Sigma and Renaissance Technologies built their entire advantage on data infrastructure.
Common Mistakes to Avoid
After seeing numerous financial services data programmes, these are the patterns that consistently lead to failure:
- Starting with technology instead of business outcomes. Buying Snowflake before defining what questions you need to answer is backwards.
- Treating data governance as a compliance exercise. If governance is only about ticking regulatory boxes, business teams will treat it as an obstacle rather than an enabler.
- Boiling the ocean. A strategy that tries to fix everything at once fixes nothing. Pick two or three high-impact use cases and deliver them within six months.
- Underinvesting in data quality. Models and dashboards built on dirty data produce confident but wrong answers. Budget at least 25% of your data programme spend on quality remediation.
- Ignoring change management. The best data platform in the world fails if relationship managers, underwriters, and traders do not use it. Build adoption plans for every major deliverable.
Measuring Data Strategy Success in Financial Services
You need metrics that executives care about. Here are the ones that actually move the conversation:
- Time to insight: How long from “I have a question” to “here is the answer”? Measure in hours, not days.
- Regulatory reporting accuracy: Percentage of reports submitted without restatements or corrections.
- Data quality scores: Completeness, accuracy, timeliness, and consistency across critical data domains.
- Model performance: For ML-driven use cases (fraud, credit scoring), track precision, recall, and false positive rates.
- Adoption rates: What percentage of target users actively use the new data tools and dashboards?
- Cost avoidance: Regulatory fines avoided, manual processes automated, duplicated efforts eliminated.
Review these quarterly with the executive committee. Data strategy is not a one-time project; it is an ongoing capability that needs sustained attention and funding.
Frequently Asked Questions
How long does it take to implement a data strategy in financial services?
Expect 12 to 18 months for the foundational elements: governance framework, core data platform, and first two or three use cases in production. Full maturity across a large bank typically takes three to five years. The key is delivering incremental value every quarter rather than waiting for a “big bang” launch.
What is the biggest barrier to data strategy adoption in banking?
Organisational silos and politics, not technology. In my experience, getting the head of retail banking and the head of wealth management to agree on shared data standards and ownership is harder than any technology integration. Executive sponsorship from the CEO or COO level is essential to break through these barriers.
How does data strategy differ between a large bank and a fintech?
Fintechs typically start with clean, cloud-native architectures and less regulatory baggage (though that is changing). Their challenge is scaling governance as they grow. Large banks have the opposite problem: massive data assets locked in legacy systems with heavy compliance requirements. A fintech might build its data platform in months. A large bank is working in years, navigating change management across thousands of employees.
Should financial services firms build or buy their data platform?
Buy the platform (cloud data warehouse, ETL tools, BI layer) and build the domain-specific logic on top. Very few financial institutions benefit from building custom infrastructure from scratch. The exceptions are firms where data processing speed is a direct competitive advantage, like high-frequency trading shops. For everyone else, managed platforms from providers like Snowflake, Databricks, or cloud-native services from AWS, Azure, or GCP are the pragmatic choice.
Ben is a full-time data leadership professional and a part-time blogger.
When he’s not writing articles for Data Driven Daily, Ben is a Head of Data Strategy at a large financial institution.
He has over 14 years’ experience in Banking and Financial Services, during which he has led large data engineering and business intelligence teams, managed cloud migration programs, and spearheaded regulatory change initiatives.