Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Overview

Most securities that accrue interest follow terms that remain constant throughout their tenors. However, some securities stipulate a scheduled change in the way interest accrues. Fixed-to-float bonds, for example, change from fixed rate to floating rate at a predetermined point prior to maturity. There are also total return swaps (TRS) where the spread above the floating rate change as frequently as daily. In other cases, there are market events that require a modification of the accrual terms, such as the transition from traditional interbank offered rates (LIBOR, EURIBOR, etc.) to risk-free rates (RFR) including SOFR and EONIA.

Eagle has full support for these securities using "time sensitive" functionality. This allows you to enter different accrual terms for specific date ranges that override the values on the security master file (SMF). You cannot override individual dates or date conventions. The eligible fields are:

  • Coupon (70)

  • Coupon Type (97)

  • Day Count Basis (471)

  • Payment Frequency (472)

  • Underlying Security (1347)

  • Spread/Index Offset (55)

Using Time Sensitive functionality is different than simply updating accrual terms on the SMF, which does not support rollback/replay for dates prior to the change. If a backdated trade is booked or accruals rolled back for any other reason, those dates are re-accrued using the new terms. The only way to maintain integrity of the accrual terms across different periods is to use the time sensitive functionality.

Pay special attention to underlined sections, as these highlight the most frequently encountered issues. Bold is used for navigation, modules, and screens. Italics are used for fields, tables, and errors. Fixed width indicates values for fields or code/text that should be entered. Tags are shown in parentheses (#) after field names.

Implementation

A brief description of the process is provided first, followed by detailed step-by-step instructions.

High-Level

Time sensitive functionality consists of two components:

  1. Specifying that a security is eligible to use it

    • This can be done during initial setup or at any point throughout the security's tenor

  2. Setting up the records that define the accrual terms for subsequent periods

    • When you specify a security as eligible, an initial open-ended SMF Earnings Time Period record is created automatically

    • To establish a change, you must update the initial record include an end date and add a subsequent open-ended record with the altered accrual terms

    • Spread changes can occur on any date

    • Underlying changes can only occur on coupon dates

Detailed

Security Setup

To specify a security as eligible, set Time Sensitive (11926) = Yes and save it. This a) overrides the earnings process to retrieve accrual terms from SMF Earnings Time Period records instead of the SMF and b) creates an initial open-ended record based on the SMF data. The SMF can be updated to reflect the new accrual terms, but the data is no longer retrieved from the SMF. This is discussed in more detail under Option 2: Updating SMF below.

  • Securities can be set up at inception with Time Sensitive = Yes for processing consistency even if you do not know whether their accrual terms will change

  • If the initial record is correctly set up with Begin Date = Dated Date (1183) and no additional records are added, the results will match a security with Time Sensitive = No

SMF Earnings Time Periods

This is the critical piece of time sensitive configuration. There are different options for managing the periods, but regardless of your preferred method, the configuration must follow these two rules:

  1. Begin Date (220), which is the effective date of the change, must be equal to an actual coupon date for underlying security changes; spread changes can occur on any date

    1. Must be less than/equal to Dated Date (1183) for the initial period

    2. If you are changing the underlying security and using an Adjusted day count basis such as ADJMBC (Modified Following - Adjusted), Begin Date must equal the adjusted coupon date

  2. End Date (221) of one period must not overlap with Begin Date of the subsequent period

    • Because Begin Date indicates the effective date of the change, each End Date must be one calendar day prior to Begin Date of the subsequent period

Having multiple periods with no End Date may cause the TRAN engine to hang. Ensure you do not have any overlapping periods, or multiple periods with no End Date, before attempting to process trades or accruals.

As mentioned above, an initial open-ended record (End Date = NULL) is created when Time Sensitive is set to Yes. This record will have Begin Date = Issue Date (68) of the security by default, but that must be changed to Dated Date if it is earlier. Notes:

  • The Add/Change Earnings Time Period screens currently do not allow Begin Date < Issue Date

    • This can be resolved locally by adding an overlays to these two screens that comment out the LISTBOX line containing this code: IF (:220:< :68:) THEN ERR("Cannot Add a Record Less Than Issue Date");

  • Setting Time Sensitive = Yes through Message Center or Security Reference Manager (SRM) results in Begin Date being incorrectly populated with current date on the initial record; in this case you must update it manually to less than/equal to Dated Date before processing accruals

Once the records have been set up, you can run and rollback/replay accruals across the date(s) of change and interest will be correctly calculated based on the specific terms for each period.

Option 1: Updating SMF

