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 7 Next »

Overview

This document applies to all releases of Eagle software V12 and above. Version-dependent functionality is noted with the initial release(s) it became available.

Portfolio Swaps are a flavor of Total Return Swap (TRS) where the return payments are based on the value on an underlying portfolio of securities. Unlike a TRS on an index or basket where the notional can be expressed as a number of units or shares * price, the notional is derived from a portfolio of securities with different, and varying, quantities and prices. Trades can be made daily within the underlying portfolio, which changes the notional and market value of the Portfolio Swap contract.

Eagle does not have a specific module designed to support Portfolio Swaps, but a streamlined workflow can be implemented using the core TRS functionality. This involves setting up a separate TRS for each underlying portfolio constituent, then booking the equity activity directly against the TRSs to a given portfolio. Benefits include support for different spreads across equity constituents, automated corporate action processing, and eliminating the need to maintain a dummy entity that tracks the underlying equity portfolio. Refer to Instrument Engineering’s Total Return Swaps (TRS) Best Practices best practices for more information on general TRS lifecycle events and workflow.

Content on this page:

Due to their highly customized nature, each Portfolio Swap can have unique attributes that may be different than the examples used to create this document. Please contact Instrument Engineering to discuss your particular contract in greater detail.

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.

Example reference data screens, trade screens, and reports are attached:

Entity Setup

Before any trades can be booked, the entity that will hold the Portfolio Swap TRSs must be set up appropriately.

Unable to render {include} The included page could not be found.

Reference Data

Storage & Configuration

Eagle models Portfolio Swaps as multiple TRS security master files (SMFs), each with three rows in Data Management. Every row of a TRS has its own Security Alias (10), linked by a common Primary Asset ID (14) across the contract and legs.

Follow the steps below to allow duplicate cross reference identifiers (IDs) in Eagle Accounting. This example is for multi-leg swaps. You may need to follow the same steps for Forwards or for any other case where you want to allow multiple securities to share the same identifier. This is different than reusing an identifier that has been reissued to a new security after the original security matured or expired, which is explained in Reuse Cross Reference Identifiers Processing Notes.

  1. Open Create Security Cross Reference Configuration (V17 & above)/Add Security Cross Reference Configuration (prior to V17)

  2. Populate Xreference Security ID Type (1234) with the Primary Asset ID Type (1432) that will be used for multi-leg swaps (i.e. INTERNAL)

  3. Populate Xref Qualifier (9111) with Duplicate

  4. Populate Investment Type (11) with DERV (SWAPS) and click Submit

Keywords: KB 11614, Duplicate Xref ID, Duplicate Xreference ID, Duplicate SWAPID

Market Data

Return leg payments are derived directly from the value of each underlying equity, whether paying or receiving the return. Equity prices must be entered directly on the TRS return legs (this is discussed in detail in the Valuation section). Corporate action processing can be automated starting in V17, but announcements must be created individually for each TRS return leg in lower versions. Refer to the Corporate Actions section below for details. 

The financing for each underlying equity generally floats against the same underlying interest rate index, but often with different spreads. Setting up a separate TRS for each constituent allows you to enter the appropriate spread for each one for automated accrual processing and provides the most granular level of reporting for each constituent's financing costs. Many Portfolio Swaps also involve financing spread changes to accommodate changes in borrowing costs for the underlying equities. These can be supported using Time Sensitive functionality starting in V17. Refer to Time Sensitive for details.

The underlying interest rate 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 the currency. 

Security Data

Portfolio Swap TRSs can be set up and maintained using Issue Viewer, SRM, or RDC. Every TRS for a given underlying equity portfolio will have an identical setup other than the IDs, underlying security, and pay/receive leg directions. Long underlying positions should be set up as TRS that are paying financing/receiving return while short underlying positions are paying return/receiving financing. 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)
  • Issue Country (1418)
  • Asset Currency (85)
  • Notional Reset Type (4409): typically Recalc Notional (R) for Portfolio Swaps (financing notional changes at each reset)
    • Select Constant Notional (C) if the financing notional should stay the same throughout the life of the swap
  • 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
  • Lag/Coupon Delay Days (4908): number of days between valuation date (date from which price is pulled) and reset date (date when reset takes effect)
    • NULL/0, 2, and 3 are most common
    • Finance leg continues to accrue on the old notional during this period
    • If a value greater than zero is used, each reset will be projected as valuation date + X days
    • Applies to floating rate resets (the first one occurs on First Rate Reset Date + X days)
  • Lag/Coupon Delay Days Type (3999): measure the delay between valuation date and payment date in B (Business) or C (Calendar) days; typically B (Business) days
  • 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; refer to the Corporate Actions section below for details
    • Yes: Swap Reset Schedule is generated automatically for both legs when security is added or changed via Issue Viewer or SRM; this is the default for new securities
    • No: Swap Reset Schedule is not generated automatically when security is added or changed; this is the default when changing securities
    • Note: if set to Yes when changing a security, new Swap Reset Schedules will be generated for both legs and will overwrite any existing schedules

