What are the specificities of setting up and ensuring the reliability of a third-party repository in the finance sector?

Table of contents
Share:
Discover Phoenix Data Platform
Mise en œuvre référentiels tiers dans la banque et l’assurance

In a banking and insurance sector marked by the multiplication of products, the fragmentation of information and increasingly stringent regulations, the implementation of a reliable third-party repository is an imperative. Between data quality requirements, 360° customer consolidation and regulatory compliance, banks and insurers need to guarantee a unified vision of their customer data.

But how do you make a success of this project specifically in the financial sector, and what are the specific issues to be anticipated? In this interview, we explore these issues with Frédéric Toumelin, an expert in data governance in the financial sector. He shares his experience of how to make a third-party repository reliable, and get the most out of it.

What are the specific features of a third-party repository in the banking and insurance sectors?

What makes the subject of third-party repositories particularly complex in the banking and insurance sector is, above all, the fragmentation of information and the diversity of sources that feed it. Unlike other industries, where customer data is centralized in a single CRM or ERP, banks and insurance companies have historically organized their systems around products, not customers.

Let’s take a concrete example: when a customer opens a current account and then takes out a mortgage a few months later, the information is often stored in separate systems, sometimes with no interconnection. This is the result of a sales approach that has long favored the sale of specific products (savings, consumer credit, car insurance, etc.) where each department or subsidiary has its own tools. The result: a fragmented view of the customer and difficulties in unifying data.

Another specific feature is the concentration of the sector. Mergers and acquisitions have led to the juxtaposition of heterogeneous information systems. When a bank or insurer takes over a competitor, consolidating customer databases is often a headache. You end up with technological silos, and different ways of structuring information. This necessarily complicates the consolidation of a 360° vision of the customer, and the implementation of consistent data governance.

What factors in particular make managing repositories more complex?

Another fundamental challenge is that banks and insurance companies do not manage all their customer interactions directly. Distribution often relies on an ecosystem of third parties: brokers, general agents, B2B partners… all of whom handle customer data without necessarily following the same standards.

In a B2C model, a bank can deal directly with its customers, but when a product is sold by a network of partners, the information fed back is not always homogeneous. Each partner applies its own contract and customer management logic, which complicates data synchronization.

The insurance sector adds a further layer of complexity with the notion of beneficiaries. An insurance contract may cover several people in the same family, creating links between customers, beneficiaries and policyholders, which need to be modeled precisely to avoid errors and inconsistencies. Mastering the links between B2B and B2C customers also brings value in knowing the context of each customer. The relationship between natural and legal persons is not the same as in other sectors, and modeling it is important for better risk management.

When the relationship between several customers changes (divorce, marriage, independence of a child…), you need to be able to pass on the information and manage the evolution of the relationship. Reconciliation and change management are particularly thorny issues.

Finally, certain specific models, such as mutualism, introduce unique challenges. Member-policyholders are both customers and shareholders, which implies decentralized information management. Regionalism and local entities also accentuate the weak interconnection of systems.

To sum up, there is no single model for third-party repositories in the banking and insurance sectors. Some entities opt for a single repository for all third parties (customers, partners, suppliers), while others prefer a finer segmentation according to typologies. The key is to strike a balance between consolidation and flexibility, while guaranteeing data reliability to meet compliance and risk management challenges.

What are the strategic and regulatory challenges of a third-party repository in banking and insurance?

Behind the implementation of a third-party repository, there is of course a challenge common to all sectors: the ability to offer a consolidated vision of the customer, and to steer the company towards a customer-oriented model rather than just a product-oriented one.

In the financial sector, even more than in other industries, a third-party repository is indispensable. Customer interactions pass through a multitude of channels, subsidiaries and partners. Without a suitable repository and a rigorous data governance strategy, it’s impossible to have a reliable, usable view of customers.

Another unavoidable issue is regulatory compliance. The RGPD, of course, imposes strict management of personal data, but the financial sector is also subject to specific regulations, dictated, for the most part, by the need to control systemic risks.

Let’s take the example of credit: each institution is required to submit precise data to regulators as part of the AnaCrédit collection process, a reporting system detailing every loan granted (amount, rate, customer profile, etc.). This information is consolidated at national level and then transmitted to the European Central Bank to monitor any risk thresholds that may have been exceeded.

