IBOR reform is transforming the portfolios of lenders, borrowers, and hedgers around the world. A typical wholesale bank might have tens to hundreds of thousands of individual IBOR exposures facing counterparties of all levels of sophistication, via products ranging from overdrafts to exotic derivatives. Having the right data is therefore integral to designing and implementing an effective transition, avoiding risks (including conduct, market, regulatory, and reputational), and ultimately maintaining strong client relationships.

Here we discuss our experiences of IBOR data uses, requirements, challenges, and best practises. We will focus on new data uses required by IBOR programmes as opposed to the impacts IBOR reform has on BAU data uses, like hedge accounting, new product approvals, or stress testing; however, these should feed into the overall considerations.

Data Uses

For many an initial prompt to collect comprehensive IBOR data was the PRA’s "Dear CEO" letter. The regulatory demand has since grown with other regulators asking for IBOR exposure data in their own preferred formats, like the HKMA and MAS, as well as attention pivoting from sell-side to buy-side firms. It is reasonable to expect the extent and granularity of regulatory requests to increase over the course of the transition. For example, a more detailed view of products and counterparties is needed to identity what has been coined ‘tough legacy’ exposures.

Next is the use of data to guide internal strategies. At its core, data should inform a firm’s view on what transition options are appropriate for given products and counterparties. For example, data should allow firms to approximate the financial impact of having all ISDA based derivatives fall-back to the new protocol, and inform whether or not similar terms are appropriate for other products.

Soon the focus will be on client outreach. Data should allow an appropriate client segmentation, presentation of a client’s IBOR linked portfolio, and chart what options are available to them along with the potential impacts of each.

Alongside these critical uses, data uses will evolve, for example as part of client outreach workflows and audit trails, tracking LIBOR exposures winding down and RFRs picking up, other programme tracking metrics, responses to consultations and industry working groups, and new regulatory requests.

Data Requirements

Data is required firm-wide at trade, position, or facility level, albeit with a heavier requirement on rates and lending businesses than equity, credit, or FX. The core data fields needed are: trade static (product type, business hierarchy, counterparty, and dates), exposures (notional, principal, market value, DV01, and duration), and of course reference rate information for both LIBOR and RFRs.

It might also be necessary to include some non-LIBOR rates either because a regulator has requested it (e.g. EURIBOR or HIBOR) or to provide context (e.g. clients want to include the Fed Funds Rate in their considerations).

The next layer of detail is whether or not a trade or position is cleared, callable, syndicated, client-money, agency, used as collateral, or a capital instrument. Data will also need to identify the relevant relationship managers or sales people to engage with clients and how best to contact them (note that hard to contact clients may be a significant part of the tough legacy portfolio).

Then there is contractual data required. Initially, where is the exposure booked and what is the jurisdiction or governing law, what consent is required to modify contracts, is there a master agreement, and what is the counterparty’s legal entity. Ultimately, the presence and wording of fall-back provisions will be needed which may require wholesale contract digitisation.

Currently data is typically required at least quarterly and on a best efforts basis for regulatory requests; however, higher frequency and better quality may be required as firms start to engage clients and implement transitions.

Data Challenges

The 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, invested in data lineage tools, and unified business or country specific platforms.

From our experience some key pain points to look out for 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. This is typically because the data is held at different levels of granularity, refreshed at different frequencies, or has differing data qualities. Additionally, product taxonomies and other mapping tables tend not to be unified firm wide and exposure measures can differ between banking book (duration) and trading book (DV01) products.
  • Ensuring completeness: A critical concern is missing reference rate information, which can arise if an exposure has an unspecified rate (e.g. labelled as ‘user input rate’), or the LIBOR exposure is obscured (e.g. in a total return swap or CFD’s underlying, part of a cost of funds rate, or in fixed-to-floating rate bonds). Other completeness concerns arise when sourcing data for less liquid businesses (e.g. securitised products or SPVs/ JVs) or jurisdictions with tougher data sharing rules (e.g. Korea and Saudi Arabia).
  • 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. This runs the risk of a client not recognising the portfolio presented to them or misclassification against internal strategies and reporting.
  • Ensuring uniqueness: The same exposures can be duplicated across multiple systems, most 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. Even with the right data, attention should be paid to appropriately aggregating exposures. For example, cross-currency swaps are best split into separate legs, structured products may be best viewed at a structure level, and summing DV01s across currencies and tenors loses meaning.
  • 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.
  • Various oddball challenges: 
    • Re-combining exposures where different risks have been split/ stripped and recorded separately.
    • Identifying other indirect LIBOR exposures where LIBOR is a component in the coupon formula or part of the funding structure (e.g. credit-linked notes).
    • Products that have front or back ‘stubs’ linked to LIBORs other than the main underlying rate (e.g. a 6 month swap with a LIBOR 2 month front stub exposure) leading to notionals being double or even triple counted.
    • Identifying the appropriate counterparty for SPV issued debt, especially if ownership has changed.
    • Removing already fixed LIBOR exposures (e.g. a LIBOR 6 month exposure expiring next month) to avoid over-reporting.
    • Only taking data cuts at quarter ends can introduce a selection bias. 
    • Retail and wealth clients can have enhanced data privacy rules making data collection and handling more challenging.
    • It is also worth noting that exchange traded products can be recorded as a standardised amount per contract and a quantity of contracts, which then need to be multiplied.