Return Leg

  • Processing Security Type (3931) = SWLXEQ (Swap Leg Total Rate Return on Equity)
  • Price Multiplier (18) = 1.00
  • 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): # 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
      • Setting this to 0 has the same effect as setting Reset Price Timing/Calc Price = Reset Day
  • Payment Frequency (472): select appropriate payment 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 10th 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)
  • Delay Days (1799): number of days to delay cash settlement of the reset payment; these are applied to the reset date
    • Delay Days Type (5074): measure cash settlement delay in B (Business) or C (Calendar) days
  • First Payment/Valuation Date (473): enter the first valuation date; 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
  • Final Valuation Date (1369): only enter if applicable, typically 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 pull the underlying price up to the return leg; refer to TRS Underlying Pricing in Pricing Center for details

Finance Leg

  • Processing Security Type (3931) = SWLEAC (Swap Interest Accrual Leg)
  • Coupon (70): enter zero for floating (or variable) rate to indicate that rates must be viewed from underlying index, or 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) & Delay Days Type (5074): typically same values as return leg, but can be different if necessary
  • 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
    • Reset Frequency (1788): same as Payment Frequency
    • Reset Look-Back Days (10547): # of days prior to each reset date (or Dated Date for the initial period) to grab the new floating rate
      • 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 for details about modeling spread changes

TRS Reset Schedules

There are two options for defining the schedule of TRS reset dates, automated and manual, as described below.

Option 1: Automated Scheduling

Valuation and payment dates are calculated automatically based on SMF attributes.

  • First Payment/Valuation Date + Lag/Coupon Delay Days is used to project all future reset dates
  • By default, reset schedules are calculated on the fly in releases prior to V17, but they can also be stored in the SCHEDULE table for verification and modification
    • This is done using Generate Swap Reset Schedule, and once created it can be viewed using List Schedule
    • Generate Swap Reset Schedule on the SMF defaults to Yes in V17 because existence of the schedule is required for automated corporate action processing
  • 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 an automatically generated 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

Option 2: Manual Scheduling

Unable to render {include} The included page could not be found.

Unscheduled/Ad Hoc Resets

Some Portfolio Swaps can have unscheduled/ad hoc resets when predefined exposure levels are breached, among other reasons. This is more common than with traditional TRS on indexes or single-name equities. 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. Example: resets occur on the last day of each month (ignoring non-business days) - 1/31/16, 2/29/16, 3/31/16, etc. - and a reset is required on 3/13/16.

Example: resets occur on the last day of each month (ignoring non-business days) - 1/31/16, 2/29/16, 3/31/16, etc. - and a reset is required on 3/13/16.

  1. The full schedule must be generated prior to adding the new period

  2. Open Change Schedule

    1. Query for one leg of the TRS

    2. Select the row with the closest following End Date and click Change Schedule Record(s)

      1. Example: row with Effective Date = 2/29/16 and End Date = 3/31/16

    3. Set End Date = new reset date and click Submit

      1. Example: End Date = 3/13/16

  3. Open Add Schedule

    1. Query for the same leg as above

    2. Set Effective Date = new reset date and End Date = next scheduled reset date (the original End Date from the row edited above) and click Submit

      1. Example: Effective Date = 3/13/16 and End Date = 3/31/16

  4. Repeat steps 1 & 2 for the other leg with the same date information

After following these steps the reset process can be triggered for the new reset date (example: 3/13/16). If accruals have already been processed for the new reset date - 1 (example: 3/12/16), they will have to be rerun with Allow Earnings Rollback (1257) = Yes to drop the coupon.

Trade Processing

TRSs are traded based on a number of shares and a price, which allows the Portfolio Swap's underlying trading activity to be mapped directly to the associated TRSs. A batch of open trades is booked at inception to establish the initial values of the Portfolio Swap, all with the same trade/settle dates. These transactions will not create any cash settlements because TRS opens are cashless (unless there is an explicit fee, which can be entered if necessary).

