IBOR reform is transforming the portfolios of lenders, borrowers, and hedgers around the world. Having the right data and analytics tooling is crucial to a successful transition. It enables a complete understanding of current IBOR exposures and contracts, and proper analysis of the impacts of moving to risk-free rates (RFRs). The three key components to achieving this are:
- Dedicated IBOR data processing and visualisations
- Multi-asset value transfer analytics
- High volume contractual analytics
The data visualisation and analytics requirements of large change programmes can often give rise to a cumbersome collection of databases, dashboards, scripts, macros, and side-of-desk analysis. Since IBOR programmes are firmwide and temporary, the overall architecture should seek to combine these capabilities into as few components as possible.
Here we explore some of our experiences in developing IBOR data and analytics capabilities.
Data Processing & Visualisations
The initial challenge of sourcing and collating IBOR data across all relevant businesses, products, clients, and geographies is unprecedented in terms of breadth and depth in the given timescale. Fortunately, firms will benefit hugely from having established centralised trade data lakes and invested in data exploration tools that sit on top of them.
A firm’s existing data exploration tools, in use on the main trade repository, is a natural choice to coalesce all IBOR data around. As IBOR data typically resides in many systems, tools that can automatically take data from many sources and that provide easy to view data models are critical.
From our experience, some key pain points to look out for in processing IBOR data are:
- Business disparities: Each part of a bank, whether that be separate businesses, source systems, or geographies may hold data in ways that are hard to combine.
- Ensuring completeness: A critical concern is missing reference rate information, which can arise if an exposure has an unspecified rate or the LIBOR exposure is obscured.
- Ensuring accuracy: A common inaccuracy arises where the product name does not reflect the product economics due to a misused booking template or simple mislabelling.
- Ensuring uniqueness: The same exposures can be duplicated across multiple systems, often relating to businesses sharing booking systems, internal risk transfers, or funding positions.
- Levels of aggregations: For some products, risk exposures are not held at trade or position level, so identifying the IBOR subset and joining to trade static is not possible. In other cases, trade level risks can be based on curves aggregated by currency and tenor or net the forward and discount components.
- Linking data: Data needs to be linked in several ways that are hard to achieve, for example linking exposures to their hedges, legs within a structured product, or exposure data to contracts. Additionally, linking client entities to get a reliable single client view is a notoriously difficult challenge.
Figure 1: Exposure Explorer - Data visualisation to explore firmwide IBOR exposures from a single screen
Once the data has been prepared the next challenge is creating data visualisations (see figure 1). IBOR dashboarding needs to be flexible as there is often the need to create specific views per business or region, and adaptable as requirements can quickly change based on market updates and regulatory requirements. Whilst having the data processing and visualisation steps performed by the same tool will help with agility, the ideal tooling will also be able to combine on-the-fly analysis.
Value Transfer Analytics
There are various IBOR exposure analyses useful in the transition, for example identifying hard-to-transition trades or hedge-relationships between trades, however, the key analysis required is stress-testing portfolio values under various transition scenarios. This is typically formulated as the approximated present value change of a portfolio under a new ‘scenario’ curve (see figure 2).
The standard scenario many market participants are analysing is the dollar impact of automatically switching from LIBOR to ISDA defined contractual fall-back rates. The ISDA fall-back rates are based on compounded RFRs with a historically determined spread that fixed at the point of cessation. This scenario can then be encapsulated as a forward curve based on the forward RFR term structure from a likely cessation date, shifted by the fixed ISDA spread.
Scenarios can also be tailored to analyse potential transition options for given counterparties or products. For example, a bank may want to provide a blanket offer to all mortgage customers such that no customer is left disadvantaged by the transition. At the other end of the spectrum, a bank may want to negotiate a portfolio of diverse products with one sophisticated counterparty and optimise their offer to balance out value transfers whilst being as operationally simple as possible.
In this way, scenario analysis needs to be able to deal with any desired cut of the data, across all products and counterparties.
Figure 2: Financial Impact – Analytics to design transition scenarios and measure their impacts on IBOR exposures
For non-linear products there is the need to go beyond such approximate impact analysis to a full re-valuation of exposures. This might be the case for example, to determine the impact of contractual fall-backs on swaptions, or to calculate value transfers for what regulators have termed ‘tough legacy’ exposures. Ultimately full re-valuation will be required where trades are modified. For this use case it is best to use existing valuation software, but thought should be given to how to connect it to IBOR data and analytics tools. In the ideal case, specific portfolios can be carved out of IBOR data exploration tools and their trade static passed to valuation libraries to display precise value impacts.
Since a large part of transitioning away from IBORs might ultimately involve re-papering of legal contracts or at least understanding current contracts from a LIBOR transition viewpoint, contract analytics is a big part of the required capabilities. This means both the use of AI to digitise paper contracts and having the workflow tools to perform bulk re-papering.
A typical bank might have tens to hundreds of thousands of individual IBOR contracts facing counterparties of all levels of sophistication, via products ranging from overdrafts to exotic derivatives. This means any contract analytics will need to be able to deal with both large volumes and diverse contract types.
The first step is identifying the presence and nature of ‘fall-back’ language that describes the legal consequences of not repapering. This is not only required for developing the transition strategy and performing scenario analysis, but also for various regulatory reporting. Once the population of contracts is understood at a granular enough level and the required information is sufficiently structured, the next challenge is connecting these outputs to exposure data at a trade or position level. The final step is negotiating, modifying, and tracking re-papering efforts digitally, and feeding progress back to the central IBOR data storage and subsequent reporting.