Entity Setup

Before any trades can be booked, the target entity must be set up appropriately.

Reference Data

Storage & Configuration

Eagle models TRS security master files (SMFs) as three rows in Data Management, each with its own Security Alias (10), linked by a common Primary Asset ID (14).

Market Data

Return leg payments are derived from an underlying index, equity, or basket, which can be linked by entering its ID in the Underlying Information section. While TRSs are valued based on the underlying's price, it must be entered directly to the return leg; this is discussed in detail in the Valuation section.

The finance leg of a TRS generally floats against an underlying interest rate index. Each index must be set up as an Index security using Issue Viewer, Security Reference Manager (SRM), or Reference Data Center (RDC). Other than identifiers, the only information that must be entered is currency.

Once the index has been set up, floating rates can be loaded using Add Variable Rate. Eagle Accounting will automatically pull the appropriate rates into the accrual process based on the finance leg’s First Rate Reset Date (10911), Reset Frequency (1788), and Reset Look-Back Days (10547).

• Interest rates must be loaded to the underlying index at least back to Dated Date (or previous reset date if swap is traded off-cycle) and each subsequent reset date minus Reset Look-Back Days
• Ensure rates are loaded to the same Source (3301) as your entity's Variable Rate Source

Spread Changes (V17 R2): some TRS contracts include terms specifying that the floating rate spread changes periodically throughout the life of the deal. Eagle supports this with Time Sensitive functionality, which was expanded to include swaps in V17 R2. Spread changes are supported both on coupon and non-coupon dates. Refer to Time Sensitive Processing Notes for details about modeling spread changes during the life of swap.

Security Data

TRSs can be set up and maintained using Issue Viewer, SRM, or RDC. Most data is entered on the contract and propagated to the legs. Specific reset and accrual conventions are entered separately on each leg.

Contract

• Issue Name (961)
• Primary Asset ID (14) & Type (1432): ensure duplicate IDs are allowed (see Storage & Configuration section above)
• Processing Security Type (3931) = SWCOTR (Total Return Swap Contract)
• Price Multiplier (18): 1.00 for equity, index, or basket underlyings, or 0.01 for single-name debt
  • Entered on contract in RDC and automatically propagated to legs
• Issue Country (1418)
• Asset Currency (85)
• Notional Reset Type (4409): select Recalc Notional (R) for floating notional or Constant Notional (C) for fixed notional
  • V17 R2: Recalc Notional - Forward (RF) and Constant Notional - Forward (CF) were added to support forward-starting TRS where the number of shares or total notional is known at trade time, but the price is not
    • These elections allow a trade to be booked without providing a price
    • When the price is locked in, an initial "cashless" reset (only locks in the price/cost) is triggered using the normal process
• Issue Date (68): first trade date of the swap
• Dated Date (1183): date accruals start, "Effective Date" in ISDA contracts
• Maturity Date (38): date swap expires, "Expiration Date" or "Termination Date" in ISDA contracts
  • Must be a valid business day
• Maturity Delay Days (3997): delays core maturity process X days to allow a close transaction to be entered in lieu of maturity (during this period valuations will still be calculated if the security is priced); the maturity process will trigger as normal after this delay
  • Using this field does not affect the actual Maturity Date stored in Eagle on the cost object, in the position table, etc.
  • Instead, the maturity process checks for Maturity Delay Days on the fly
• Maturity Delay Days Type (3998): measure the maturity delay in B (Business) or C (Calendar) days
  • Note: you must have a business calendar populated in Calendar Name (1941) on your entity to use B (Business) days
• Generate Swap Reset Schedule (2299, V17): existence of the schedule is crucial for automated corporate action processing (see the Corporate Actions section for details)
  • Yes: schedule is generated automatically for both legs when security is added or changed
    • This is the default for TRS
    • When a security is changed, new schedules will be generated and will overwrite any existing schedules
  • No: schedule is not generated automatically when security is added or changed

Return Leg

• Processing Security Type (3931): SWLXEQ (Swap Leg Total Rate Return on Equity) for index, equity, or basket underlyings, or SWLEDB (Swap Leg Total Rate Return on Fixed Income) for single-name debt
• Price Multiplier (18): 1.00 for equity, index, or basket underlyings, or 0.01 for single-name debt
  • Entered on return leg in Issue Viewer
