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). Eagle Accounting must be set up to allow duplicate IDs for swaps by following the steps in Allow Duplicate Cross Reference Identifiers Processing Notes.

Refer to Multi-Leg SWAPIDs Processing Notes for information about the unique SWAPID identifiers that are automatically created for the contract and each leg of a multi-leg swap.

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 during SMF setup. The price/level of the underlying must be directly populated on the return leg. There is functionality available in Pricing Center to automatically pull the price of the underlying up to the return leg as described in TRS Price from Underlying Processing Notes.

In some cases, such as long-date contracts, there may be a need to apply a discount factor to the valuation derived purely from the underlying. Eagle supports this via the Price Conversion functionality. See TRS Price Conversion Processing Notes for more information. When using this functionality, the calculated price is used for both valuation and resets. If you need to use different prices for valuation and resets, see the Separate Valuation & Reset Prices section below.

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 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.

Separate Valuation & Reset Prices (V17 R2.49)

In some cases there may be a requirement to fair value TRS or include another form of discounting in the valuation. However, these discounted prices cannot be used for resets because they would result in incorrect calculations for the finance leg notional. Prior to V17 R2.49, the only way to support this is to use close and open trades in lieu of resets because it allows you to explicitly set the “reset” price used for the trades. Beginning in V17 R2.49 you can specify a different source to be used for TRS resets. Refer to TRS Separate Reset & Valuation Prices Processing Notes for full configuration details.

Security Data

TRSs can be set up and maintained using Issue Viewer 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): can be 0.01 or 1.00 as the contract is not used for valuation

  • When using RDC, enter the value required for the return leg because it will propagate down

• 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

  • For TRS on SNFI, this can be set to Dated Date of the the underlying bond

• 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. because the maturity process checks for Maturity Delay Days on the fly

  • Must be populated on the contract and legs for SMFs created via Message Center

• 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

  • Must be populated on the contract and legs for SMFs created via Message Center

Return Leg

• Processing Security Type (3931)

  • SWLXEQ (Swap Leg Total Rate Return on Equity): for index, equity, or basket underlyings

  • SWLEDB (Swap Leg Total Rate Return on Fixed Income): for an SNFI underlying where the return leg drops coupons following the schedule of the underlying bond

    • Support for bullet contracts (one reset at maturity) was added in V17 R.43 and support for resetting contracts was added in V17 R2.44

    • See TRS on Single-Name Fixed Income Processing Notes for additional information

• Price Multiplier (18): 1.00 for equity, index, or basket underlyings, or 0.01 for SWLEDB

  • 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

  • Set to Reset Day when using Decoupling

  • 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)

• Day of Month Override (1533): set to WDC (Week Day of First Coupon) for swaps using the International Monetary Market (IMM) calendar, otherwise leave null

• Delay Days (1799): number of days between reset date and payment date (reset date is the same as valuation date when using Decoupling)

  • 2 and 3 are most common when using Decoupling, null or 0 when using the original method

  • 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 or 0 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

  • Refer to Calculate Coupon Dates Processing Notes if the adjusted date is not available

  • SWLEDB: enter the underlying bond’s next coupon date after Dated Date of the TRS (V17 R2.43+)

• 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

  • Refer to Calculate Coupon Dates Processing Notes if the adjusted date is not available

  • Set to the final valuation date (not penultimate) when using Decoupling

  • SWLEDB: enter the underlying bond’s last coupon date prior to Maturity Date of the TRS (V17 R2.43+)

• Final Valuation Date (1369): required when using Decoupling and for Bullet Swaps where there is a single reset at maturity

• Generate Swap Reset Schedule (2299, V17): a Swap Reset Schedule is critical for automated corporate action processing (see the Corporate Actions section for details)

  • Yes: schedule is generated automatically when security is added or changed

    • A schedule is required to process return leg resets starting in V17 R2.43

      • In earlier releases a schedule is only required for automated corporate action processing and this field can be set to No for any TRS that are ineligible for corporate actions

    • If dates in the SMF-level Business Calendar are modified after the schedule is 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

  • No: schedule is not generated when security is added or changed

    • This is the default for Processing Security Type = SWLEDB (Swap Leg Total Rate Return on Fixed Income) starting in V17 R2.43 because additional dates must be provided when generating the schedule

  • Additional information about Swap Reset Schedules is available in https://eagledocs.atlassian.net/wiki/spaces/IE/pages/9671999489

