Recovery and resolution: Why bank technology must be flexible and robust

2014/01/13
by Hans Tesselaar, Executive Director of BIAN
Publication: Bobsguide


Hans Tesselaar is the executive director of the Banking Industry Architecture Network (BIAN), a worldwide not-for-profit with over 45 tech and banking members, dedicated to creating a de-facto open standard for Service Oriented Architectures (SOA) in the banking industry. He is a member of the bobsguide blogger (aka contributing editor) team.

There has been a great deal of discussion in recent years about separating ‘zombie banks’ out into their ‘good’ and ‘bad’ parts in an effort to prevent the latter from contaminating the former, and how best to dispose of those failed institutions that cannot be rescued. Whatever recovery and resolution regime is implemented by various countries and regions to address the key post-crash issue of ‘too big to fail’, technology will always play a central part in its operation, says Hans Tesselaar, executive director of the Banking Industry Architecture Network (BIAN), in this review of the supporting technology and the differing approaches of the UK, EU, Netherlands and elsewhere.

The UK had its post-crash Vickers report emphasising Chinese walls and ring-fencing, while the EU has its Liikanen stipulations, and even the global Financial Stability Board (FSB) has addressed the ‘too big to fail’ issue of how best to wind up banks that have failed.

There have also been numerous regulatory initiatives such as the move towards centralised trade repositories — under the European Market Infrastructure Regulation (EMIR) and SEFs under the US Dodd-Frank and other rules — and efforts to introduce standardised common legal entity identifiers (LEIs) on the derivative and other financial markets. All of these efforts are aimed at making it easier to recover or unwind trades in the future at failed financial institutions (FIs), such as Lehman Brothers, and to prevent contagion spreading into the wider banking and financial markets.

Recovery and resolution regimes matter, therefore, and in this blog I’d like to take a look at them and some of the technology needed to support them. Generally, it is fair to say that introducing electronic platforms to do away with any remaining paper-based processes and introducing real-time reporting and risk monitoring obligations are the key tech trends resulting from the stricter post-crash global regulatory regime now coming into force. This rule of thumb applies to winding up FIs as much as it does overseeing them on a day-to-day basis.

In future, bad assets such as illiquid and risky securities assets and non-performing loans can be more easily segregated from the ‘good’ assets of a struggling bank, which provide on-going business for the institution. We saw this recovery procedure on numerous occasions after the 2008 financial crisis with RBS and many others being split up into ‘good’ and ‘bad’ banks, but the process was very very slow. It need not be under the new recovery regime in the UK which is in-line with other similar initiatives worldwide. Indeed the ‘bail-in’ procedure enacted in the UK to save the troubled Co-op Bank last year illustrates some of the changes and present realities, while also emphasising how difficult it is to separate out IT systems.

Recovering Banks Presents Technological Challenges
Facing a liquidity crisis, banks must be transparent and robust. Ring-fencing off trading activities, if appropriate, significantly reduces the risk profile of a struggling universal bank, while splitting up large banks is also a way of breaking up the monopoly of big FIs, thereby increasing competition and prudence on the High Street.

As simple an idea as this may sound, splitting banks apart during recovery procedures is a complex and risky business. It could lead to hugely expensive outgoings as banks are required to separate and rebuild IT systems that were not designed to be split — just look at the recent TSB example in the UK, which only arose because of the failure of the Co-op’s proposed takeover. The similar project rainbow exercise at RBS is also pertinent to this discussion.

Dutch Example
The same recovery issue was recently discussed in the Netherlands by the Commission on the Structure of Dutch Banks. During the Commission’s investigation into how best governments can support the stability of a banking system the proposal was put forward that if trading activities exceed a certain limit they should be protected from the deposit bank and accommodated within a separate legal entity, in order to reduce risk. This mirrors the UK Vickers report idea of ring-fencing.

In an effort to restore trust in the Dutch banks — where ABN Amro famously imploded despite RBS’ ill-timed takeover of its trading arm, igniting its own troubles — the government and the Commission in the Netherlands are seeking to ensure that they are better protected in future. The Commission has argued that Dutch banks should from now on be organised in such a way that they can be separated out quickly in the case of an emergency.

Yet, with banking IT infrastructures currently a tangled mess of age-old siloed systems and isolated ad hoc updates and bolt-ons, this is easier said than done. A quick separation of retail and investment banking activities at a Dutch universal bank would currently be impossible, but this is changing and technology will have to be at the forefront of the new recovery regime. Service orientated architectures (SOAs) can help make more flexible and changeable IT infrastructures a reality and that is why I believe they are key to this debate.

Conclusion: SOAs can help
Recognising the importance of technology in recovery regimes, the Dutch Commission identified enterprise architecture as a key element in rectifying the muddled situation that arose back in 2008. The Commission highlighted the importance of technology in its report entitled ‘Towards a serviceable and stable banking system’ and knows that an SOA can help.

By relying on a SOA that separates out processes into business functions, banks can in future more easily straighten out their IT infrastructures and turn the present siloed mess into building blocks of pre-defined services; thus making a split more manageable. In the event of a bank split, this approach would enable the necessary changes to be made one layer at a time, without disrupting the whole system.

Implementing a common enterprise architecture approach across the entire financial system would take time but it is an achievable goal, especially if FIs and tech firms can agree on shared software and development standards to ensure a flexible SOA is possible. Encouraging this type of collaboration is BIAN’s mission and I believe the need for better, quicker recovery and resolution regimes in the future can aid this drive.

By starting work now, banks could at least lay the foundations of a stable system and prepare themselves in case — god forbid — another financial crisis should occur that demands the recovery and resolution of more FIs in the future. A good starting point would be if central banks and their members would begin using the same SOA reference model to ensure they all speak the same interoperable tech language in the future.