9 Apr 2024
Weekend celebration in Barcelona city with light with the main subject. Llum BCN 2016.

How banks can leverage internal data markets to curb data mesh-led risks

Authors
Henrik Hilberts

Partner, Financial Services, EY Sweden

Henrik has devoted his most recent 25 years to serving the international financial services industry with focus on digital transformation thought leadership and forming world class consulting teams.

Fredrik Gyllenswärd

Senior Manager, Data & Analytics, Financial Services, EY Sweden

FS transformation consultant with 21 years of experience.

9 Apr 2024

We explore how banks that adopt data mesh, as part of their efforts to adapt to the ecosystem trend, can tackle some of the subsequent risks. 

In brief

  • Many banks that embrace the enduring 25-year-old global ecosystem trend actively seek operating models that align with this evolution.
  • Emerging three years ago, data mesh, an operating model for federated data management, has grown popular yet it brings risks that call for mitigation strategies.
  • The data marketplace, explained in this article, is a likely tool to mitigate parts of these risks, especially if combined with monetization and contracting. 

Aquarter-century ago, the banking ecosystem trend, known in data lingo as federated data management, gained significant momentum. The internet was born, and the erosion of isolated monolith banks had begun. Many years later, we can see some banks struggling with challenges such as rising data integration costs, hampered IT innovation, stale data management and a constant battle with the continuous change in data regulations (BCBS 239, GDPR, AI Act, DORA etc.). Part of the explanation to these challenges might just be that they have fallen behind on this seemingly persistent trend.

The evolving corporate ecosystem world has heightened the demand for efficient data integrations and prompted banks to seek more cost-effective and risk-controlled data operating models. One such model, data mesh (Fact box 1), emerged about three years ago and has ever since steadily gained traction. In 2023, we can see numerous Fortune 5000 companies prioritizing data mesh in their change portfolio and bank clients do ask us about this operating model and how to make it all work.

Data mesh has attracted many with possible advantages such as; reduced integration costs, accelerated innovation, streamlined change processes and enhanced data management. While we have guided numerous clients on harvesting these, we also recognize the importance of understanding and mitigating the associated risks.

  • Fact box 1 - Data mesh

    • Zhamak Dehghani and Martin Fowler are prominent contributors to the data mesh community. They published their first article in 2019, and in 2022, Zhamak authored the globally acclaimed book (reviewed by Martin): "Data Mesh: Delivering Data-Driven Value at Scale," O’Reilly, 2022.
    • At this juncture, EY teams perceive data mesh as a paradigm shift in operating models, leading to subsequent technological changes. This shift impacts both analytical (e.g., reporting) and operational (e.g., transactional) data.
    • Zhamak outlines four design principles in her book: viewing data as products, establishing domains, leveraging self-service platforms, and implementing federated governance.
    • Self-service platforms can be implemented either centrally or in a federated manner through logically separated solutions or physically distinct platforms.
    • In our perspective, existing central solutions, such as data fabrics and warehouses, can be repurposed to function as self-service platforms. However, in such cases, they are no longer mandatory and face ongoing competition from other platforms, such as the cloud.
    • A data mesh can be incrementally implemented to facilitate adaptations, assess value and right-size the approach. Refer to Figure 1 for a theoretical implementation two years from now.

We will explore a few of these risks in this article but before that its worth mentioning one quite significant benefit which is how banks can leverage data mesh to enhance their investments in group-wide mandatory central data warehouses and platforms. For instance, most large Nordic banks have well over 3,000 IT systems running in parallel, and the effort to centralize all related data has proven complex, with issues ranging from resource bottlenecks to unnecessary integrations, outdated central data catalogs, and business teams' preferring alternative solutions. Consequently, banks have begun exploring data mesh-like solutions in parallel as part of their ongoing evolution and in hope of finding a value adding balance between “stifling but organized centralization” and “simple but overlapping federated data management”.

We have advised clients on risk management for well over a century, including strategies on how to navigate regulatory and business driven data risks. Data mesh is no exception and while we cannot share our complete risk catalog here, we will give you some examples which are: mismatched local data silos, failure in meeting data contracts, data producers and consumers – failing to report changes, incomplete cost impact assessments and neglected considerations for scalable solutions.

When it comes to mitigating these risks, we see a recurring topic which is the data marketplace (Fact box 2). This component appears to play a pivotal role in building a functional data mesh and it is borderline to being a necessity in mitigating many of the aforementioned risks. In particular, when equipped with the following two experimental features: monetary and contractual incentives.

In short, a data marketplace incorporating monetary and contractual incentives seems to reduce risks even more than those who do not. As these two incentives may appear as complex features to implement, let us share some of the rationale behind them. 

First, assigning value to intangible assets is not a novel concept. Similar to the introduction of goodwill in the 1940s data is acknowledged to have value. While we are not proposing changes to balance sheets as such we still argue that discussing this value of data in the light of the persistent global ecosystem trend holds relevance, and the data marketplace appears to be a suitable starting point for such value or monetization discussion.