In the insurance sector, Solvency II imposes similar requirements. An insurance company exceeding certain thresholds may be considered insufficiently covered, leading to restrictions or additional obligations.

In this context, the quality of reporting is non-negotiable! When a bank or insurance company groups together several subsidiaries operating with heterogeneous systems and methodologies, data consolidation is a challenge. Not only must information be unified and standardized within a repository to guarantee its consistency, but it must also be ensured that it flows smoothly between the different systems via harmonization and transcoding processes.

In addition to regulatory imperatives, reputational risk is also at stake. Trust is the cornerstone of the banking and insurance industries. Data mismanagement (contractual errors, dissemination of erroneous information, etc.) can have major consequences that are out of all proportion to other sectors.

In the financial sector, customer expectations regarding the management of sensitive data and the prevention of incidents are at a very high level!

What are the keys to success, and what advice do you have for successfully implementing a third-party repository in the financial sector?

The first step is to define the data model. We need to identify the attributes that will be managed in the repository, and precisely map the applications that manipulate this data. This enables you to determine where the golden data will be shared and which applications will need to subscribe to it. Without this upstream work, you run the risk of ending up with a poorly integrated repository that is under-utilized and under-performing.

Depending on initial maturity, a preliminary step may be to take stock of the organization’s entire data assets, using data mapping tools.

Another key point is data quality. It’s not enough to store information, we also need to ensure that it is reliable, consistent and usable. This requires strict rules for quality assurance, with clearly defined processes and responsibilities, as well as the application of regulatory constraints such as the RGPD or security standards specific to the financial sector, such as PCI DSS. As soon as the repository feeds into regulatory reporting, it falls within the ACPR’s potential scope of control. It must therefore be auditable, and prove that the company has full control over its data.

Another key point is data quality. It’s not enough to store information, we also need to ensure that it is reliable, consistent and usable. This requires strict rules for quality assurance, with clearly defined processes and responsibilities, as well as the application of regulatory constraints such as the RGPD or security standards specific to the financial sector, such as PCI DSS. As soon as the repository feeds into regulatory reporting, it falls within the ACPR’s potential scope of control. It must therefore be auditable, and prove that the company has full control over its data.

Synchronization with the applications that will consume the data must also be taken into account in your third-party repository project. How will the exchange flows work, and who will be using the data? Customer advisors, offer managers… Each category of user has specific expectations, and it’s important that data is structured accordingly.

Setting up a third-party repository also involves a phase of historical recovery and quality enhancement of existing data. This is where the “Garbage In, Garbage Out” principle comes into play. If the data integrated into the repository is erroneous or incomplete from the outset, it will remain so at the end. A good approach is to automate data quality as soon as it is created, using BPM (Business Process Management) processes integrated into forms and portals, rather than relying on uncontrolled manual input.

Finally, the repository should not be seen as a static base, but as a central element of the IS, constantly evolving and interacting with other applications. The challenge is not only technical, but also organizational. That’s why a strategy of continuous improvement is essential, with regular monitoring of data quality and the involvement of business functions in validating management rules.

The value of a repository in the financial sector also lies in its ability to evolve and adapt to new business and regulatory needs. Governance can provide agility in the face of changing market conditions!

What solutions does Blueway offer to meet the challenges of data quality and the implementation of third-party repositories specifically adapted to the banking and insurance sector?

With the MDM Master Data Management module of its Phoenix data platform, Blueway offers banks and insurance companies a complete solution for setting up, structuring and securing their third-party repositories.

What’s more, Phoenix’s modular approach (MDM, BPM, ESB/ETL, APIM, Data Catalog) enables us to adapt to your technological environment. Our customers activate only the bricks they need – in addition to the third-party repository – ensuring seamless integration with their existing IS. To speed up implementation, we also offer pre-configured data and process repository models.

As a French software publisher, Blueway meets your digital sovereignty challenges. We also give financial players the choice of SaaS or On-Premise deployment, depending on their architectural choices and security constraints. And with our Finance Business Unit, we guarantee personalized support and an understanding of your challenges and your business language!

Photo Frédéric Toumelin
Frédéric Toumelin
With more than 20 years’ experience in strategic support, Frédéric works with banking sector executives to advise them on the tools they need to implement an effective approach to maximising the value of their data assets.
In the same category: Data Catalog & Data mapping