Furthermore, as each regulator makes idiosyncratic requests, the data gathered needs to be transformed and internal taxonomies need to be mapped separately for each request.

Best Practices

After a few cycles of collecting IBOR data as a tactical exercise, it can be difficult to get users comfortable with the data quality. A few of the following steps can help build a more robust approach:

  • Measure data quality both as a one off audit and on an ongoing basis. Data quality testing can combine several methods:
    • Structured testing: automate ongoing checks that are definable as rules (e.g. the completeness of the reference rate field, uniqueness of trade IDs, or validity of maturity date as a future date).
    • Unstructured testing: sense-check at a portfolio-level against a fuzzier set of rules, e.g.:
      • Do any typically short dated products have long maturities?
      • Are there jurisdictions with exposure to unusual IBOR currencies, e.g. Australia having large CHF positions?
      • Does a small client have large exposures or a less sophisticated client have exotic products?
    • Sample testing: perform end-to-end deep-dives on a sample basis focusing on a particular concern. For example, test securitised products for completeness, track tough legacy products from source systems to contracts, identify a single client and validate against a single client view, or test outliers like the biggest external exposure.
  • Review data outputs with relationship managers and the front office. A regular review of data in an IBOR dashboard or as part of deep-dive sample testing will provide assurance and socialise any data assumptions and insurmountable issues. This might also form the basis of client outreach work or business requirements gathering for data tooling. One challenge that may require a salesperson’s view is linking a client’s exposures and hedges. If there are no IDs to do this in a structured way, sorting a client portfolio by maturity date might give an initial idea that can be refined with an RMs understanding of the client.
  • Identify and perform reconciliations with multiple existing data sources. The ultimate reconciliation is with underlying contracts, which can be done on a sample basis until all contracts are digitised. Additional reconciliation can be performed against balance sheet reports (especially for capital instruments), business or client product mandates, externally sourced client group structures, or DV01 against risk limits. Once you have a steady state of data collection and transformations, performing quarter-on-quarter comparisons and other trend analysis will highlight issues, and can form the basis of tracking the wind-down.

More broadly, the following best practises should be considered as part of the IBOR data collection and use:

  • Establish key data governance artefacts including defining ownership, setting up issue management processes and logs, and documenting transformations and assumptions.
  • Automate any data plumbing or processing possible but retain an experts-eye view.
  • Design data visualisation tools alongside business users.
  • Create a dedicated IBOR database. This makes it easier to respond to new use-cases, track trends over the course of the programme, and retain records for the long run.
  • Use internally approved reference data particularly for business hierarchy, product taxonomy, and client information. It is also worth maintaining a list of in-scope benchmark rates with a rationale (e.g. some rates do not have a plan to demise but might in time).
  • Leverage existing data processes and tooling including aligning with data policies, using data governance frameworks and data quality tooling, and linking into source system change management processes.

Life after LIBOR

IBOR reform data considerations are built on infrastructure and lessons learnt from previous big market changes, like Brexit, FRTB, and the Volcker Rule. Whilst the IBOR problem has its own set of data challenges, some are likely to reappear for example combining firm-wide data, dealing with large numbers of disparate counterparties, and engaging in a market led transformation.

Already firms are seeing the opportunity to build on IBOR transition dashboards and processes for other uses, including:

  • Creating better single-client views that combine data from across all business lines and products, to provide relationship managers with a more complete picture of their client’s exposures and hedge linkages.
  • Digitising contracts and linking them to exposure data to facilitate future contractual changes and a broader understanding of a portfolio’s legal nuances.
  • Performing agile scenario analyses on multi-product portfolios.
  • Conversing with clients as one-firm with an integrated and complementary product offering.

Investment in processes, tools, and other improvements to tackle the IBOR reform challenge will therefore prove beneficial for the next big change and well beyond 2022.