Financial services firms can use interbank offered rates migration as a springboard to transform their approach to managing technology.
As banks and other financial services organizations gear up for the big migration from London Interbank Offered Rates (LIBOR) and other Interbank Offered Rates (IBOR) to new Alternative Reference Rates (ARRs), the major repercussions for technology and data requirements need attention.
A significant proportion of a bank’s systems are likely to be impacted directly or indirectly by IBOR migration. The first step in addressing such a major systems change challenge is to identify exactly which systems are affected by IBOR migration, and then to understand the level of change required. Is this an activity that can be treated as business as usual? Or should it be regarded as a separate activity outside business as usual? Different approaches can also be taken to this identification issue, such as manual analysis, looking at models or scouring systems logs. Third-party applications, e.g., market data providers, create further complexity as there is potentially less control over the change timeline as well as downstream dependencies.
This exercise could be viewed as a one-off, manual activity, but this does not help to prepare the business for handling future systems changes efficiently. There is no “repeatability” built into the response. A more considered approach is to view IBOR migration as an opportunity to make structural changes to the way that financial services organizations approach technology delivery – to start embedding a methodology, roadmap and tooling across the organization to support a consistent ongoing approach to systems updates.
This begins with building a detailed understanding of what specific systems are doing. This in turn supports the creation of a design pattern for the way that wholesale systems changes will be handled across the organization. The result should be greater consistency in the way that different application owners solve the systems change problem – and greater predictability around the timing, effort and skills required.
Take the example of testing. New systems supporting the trading of new ARR-linked products will need thorough testing before going live. We’re challenging clients to think about whether they should be trying to automate as much of this testing as possible, or moving to some form of testing service, whether internal or external.
Financial services organizations must remain focused on the need to treat customers fairly as existing contracts are repapered or new ARR-based products are taken up. For example, what happens when a client formerly “in the money” on their old IBOR-based product becomes “out of the money” on the new ARR-based product? Organizations will need to be able to demonstrate that they have followed proper processes and helped clients to understand the impacts of IBOR migration – and that will require data.
Organizations need to consider what data they need to not only treat customers fairly, but also demonstrate they have done so to regulators. They need to consider how to capture that data with the right detail and over the appropriate periods. They also need to assess how – and how long – to store that data. The answer should take account of the type of customer (e.g., a small or medium size enterprise [SME] may need a different approach to that applied to a professional investor) and the jurisdiction involved.
IBOR migration poses a huge logistical challenge. Take the issue of repapering. Banks and other financial services organizations face the significant task of accessing and understanding the details of vast numbers of contracts. Tackling this manually would require an extensive human resource commitment. Technology can help by the creation of a digital contract warehouse and the use of artificial intelligence to read and interpret contract details. Machine learning, natural language processing (NLP) and other forms of algorithms can be used to capture information so that the context of contractual wording can be understood without human interaction. By applying technology in this way, organizations can accelerate their repapering activity and maintain high levels of accuracy.
Although organizations are currently focusing on contracts, IBOR references occur in many other documents and formats – for example, in invoices and annual reports. At some point, organizations will need to consider whether they might have any associated exposures, which may require sampling across a broad set of documents. Manual sampling and review is likely to be impractical. Applying technology may provide the only way to gain insight into the full scope of IBOR-related exposures and take mitigating action.
Looking ahead, the financial services sector is moving from an environment defined by written documentation to one where exchanging information electronically and contracting electronically is the norm. Digitizing contracts therefore not only addresses the IBOR migration challenge; it also creates the foundations for the development of forward-looking digital contracting – or smart-contracting – operations that could enable new ways of working, as well as enhanced efficiency.
Using IBOR migration as a springboard, control functions have a real opportunity to embrace technology to transform their way of working. Client outreach and the process of contract repapering need not be a time-consuming, paper-based process. Instead, financial services organizations and their clients could engage through a shared platform that enables them to efficiently understand and agree contract variations.
Using a shared platform makes particular sense in the context of complex financial services products, such as syndicated loans, that involve numerous different parties with different functions. It could enable all parties to see, and agree to, a single, clean version of the contractual documentation. If that documentation needs to be updated, the shared platform enables this to happen efficiently and transparently.
Should the general counsel offices (GCOs) own contracts, or should they consider using a trusted third-party platform? GCOs see little advantage in building a set of specific data science skills internally, around a transient set of data modules, when those human resources could be better deployed on other activities with a direct impact on revenue generation or customer service. Data scientists themselves see little attraction in developing document ingestion or other specialized skills that would likely be in demand for only a limited period.
Financial services organizations need not undertake all the technology and data challenges of IBOR migration in isolation. Many entities face similar quality challenges, for example, around testing new models and systems that refer to the new ARRs.
Entities using an independent software vendor (ISV) could apply lessons from past technology change programs (such as MiFID, Y2K and Euro migration) and work together – carving up the problem and running pilots in specified firms. In this way, through coordinated action, entities can share the burden and reduce the wider systemic risk posed by IBOR migration to the financial services sector. As the Financial Conduct Authority and the Bank of England have highlighted, the sector needs to work collaboratively to maintain operational resilience and ensure sustained customer service delivery.