TRSs are always held with the contract and receive leg as long positions and the pay leg as a short position. Buys and sells of an underlying constituents are booked against TRSs set up to pay financing/receive return, while short sells and buys to cover are booked against TRSs set up to pay return/receive financing. Additional lots, new positions, partial closes, and full closes can be processed against the TRS just as they would be against the equities. The only difference is that buys and short sells will use the same event types, as will sells and buys to cover. 

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.

Contract

  • Traded Interest/Effective Date (2857): date to which traded interest is calculated; typically Trade Date or TD + 1
  • Swap Fee Local (7510): paid, received, or zero; represents the fee paid to enter the TRS (typically zero)
  • Broker (88)
  • Counterparty (1144, optional): counterparty can be selected from a list of all Issuers that have been tagged as counterparties (see Setting Up Legal Entities Best Practices for more information)

Return Leg

  • Shares (40): # of shares of the underlying equity
    • Do not enter Shares on the Contract, it will be automatically propagated from the return leg
    • Constant Notional: Notional (7782) is entered directly (instead of being calculated)
  • Price (45): initial price of the underlying equity
  • Commission (47) & Other Fee (3752): enter any commissions and/or fees; these are factored into the notional value calculation on the finance leg for the initial period, but not exchanged in cash
    • Notional = (Shares * Price) + return leg Commission + return leg Other Fee

Finance Leg

  • Finance leg notional value (in Shares field) is automatically calculated based on return leg information.
    • Example: if # of equity Shares is 1 million, the initial Price is $10, and Commission and Other Fee are zero, the finance leg notional will be $10 million
    • Constant Notional: finance leg notional (in Shares field) is taken directly from Notional entered on the return leg and does not change as part of the reset process
  • Select Values to be Calculated by STAR (7000): set to Traded Interest to have it calculated, or Calculate None to enter it manually
  • Traded Interest Local (49): interest bought or sold, calculated since Dated Date or last coupon date
    • Lot Level Dated Date (4411): used to override when the lot starts accruing interest (accruals start on Dated Date by default)
    • First Period Coupon Rate (1360): overrides the interest rate for the first period; Eagle Accounting will automatically start using the appropriate interest rates after the next reset is processed

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

Enter Shares, Price, Commission, and Other Fee on return leg; Eagle Accounting will automatically calculate the proceeds on each leg and separate gain/loss entries will be posted. Any other cash fees can still be entered on the contract, although this is somewhat rare.

  • Gain/loss on the return leg will be equal to the return leg Principal - finance leg Shares
    • This will tie to the realized gain/loss on the underlying equity
  • Return Leg Principal: Shares * Price - Commission - Other Fee
  • Finance Leg Shares: outstanding cost of shares to be closed
    • This is equal to total outstanding cost / total outstanding Position Shares * # of Shares to be closed
  • Lot Selection Method (27): TRS closes must be processed using Identified Lot in versions prior to V12.1.5.18, V13.1.2.15, and V15 R2; a dropdown is used to select the appropriate lot to close

Traded Interest Local on the finance leg, if applicable, can either be entered manually or calculated by Eagle Accounting. This will be included in trade proceeds on the finance leg.

  • By default the legs will continue to accrue through Settlement Date - 1 (similar to a bond); to accrue through Trade Date, populate Accrual End Date with Trade Date + 1

Constant Notional: similar to the open, constant notional TRS closes are entered based on notional value rather than # of shares.

  • Close Notional (7782, Return Leg): portion of notional being closed; this is pulled into finance leg Shares directly
    • The screen calculates the proportional # of Shares to close for the contract and return leg as Close Notional / Position Notional (7783) * Position Shares (122)
    • Principal (165, Return Leg): number of Shares calculated * Price
  • Gain/loss on the return leg is still equal to the return leg Principal - finance leg Shares

Booking Multiple Lots

There are two important notes about FIFO/LIFO closes when trading multi-lot TRS:

  • If Lot Level Dated Date is used to override the initial rate and a FIFO close is booked before the next reset, traded interest calculated by Eagle Accounting may be incorrect because it will be based on the SMF attributes
    • In these cases, traded interest can be entered instead of calculated
  • If multiple lots are opened at different prices and a partial FIFO close is entered that spans lots (open lots of 300 and 400, then a close of 500, for example), the amount of notional closed may be incorrect because it will be closed proportionately based on shares
    • In these cases, IDLOT closes are recommended

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 portfolio swap TRS trades are booked, they will be picked up in Eagle's global workflow. Daily accruals 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

