The Data Product Bank: Why Federated Data Ownership Is APAC BFSI's Next Structural Advantage
Centralized data lakes: the dominant BFSI investment of the past decade - are showing structural limits: long lead times to consumption, degraded quality, opaque lineage, and cost curves that outpace the value delivered. McKinsey's most recent data-and-analytics research finds that a majority of large institutions still struggle to convert enterprise data assets into measurable business outcomes at scale (McKinsey & Company, 2024a).
A federated model: data mesh, data products, contracts, and a self-serve platform - is displacing the "one giant lake" doctrine. Gartner has forecast that data fabric, and mesh patterns would become the dominant architecture in three-quarters of large enterprises by mid-decade (Gartner, 2023). APAC BFSI is at the front of this shift because regulatory data intensity here is now among the world's most severe.
The pay-off is compounding. Real-time credit decisioning, IFRS 17 and CPS 230 reporting, ML feature reuse, agentic AI grounding, and open-finance consent enforcement all draw from the same underlying discipline: treat data as a product, with an owner, an SLA, and a contract.
The barrier is not technology. It is operating model - a CDO mandate strong enough to redraw ownership boundaries, and the engineering muscle to build the platform that makes federated ownership safe.
For CIOs and CDOs in APAC banking and insurance, 2026-2027 is the window to move from centralized extraction to federated productization. Institutions that get it right will run leaner data teams, ship AI faster, and satisfy regulators with materially less friction.
The Lake Is Not the Lever
Every APAC bank of consequence has spent the past decade building and rebuilding - a central data platform. Hadoop gave way to cloud lakes. Cloud lakes gave way to lakehouses. Warehouses were federated, then unified, then federated again. And yet, ask the same question of any regional Chief Data Officer today, and the answer is unnervingly consistent: the data is there, but the value isn't.
This is not a failure of tools. Snowflake, Databricks, BigQuery and their peers work. It is a failure of ownership. When a central platform team is responsible for ingesting, modelling, cleaning, and serving every domain's data, three predictable pathologies emerge. First, backlogs - because every business ask routes through a single team. Second, quality decay because the people closest to the data (the operators of core banking, cards, claims, treasury) are not the ones who publish it. Third, opacity - because lineage becomes a story told after the fact rather than a property of the pipeline.
The winners of the next cycle will not be the banks with the biggest lake. They will be the banks that turned data into a product - owned, versioned, contracted, and discovered - and built the platform that makes doing so safe by default. This article sets out why the shift matters now, what "good" looks like, and how APAC BFSI leaders should sequence the move.
Data Investment Is Growing - Value Realization Is Not
APAC's data infrastructure boom is not in doubt. IDC's global data forecasts point to worldwide datasphere growth compounding at over 20% per year through the second half of the decade (IDC, 2024). Data-center capacity across the region - a proxy for enterprise data platform build-out - continues to expand at double-digit CAGRs, with Southeast Asia's hyperscale footprint (Singapore, Malaysia, Indonesia) among the fastest growing globally (JLL, 2024).
BFSI is the tip of that spear. Financial services rank consistently among the top two verticals for cloud and analytics spend across APAC in Gartner and IDC tracker series. Yet the value curve has flattened. McKinsey's global banking work in 2024 found that fewer than one in three banks could point to enterprise-wide, quantifiable P&L uplift from their data platform investments - despite an average of 3-5% of IT budget dedicated to it (McKinsey & Company, 2024b). BCG's global data survey has repeatedly identified a "leaders vs laggards" gap in data-driven performance of 1.5x-3x on financial KPIs (BCG, 2023).
In APAC specifically, three concurrent pressures are compressing the timeline for change:
- AI grounding. Every generative and agentic use case - from underwriting copilot to relationship-manager assistant - is bottlenecked by the availability of clean, discoverable, permissioned data. This bank has been made in earlier sourceCode pieces on agentic AI and copilots.
- Regulatory intensity. MAS FEAT, MAS Notice 655, APRA CPS 230 and CPS 234, HKMA's Supervisory Policy Manual, RBI's data localization guidance, and Bank Indonesia's data governance provisions all demand specific, lineage-traceable, time-stamped data, not spreadsheet reconciliations.
- Real-time economics. ISO 20022 payments, instant credit, streaming fraud, and open-finance consent all require data serving latencies measured in milliseconds - not the nightly cadence a central lake was built for.
The lake was the right answer to yesterday's question. It is not the right answer to today's.
Current Challenges: Five Symptoms of the Centralized Data Ceiling
Across APAC BFSI engagements, the same five symptoms recur. Recognizing them is the first honest step.
1. Consumption lag. Time from business request to production-grade data feed is measured in months, not weeks. A domain analyst waiting for a new credit-risk feature is often faster building a spreadsheet workaround than waiting for the central platform.
2. Quality debt compounding. Because the platform team owns publication, but the domain team owns the source, defects are caught late - often only when a regulator asks. BCBS 239 principles of data aggregation and risk reporting explicitly warn against this ownership gap (Basel Committee on Banking Supervision, 2013), yet in survey after survey, banks self-rate their BCBS 239 maturity as materially incomplete more than a decade after the principles were issued.
3. Discovery friction. Analysts cannot find what already exists. In one large APAC universal bank, an internal audit found more than a dozen versions of "customer" table lineage in production - each subtly different, each owned by no one.
4. Feature and model duplication. Data science teams build, retrain, and re-serve the same features across product lines because there is no shared, contract-backed feature layer. The economic drag is severe: teams spend, by common consulting estimates, 60-80% of data-science effort on data preparation rather than modelling (multiple industry references, including Anaconda's annual State of Data Science and similar surveys - commonly cited but should be verified for the current cycle).
5. Regulatory reporting fragility. Month-end reporting labor scales linearly with product complexity because there is no reusable, semantically stable data product for regulatory objects (exposures, positions, customers, transactions). This shows up in Big Four audit findings and in the persistent under-investment banks report in stress-testing infrastructure.
Each symptom in isolation is manageable. Together they cap the ceiling on how far AI, CX, and real-time regulation can go.
Key Trends: Four Shifts Reshaping the Bank's Data Operating Model
Shift 1 - From central lake to data mesh. Zhamak Dehghani's four founding principles: domain ownership, data-as-a-product, self-serve platform, federated computational governance - are being adapted rather than adopted wholesale (Dehghani, 2019; ThoughtWorks, 2022). BFSI's regulatory constraints make pure mesh untenable; the practical pattern is a hybrid - federated ownership of business-domain data products, on top of a strongly governed central platform for identity, security, catalog, and lineage.
Shift 2 - Data contracts as first-class artefacts. A data contract makes the interface between producer and consumer explicit - schema, semantics, freshness, quality thresholds, PII classification, and retention. It shifts quality from downstream reconciliation to upstream commitment. Data contracts are becoming to data engineering what API contracts became to microservices in the 2010s.
Shift 3 - Rise of the data marketplace. DBS's internal data marketplace, publicly documented in industry forums, exemplifies a pattern now emerging across major APAC banks: a discoverable, catalog-driven consumption experience where domain-owned data products can be requested, permissioned, and consumed without a central bottleneck (DBS, 2023). Standard Chartered's aXess data services and JPMorgan's Fusion platform are additional publicly discussed reference points from the global majors (Standard Chartered, 2022; JPMorgan Chase, 2023).
Shift 4 - Data + AI convergence. Feature stores, vector stores, embeddings, and RAG grounding data are converging with traditional data products. The Bank for International Settlements has flagged that AI adoption in supervised institutions is fundamentally a data-governance problem before it is a model problem (Bank for International Settlements, 2024). Institutions that have already productized data enter the AI cycle with a decisive head start.
Strategic Analysis: What "Data Product Bank" Actually Means
A useful working definition. A data product is a versioned, owned, contracted, discoverable, and permissioned unit of data - with a defined consumer, an SLA, a quality bar, and a business owner accountable for its health. A data product bank is one whose operating model, platform, and incentives are built around producing and consuming such products at scale.
Four consequences follow - each an executive-level design choice, not a technology decision.
A. Ownership is redrawn. Data products are owned by business domains (cards, mortgages, deposits, claims, wealth), not by the central data team. The central team owns the platform on which products are built and the governance rules they must comply with. This is the mesh principle, adapted for a regulated environment.
B. Contracts are enforced at build time, not audit time. A pull request that would break a downstream contract fails CI. A schema evolution that has no consumer sign-off cannot merge. Quality is a compile-time property, not a Monday-morning reconciliation.
C. The platform is a product too. The internal platform team ships developer experience - templates, catalog, lineage, observability, cost telemetry - as a product to internal domain teams. This is the same "platform engineering" thesis sourceCode has argued applies to AI-native delivery.
D. Governance is computational. Access control, PII masking, retention, region-of-residence, and consent enforcement are enforced in code and at query time, not in policy PDFs. Regulators, over time, will move from asking for documents to asking for evidence - computational governance is what makes evidence cheap.
The trade-off deserves an honest hearing. Federated ownership costs more in the short run - more domain data engineers, more platform capability, more coordination overhead - before it costs less. Institutions that do not commit to the operating-model change and hire the engineering talent to run the platform end up with the drawbacks of both centralisation and mesh, and the benefits of neither.
Real-World Examples: What APAC and Global Leaders Are Doing
- DBS Bank (Singapore). Publicly discussed its enterprise data mesh and data marketplace approach, with the bank's data leadership describing thousands of data products discoverable to internal consumers via a catalog-driven experience (DBS, 2023). DBS has consistently been recognized in global banking data-and-AI rankings during 2023-2024 (Euromoney; The Banker awards series).
- Commonwealth Bank of Australia. CBA has publicly discussed its investment in a customer engagement engine and its AI-and-data platform, presented as a productized, real-time capability rather than a project-by-project build (Commonwealth Bank of Australia, 2024, investor communications).
- Standard Chartered. aXess data services are described as an internal data platform combining marketplace, catalog, and shared services; the group has published on its data platform architecture in the context of client analytics and financial-crime detection (Standard Chartered, 2022).
- JPMorgan Chase (reference point). Fusion, the bank's data-management platform, provides discoverable, standardized, contract-backed data products to institutional clients and internal consumers, and is a widely cited reference in the industry (JPMorgan Chase, 2023).
- ING (reference point). The Dutch bank's public documentation on its data mesh journey, including the operating-model shift and the internal platform, has been influential in shaping banking-industry adoption of mesh (ING, 2022).
These are directional examples, not prescriptions. The pattern is consistent: an executive mandate, a platform investment, a catalog-first consumption model, and a redrawn ownership map.
A Sequenced Playbook for APAC CIOs and CDOs
1. Establish executive mandate before architecture. The single most reliable predictor of failure is starting with a mesh reference architecture and no CDO/CIO-level operating-model authority. Ownership boundaries - who owns customer data, who owns transactions, who owns product catalogs - must be settled before code is written.
2. Anchor on 5-10 high-value data products in year one. Do not try to boil the ocean. Pick the products whose reuse yields disproportionate value: authoritative customer, position/exposure, transaction, risk-adjusted revenue, KYC/AML entity, claims. Ship each as a contracted, discoverable product with a business owner.
3. Invest in the platform as a product. The internal platform team must ship self-serve capabilities - templates, catalog, lineage, contract enforcement, cost observability - that make it faster and safer for domains to publish a product than to work around it. If the platform is not faster than the workaround, mesh dies.
4. Adopt data contracts as a first-class artefact. Contracts should be versioned code, enforced in CI, and jointly owned by producer and consumer. Break-glass processes for schema evolution should be measurable and audited.
5. Wire regulation directly into the mesh. MAS FEAT, APRA CPS 234, HKMA and RBI data guidance should be encoded as platform-level policies - computational governance - not as slide-deck controls. This is the deepest source of long-term cost advantage.
6. Fund the operating-model shift honestly. Federated ownership requires domain data engineers, product managers for data, and a stronger platform team. Do not attempt the model with a hollow CDO office and a hopeful memo.
7. Instrument every product with a value scorecard. Consumption metrics, cost-per-consumption, quality SLIs, and business KPIs enabled. Data products that no one consumes should be sunsetted like any other software product.
sourceCode Perspective: The Engineering Discipline That Makes Federation Safe
Every mesh conversation ends up at the same place: "we agree on the principles - we don't have the engineering muscle to run this at BFSI scale."
At sourceCode, our work with APAC BFSI clients on core modernization, platform engineering, and AI-native delivery has surfaced a consistent conclusion. Federated data ownership is only as safe as the platform underneath it. That platform is not a purchase; it is a product - built with the same disciplines that make production software reliable: contract testing, CI-gated deployments, observability, cost telemetry, and a paved road that makes the right way the easy way.
Our engineering practice supports institutions across three fronts most banks find hardest to staff: platform build-out and hardening (self-serve, catalog, lineage, contracts), domain-team enablement (paved-road templates, coaching, contract patterns for regulated data), and computational governance (regulatory policy-as-code encoded into the platform). Each is where mesh initiatives most commonly stall, and each is where careful engineering, not slideware, decides the outcome.
The result - for the CDOs and CIOs willing to commit - is a bank where every new AI product ships faster because the data is already productized; every new regulatory ask is cheaper because the objects already exist; and every new market entry is quicker because the platform, not the project, is doing the work.
Conclusion
The centralized data lake was a defensible investment for a decade. It is no longer a defensible investment for the next one. The institutions that continue to add pipelines to the lake without redrawing ownership will find their AI ambitions bottlenecked, their regulatory bills rising, and their unit economics compressed. The institutions that make the operating-model shift - anchored on a small number of high-value data products, on a platform built as a product, on contracts enforced at build time, and on governance encoded in code - will run leaner, ship faster, and satisfy regulators with materially less friction.
For APAC BFSI, the window is now. The next 18-24 months will separate the banks that treat data as a product from the banks that continue to treat it as exhaust.
Looking to redraw the operating model behind your data platform - and build the engineering discipline that makes federation safe? Talk with sourceCode about designing and building a data product operating model for your bank or insurer.
Frequently Asked Questions
Is data mesh a replacement for the data warehouse or lakehouse? No. Data mesh is an operating and ownership model. Warehouses and lakehouses remain the storage and compute substrate on which domain-owned data products are built.
What is the difference between a data product and a dataset? A dataset is a table. A data product is a versioned, owned, contracted, discoverable, and permissioned unit of data with an SLA, a business owner, and a defined consumer. All data products contain datasets; not all datasets are data products.
How does data mesh comply with APRA, MAS, or HKMA data governance requirements? Mesh, correctly implemented, strengthens compliance because ownership is explicit, lineage is a property of the pipeline, and governance rules (PII masking, retention, region-of-residence) are enforced computationally rather than by policy document.
Does a mid-sized APAC bank need data mesh? Not necessarily. Institutions with fewer than roughly 30 domain teams often do well with a well-governed lakehouse and clear stewardship. Mesh becomes structurally attractive above a certain scale of domain complexity - usually the top ten banks in each APAC market.
What is a data contract? A data contract is a machine-readable specification of the interface between a data producer and its consumers - schema, semantics, freshness, quality thresholds, PII classification, and retention - enforced in CI/CD.
References
Bank for International Settlements (2024) Artificial intelligence and the economy: implications for central banks. BIS. Available at: https://www.bis.org/publ/othp84.htm (Accessed: 29 July 2026).
Basel Committee on Banking Supervision (2013) Principles for effective risk data aggregation and risk reporting (BCBS 239). Bank for International Settlements. Available at: https://www.bis.org/publ/bcbs239.htm (Accessed: 29 July 2026).
BCG (2023) Digital and AI leaders vs laggards: the widening performance gap. Boston Consulting Group. Available at: https://www.bcg.com/publications (Accessed: 29 July 2026).
Commonwealth Bank of Australia (2024) Annual results presentation - technology and data commentary. Sydney: CBA Investor Relations. Available at: https://www.commbank.com.au/about-us/investors.html (Accessed: 29 July 2026).
DBS (2023) Building a data-first bank: data marketplace and mesh approach. DBS technology forum communications. Available at: https://www.dbs.com/newsroom (Accessed: 29 July 2026).
Dehghani, Z. (2019) 'How to move beyond a monolithic data lake to a distributed data mesh'. martinfowler.com. Available at: https://martinfowler.com/articles/data-monolith-to-mesh.html (Accessed: 29 July 2026).
Gartner (2023) Predicts 2023: data and analytics - data fabric and mesh will dominate enterprise architectures. Gartner Research. Available at: https://www.gartner.com/en/research (Accessed: 29 July 2026).
IDC (2024) Worldwide Global DataSphere Forecast, 2024-2028. International Data Corporation. Available at: https://www.idc.com/getdoc.jsp (Accessed: 29 July 2026).
ING (2022) 'How ING has built a data mesh to accelerate data-driven decisions'. ING technology blog. Available at: https://medium.com/ing-blog (Accessed: 29 July 2026).
JLL (2024) Asia Pacific Data Centre Market Report. Jones Lang LaSalle. Available at: https://www.jll.com/en/trends-and-insights (Accessed: 29 July 2026).
JPMorgan Chase (2023) Fusion - data management platform overview. JPMorgan Chase & Co. Available at: https://www.jpmorgan.com/fusion (Accessed: 29 July 2026).
McKinsey & Company (2024a) The data-driven enterprise of 2025: eight characteristics that will separate winners. McKinsey Digital. Available at: https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights (Accessed: 29 July 2026).
McKinsey & Company (2024b) Building the AI bank of the future. McKinsey Global Banking Practice. Available at: https://www.mckinsey.com/industries/financial-services/our-insights (Accessed: 29 July 2026).
Standard Chartered (2022) aXess data services - a platform approach to enterprise data. Standard Chartered technology communications. Available at: https://www.sc.com/en/media (Accessed: 29 July 2026).
ThoughtWorks (2022) Data mesh in practice: principles and platform patterns. ThoughtWorks Technology Radar and publications. Available at: https://www.thoughtworks.com/insights (Accessed: 29 July 2026).