• Reset Price Timing/Calc Price (3314): defines whether the price used in the reset process is taken as of payment date, or X number of days prior to payment date
  • Typically Reset Day if Lag/Coupon Delay Days = NULL/0 or Prior Business Day if Lag/Coupon Delay Days > 0
  • Prior Business Days/Preceding Business Day (10548): number of days prior to reset date to pull the reset price
    • Typically set to same value as Lag/Coupon Delay Days to use the price from valuation date
    • A value of 0 has the same effect as setting Reset Price Timing/Calc Price = Reset Day
• Payment Frequency (472): select appropriate reset frequency
• Business Day Convention (1536): typically Modified Following, which is ADJMBC (Modified Following - Adjusted) in V15 R2 and above, ADJMBC (Modified Business Day - Adjusted) below V15 R2
  • Coupon Day of Month (10551): required if Business Day Convention != NULL/None (NONE)
    • Enter the regular valuation day of month
    • Allows for valuation dates that are out of sync with the true first valuation date
    • Example: if the first valuation date were the 11th due to a holiday, but all other valuation dates were the 10th, the 10 would be entered and used to project future valuation dates
• Business Calendar (1480): as specified in the contract; a composite calendar (including dates from two different calendars) may need to be set up if multiple business calendars are observed
  • This is required even if Business Day Convention is set to NULL/None (NONE)
  • IMM Swaps: for quarterly resets using the International Monetary Market (IMM) calendar, set Day of Month Override = WDC (Week Date of First Coupon) and Lag/Coupon Delay Days = 2
• Delay Days (1799): number of days between reset date and payment date (reset date is the same as valuation date when using Decoupling, which is recommended)
  • 0, 2 and 3 are most common
  • Allows the final payment to occur after Maturity Date
  • Delay Days Type (5074): measure cash settlement delay in B (Business) or C (Calendar) days
• Lag/Coupon Delay Days (4908): number of days between valuation (pricing) date and reset date (when cost and notional change)
  • Typically null/zero when using Decoupling, 2 or 3 when using the original method
  • Each reset date is projected as valuation date + X days
  • Lag/Coupon Delay Days Type (3999): measure delay between valuation date and reset date in B (Business) or C (Calendar) days; typically B (Business) days
• First Payment/Valuation Date (473): enter the first valuation date (1/5/12 from attached example)
  • Lag/Coupon Delay Days will be added to this to determine the first reset date
• Last Payment/Valuation Date (474): enter the valuation date associated with the last reset prior to termination
  • Lag/Coupon Delay Days will be added to this to determine the last reset date
  • Set to the final valuation date (not penultimate) when using Decoupling
• Final Valuation Date (1369): required when using Decoupling and for Bullet Swaps where there is a single reset at maturity
• Underlying Security (1347): mainly for reporting purposes as Eagle Accounting does not automatically retrieve the underlying’s prices for trading and valuation
  • Note: the return leg must be priced directly
  • Pricing Center rules can be configured to automatically price the return leg based on its underlying; refer to TRS Price from Underlying Processing Notes for details

Finance Leg

• Processing Security Type (3931) = SWLEAC (Swap Leg Interest Accrual)
• Coupon (70): enter zero for floating (or variable) rate to indicate that rates must be viewed from underlying index, or enter stated fixed rate if applicable
• Coupon Type (97): typically X (Floating Rate) or F (Fixed Rate)
• Day Count Basis (471): as specified in contract
• Payment Frequency (472): as specified in contract
• Business Day Convention (1536), Coupon Day of Month (10551), & Business Calendar (1480): same values as return leg
• Delay Days (1799) & Type (5074): number of days to delay coupon cash settlement after reset date
  • Typically zero for finance leg
• Lag/Coupon Delay Days (4908): number of days between valuation (pricing) date and coupon date (when interest is paid)
  • Typically same value as Delay Days on the return leg when using Decoupling, or Coupon Delay Days when using the original method
  • Each coupon date is projected as valuation date + X days
  • Applies to floating rate resets (the first one occurs on First Rate Reset Date + X days)
  • Cannot be used to extend the final coupon period past Maturity Date (it must be adjusted in order to extend the final coupon period)
  • Lag/Coupon Delay Days Type (3999): measure delay between valuation date and coupon date in B (Business) or C (Calendar) days; typically B (Business) days
