Total Return Swap Method
Modeling CFDs as Total Return Swaps takes advantage of Accounting’s ability to process accruals (financing), total returns on the underlying asset, and corporate actions such as dividends.
Entity Setup
Security Reference Data
Issue Viewer / SRM > Add > Derivatives > Total Return Swap
Field Name | Tag # | Additional Comments |
Contract, Pay, and Receive Leg Shared & Required Fields | ||
Issue Name | 961 | Required |
Primary Asset ID Type | 1432 | Required |
Primary ID | 14 | Required |
Processing Security Type | 3931 | SWCOTR, SWLEAC, SWLXEQ |
Issue Country Code | 1418 | Required |
Asset Currency | 85 | Required |
Notional Reset Type | 4409 | Recalc Notional |
Issue Date | 68 | Required |
Issue Date | 1183 | Required |
Maturity Date | 38 | Required |
Payment Frequency | 2287 | Required |
Payment Code | 472 | Required |
Business Calendar Name | 1480 | Required |
First Payment/Valuation Date | 473 | |
Last Payment/Valuation Date | 473 | |
Coupon Day of the Month | 10551 | |
Finance Leg | ||
Coupon | 70 | |
Coupon Type Code | 97 | |
Day Count Basis | 471 | |
First Rate Reset Date | 10911 | If Coupon Type Code = X (Floating) |
Reset Frequency | 476 | If Coupon Type Code = X (Floating) |
Reset Frequency Code | 1788 | If Coupon Type Code = X (Floating) |
Underlying Security ID | 1348 | If Coupon Type Code = X (Floating) |
Underlying Security Name | 1141 | If Coupon Type Code = X (Floating) |
Index Offset | 215 | If Coupon Type Code = X (Floating) |
Return Leg | ||
Reset Calc Price | 3314 | |
Underlying Security ID | 1348 |
Data Strategy in RDC
Reference Data Center allows to create data strategy by duplicating other existing data strategy.
In RDC > Data Strategy in setup choose Total Return Swap strategy and click “duplicate” button. Change name to “Contract For Difference”
In Web Panel Designer changes must be made to support conditional logic. Find the new DS in WPD and copy from the core TRS logic to all three legs of the CFD. Eagle > RDC > Securities > Unlinked files. Locate the new strategy by strategy ID and copy the Listbox data from the TRS contract to the new CFD contract and from each of the TRS legs to the new CFD legs. This should be done in core mode.
Data strategies cannot conflict. In order to do this create Security type and Sub-Security type of CFD in Code Panel. Codes (Metadata Center) > Search for SECURITY TYPE > Code Values> Add Code Value. Once this is complete, right click on the data strategy to ensure no conflicts exist.
In RDC Data Strategy – Contract for Difference change the criteria to:
Trade Processing
Trade > Book Trade > Open (OPENSWAP) / Close Swap Contract (CLOSESWAP)
Field Name | Tag # | Additional Comments |
Trade Date | 35 | |
Settlement Date | 37 | |
Primary ID | 14 | |
Pay/Receive Flag | 10485 | |
Broker Name | 1235 | |
Broker Code | 88 | |
Shares | 40 | Units of the return leg; financing notional is calculated based on unit amount * price |
Select Values to be Calculated by STAR | 7000 | On Finance Leg |
Price | 45 |
Valuation
TRS Valuation is based on Return Leg prices. It can be priced on a daily basis, and unrealized gain/loss is calculated based on the day-to-day price movements. The contract should not be priced.
Add Issue Price can be accessed through Issue Viewer, SRM, or Reference Data Center (RDC)
The contract and finance leg are filtered out, ensuring that only return legs are available
If a price is loaded to the return leg's underlying for Effective Date (1109), it will be pulled into the screen automatically when the return leg is retrieved
You must click Submit to add this price to the return leg
Rules can be established in Pricing Center to automatically pull the underlying price up to the return leg; refer to TRS Price from Underlying Processing Notes for more information
Total Market Value of TRS = Cumulative Unrealized Gain/Loss Return Leg + PTD Accrual Finance Leg
Cumulative Unrealized G/L = Shares * (Current Price - Initial Price)
Effective Date | Issue Name | Price |
---|---|---|
2008.06.11 | EQUITY INDEX SWAP HIMALAYA/CDOR (ESD1455)_EQUITY_R | 0.18950000 |
2008.06.12 | EQUITY INDEX SWAP HIMALAYA/CDOR (ESD1455)_EQUITY_R | 0.18970000 |
2008.06.13 | EQUITY INDEX SWAP HIMALAYA/CDOR (ESD1455)_EQUITY_R | 0.19500000 |
Effective Date | Equity Shares | Price Change | URGL | Cumulative URGL |
---|---|---|---|---|
2008.06.12 | 8,741,881.00 | 0.00020000 | 1,748.38 | 1,748.38 |
2008.06.13 | 8,741,881.00 | 0.00530000 | 46,331.97 | 48,080.35 |
Lifecycle Events
Reset Processing: Global > Global Processing Center > Total Return Swap Reset
Total Return Swap Reset processing is used to create the cash difference between the opening price and the closing price for Contracts for Differences. The cash flow direction (payment or receipt) will depend on the price movement.
Calculation
The direction of the cash flow is determined by the price change above or below the trade price or most recent reset price.
- Shares of Return Leg: 1,000,000
- Start price for reset period: $80
- End price for reset period: $85
- Reset payment = (85 - 80) * 1,000,000 = $5,000,000
Corporate Actions: Reference > Corporate Action Announcements
Corporate actions can be set up and processed for Contracts for Differences on the return leg (SWLXEQ).
Future & Bond Method
Entity Setup
Future Contract
Entities trading the Future Contract side of a CFD need two additional pieces of data. The Add Entity, Change Entity, Master Fund Setup, or Change Master/Sector Entity panels can be used to populate the following fields:
- Net Futures Positions: Yes or No
- No: long and short trades will create two separate position rows
- Yes: long and short positions will be netted to a single position
- Futures Clearing Broker Code: there can only be one clearing broker per futures trade
- By populating the broker name during entity setup, the trade panel will automatically default to this broker
- Users can override this in the trade panel and input another clearing broker if needed
Long-Term Debt
There are no special entity configurations necessary for the Long-Term Bond side of a CFD. The bond is purchased at par and therefore accrues only interest, so no amortization will be calculated.
Security Reference Data
Future Contract
The Future Contract will have its own security master record. The following characteristics are unique to modeling CFDs as Futures with Variation:
- Processing Security Type = FTXXXX; this will automatically populate when adding a future
- Price Multiplier = 1.00
- Contract Size = 1.00
- Variation Margin = Yes
- Variation Margin Rule = Standard Life to Date
Long-Term Bond
The Long-Term Bond will be a separate security master record. Ensure data is populated as follow:
- Payment Frequency = Daily
- Issue Price = 100
- First Coupon Date = As calculated
- Last Coupon Date = As calculated
- Maturity Price = 100
Trade Processing
Future Contract
Required Data: Entity ID, Trade Date, Accounting Date, Settlement Date, Price per Contract, Broker Name, and Broker Code. Clearing Broker and Clearing Broker Code are also required when Variation Margin = Yes. Any commissions or other fees may also be entered on the trade.
Open
Future Contract positions can be established as either long or short. Once the security reference and entity data is setup, trades can be entered using the Trade > Book Trade module. Other than basic information like Trade Date and Settlement Date, below are Future Contract-specific considerations:
- Entity - Net Futures Positions: No (entities with this election will have two options to open a position; by selecting No during entity setup, long and short positions will be treated as two separate holdings)
- Open Long: establishes a long position
- Open Short: establishes a short position
- Entity - Net Futures Positions: Yes (entities with this election will have one option to open a position)
- Open Long: establishes a long position
- Note: if a user wants to trade a short position they will use the Close Long option to go short (also referred to as technical short)
- Clearing Broker: Accounting has a hard edit to prevent a single Future Contract from being traded with two different clearing brokers in the same fund; if this is attempted the trade will fail with a “Future trade clearing broker must be same as previous trades” error
Close
The Book Trade module should be used to process close transactions. Accounting supports both full and partial terminations.
- Entity - Net Futures Positions: No (entities with this election will have two options to close a position; by selecting No during entity setup, long and short positions will be treated as two separate holdings)
- Close Long: closes a long position
- Close Short: closes a short position
- Entity - Net Futures Positions: Yes (entities with this election will have one option to close a position)
- Close Long: closes a long position or establishes a short position
Long-Term Bond
Required Data: Trade Date, Accounting Date, Settlement Date, Select Values to be Calculated by STAR, Par Value/Current Face, Price, Broker Name, and Broker Code.
- The trade price must be clean and par-based
Buy
The Long-Term Bond side of the CFD can be booked using Book Trade > Open > Buy or ShortSell depending on whether the accrued interest is being paid or received.
Close
Book Trade > Open > Sell or BuytoCover can be used to close out the Long-Term Bond side of the CFD, depending on whether the initial position was opened long or short.
Valuation
Future Contract
CFDs with VM calculated by Accounting will always have market values equal to zero. Each day’s VM (after calculation and approval) will be captured in Market Value Income, as the security’s true value is equal to its day-over-day price change.
The Standard Life to Date VM formula is:
- Variation Margin = Notional Market Value of Future Contract on T - Notional Cost of Future
- Notional Market Value = Future Price * Price Multiplier * Number of Contracts * Contract Size
- The current day’s Notional Market Value becomes Notional Cost used for the next day’s variation margin calculation
Variation Margin
The VM process will have to be triggered on a daily basis for the Future Contract side of a CFD. This can be done using Global Process Center module. It is a three-step process that involves calculation, approval, and cash settlement.
- Step 1: Calculating Daily VM
- Calculates Variation Margin based on Future price change
- Posts it to unrealized gain/loss of the fund
- Step 2: Approving VM
- On Approval, Variation Margin posts to receivable or payable
- By default, VM will settle the following business day if a Business Calendar is selected on the entity; if no calendar is selected, VM settlement date will be equal to VM approval date
- Market Value Income is impacted after running approval
- Step 3: Cash Settlement – via Contract Cash or Manual Settlements
- Upon settlement, VM posts to CASH
- The direction of the price movement will determine if VM is paid or received
Clients who do not wish to impact cash on the current day can elect to delay cash settlement when approving margin. On the Approve Margin panel, setting Advance Variation Margin Settlement Date to Yes (or leaving it null) will result in the cash being settled on margin date + 1 business day. Selecting No will cause the cash to be settled on margin date when a contract cash event is run.
- When margin settlement is delayed by a day, running Contract Cash on T + 1 settles the cash records that were created on T
- If users elect to delay cash settlement of the margin by one day, the same approach should be followed for the related income or expense posting
Long-Term Bond
Prices for the Long-Term Bond side the CFDs must be clean and par-based. Accounting calculates the security’s value by using the formula below:
- Market Value = Par Value * Clean Unit Price * Price Multiplier * Quantity Scale
0 Comments