Many in the community are starting to look at the phaseout of LIBOR and move to alternative reference rates such as SOFR. One small, but important, part of the plan that needs attention is how to handle deal modeling of the new SOFR derivatives, and specifically the calculation of the payments.
There remains uncertainty about precisely how payments will be calculated on renegotiated LIBOR swaps. The good news is that of the various methods under discussion, many, if not all, have existing support in Findur, including clients using versions as far back as v12.
LIBOR swaps reset at the beginning of the calculation period, which simplifies settlement because the back office has a long time to confirm and release the payment.
A plain in-arrears method resets daily on the overnight SOFR rate, is averaged over the calculation period, and paid on the first day of the next calculation period. SOFR publication is delayed until about 8am (New York) of the following business day, which means that the back office only has same-day notice of the rate required to complete the payment.
Swaps in Findur support this reset timing convention. This convention, and the operational complexities that it introduces, is already in use for swaps tied to the Fed Funds Effective Rate. We have a client with active trading in derivatives with products floating on Fed Funds that suffer from delayed publication and same-day settlement of the payments.
As there are some complexities that vary by client site, please reach out and we are happy to discuss how Findur EOD processing can be updated to handle these products.
If the same-day processing of interest calculations is too onerous, the payment may be delayed to allow for back office operations to prepare for the payment. This method can introduce problems elsewhere, for example, cash flow timing mismatches with other payments. Findur already supports a configurable payment delay using the Payment Date Offset field.
A lockout period may simplify back office operations by applying the same rate from k days before the end of the calculation period for the remainder of the period. Findur has support for this convention via the Rate Cut–Off field.
When an instrument has a lookback period, each day in the calculation period uses the SOFR rate from k days earlier. This method is used, for example, in SONIA FRNs. Findur uses the term Reset Shift to support this convention.
Findur supports daily compounding and averaging, including weighted and unweighted varieties. Cleared SOFR swaps with the CME use daily compounding on the SOFR leg with a 2 day payment lag.
There are other features of SOFR swaps that may not be familiar to clients for whom existing trade is limited to vanilla LIBOR instruments.
Findur supports different reset and payment calendars, many roll conventions such as IMM, rate spreads, rate multipliers, negative spreads, and negative rates. In these times of low nominal interest rates, it is important to confirm that negative rates are supported. Regarding roll conventions, these can be easily extended to virtually anything that may be dreamed up. Roll convention customizations are heavily used, particularly amongst energy trading, so this is a part of the system that is well-tested under production conditions.
Regarding standard compounding and averaging, we see clients and consultants implement customizations. We have later removed these customizations as the deal modeling is brought closer into alignment with the application’s native features.
There are other conventions under consideration, and Findur has robust support for many features of OTC derivative payment calculations. The Alternative Reference Rates Committee (AARC), convened by the New York Fed, last week held a conference call to discuss payment calculation methodology. During that call, several methodologies were discussed. One method may require a change to Findur: the method discussed as the committee’s preferred ‘compound in arrears’ methodology.
SOFR is an annualized rate, and under this proposed methodology, the rate will be divided by 365 to convert to a daily rate, then compounded daily and converted to an annual rate. The calculation must ensure that weekends have 3 day compounding, and also take into account compounding over holidays. Participants on the call requested guidance around the proposed rounding conventions.
Payment Calculator Extensions
For anything that has no existing support, since version 11, Openlink has supported custom Payment Calculator extensions. These components are relatively simple to build, although they are a licensable feature.
The proposed favored methodology described last week by the AARC implies that a Payment Calculator may be necessary. During the call, that methodology was stated to required ‘significant system changes required’. A Payment Calculator should not be considered a ‘significant’ system change in Findur. Finally, note that SOFR swaps cleared by the CME do not use that methodology, so it is not yet a certainty.
This paper has been focused on SOFR, which is reference rate for USD fixed income instruments and interest rate derivatives. The phaseout of LIBOR affects other currencies as well, so the payment calculation questions discussed above will apply also to the new non-USD reference rates.
For the benefit of clients, these are the reference rates that will replace LIBOR for other major currencies, including details about whether the rate is based on secured or unsecured rates, and the timing of the publication.
|Currency||Reference Rate||Secured / Unsecured||Publication Timing|
|USD||SOFR||Secured||8am the next business day|
|GBP||SONIA||Unsecured||9am the next business day|
|JPY||TONA||Unsecured||10am the next business day|
|EUR||ESTER||Unsecured||8am the next business day|
|CHF||SARON||Secured||6pm the same business day|
|AUD||AONIA||Unsecured||9.20am the next business day|
Modeling of SOFR swaps and other derivatives is only part of the plan for capital markets participants as LIBOR is phased out. For clients that currently have vanilla instruments, the move to compounded or averaged resets can introduce complications that affect reports and back office documentation.
We often see duplicate records appear in reports and confirmations because multiple resets are used to generate the rate used to calculate the payment. These problems are easy to address if you are familiar with Findur’s data model. You are welcome to reach out with any questions, particularly about the data model.
In future notes, we will look at processing terminations and novations, advice about curve construction, accounting, hedge accounting, customer trade confirmations, and more. Watch this space for more details.