• First (473) & Last Payment/Valuation Date (474): same dates as return leg
• Floating Rate Fields
  • First Rate Reset Date (10911): same as First Payment/Valuation Date
    • This is used with Lag/Coupon Delay Days and Reset Look-Back Days to calculate fixing dates
    • Example (attached): enter 1/5/12 for First Rate Reset Date because First Payment/Valuation Date = 1/5/12
  • Reset Frequency (1788): same as Payment Frequency
  • Reset Look-Back Days (10547): number of days prior to each reset date (or Dated Date for the initial period) to grab the new floating rate
    • For the first reset date from attached example (1/10/12), a value of 2 will take the rate from 1/6/12 (fixing date)
    • Reset Look-Back Days Type (5075): measure look-back in B (Business) or C (Calendar) days
  • Fixing Date Business Center (16407, V15 R2.18): select calendar used for floating rate resets, which may be different than the calendar used for payment dates
    • This calendar is used in lieu of the main Business Calendar when applying Reset Look-Back Days for fixing dates
  • Underlying Security (1347): floating rates will be automatically retrieved from this underlying index
  • Spread/Index Offset (215): spread above or below the floating rate, entered in basis points (0.55% = 55)
    • When a floating rate (0.25%) plus negative spread (-55 bps) goes negative (effective rate = -0.3%), accruals and coupons are posted in the appropriate direction
    • Refer to Time Sensitive Processing Notes for details about modeling spread changes during the life of swap

Commodity Swap Accrual Conventions (V17 R2)

Some commodity-based TRS have unique accrual conventions. For example: assume one based on the 91-Day Treasury Bill rate.

• This is calculated as the 3-month US Treasury high-discount auction rate converted from a discount to a daily compounded basis
• To calculate accruals correctly one day’s worth of return needs to be applied to the finance leg notional and compounded daily during the period
• Compounding only occurs on the floating rate portion of the accrual and does not include the fee (spread); this is known as Compounding with Simple Spread (non-ISDA) and can be accomplished with the following settings
  • Underlying Security (1347): select index security loaded with 3-month US Treasury high-discount auction rates
  • Compounding Indicator (11875) = Yes
  • Compounding Method (11876) = Spread Exclusive
  • Convert Interest Rate (9154) = Yes
  • Rate Conversion Rule (12849) = DRA3601DA365 (Discount ACT/360 to Daily ACT/365)

TRS Reset Schedules

Prior to V17, the Swap Reset Schedule is calculated on the fly. Starting in V17, it is generated automatically for each TRS and stored in the SCHEDULE table because it is required for automated corporate action processing. The schedule is automatically regenerated each time SMF data is changed. It can also be triggered ad hoc using Generate Swap Reset Schedule. When implementing TRS for the first time or adding new flavors, you should check the schedule for accuracy before booking trades.

• If any of the dates are incorrect due irregular resets, they can be updated by deleted, changed, or added using the Schedule tools
  • Note: once a schedule is amended, the remaining schedule can only be updated manually (all changes are overwritten when a schedule is regenerated)
• If dates in the SMF-level Business Calendar are modified subsequent to the schedule being generated, it will need to be regenerated for the changes to take effect
  • We recommend regenerating schedules annually and/or whenever a security's Business Calendar is updated, unless the schedule has been customized

Decoupling

In V17 R2.22, an alternate method of setting up TRS return legs was added, called Decoupling. This is the recommended method for all newly established TRS positions and can be used alongside the original method. It applies to TRS with:

• A schedule dictated by valuation dates
• A delay between valuation date and payment date

In prior versions, this could only be accommodated with Coupon Delay Days (4908) on the return leg, which effectively shifts the reset process and realized gain/loss from valuation date to payment date. To invoke the Decoupling method, leave Coupon Delay Days as null or zero on the return leg and use Delay Days (1799) instead. There are no changes to the finance leg (it will continue using Coupon Delay Days). This setup allows the return leg reset to process on valuation date, while the finance leg continues to accrue on the pre-reset notional until payment date. Delay Days on the return leg should typically be equal to Coupon Delay Days on the finance leg. An example is provided below.

When Decoupling is used, Last Payment/Valuation Date (474) on the return leg must be equal to the final valuation date in the schedule. Before Decoupling, it could be either the penultimate or final date. Both can still be used on the finance leg.

