Time Sensitive Processing Notes
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.
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:
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
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 changeIf 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:
Begin Date (220): effective date of the change
Must be equal to an actual coupon date for most changes
Spread changes can occur on any date
Must be less than/equal to Dated Date (1183) for the initial period
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
End Date (221): set to one calendar day before effective date of the change, or leave null if there are no subsequent changes
Must not overlap with 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 it. 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
Query for the security and open it in Edit mode
Click the SMF Earnings Time Period tab
Double-click the record with Begin Date = Issue Date of the security
Set End Date = one calendar day prior to effective date of the change
Click Save
Back in the SMF Earnings Time Period tab, click Add SMF Earnings Time Period
Enter accrual terms
Set Begin Date = effective date of the change
Click Save
Issue Viewer/SRM
Query for the security and select it in the results (do not open it)
Click the SMF Earnings Time Period tab in the lower section of the screen
Select the record with Begin Date = Dated Date of the security and click Change SMF Earnings Time Period
Set End Date = one calendar day prior to effective date of the change
Click Submit
Back in the SMF Earnings Time Period tab, click Add SMF Earnings Time Period
Enter accrual terms
Set Begin Date = effective date of the change
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
When using the Time Sensitive functionality to change the underlying index for a floating rate security, rates must be loaded through the fixing date when the change occurs
This is different than a standard floating rate security where the earnings process will pick up a stale rate
 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