Portfolio Swap valuation is based on pricing the return leg of each TRS with the underlying equity price. TRS are valued with market value equal to unrealized gain/loss. The sum of the TRS return leg valuations represents the total value of the Portfolio Swap.

  • Return Leg Market Value = Shares * (EOD Price - Open or Last Reset Price)

Each TRS's market value and unrealized gain/loss, and their sums, tie to the underlying equity portfolio's unrealized gain/loss. Notional Cost Local (10791)/Base (10792) and Notional Market Value Local (10793)/Base (10794) tie to equity portfolio's costs and market values.  

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

Corporate Actions

Overview

Accounting has core support for three types of corporate actions on TRSs: cash dividends, stock dividends, and stock splits. Announcements are set up using the same workflow as regular equities. All corporate actions are processed in two steps: 

  1. Creating the Corporate Action Announcement: establishes the details of the corporate action (ex date, pay date, dividend rate, etc.)

  2. Triggering the corporate action for the targeted security and entity(ies)

On this page

The functionality for setting up TRS announcements is slightly different depending on your current Eagle release.

V17 R2 & Above

Corporate actions affecting TRSs can be automatically processed based on announcements for their underlying securities (this is optional if you are satisfied with the previous functionality). Following the previous example, the 5 TRSs on Microsoft can now be driven by an individual announcement for Microsoft.

  • A Swap Reset Schedule must exist to settle cash dividends with the TRS reset; if one does not exist cash will settle based on the underlying corporate action announcement

  • Corporate Action Reset Indicator (16633): controls the date cash settles for cash dividends

    • Pay Date (Swap Reset Schedule Exists): cash settles on next reset payment date following Pay Date from underlying announcement

    • Ex Date (Swap Reset Schedule Exists): cash settles on next reset payment date following Ex Date from underlying announcement

    • Pay Date (No Swap Reset Schedule): cash settles on Pay Date from underlying announcement

    • Ex Date (No Swap Reset Schedule): cash settles on Ex Date from underlying announcement

    • Corporate Action Pay Date: cash settles on Pay Date from underlying announcement (regardless of Swap Reset Schedule existence)

    • Note: when upgrading existing positions to V17 this field defaults to NULL, which results in the same activity as Corporate Action Pay Date; select an alternate value if you require a different settlement convention

  • Stock Split: Treatment of Fractional Shares must be populated with a value other than European

    • Selecting European hides the Split Ratio field and uses a different calculation method

  • Corporate actions are triggered using the same global processes as earlier versions, with the exception of the field below

    • Process Corporate Action on Swap (16813): if a corporate action is being reprocessed for a particular TRS underlying, setting this to No will prevent TRS on that underlying from being affected

      • Available only when Select Query Option (2283) = One Entity/One Security or All Entities/One Security when triggering the corporate action

  • If you are on V17 R2 or above and want to use the previous functionality, you can continue setting up corporate action announcements directly for return legs

    • If a record has the same Ex Date as a corporate action on the underlying security, the return leg announcement will take priority and the underlying security's announcement will be ignored

Prior to V17 R2

Separate announcements must be set up for the return leg of each TRS. For example: if there are 5 TRSs on Microsoft, 5 corporate action announcements are required. Start by searching for Cash Dividend, Stock Dividend, or Stock Split. Required data is listed below.

  • Asset ID (14): enter the TRS's Primary Asset ID (only the return leg will be returned)

  • Process Corporate Action for Swap (16813): controls whether the corporate action is triggered only for TRS (Yes) or only for direct equity holdings (No) when Select Query Option (2283) = One Security

    • If you want to trigger the corporate action for both, you must run/schedule the job twice (once with each setting) or use Select Query Option = All Securities

  • Sweep Date (1197): date when the global corporate action process will pick up and execute the corporate action (generally current date)

  • Ex Date (65): date when the corporate action takes effect

  • Pay Date (1275, required for cash dividends): date when cash settles

    • Typically set to the following reset payment date

  • Treatment of Fractional Shares (3965, required for stock dividends and splits)

  • Corporate Action Status (54) = Released

  • Corporate Action Sub Priority (3961): order of priority for corporate actions processed on the same day

    • Enter 1 unless you have this scenario

  • Dividend Rate (1259, required for cash dividends): on a per-share basis; only required for cash dividends

  • Dividend Per Share/Rate Of Action (1001, required for stock dividends): enter the number of new shares to be spawned for each share of the current holding

  • From Shares (1710): enter current number of shares of the return leg holding

  • To Shares (1723): enter ending number of shares as a result of the corporate action

  • Split Ratio (1001, required for stock splits): calculated automatically based on From Shares and To Shares

    • Can also be populated directly

  • Corporate Action Type (1728) = Cash Dividend, Stock Dividend, or Stock Split

