Why Test RFRs?
LIBOR (London Interbank Offered Rate) was the key benchmark interest rate used by global lending institutions for decades. However, its role in the 2008 financial crisis led to its sunset. The fall and replacement of LIBOR has made the migration to an invulnerable system imperative in financial institutions across the world. Indeed, the publication of 24 of the 35 LIBOR settings was halted on
22nd January, 2022. As LIBOR is phased out, RFR, or Risk-free Rates, are robust alternatives for your institution. Unlike LIBOR, RFRs are backward-looking and do not include a premium for longer-term funding.
It is important to factor in the impact and risks associated with implementing RFRs. GreenPoint’s Summit teams work closely with clients to ensure a seamless migration from LIBOR to RFRs. Our RFRs testing methodologies are designed to effectively implement RFRs while pre-empting and mitigating the pitfalls and risks associated with this complex transition. In this article, we delineate how we successfully implemented RFRs at a client institution using our testing strategy to minimize disruption, error, and risk.
Our Testing Strategy
Our methodology studied Risk-Free Rate (RFR)/Overnight Swap Index (OIS) curves to perform impact analyses on trade/portfolio valuation and accounting. The strategy tested these curves to mitigate the impact of material changes in the variables on downstream feeds or accounting. As a result, we closely determined the maintenance of all variables within the required thresholds and captured any
associated financial risks with the implementation.
Our Testing Approach
To ensure this risk mitigation and a comprehensive understanding of any impact, our testing approach was defined at five different levels.
Our Testing Objectives
- During the build phase, our objective was to validate the RFR/OIS functionality while preserving System Integration Testing and User Acceptance Testing timelines.
- Our quant team oversaw the curve build and the unit testing of the RFR/OIS setup, including curve build changes.
- We performed functional tests to ensure the delivered RFR/OIS functionalities corresponded to those defined in the scope.
- Avoiding impact on the client’s business processes during the RFR/OIS implementation was our top priority. Testing was performed incrementally on the existing build to optimize the scope coverage and lower the number of potential defects when entering the SIT/UAT environments. Any potential changes and impacts, including batch processes, were immediately relayed to the client.
The Pre-Testing Phase
- Our first-level testing validated the (i) Initial Build, (ii) Internal Consistency, and (iii) Zero Rate to ensure that either a) the zero rate was unaffected, or b) the change was within the permissible threshold outlined in the scope.
- Due to its impact on trade booking, this phase also included the validation of the Mark to Market (MTM) impact to ensure the pre-implementation and post-implementation values were within the specified thresholds.
- If the difference was above the thresholds, we rebuilt the curves to accommodate the differences.
The sequence of our pre-testing phase is depicted below:
Regression Testing
We performed regression testing to ensure that existing infrastructure and systems at the client institution continued to perform seamlessly after the transition.
- We consolidated the changes and automated their release into the environment for end-to-end testing. This helped us verify that the curve internal consistency and the MTM difference are the same as determined during the pre-test.
- We then performed downstream system tests. To ensure their prominent impact on feeds and downstream systems, we tested changes in the curve construction and static changes related to the RFR requirements respectively.
- The key test involved comparing the MTM value with the counterparty MTM value to verify that it was matched within the threshold.
- Under this phase, all test cases prepared during the pre-test phase were tested again to ensure that they passed before the production phase.
- All the test results captured during this phase, including the MTM value comparisons were then submitted to the client for their final sign-off.
The workflow of our regression-testing phase is as follows:
The Regression Testing Environment
We set up two different environments to highlight the differences between an RFR and non-RFR implementation. This also allowed us to easily investigate (i) regression issues and (ii) valuation differences due to the RFR/OIS setup.
Our Roles and Responsibilities
The roles and responsibilities of GreenPoint’s project team, our client, and Finastra product team are outlined below:
Testing Environments
We used a number of environments to perform all tests related to the RFR/OIS implementation:
- Environment 1: Functional Setup and Unit Testing
- Environment 2: Integration Testing
- Comparison Testing: Production-like Setup (Environment 1) vs. Integration Testing (Environment 2)
- Client Environment 3: User Acceptance Testing
- Parallel Testing, as applicable
Defect Management
Our defect management system allowed quick and effective responses to any issues that arose during the testing process.
- Identified issues were raised as tickets on the product defect ticketing portal.
- Thereafter, the product team took the responsibility for the raised ticket and provided a solution.
- After receiving the solution, the project development team implemented it.
- The functional team re-tested for the defect to ensure it was fixed.