Second, banks have long managed externally procured data with diligence and rigor. The primary distinction between these data flows and the internal ones is the presence of monetization and contractual incentives. We simply see potential value in extending these practices to internal data.

Third, a marketplace without monetization risks becoming a stagnant, disregarded and painful governance component — similar to many current data dictionaries, catalogs and other metadata solutions — instead of a vibrant, natural and simple source of insight.

  • Fact box 2 – Data marketplace

    • Our current definition of a data marketplace entails a solution where data producers and consumers can discover, manage and trade data. In Zhamak's book, the marketplace or discovery tool is primarily envisioned as an automated data mesh component. However, until this long-term vision materializes, there remains a need for a visual digital experience to align with our proposed definition.
    • Consequently, a marketplace operating model should be built with the expectation of having such a visual tool available. The related policy should be led by the federated governance team, a pivotal function within the data mesh.
    Examples of likely sections in this policy include:
    • How the marketplace will facilitate cross-domain data lineage and semantics.
    • Procedures for automated reconciliation, if needed (e.g., risk data or BCBS239).
    • Guidelines for contracting between legal entities, data pricing and accounting.
    • Directions on mandatory metadata and cross-marketplace interfaces.
    • Clarifications regarding data ownership, quality responsibilities and data governance.
    • Protocols for trading data products outside the market and with third parties.
    • The subsequent technical platform should prioritize simplicity, and it's not necessary to use the same marketplace solution throughout the entire organization.
    Some technical design principles for such a platform could include:
    • Providing access to parts of the marketplace without requiring logon, enabling immediate use.
    • Allowing for data to flow outside the marketplace when necessary.
    • Simplifying accounting and transaction processes if monetization is involved.
    • Involving interaction designers to optimize the tool for efficiency and effectiveness, considering it a professional tool.
    • A marketplace with monetization and contracting capabilities can integrate with data catalogs, dictionaries and other metadata tools and may even replace them over time.
    • We anticipate that prices in a monetized solution will be determined by supply and demand, with occasional policy interventions for support.

Fourth, a select group of our clients are already considering experimental monetization incentives. Given that most banks already have established intra-group invoicing procedures, incorporating this sort of transactions into existing service catalogs should not be an insurmountable challenge. It is also unlikely to have significant implications for taxation or external reporting, but we recommend consulting with tax and accounting specialists on this topic (especially for cross-border or inter-entity transactions).

Regarding contracting, many data transfers at banks typically already involve a service level agreement today. Data mesh embraces this approach and takes it even further with so called data contracts and - the data marketplace is a natural focal point to facilitate and manage these. Through contracts - which may encompass shared service level objectives, policy implementation through code, data recency standards, data product guarantees, and considerations related to regulations such as privacy and outsourcing - we can among others mitigate risks associated with data inaccuracies that long data transfer or trade chains may entail. We can also foster more trust between “consumers or buyers” and “producers or sellers” of the data.

It's important to note that there are at least two types of contracts in this context. First, there's the general contract that all data marketplace users must adhere to. This includes minimum documentation, a code of conduct, defined responsibilities and platform service level agreements. Second, there are the data product contracts, which are the specific agreements discussed here, tailored to the exchange of particular data products.

In a typical ecosystem, data products are exchanged among various groups (domains), both within the legal entity as well as with third parties. To effectively mitigate these additional risks, we recognize the need to facilitate pragmatic contracting across the entire trade chain and as mentioned, the data marketplace is a natural facilitator to this.

So, to wrap it up, when banks consider implementing data mesh operating models – e.g., to meet the persistent ecosystem evolution - we acknowledge the mix of benefits and risks associated with this work and also believe that a well-designed data marketplace can play a significant role in mitigating some of these risks.

How do EY teams assist clients in implementing data mesh?

We have supported numerous clients on their data mesh journey, some examples:
  • Planning the implementation of data products across enterprise data domains
  • Formulating strategic approaches toward data products and self-service platforms
  • Developing case studies to explore first steps toward data mesh operating models
  • Implementation of such data mesh operating models, often including early versions of data marketplaces
  • Establishing early versions of data marketplaces to democratize data access

Figure 1: a theoretical mesh implementation two years down the road. At this financial institute three groups (“domains”) have embraced the operating model, two of these share a data marketplace and one has its own. Whilst all data flows are visible through these marketplaces, the actual physical integrations are not necessarily implemented in the marketplace as such.

Summary

The global corporate ecosystem trend continues blurring the lines between bank’s internal and external functions. Data mesh, an operating model for federated data management, can support this evolution, but it also comes with risks. We consider data marketplaces, with experimental tests on monetization and contracting features, to be a fundamental component when managing such risks.

About this article

Authors
Henrik Hilberts

Partner, Financial Services, EY Sweden

Henrik has devoted his most recent 25 years to serving the international financial services industry with focus on digital transformation thought leadership and forming world class consulting teams.

Fredrik Gyllenswärd

Senior Manager, Data & Analytics, Financial Services, EY Sweden

FS transformation consultant with 21 years of experience.