This can be done through Reference Data Center (RDC), Issue Viewer, or SRM, although the workflows vary due to the known issues described below, which should be reviewed closely. The benefits of this method are a) you may not need add/edit any SMF Earnings Time Period records directly if you update the SMF on effective date of the change and b) your SMF accrual terms will always be in sync with the most recent SMF Earnings Time Period record. The downside is this method is not well suited to setting up future periods.

Once Time Sensitive has been set to Yes, changing accrual terms on the SMF automatically affects the SMF Earnings Time Period records. When you update the SMF, a new record is added with Start Date = current date and the initial record is updated to populate End Date with prior date. At this point the setup should be complete because you have the initial record running from less than/equal to Dated Date through the prior date, and another open-ended record starting from the current date. However, additional configuration may be required due to the known issues described below.

There is additional functionality for swaps in Issue Viewer V17 to simplify the manual workflow.

  • The following fields become available after saving a swap with Time Sensitive = Yes, then reopening; they will not be available when setting Time Sensitive = Yes for the first time

    • Existing Effective Dates (7017): returns any time sensitive records that have been added and the associated data

    • As Of Effective Date (4212): date a time sensitive change takes effects; this must be populated and is used as Begin Date when defining a time sensitive data change

Option 2: Managing Records Directly

The workflow is slightly different depending on whether you use RDC or Issue Viewer/SRM. The benefits of this method is that it does not require any additional updates to the SMF and you can set up the periods at inception. The downside is your SMF accrual terms will be stale as they always reflect the initial period.

RDC

  1. Query for the security and open it in Edit mode

  2. Click the SMF Earnings Time Period tab

  3. Double-click the record with Begin Date = Issue Date of the security

  4. Set End Date = one calendar day prior to effective date of the change

  5. Click Save

  6. Back in the SMF Earnings Time Period tab, click Add SMF Earnings Time Period

  7. Enter accrual terms

  8. Set Begin Date = effective date of the change

  9. Click Save

Issue Viewer/SRM

  1. Query for the security and select it in the results (do not open it)

  2. Click the SMF Earnings Time Period tab in the lower section of the screen

  3. Select the record with Begin Date = Dated Date of the security and click Change SMF Earnings Time Period

  4. Set End Date = one calendar day prior to effective date of the change

  5. Click Submit

  6. Back in the SMF Earnings Time Period tab, click Add SMF Earnings Time Period

  7. Enter accrual terms

  8. Set Begin Date = effective date of the change

  9. Click Save

Notes

  • If Dated Date is prior to Issue Date, you must also set Begin Date = Dated Date during step 4

  • In Issue Viewer/SRM, you can edit multiple records at the same time by shift- or ctrl-clicking the desired rows and then using Change SMF Earnings Time Period

  • In the Classic UI, you can also access Add/Change/Delete/List Earnings Time Period through the main menu to perform these steps

Known Issues

Please review the issues below for your release before beginning to test.

  • All Versions

    • Editing an existing record through Issue Viewer or SRM where Begin Date is changed results in a new record being created, instead of the existing record being updated

      • The old record must be deleted when this happens

      • Tracked as SDP-34183

    • The records created by RDC based on SMF changes do not inherit Underlying Security (it is NULL)

      • In this case you must edit the records manually to populate Underlying Security

      • When Underlying Security is populated, the SMF Earnings Time Period tab shows its Security Alias instead of its Issue Name as shown in other screens

  •  V17

    • Issue Viewer: updating a fixed income SMF results in an End Date = current date for the initial period, which will trigger an error if you try accrue through that date

      • In this case you must edit the initial record to set End Date = prior calendar date by following steps 1-5 above under Issue Viewer/SRM

      • Swaps are unaffected as the initial record is updated correctly

      • Fixed in V17 R2.22

  • V13 Custom

    • SRM: updating the SMF results in only the initial record being changed to reflect the new accrual terms, instead of the initial record being updated to include an End Date for the old terms plus an additional record for the new terms

      • In this case you will have to add/edit records SMF Earnings Time Period records manually by following steps 1-9 above under Issue Viewer/SRM

      • This makes updating the SMF only useful for keeping the accrual data in sync with the most recent SMF Earnings Time Period record, not for maintaining the records

  • V15

    • Issue Viewer and SRM both exhibit the same issues as described under V13 Custom above, which has two implications:

      • This makes updating the SMF only useful for keeping the accrual data in sync with the most recent SMF Earnings Time Period record, not for maintaining the records

      • All maintenance of the records must be done manually by following steps 1-9 above under Issue Viewer/SRM

  • No labels