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

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. 

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.

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.

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