• 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)

Most commodity TRS use standard interest accrual conventions (simple average or compound average in arrears). However, some bespoke contracts stipulate unique accrual conventions. The functionality described below should only be used in these rare cases. One example is 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

    • This field is not used or required in RDC

  • Rate Conversion Rule (12849) = DRA3601DA365 (Discount ACT/360 to Daily ACT/365)

TRS Reset Schedules

We recommend not generating a Swap Reset Schedule unless the TRS is eligible for corporate actions. Refer to https://eagledocs.atlassian.net/wiki/spaces/IE/pages/9671999489 for additional information.

Decoupling

In V17 R2.22, an alternate method of setting up TRS return legs was added, called Decoupling. This is recommended for all newly established TRS positions and can be used alongside the original method. It applies to TRS where the schedule is dictated by valuation dates and there is a delay between each valuation date and payment date. There are two main benefits of Decoupling:

1. Resets can be processed on valuation date to lock in gain/loss, while still accruing on the correct finance leg notional through payment date

2. Trades between valuation/reset date and payment date are processed correctly

In prior versions, Coupon Delay Days (4908) would be used on the return leg, which effectively shifts the reset process and realized gain/loss from valuation date to payment date. To invoke Decoupling, leave Coupon Delay Days as null or 0 on the return leg and use Delay Days (1799) instead. There are no changes to the finance leg (it will continue to use Coupon Delay Days). Delay Days on the return leg should typically match 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 set to the final valuation date from the reset schedule. Before Decoupling, it could be either the penultimate or final date. Either date can still be used on the finance leg.

Open

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

Eagle Accounting also supports loading Swap Reset Schedule data. Refer to https://eagledocs.atlassian.net/wiki/spaces/IE/pages/1658978702 for details.

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 in https://eagledocs.atlassian.net/wiki/spaces/IE/pages/1658978548 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: only method available prior to V17 R2.27

• Single Event: introduced in R2.27 to allow additional lot selection methods beyond FIFO, LIFO, and IDLOT

Single Event is the recommended method. Refer to https://eagledocs.atlassian.net/wiki/spaces/IE/pages/10607722501 for additional information.

Open (event 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.

If Accrual Convention Offset (12038) is set to Settlement Date + 1 on the entity, Accrual Convention Offset Override (1604) can be used to override the entity value and fall back to standard accrual processing for the resulting position.

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 (event 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.

SWLEDB: in V17 R2.43, you must book a close at the final valuation price instead of processing the final reset. Trade Date and Settlement Date should match the valuation date and settlement date (respectively) of the final reset. This is not required in V17 R2.44 and above.

• Accrual End Date (4412): date to which traded interest is calculated; typically Trade Date or T+1

• 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 for Multiple Events, 4404 for Single Event): 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 except Tax Advantage (TXADV) and Tax Efficiency (TXEFF)

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.

Valuation

Accruing on Negative Interest Rates

Reset Processing

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. 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. 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

  3. Set Earn Through Date = 9/30/15 and Allow Earnings Rollback = Yes

  4. Process return leg reset on both lots

     1. Set Trade Dt = 10/1/15

  5. 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 Rollback (V17 R2)

A global process can be used to streamline the workflow by canceling a TRS reset across entities. 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 then needs to be reprocessed manually following the steps from the previous section.

Corporate Actions

Refer to https://eagledocs.atlassian.net/wiki/spaces/IE/pages/1658978521 for details about booking corporate actions on TRSs.

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 Final Valuation Date (Decoupling) or Maturity Date (non-Decoupling) 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

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 meaningful returns. The documentation and .egl files are linked below. Additional details are available in https://eagledocs.atlassian.net/wiki/spaces/IE/pages/1658978513 and https://eagledocs.atlassian.net/wiki/spaces/Portfolio2017/pages/1932722204.

Automation

Refer to https://eagledocs.atlassian.net/wiki/spaces/IE/pages/1658978825 for general information about multi-leg security setup and trade processing via Message Center.

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. The second row of each CSV message contains the tag names; this is for informational purposes only and should be deleted before the message is loaded.