Example

Valuation and payment dates are calculated automatically based on the SMF attributes. The example above would be set up as follows.

• Both Legs
  • First Payment/Valuation Date = 1/5/2012
• Return Leg
  • Decoupling
    • Reset Calc Price = Reset Day
    • Delay Days = 3
    • Delay Days Type = B (Business)
    • Lag/Coupon Delay Days = null/zero
  • Original Method
    • Reset Calc Price = Prior Business Day
    • Preceding Business Days = 3
    • Delay Days = null/zero
    • Lag/Coupon Delay Days = 3
    • Lag/Coupon Delay Days Type = B (Business)
• Finance Leg
  • Lag/Coupon Delay Days = 3
  • Lag/Coupon Delay Days Type = B (Business)
  • First Rate Reset Date = 1/5/2012
  • Reset Lookback Days = 2
  • Reset Lookback Days Type = B (Business)

Manual Scheduling

Unscheduled/Ad Hoc Resets

Some TRS can have unscheduled/ad hoc resets when predefined exposure levels are breached, among other reasons. In these cases the schedule for both legs must be edited to add the new reset date. Follow the steps below to edit the current period and add a new period.

Trade Processing

Beginning in V17 R2.27, there are two methods available for booking TRS trades:

• Multiple Events: this was the only method available prior to V17 R2.27
• Single Event: this was introduced in R2.27 to allow TRS to use additional lot selection methods beyond FIFO, LIFO, and IDLOT

There are no differences in security setup or the resulting positions. You will still end up with separate positions for the contract and each leg. The difference when using the Single Event method is that all data is entered on the return leg and the contract and finance leg transactions are spawned in the engine. The same applies to transactions entered via Message Center. 

Open (transaction type: OPENSWAP)

Trades are entered using the Book Trade module once the entity and reference data have been configured. Enter the appropriate entity, security identifier, and trade (35)/settle (37) dates and click Submit to query for the security. Right-click it and select Open > Open Swap Contract or Open Swap Contract - Single Event.

Multiple Events

Single Event (V17 R2.27)

Booking Multiple Open Lots

By default, opens of additional TRS lots will not generate an upfront payment based on trade price. To prevent traded interest from being calculated and exchanged, set Lot Level Dated Date = accrual start date of the additional lot (same date should be used for Settlement Date, or Traded Interest/Effective Date if available).

• For a floating rate TRS, First Period Coupon Rate can be left blank to automatically pull the rate from the underlying index based on Lot Level Dated Date minus Reset Look-Back Days, and apply the appropriate spread
• Alternatively First Period Coupon Rate can be entered, with the supplied rate used up until the next reset date; this requires the all-in rate (floating rate + spread) to be entered
• After the next reset all lots are reset to same unit cost and all financing is calculated the same based on the original SMF configuration

Close (transaction type: CLOSESWAP)

The Book Trade module should also be used to process both full and partial terminations. Enter the same information as the open to query for the security. Right-click it and select Close > Close Swap Contract or Close Swap Contract - Single Event.

Most close fields are identical to the open, with some exceptions and other notes listed below. Eagle Accounting will automatically calculate the proceeds on each leg and separate gain/loss entries will be posted.

• Pay/Receive Flag (10485): this captures any fees paid or received to close the TRS beyond what is calculated by entering the market close price
  • This is not typically used 
  • Swap Fee Local (7510): absolute value of the fee, if applicable
• Lot Selection Method (27): defines the order in which lots are relieved
  • Inherited from the entity, but can be overridden
  • Closes must be processed using Identified Lot (IDLOT) in versions prior to V12.1.5.18, V13.1.2.15, and V15 R2
  • If Lot Level Dated Date or First Period Coupon 
  • The Multiple Events method only supports Identified Lot (IDLOT), FIFO, and LIFO closes in the versions listed above and all subsequent releases
  • The Single Events method supports any available Lot Selection Method (27) in V17 R2.27 and above

Multiple Events

Single Event

Conversion

The CONVERSION event is not supported for TRS. Conversions should be booked using the OPENSWAP event as of the most recent reset prior to conversion date. Because TRS opens are typically cashless events, booking an open on a reset date produces the same accounting results going forward.

Cancel & Rebook