Trigger Corporate Actions

Once announcements have been set up, they can be processed via an automated event or triggered manually.

  • V17 & Above: Accounting Center > Processing and Exceptions > Global Processes > Corporate Actions > Cash Dividend Processing or Stock Dividends/Stock Splits

  • Prior to V17: Global Process Center > Corporate Actions Processing > Cash Dividend or Stock Dividends/Stock Splits

Ensure Corporate Action Begin Sweep Date (220) and Corporate Action End Sweep Date (221) capture the Sweep Date you entered on the announcement(s).

Closes with Pending Dividends

Cash dividends typically settle 2-4 weeks after Ex Date. If a close is booked after Ex Date and prior to Pay Date, the pending dividend will not be taken down proportionately. If this occurs, follow the steps below to manually settle the pending dividend, either partially or fully.

  • Open Accounting Center > Transactions > Cash > Run Manual Settlements

  • Enter the appropriate entity and/or security criteria to target one or more positions

  • Select the applicable pending dividends and click Select settlement record in the ribbon

  • If the pending dividend should settle with the close trade, adjust Settlement Date (37) to equal the close trade

  • Adjust Quantity to Settle (40) and Local Settlement Amount (50) proportionately to the amount of notional that was closed

    • Example: if half the position is closed, set the two fields to half of their starting values

  • Set Write off remaining amount? (1076) to No leave difference in payable status

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 Portfolio Swap 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

The sum of these fields across all the TRS in a given Portfolio Swap entity represent the total values of the swap. Reporting at the entity level shows the whole Portfolio Swap as a single line item.

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.

Each Portfolio Swap TRS is 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.

Performance

The performance toolkit calculates market value-based performance for individual Portfolio Swap 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 for TRS enrichment are linked to Total Return Swaps (TRS) Best Practices. Additional details are available in the Exposure Reporting Best Practices and Eagle Enrichment User Guide 2015 documents.

Automation

Multi-leg swap security master files (SMFs) and trades can be loaded through the standard _all streams in Message Center (MC) in addition to the dedicated _smf and _trades streams. SMFs must be loaded prior to trades (trades do not spawn SMFs) and both must be sent as three-row files (contract, pay leg, receive leg) in versions prior to V17 R2.27. Beginning in V17 R2.27, Interest Rate Swap, Total Return Swap, and Inflation-Linked Swap trades can be entered as single rows using the Single Event method (refer to https://eagledocs.atlassian.net/wiki/spaces/IE/pages/1658978617/Interest+Rate+Swaps+IRS+Best+Practices#Trade-Processing and https://eagledocs.atlassian.net/wiki/spaces/IE/pages/1658978705/Total+Return+Swaps+TRS+Best+Practices#Trade-Processing for additional information).

  • Ensure Trade Ticket Number (761) is populated for all multi-leg swap trades because it is required to process cancels and IDLOT closes

    • The same value is copied to Batch Identifier (701)

    • You cannot use Batch Cancel Trade if Trade Ticket Number was null on the original trade because Batch Identifier will be null

    • Trade Ticket Number should be the same across all rows for a particular trade, but unique for each trade

    • IDLOT closes must be entered with Target Trade Ticket Number (762) = Trade Ticket Number (761) of the open lot to cancel

    • Multi-leg swap cancels can be entered through Message Center as a single row with Target Trade Ticket Number (762) = Trade Ticket Number (761) of the transaction to be cancelled  

      • Set Long/Short Indicator (15) based on the contract-level: L to cancel long transactions or S to cancel short transactions

      • This is automatically routed to Batch Cancel Trade

  • Multi-leg swap prices and other reference data, such as variable rates, can also be loaded via default streams

    • To accomplish this, tag 4590 (Swap Type/Component) must be included in the message

      • 4590 = C to price the contract

      • 4590 = P or R price the pay or receive leg respectively

    • Either combination of these tag can be used for security resolution:

      • 14 (Primary Asset ID) and 1432 (Primary Asset ID Type)

      • 1233 (Xreference ID) and 1234 (Xreference ID Type)

      • When loading variable rates, 961 (Issue Name) must be included as well

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 it is paying or receiving the return.

Sample messages to create a security, book an open, and book a close are attached to Total Return Swaps (TRS) Best Practices.

  • No labels

0 Comments

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.