Over the last decade or so, many established players have transformed the shiny frontends of their digital channels. However, the backend and systems of record that underpin these offerings are often traditional and monolithic in nature.
ML in the immediate future and AI in the medium term can be transformative for the financial services sector as a whole. What we have unveiled over the course of this blog series, is just how vast the amounts of customer, business, transactional and financial data these organisations have at their fingertips. Whilst the use cases we have covered illustrate that ML & AI enable firms to:
1) Become more operationally efficient.
2) Enhance customer experience and more.
3) More effectively manage their balance sheet.
4) Control risk management practices.
However, whilst we have alluded to the art of the possible for banks and insurers alike, implementing these solutions is a challenging undertaking. In essence, successful and effective deployment of ML & AI requires data to be easily discoverable, accessible and of high quality.
Clean and high-quality data is the bedrock of a technology strategy that wishes to deploy ML & AI-driven business services and applications. Therefore the first step in any ML & AI strategy is to ensure your data sets are cohesive, cleansed and interpretable. Earlier in this white paper, we used the terminology “garbage in, rubbish out”. The same can be said for ML & AI. If the models your organisation wishes to deploy are trained on bad data, then the resulting outcomes can be detrimental to your businesses performance. In a highly regulated environment like financial services, these disruptions can be catastrophic to the firm, its customers and the wider market.
In this instance, we believe a data mesh approach should be used to underpin the technology and operating principles for any financial services organisations that are seeking to deploy ML & AI at scale.
We define data mesh as “an organisational, technical and architectural approach that unlocks data, to increase business value. It enables unbounded possibilities and outcomes in scenarios where machine learning, artificial intelligence, analytics or data-intensive applications are applied to solve complex problems”.
When we overlay the challenges referenced earlier by financial services organisations around the accessibility to high-quality data legacy systems. Data mesh is founded on a set of architectural principles that can be used to overcome these very challenges. They are as follows:
1) Move towards a domain-driven approach for data management:
Inspired by Eric Evans’ concept of domain-driven design, the data mesh turns how we think about ownership in the world of data upside-down. Rather than thinking in terms of pipeline stages (i.e. data source teams shipping data to a central data lake to be sifted through by a centralised data team, who then prepare it for data consumers), we think about data in terms of domains (e.g. marketing or finance). This is much more useful from a business perspective as it maps much more closely to the actual structure of your business. Importantly, domains can be followed from one end of the business to the other, meaning teams are accountable from end-to-end and that their processes can be scaled without impacting other teams.
Why does it matter to Financial Services?
This makes perfect sense in a financial services business where organisations are typically structured by-product lines (e.g., motor insurance, mortgages), asset classes (fixed income, foreign exchange) and important business services (e.g., make a claim, make a faster payment). Furthermore, lines of ownership and accountabilities can be clearly defined given the need to demonstrate this type of information to regulators.
2) Implement a federated data governance structure and operating model:
Federated data governance in a data mesh describes a situation in which data governance standards are defined centrally, but local domain teams have the autonomy and resources to execute these standards however is most appropriate for their particular environment. In this model, autonomous data domain teams and centralised data governance functions collaborate in order to best meet the data needs of the whole organisation. In this way, teams can “shift left” the implementation of data governance policies and requirements in order to embed them into their data products early in the development lifecycle.
Why does it matter to Financial Services?
By federating data governance, financial organisations can still continue to centralise policies and controls. Which is a behaviour and practice that they have become accustomed to in their existing data operating models. However, they can remove the burden of creating a single team that is responsible for enforcing and administering these policies by deploying modern data management practices, high levels of automation and more granular & traceable accessibility controls.
3) Treat data as a living and breathing product across their business:
By thinking about data in terms of domains, this enables a shift towards Product Thinking. Product Thinking emphasises solving the customer’s problem as the main priority of any task or project. So keeping your eye on the business goal, rather than getting lost in technicalities. The paradigm shift is for these data domains and their teams to start thinking about themselves as a ‘mini enterprise’ that is building a product (high-quality, accessible data sets) that will make their customers (lines of business, other data teams etc.) deliriously happy!
Why does it matter to Financial Services?
Financial organisations are sitting on a wealth of customer information. The challenge for many is getting access to it in a timely manner. By treating data as a product, it makes data everyone's responsibility in the organisation. Enabling cross-functional teams to better understand real customer needs and identify ways in which they can monetize their data with differentiated products and services that outstrip the competition.
4) Introduce high levels of self-service automation across data infrastructure and analytics tiers:
The one problem you might foresee with such domain-specific mini enterprises is that there would be a lot of duplication of effort (particularly with each needing their own data pipelines and infrastructure). But, again, this is a solved problem in the software development space. The data mesh approach is to leverage the cloud and automation to create templates for self-serve data infrastructure that any team can instantly spin up. This ‘universal interoperability layer’ means each domain can handle its own pipelines while maintaining company-wide data and security standards.
Why does it matter to Financial Services?
Self-service doesn’t mean chaos and unruly consumption. Financial organisations can create highly automated blueprints and pre-approved infrastructure patterns that are codified, version control and immutable. Furthermore, each and every action can be tracked and traced with rigorous access control policies and granular identity and access management privileges.
Whilst a full audit trail of who did what, when and why can be monitored end to end with configuration management, real-time telemetry, observability and notification systems. This self-service utopia can be achieved with DevSecOps principles at its heart. Self-service can be the dream of regulators and compliance teams, as separation of duty concerns can be fulfilled and demonstrated in almost real-time.
By applying these principles and technology capabilities like cloud; data discovery, metadata management and data accessibility, ML & AI become more manageable at scale. Which, in a complex financial services organisation, is music to the ears of CIO’s, CTO’s, CDO’s!
Finally, there is a heightened level of focus across financial services with regulators becoming more concerned around material outsourcing to the public cloud. As well as an increasing reliance on critical third parties. This is particularly prevalent in data-intensive systems and firms are being instructed to ensure that they have “exit strategies” in place. This is to protect against systemic outages, operational disruptions or the need to urgently move core services to another hosting provider in the event of a commercial challenge based on consumption levels. In essence, the exit strategy is a backstop that is aimed at preventing systemic outages that could disrupt the financial markets.
It should be noted that whilst it is a somewhat trivial task to migrate an application tier. Moving petabytes of data in a rapid manner is not as easy. Ultimately, this means that financial services organisations are adopting a multi-cloud approach which will result in their data being stored and replicated either on-premise or in the public cloud, with a single or many trusted suppliers. As such the practices and principles referenced above become all the more compelling to support this type of regulatory requirement. As well as the business-driven use cases we have discussed over the course of this blog.
Having explained how to tackle the data quality challenges and accessibility constraints identified by financial organisations with a data mesh approach. In our final blog as part of this series, we will discuss how MLOps can address the model lifecycle management, explainability and risk management concerns for financial services organisations.
We will specifically explore the following talking points:
1) What is MLOps?
2) Why does it make sense for the financial services sector to adopt MLOps?
3) MLOps and the use of responsible ML & AI in financial services.
4) How does MLOps enable safe & scaled adoption of ML & AI?
If you want to be competitive, you need to sort your data constraints, and that's where Mesh-AI can help. Identify the areas in your organisation that require the most attention and solve your most crucial data bottlenecks. Get in touch with us at hello@mesh-ai.com for a Data Maturity Assessment.
Interested in seeing our latest blogs as soon as they get released? Sign up for our newsletter using the form below, and also follow us on LinkedIn.
.png)
.png)