Faulty TRS transactions must be cancelled using Batch Cancel Trades, with the transaction rebooked using the Book Trade module. TRSs are not supported in the Cancel & Rebook Trade process or the Cancel Trade screen. Maturities must also be canceled using Batch Cancel Trades.

Accounting

Once a TRS trade is booked, it will be picked up in Eagle's global workflow. Daily accruals (whether positive, negative, or zero) and periodic resets are generated as part of the earnings process, Accounting valuation is calculated when posting unrealized gain/loss, and Data Management valuation is calculated in the STAR to PACE push. These can be scheduled or triggered manually.

• V17 & Above: Accounting Center > Processing and Exceptions > Global Processes

  • Accruals: Earnings > Run Income Accruals

  • TRS Resets: Swaps > Reset Total Return Swap

  • Accounting Valuation: Unrealized Gain Loss Entries > Post Daily Fund Unrealized Gain Loss-Position

  • Data Management Valuation: Eagle STAR to Eagle PACE Direct Processing > Transfer Data - Batch

• Prior to V17: Global Process Center

  • Accruals: Earnings > Accrue

  • TRS Resets: Total Return Swap Reset > Total Return Swap Reset

  • Accounting Valuation: Unrealized Gain Loss Entries > Post Daily Fund Unrealized Gain Loss-Position

  • Data Management Valuation: STAR to PACE Direct Processing > Transfer Data - Batch

Valuation

Accruing on Negative Interest Rates

If a swap leg is long, Eagle Accounting makes negative postings to a receivable account. If the swap leg is short, the negative postings are to a payable account. Swap accrual postings are not made to the opposite account (payable vs. receivable) when accruing on negative interest rates.

Reset Processing

Workflow

• Global process is scheduled to run on a daily basis in a production setting

• The underlying price must be populated directly on the return leg for valuation date before processing the reset

  • Accounting does not automatically look to the underlying for reset prices

• Security Query Flag (1256) controls whether prices and FX rates must be loaded for the reset date (ACTUAL, default), or if the most recently available will be used (RECENT)

  • When ACTUAL is used and either prices or FX rates (for foreign TRS) are missing, the reset will fail

  • Using RECENT will prevent failures, but may lead to incorrect reset activity

• Resets should be scheduled to run prior to accruals to ensure financing is calculated on the correct notional on reset date

Calculation

The reset cash flow direction is determined by reset price being above or below initial price (trade price or last reset price). Positive amounts are disbursements when paying the return and receipts when receiving it. Conversely, negative amounts are receipts when paying the return and disbursements when receiving it.

• Shares: 1,000,000, Initial Price: $80, and Reset Price: $85

• Return Amount = 1,000,000 * (85 - 80) = $5,000,000

• New Notional = 1,000,000 * 85 = $85,000,000

Finance leg notional is recalculated based on return leg # of shares and reset price. The finance leg starts accruing on the new notional on reset date (valuation date + Lag/Coupon Delay Days). This is the 10th in the attached example.

Constant Notional: reset payments are calculated the same way as outlined above, except the initial price is always trade price. Notional and notional cost are established at trade time and do not change.

• To keep notional constant, Accounting divides it by reset price to calculate an updated # of shares

Reset Rollback/Replay - Manual

Rollback/replay cancels the finance leg portion of any reset transaction that has occurred chronologically on or after the “as of” trade date, but not return leg resets. Resets have to be re-run manually.

• Note: performing a batch cancel of a single lot with a trade date less than or equal to last reset date will cancel the reset for all lots; the reset process must be re-run to reset the remaining open lots

Finance leg accruals after the reset must be rolled back to ensure recalculated notional amounts are used. Example: user wants to book an “as of” transaction involving a reset.

• Lot 1 Trade Date = 9/1/15, accrued through 9/30/15, reset on 10/1/15, accrued through 10/9/15
• On 10/9/15 an additional open (Lot 2) is booked as of 9/23/15
• Automated accounting rollback/replay will:

1. 1. Cancel Lot 1 accrual through back to 9/23/15 and cancel coupon on 10/1/15
   2. Insert additional open (Lot 2) on 10/9/15, as of 9/23/15
   3. Accrue both lots from 09/23/15 - 10/9/15 and drop coupon on 10/1/15
   4. Cancel the reset from 10/1/15 in some cases
      1. When this happens, you must use Cancel Entitlements to cancel the traded cash record

