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 11 Current »

Overview

A Forward Rate Agreement (FRA) is the simplest form of an Interest Rate Swap (IRS), essentially a single period IRS. The major difference is that FRAs do not accrue interest income. Since FRAs are single period instruments, the payoff is known well before maturity. The price of an FRA remains constant after the Dated Date of the floating leg, so there is no need for the legs to accrue. This document covers the details of Accounting, Data Management, and Performance for FRAs.

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.

Entity Setup

Before any trades can be booked, the target entity must be set up appropriately. Refer to Swaps Entity Setup Processing Notes for details.

Reference Data

Eagle has modeled FRAs 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 by following the steps here: Allow Duplicate Cross Reference Identifiers Processing Notes.

FRAs should be set up and viewed using Issue Viewer or Security Reference Manager > Add > Derivatives > Interest Rate Swap, or Reference Data Center.

  • The contract as well as the pay and receive legs will have their own Security Aliases

  • All three records share the same Primary Asset ID

  • Payment Frequency: set to At Maturity (MAT)

  • Stopping accruals on FRA legs: to keep the legs of an FRA from accruing, use Add Debt Default Period/Inhibit Earnings

    • Both legs of an FRA can be marked to not accrue, with appropriate Comments added

    • This will stop the legs from accruing even past Dated Date/Settlement Date

    • Default Start Date must be set to Issue Date of the FRA

Trade Processing

Open (event type: OPENSWAP)

Once the security reference and entity data is setup trades can be entered using the Book Trade module under the Trade tab. Other than basic information like Trade Date and Settlement Date, below are FRA specific required fields:

  • Data Entry Method: Enter Price to supply a clean unit price or Enter Total Settlement Amount to supply a value representing all-inclusive trade proceeds (both can be positive or negative)

  • Notional Principal Value: represents the notional of the FRA.

  • Traded Interest Local = Calculate None

Close (event type: CLOSESWAP)

The Book Trade module should be used to process closes. Eagle Accounting can handle both full and partial terminations.

Cancel & Rebook

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

Accounting

Once an FRA trade is successfully booked it will follow all core Eagle Accounting processes.

Valuation

FRAs should be priced at the contract level. Accounting calculates the value of an FRA by using the formula below:

Market Value = (National Amount * Clean Unit Price * Price Multiplier * Quantity Scale)

Quantity Scale and Price Multiplier are typically 1 for FRAs, and accrued interest is 0.

Similar to a fixed income instrument, accounting assumes a swap has the same price across all accounts. If there is a need to use different prices across entities then account level price overrides have to be used. If there is a need to use dirty pricing, then the pay and receive legs of the FRA should be setup to not accrue. This can be accomplished by populating both legs with a coupon of zero. Note that this also implies that cash and payments will not be created.

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 FRA in the POSITION, POSITION_DETAIL, TRADE, and CASH_ACTIVITY tables. The MARKET_VALUE_INCOME column captures the total market value at the contract level.

Accounting Reports

Eagle has a core set of accounting reports that can be used to review FRA 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.

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

Performance

The performance toolkit has full functionality to calculate market value based performance at the contract and leg levels. The toolkit process is pre-configured to read data supplied by the STAR to PACE process and calculate performance.

  • The swap contract and the legs will be grouped under the correct bucket based on your existing performance model

    • Rollup level returns will be accurate, however the absolute return number might not make intuitive sense

    • Because the FRA typically has a beginning market value of zero and is valued relative to the market value, the individual returns may not be meaningful

      • In these instances reporting contribution to return will make more sense

  • Clients needing returns at each instrument level can create a group based on Primary Asset ID; grouping the report by Primary Asset ID will aggregate the data at the FRA deal level with full drill through to the underlying legs

    • Contract: performance due to price change

    • Pay Leg: performance due to accrual paid to counter party; zero in case of FRAs

    • Receive Leg: performance due to accrual received from counterparty; zero in case of FRAs

  • Once performance data is committed to the database, performance link analysis, risk analysis, and performance attribution analysis features are available to analyze FRA performance

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

FRA prices must be loaded to the contract only. Make sure you set tag 4590 = C in your price message.

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