Many organizations have attempted to create centralized data groups (CDGs) responsible for sourcing, maintaining and distributing core data to all departments. There are clear reasons for doing this: efficiency, consistency, data quality, risk and regulatory compliance.
However, despite all of these drivers, very few organizations have created CDGs. Of the top 20 investment banks (as defined by asset size), only seven have created centralized structures approaching a CDG. Not one of them has managed to completely centralize all of their core data. Between the top 20 and top 50 investment banks, only a handful has a structure even remotely approaching a CDG.
CDG projects historically have enjoyed some of the lowest success rates in the industry. So much so that at least five major organizations we know of have not just tried to create a CDG once, but several times, and failed on all of them.
Why do CDG projects fail? It’s perhaps easier to point out where CDG projects don’t fail.
Technology doesn’t compromise CDG projects. None of the larger organizations who’ve created CDGs credit sophisticated technology as being a key to their success. The core data they maintain is in fact very simple. Across the seven of them the definition of a counterparty varies between just 20 and 40 fields. The data model needed to persist such simple data is not complex; in fact it’s virtually a flat file.
Nor is it processes that kill CDG projects. Pretty much all organizations have come to terms with initiatives such as KYC, and built client opening processes capable of meeting imposed standards. The problem is not that organizations can’t create adequate counterparty data; it’s that they can’t subsequently centralize it.
So what is it that’s so complex about centralization?
For the most part it seems to be because organizations drastically underestimate the strength of the forces that created their data silos in the first place.
On the surface of it silos shouldn’t exist.
Theoretically the first department to need counterparty data would create it locally, but subsequent departments would say: ‘Hang on, this data already exists in Department X. Let’s go to them rather than create a silo. It will be cheaper, and more efficient, and reduce risk.’ But that doesn’t happen.
To make matters worse, the argument that other departments should source their data from the CDG frequently doesn’t make economic sense either. Almost without fail the counter argument becomes: ‘You want me to spend my departmental budget to throwaway the data maintenance capacity that I spent a lot of money creating, to then pay more money to write links to your data, to then re-populate my systems with pretty much the same data as I just threw away?’ Followed hot on the heels with: ‘Anyway, there’s nothing wrong with my data, it works just fine for me.’
The real problem is that benefits only accrue from a CDG after the project is largely finished. Once everyone is looking at the CDG’s data, the benefits are suddenly manifest: reduced risk, greater efficiency, etc. But on the way, there the benefits are far less tangible; in fact, they might not even exist. Remember that when the CDG is first set up, and before it has a significant client base, it hasn’t simplified anything. Far from it: it’s actually become yet another silo in its own right; yet another cost centre.
The golden rule in all projects is to realize at least some economic benefit early, so ensuring continued support and funding, but that can be very difficult in CDG projects, if not impossible. And this seems to be where CDG projects tend to fail. They’re not overly complex, they don’t require enormous technology or labyrinthine process, not at all, but they do require a real change in corporate mindset.
Many organizations reach this conclusion and kick off CDG projects under the banner of a strategic goal. What they still tend to underestimate though is the sheer pressure that strategic goal will come under almost immediately. Everything in most banks conspires to sabotage CDG projects. They don’t deliver early value, they’re perceived (rightly) as high risk, many senior managers have been burnt by previous failures, there’s a continual fear the strategic goal will fail to deliver real return as so many strategic projects do, and in the short-term there are real, tangible pressures.
In essence, with regards to CDG projects, department heads and project teams are being asked to rise above their own concerns and put the ‘bank’ first. And that’s no small step to take. Most fail.
So how can organizations mitigate this risk? Governance.
Data environments don’t centralize naturally, quite the contrary, they fragment with quite alarming rapidity. It requires real cultural change to create a CDG. Some form of governance has to be put in place to battle all of the natural forces trying to tear the CDG apart. Departmental initiatives won’t create a CDG; neither will tactical cost-benefit analysis, or stated strategic aim. CDGs don’t fund themselves as they go and they don’t tend to be popular initiatives.
To succeed, CDGs need executives at board level to force cultural change and make clear that the creation of a CDG is going to happen, that departments will align to support the endeavour, that funding will be placed behind it, and that in future data consumers will subscribe to the CDG not as an option, but as a matter of fact.
Most organizations that have created a CDG, or who are meaningfully trying to build one, have encapsulated this cultural change in a set of golden rules.
The main purpose of creating golden rules is to generate a shared board-level vision of how best to manage a shared infrastructure asset.
The purpose of the golden rules is to bring greater rigour to future decision making processes, and to place the importance of clean data close to the heart of corporate culture.
By forcing compliance with golden rules, boards can affect significant change within their organizations, but only if it’s abundantly clear the rules are real and there to stay.
To download the full version of Azimuth’s white paper on the need for governance in data centralization projects, go to http://www.azdex.biz.
Subscribe to our newsletter