• Manual processes needed:

1. 1. Use Batch Cancel Trades to cancel the reset; this will create a cancel cost adjustment and cancel traded cash row (must be done prior to reprocessing the reset)
   2. Cancel accruals from 10/1/15 - 10/9/15
      
      1. Set Earn Through Date = 9/30/15 and Allow Earnings Rollback = Yes
   3. Process return leg reset on both lots
      1. Set Trade Dt = 10/1/15
   4. Accrue from 10/1/15 - 10/9/15 using recalculated notional 
      
      1. Set Earn Through Date = 10/9/15 and Allow Earnings Rollback = No

Reset Rollback/Replay - Automated (V17 R2)

A global process can be used to streamline the workflow for correcting TRS resets. This is available in Accounting Center > Processing & Exceptions > Global Processes > Swaps > Cancel Total Return Swap Reset.

• Select Query Option (2283): resets must be canceled for one security at a time
• Trade Dt (35): set to date of reset being canceled

After canceling the reset, accruals will need to be rolled back separately. The reset can be reprocessed following the manual steps described above once the necessary updates have been made.

Corporate Actions

Mature/Expire

TRSs will be picked up by Eagle Accounting’s core maturity process. This will be scheduled in production environments, but can be triggered manually via:

• V17 & Above: Accounting Center > Processing and Exceptions > Global Processes > Expirations & Maturities > Run Mature Process 
• Prior to V17: Global Process Center > Expirations > Mature

The final reset that occurs on Maturity Date must be triggered to generate the final return payment (the maturity event itself will not trigger the final reset). The final coupon payment is dropped as part of the accrual process.

Reporting

STAR to PACE (S2P)

Almost all reports in Eagle Accounting leverage data from Data Management, which is populated by the S2P process. This will be scheduled as part of the daily workflow, but can also be triggered manually as described in the Accounting section.

The S2P process creates three rows for each TRS in the POSITION, POSITION_DETAIL, TRADE, and CASH_ACTIVITY tables. The MARKET_VALUE_INCOME column for each row captures a portion of the total market value.

• Contract: always zero
• Return Leg: market value due to unrealized gain/loss on underlying security
• Finance Leg: market value due to period-to-date accrual payable/receivable

Accounting Reports

Eagle has a core set of accounting reports that can be used to review TRS and other security information. These are designed to support the daily operational workflow for business users, allowing Grid Reports to be easily exported to Excel and customized to provide additional details as needed. Advanced Reports are intended to be client-facing and do not provide the same level of customization.

TRSs are displayed as three separate rows. The contract and legs are intended to be displayed together, but may be broken into different areas depending on the report’s groupings (long/short, for example).

Insurance Reporting

To categorize derivatives for insurance reporting, such as the Schedule DB, Derivative Elections (56) must be set to Hedging Effective, Hedging Other, Income Generation, Replications, or Other on all trades. Leaving the default of Trade will prevent the transaction from appearing on insurance reports.

Data Management Reporting

General Reporting (Eagle OLAP)

OLAP reports provide the maximum level of customization, allowing any column in Data Management to be pulled into a report. These go beyond the Eagle Accounting Grid Reports because they are not limited by core queries, can support multiple sources and various types of calculations, and provide drill-down functionality based on user-defined groupings. This helps to avoid issues with swap legs being separated from the contract.

Performance

The performance toolkit calculates market value-based performance for TRSs at the return leg (price changes) and finance leg (accruals) levels using data supplied by the S2P process. However, this can be misleading because swaps use notional values and typically start with a market value of zero. Exposure-based analyses, which can be implemented using Eagle Enrichment, calculate more accurate returns. The documentation and .egl files are linked below. Additional details are available in Exposure Reporting Best Practices and the Eagle Enrichment User Guide 2015.

• TRS Enrichment Rule EGIE_022.egl
• TRS Enrichment Inventory EGIE_022.xlsx

Automation

Additional notes for TRS:

• TRS prices must be loaded to the return leg only
  • Make sure you set tag 4590 = P or R in your price message depending on whether the swap is paying or receiving the return
• For TRS closes using Multiple Events, the finance leg units/notional (tag 40) must equal the amount of notional to close (shares * last reset price)
  • It should not be set to shares * close price. 

Sample messages for the standard interfaces are listed below.