With the termination of LIBOR fast approaching, trading institutions are rapidly moving to add alternative reference rate (ARR) support to their existing trading platforms. Despite the entry of other options (i.e. – such as Bloomberg’s BSBY), SOFR has emerged as the USD ARR of choice among major market participants.
Some software vendors have already implemented support for SOFR in their core products, and others offer tools to aid customers in moving their existing LIBOR transactions to SOFR. Some of the Findur users with whom our firm has interacted, have reported fewer resources available to support their transition, especially concerning critical post-trade processing requirements. Ultimately, customers will be responsible for migrating to the new SOFR rate and ensuring that their systems will be able to handle SOFR trading from front office to back.
Embarking on an endeavor such as this within the Findur application is not for the faint hearted, but when done in an informed and structured way, a safe and effective migration is achievable within the required timeline.
Findur is a complex system, with clients shaping the product to match their own business processes. Overlap between clients may exist at a more abstract level, but at a detailed level there is too much variance that constrains easy lifting and moving of one client’s solution to another.
At a high level, there are two essential objectives that a SOFR implementation must achieve:
- Adding the ability to trade in the new market, and
- Managing the migration, or fallback, of existing LIBOR transactions.
Central to a successful LIBOR transition in Findur is executing a well-planned agile project which incorporates contributions from key business and technical groups. This allows the solution to be rapidly prototyped, giving the users an early preview of the impact of the proposed approach within their existing solutions. The importance of this cannot be overlooked.
The treatment of LIBOR transition as an iterative process makes sense, as the strategic direction of the fallback approach can be customized for each instrument or toolset. This determination can be made upfront during the analysis phase of the project.
The general assumption in the industry is that a “terminate and rebook” fallback strategy is the way to go – in this scenario open LIBOR transactions are terminated, and the remaining open portions are rebooked onto new transactions.
In Findur this approach demands automation because manual updates are too prone to deal entry errors. Given the almost limitless ways the Findur application can be customized, implementing “terminate and rebook” will take on a slightly different look for each client. We have found it important to look at each instrument separately, deriving slight variations of the “terminate and rebook” strategy for each toolset/instrument where necessary.
Sticking the Landing
We have worked extensively with our clients over the years to promote system automation and to enhance solution quality and transparency. For this critical transition away from LIBOR, our strategy includes automated reconciliation of deal terms and conditions, payment details and valuations to increase users’ confidence in the process.
At Lucido, we have seen that an agile project, supported by automated testing is the best pathway to success – we are happy to support users in this journey in any way that we can.