Forward Rate Agreements
Forward Rate Agreements
User Guide
No part of this document may be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.
Forward Rate Agreements
Table of Contents
Overview.................................................................................................................................................. 4
FRA Purchases .................................................................................................................................... 5
FRA Sales ............................................................................................................................................ 5
Setup ....................................................................................................................................................... 6
FRA.PARAMETER .............................................................................................................................. 6
General processing information ....................................................................................................... 8
Accounting information ..................................................................................................................... 8
Trading FRAs ................................................................................................................................... 9
Hedging FRAs .................................................................................................................................. 9
Upfront Profit Allocation.................................................................................................................... 9
FRA.AGREEMENT.TYPE.................................................................................................................. 10
PERIODIC.INTEREST ....................................................................................................................... 11
Deal/Transaction processing ................................................................................................................. 12
Inputting an FRA ................................................................................................................................ 12
Non Stop Processing ......................................................................................................................... 17
Rate Fixing ......................................................................................................................................... 17
Group Rate Fixing .............................................................................................................................. 18
Close of Business Processing ........................................................................................................... 22
Start of Day Processing ..................................................................................................................... 22
Related Deals .................................................................................................................................... 23
FRA positions ..................................................................................................................................... 24
FRAs and Limits ................................................................................................................................. 26
FRA Position Management Interface ................................................................................................. 27
Cash-Flow/Liquidity ........................................................................................................................ 27
Interest Gap .................................................................................................................................... 27
FX Position ..................................................................................................................................... 27
FRA calculations ................................................................................................................................ 28
Future Rate Calculation.................................................................................................................. 28
FRA Valuation ................................................................................................................................ 32
Calculation of Settlement Amount .................................................................................................. 34
Profit/Loss calculation on Trade Date ............................................................................................ 35
Accounting process ............................................................................................................................... 36
Specific rules for Trade Deals ............................................................................................................ 36
Timing of Accounting Entries ......................................................................................................... 36
Profit entries ................................................................................................................................... 36
Overview
The Forward Rate Agreement (FRA) module supports processing for both Hedging and Trading
purposes. The module is fully integrated with T24 applications such as Limits and Position
management. In addition, Trading FRAs can be monitored via separate FRA positions.
Flexibility within the FRA module allows the User to exercise a high level of control over FRA
processing and accounting rules.
Reports included with the module highlight transactions that remain unconfirmed, and due for rate
fixing.
• HEDGE
A FRA.DEAL booked by the bank to lock in a profit (or minimise a loss) to offset a Loan or Deposit
contract on the bank’s books.
• TRADE
A speculative deal that is booked and usually offset against an opposite contract which, ‘closes’ the
first deal.
FRA Purchases
• PROFIT
Where the settlement rate is HIGHER than the FRA.DEAL contract rate
• LOSS
Where the settlement rate is LOWER than the FRA.DEAL contract rate
FRA Sales
• PROFIT
Where the settlement rate is LOWER than the FRA.DEAL contract rate
• LOSS
Where the settlement rate is HIGHER than the FRA.DEAL contract rate
Setup
FRA.PARAMETER
Basic information for FRA processing is defined in the application FRA.PARAMETER. Each
COMPANY has it’s own FRA.PARAMETER record that allows FRA processing to be specific to
each business environment.
All FRAs must be classified as either Trade or Hedge on input. It is not possible to change the
classification of a FRA. If a FRA is booked incorrectly, it must be reversed and re-input.
Trading and Hedging FRAs are processed differently by T24. Trading FRAs are included in
FRA.POSITION and these positions are revalued regularly according to the rules specified in
FRA.PARAMETER. The booking of this profit/loss is defined in FRA.PARAMETER.
Hedging FRAs do not appear in FRA positions. They only make Profit or Loss at settlement, which is
then accrued over the life of the contract.
FRA.PARAMETER contains Accounting and processing rules relating to all FRA contracts, and
specific to Hedges and Trades.
Accounting information
All Contracts:
• Category codes for Brokerage expense
• First/last day accrual
Trading FRAs
Hedging FRAs
The field RECALC.MKT.PL on FRA.PARAMETER can be populated with either a YES or NULL
value. After authorisation this becomes a no change field.
When the market exchange profit /loss figure is posted on the trade date, it is not discounted because
the settlement rate is not known at this time.
If recalculation of market exchange profit/loss is required on the settlement date i.e. when the
settlement rate is known, the field RECALC.MKT.PL should be set to YES.
The fields MKT.EXCH.PL.CATEG and MKT.EXCH.PROD.CATEG either hold a NULL value or relevant
category codes. By default these fields will hold a NULL value. When internal account categories are
recorded in these fields, they are used for accounting entries for marketing department profit/loss.
Both of these fields must be populated with values to enable the user to commit the record. After
authorisation these fields become no change.
FRA.AGREEMENT.TYPE
This file is used to store the types of agreements used in FRA.DEAL contracts, e.g. ISDA, FRABBA
etc. Each contract must be linked to an agreement type. The field AGREEMENT.TYPE on the
FRA.DEAL is validated against the agreement type definitions on the FRA.AGREEMENT.TYPE
file and enriched with the associated description.
FRA.AGREEMENT.TYPE
PERIODIC.INTEREST
Rates need to be defined within PERIODIC.INTEREST for each type of floating rate that is required.
For example, 3 Month LIBOR and 6 Month LIBOR need to be set up as two different records within
PERIODIC.INTEREST. E.g.07USDyyyymmdd could represent the 3Month LIBOR rate, and
08USDyyyymmdd could represent the 6 Month LIBOR rate for the same system date.
Each record must only have one entry other than the "Rest” entry. If a table has more than these two
entries only the first value (by nearest date) is used; the second and any other subsequent values will
be ignored.
The system allows up to 99 different types of rate sets per day for each currency.
PERIODIC.INTEREST
Deal/Transaction processing
Inputting an FRA
Many of the details required to input a FRA.DEAL are similar to those for a Money Market deal i.e.: -
• Counterparty
• Principal (notional)
• Currency
• Rate
• Commission
• Brokerage
• Settlement details, etc
The field FRA.TYPE is one of the key fields for FRA input. This specifies whether the deal is a
TRADE or a HEDGE. FRA.DEAL will not accept input of a transaction unless the FRA.TYPE is
specified, as this tells the module how to process the accounting for the transaction.
The fields TREASURY.CUSTOMER and TREASURY.RATE are used to identify a customer as a treasury
customer and allow the input of a treasury rate if it is required. The TREASURY.CUSTOMER field holds
either the value ‘NULL’ or ‘NO’.
By default it records the value as NULL, which means that the counterparty is in fact a treasury
customer. However, if set as ‘NO’, it is construed that the counterparty is not a treasury customer, in
which case, it is mandatory for the user to input a value in the field TREASURY.RATE.
Input to these fields is not allowed after the authorisation of the deal
The following fields are also used to display and record certain elements of the contract throughout the
term of the trade MKT.EXCH.PL.AMT, RECALC.MKT.PL.AMT, MKT.EX.PL.DLY.ACCR,
MKT.EX.PL.TOT.ACCR, MKT.EX.PL.AC.TODAT, MKT.EX.PL.AC.EQUIV and
MKT.EXCH.PL.EQUIV.
Rate Fixing
A second stage of input is required for FRA contracts. On the day of Rate fixing, the prevailing rate
should be input so that the settlement amount can be calculated. The Rate fixing date is taken to be
the deal start date. The following table summarises the main dates for FRA events: -
A number of rates are input on a FRA transaction. Key rates are the INTEREST.RATE - the rate
agreed when the FRA is input, and the SETTLEMENT.RATE - the prevailing rate on the rate fixing
date. The difference between these two rates determines the settlement amount. In addition, the
REFERENCE.RATE and REFERENCE.PRICE are used to for tolerance checking.
Trades that match certain user-specified criteria are fixed using the ST.GROUP.FIX application. This
application allows the group fixing (also known as rate reset) operation to be run intra day or at Close
of Business (COB), and may be rerun e.g. in cases where the wrong rate has been used.
The ST.GROUP.FIX application provides an interface for the User to select which FRA trades are to
be fixed, and executes the fixing operation upon authorisation. A group fixing operation must be
authorised before it is executed since it involves changes to transaction data.
When creating group rate fixing requests, various parameters are specified (e.g. the instrument,
instrument type, currency, rate fixing code and effective date) along with operational parameters (e.g.
whether a report is necessary). The request automatically detects trades requiring a rate reset and
sets the rate accordingly.
ST.GROUP.FIX application used as an interface for selecting, which FRA Trades are to be fixed
The instrument type For FRAs is either “HEDGE” or “TRADE” as defined by the field FRA.TYPE in
FRA.DEAL.
The effective date is the date on which the new rate takes effect and is not necessarily the date on
which the fixing operation itself happens. Typically, fixing occurs two days before or on the day the
new rate takes effect, depending on the currency. This is the settlement date of the FRA.
The ST.GROUP.FIX record specifies whether the FRA trade becomes authorised or unauthorised
after the fixing operation is executed.
The rate fixing code determines which PERIODIC.INTEREST rate set to use. In the case of FRAs it
is directly linked to the PERIODIC.INTEREST table via the field REFERENCE.RATE in FRA.DEAL.
The User must input the same code in ST.GROUP.FIX that they use to flag the floating rate within
the trades.
Rates are derived from PERIODIC.INTEREST. The key to this table is NNCCYYYYYMMDD e.g.
10GBP20020602, which allows up to 99 individual records to be captured per currency per day. This
enables individual tables for individual product types.
When an unfixed leg is due for fixing the FRA application downloads the rate from the source rate file
and automatically updates the FRA transaction record with the relevant rate.
Reports are available that list details of the fixing operations carried out and any errors encountered.
If several overnight requests are required, for example on an IMM fixing date, one record per
combination of instrument/currency/rate fixing code/effective date will need to be input and authorised,
and marked to be run at COB.
If the User requests that trades are authorised by the fixing process, then the effect of the updated
transactions will be included in the same-day P&L.
The FRA.START.OF.DAY batch job matures all contracts with SOD.MAT set to ‘Yes’, where the
maturity or value date equals the processing date. (The DATE.CHANGE task occurs before the
FRA.START.OF.DAY and SYSTEM.LIMIT.SOD tasks in the overnight batch process so the
processing date now equals the appropriate start of day date).
All STMT.ENTRY, CATEG.ENTRY and CONSOL.ENT.TODAY are raised during the start of day
process. The system recognises that these accounting entries have been made so they are not
duplicated in the Close of Business process.
Similarly, the SYSTEM.LIMIT.SOD batch job updates all limits during start of day.
Related Deals
Both Hedging and Trading FRA contracts may have related deals.
Hedge transactions, by definition, are hedging another deal. This is tracked by entering the deal id in
HEDGE.TRANS.ID.
Trade FRAs may be closing an existing FRA position for profit taking. The POSN.OPEN.CLOSE flag
indicates whether a trade opens or closes a position. The CLOSED.FRA.IDS shows which FRAs
have been closed out.
If a FRA is replacing an earlier deal, e.g. a trade has been erroneously input as a hedge, it must be
reversed and re-input to make sure that all the accounting entries made so far are removed. In this
instance, the field REPL.DEAL.REF can be used to track the original deal reference.
FRA positions
The FRA module automatically updates Position Management, but in addition, a separate FRA
position file is maintained. FRA.POSITION contains position information about all ‘Trade’ contracts.
(‘Hedge’ transactions usually remove a position or risk for the bank, and so are not included in this
file.)
FRA positions are held by currency, dealer desk and period. FRA positions record information about
the deals that make up the position in addition to combined and profit data.
For an explanation of how positions and profit are calculated, see the section ‘FRA Calculations’ later
in this User Guide.
Each position also records information about the constituent deals. Trades done today are kept
separate from previous business, but the following information is stored for both:
• Deal id
• Trade date
• Principal
• FRA rate
• Profit, if closed
FRAs are not subject to a centralised exchange regulatory authority or to a centralised clearing body
who act as guarantor. As a result FRAs carry counter-party credit risk; there is a risk that monies due
for payment from one party to another will not be forthcoming.
As principal is never exchanged, exposure to credit risk is limited to the actual payments, i.e. interest
variation. Thus the potential credit risk is dependant upon the volatility of interest rates. This “reduced”
risk can be monitored, by defining a percentage risk on the LIMIT.REFERENCE file for the FRA
products.
Limits apply to both Hedging and Trading FRAs and to both sales and purchases. The exposure will
be liquidated at deal start, rather than deal maturity, as settlement is on deal start date.
See the ‘Limit’ User Guide for full details of the LIMIT application.
The FRA application is fully integrated within the Position Management (PM) module. All updates take
place at time of first input after successful validation.
The following rules apply for the interface to the various components of the PM module:
Cash-Flow/Liquidity
For both trade and hedge contracts, from the input of the FRA contract until the rate fix date, a
projected cash-flow is calculated at each Close of Business using the PERIODIC.INTEREST table,
similar to the Trade contract revaluation process. This figure is passed each day to the cash-flow
enquiry until rate fix date, when the projected figure is replaced by the ‘true’ value.
On the rate fixing date, as defined on the FRA.PARAMETER table, (normally two days before
settlement date for foreign currency, and equal to settlement date for local currency) the settlement
amount is calculated, and the resulting profit ("IN") or loss ("OUT") included in the cash flow under the
settlement value date.
Interest Gap
Only "hedging" contracts are included and feed the PM module. The REFERENCE.PRICE on the
FRA.DEAL contract is used for the LONG period rate. The SHORT period rate is calculated
according to the standard formula.
FX Position
The standard FX position request is performed within the accounting process, whenever entries impact
the foreign exchange position. This will be the case for example on:
FRA calculations
Assuming there are two futures contracts on the market with quoted rates R1 and R3, covering the
period from Spot to FRA Start and from Spot to Maturity respectively, the formula to calculate the
forward rate R2 is as follows:
Where:
R1 = rate for short period (the period between Spot and FRA Start)
R3 = rate for long period (the period between Spot and Maturity)
⎡ R3 * D3 ⎤
⎢1 +
R2 = ⎢ B * 100 − 1⎥ * B * 100
⎥
⎢ 1 + R1 * D1 ⎥ D3 − D1
⎣ B * 100 ⎦
( R3 * D3) − ( R1 * D1) ⎛ R1 * D1 ⎞
R2 = ⎜ + 1⎟
D3 − D1 ⎝ B * 100 ⎠
Example:
Today is August 8th 1996 (spot date 10th August 1996) and we wish to revalue an existing contract.
These rates are found or, when necessary, interpolated from the PERIODIC.INTEREST rate table.
(Note that number of days is always calculated from the spot date)
(1,247.40) − (385.40)
= 91
⎛ ⎡ 385.40 ⎤ ⎞
⎜⎢ + 1⎟
⎝ ⎣ 36000 ⎥⎦ ⎠
862
= 91
([0.0105589041] + 1)
= 9.47252747 10105589041
.
862
= 91
([0.0105589041] + 1)
= 9.47252747 10105589041
.
R2 = 9.37% to 2dpl
FRA Valuation
Where:
Nominal = nominal amount of FRA deal
Since the FRA contract is settled up-front the formula for the present value of the Profit/Loss is as
follows:
Profit.or.Loss
Present.Value =
Mkt.Rate * NDays
1+
B * 100
Example:
Profit
P=
[ (9.5 − 9.25) × (91 × 50,000,000)]
36000 + ( 9.50 × 91)
Profit of 0.35 at 150 million for 3 months and a new position of Short 50 million at 9.6%
S=
( I − F ) × ( N × P)
B × 100 + ( I × N )
Where:
To settle the contract in the first example, i.e. a purchase of 1 against 4 FRA for 250M USD at 9.4%,
when LIBOR is at 9.37%;
S=
(9.37 − 9.40) × (91 × 250,000,000)
360 × 100 + ( 9.37 × 91)
− ( 0.03) × (22,750,000,000)
=
36000 + ( 852.67)
= -18,519.69
Where:
P = Principal
N = number of days from start to maturity
Rt = treasury interest rate
Rc = contract interest rate
The following rules are followed for market exchange P/L calculation:
Purchase FRA:-
Profit to marketing department when
Contract interest rate < treasury interest rate
Loss marketing department when
Contract interest rate > treasury interest rate
Sale FRA:-
Profit to marketing department when
Contract interest rate > treasury interest rate
Loss marketing department when
Contract interest rate < treasury interest rate
Accounting process
The FRA module has been designed to give a high level of flexibility with regard to the accounting
aspect of FRA transactions. The User controls many accounting decisions by defining the appropriate
values on the FRA.PARAMETER table. For example, this is where the decision is made whether to
book unrealised profit, whether to recognise realised profit on trade date or FRA start date, or make
customer charges on trade or start date, etc.
FRA.PARAMETER should be set up to reflect the business environment. FRA accounting must also
reflect the results of management decisions: different rules will apply depending on whether a contract
is classified as a Hedge or a Trade.
Profit entries
• Realised profit can either be posted on trade date or deal start date
• Unrealised profit can either be posted, or not posted
1. Positions (both total and contract level) are reversed each day and re-posted. Even if the posting
leaves the figures unchanged. This is considered far better than adjustments, for audit purposes.
At the end of each day, the adjustments to the profit and loss for ‘closed’ trades are posted. This
P&L is taken as realised Profit or Loss. This adjustment can be split into two - today’s P&L and an
adjustment to yesterday’s figure. Each part is processed separately. A net P&L amount is kept on
the FRA.POSITION file. If this is Profit, daily entries are processed according to ‘Profit’
accounting rules.
2. The net open position (i.e. total position rather than deal-by-deal) is also revalued. Any previous
revaluation is reversed, and the new revaluation is posted as unrealised P&L.
3. When the rate fixing date is reached, the position P&L entries are reversed out and booked to the
individual deals.
4. Between rate fixing date and settlement (start) date, the P&L for each deal is reversed and
recalculated daily to keep the posted P&L converging to the settlement amount.
5. On settlement date, the deal P&L is again reversed, and the actual settlement amount posted as
realised P&L.
6. When the total realised profit and loss figure changes from a loss to a profit (or vice versa), then
the accounting entries will bring the loss category to zero and raise the profit position (or vice
versa).
Recognition of the FRA contract by the creation of a contingent CRF record. This will be reported as
an off-balance sheet item:
Between deal date and rate fixing date, for trade contracts only, revaluation takes place determined by
the frequency specified in the FRA.PARAMETER, with the resulting profit or loss optionally booked
or not to unrealised profits. This is determined via the field BK.UR.PFT in FRA.PARAMETER. See
the FRA.PARAMETER helptext for a more detailed explanation of the options on profit/loss booking.
The revaluation is based on the net FRA position by currency, until rate fixing day from where the
deals are re-valued individually until settlement date. Each new revaluation will result in the previous
day’s calculation being reversed, and the updated figure being posted to the internal asset or liability
account.
Profit or Loss for Closed contracts is ‘locked in’ when the closing trade is made. According to the
setting of REAL.PFT.T/S in FRA.PARAMETER this realised Profit can either be taken on trade
date or on settlement date.
If Profit is to be taken on Trade date, the following additional postings are made on Trade date:
There are no revaluation entries between Trade date and Rate setting date for Closed trades, as the
Profit from the contracts cannot change.
If the Profit is to be taken on Settlement date, the above entries will only be made in the case of
closing out a Loss. If the closure has made a Profit, no entries will be made to reflect this until
settlement date, when the money is actually received from the counterparty.
Rate fixing
At Rate fixing date, the Profit or Loss for all contracts in the position is known. Up until now, all P&L
postings have been net for the total position. This net Position P&L is reversed out:
(Unless realised profit is deferred till settlement date, in which case no entries are made for trades in
profit until then.)
On settlement date the profit or loss entries are generated as appropriate, with the offset to customer
or Nostro.
Existing off balance sheet accounting entries (reporting the deal as contingent) are removed by
application of the opposite accounting entries.
The amount to be paid or received by the bank on settlement day will be deferred to an internal asset or
liability account (IPIA/IRIA), and appropriated to profit and loss over the fixed rate period, (i.e. from
settlement to maturity date) on a straight line basis.
Existing off balance sheet accounting entries (reporting the deal as contingent) are removed by
application of the opposite accounting entries.
In the event of late rate fixing of trade contracts, entries are booked to P&L as normal, with the offset
to suspense accounts. The handling of the payment or receipt of funds is a manual activity, after
consultation with the counterparty.
Existing off balance sheet accounting entries (reporting the deal as contingent) are removed by
application of the opposite accounting entries.
In the event of late rate fixing of hedge contracts, entries are booked to P&L as normal, with the offset
to suspense accounts. The handling of the transfer to an internal asset/liability account is handled
manually.
From the internal account, the profit or loss is turned to P&L over the life of the contract i.e. from
settlement to maturity date.
Set up – FRA.PARAMETER
FRA.PARAMETER Set-up
At deal level, the Revaluation settings defaulted in field CALC.OR.BOOK can be overridden. The
system initially defaults the value from HEDGE.REVAL.METHOD of the FRA.PARAMETER into the
field CALC.OR.BOOK of the FRA.DEAL. If the value defaulted is BOOK, then the user can over-ride
it either by clearing the defaulted value or by inputting CALC. If the value defaulted is CALC, it can be
over-ridden by clearing it.
Hedge deals with a null value in the CALC.OR.BOOK field are treated like regular Hedge deals.
FRA.HEDGE.POSITION
The position for FRA Hedge deals with a value BOOK or CALC in their CALC.OR.BOOK field is
maintained in the FRA.HEDGE.POSITION file. Unlike Trade deals, where the position is
maintained group wise, the FRA.HEDGE.POSITION is maintained from a deal perspective.
FRA.HEDGE.POSITION
The FRA.HEDGE.POSTION records, among other things, whether the deal is a BUY deal or a
SELL deal, the rate at which the deal was marked to market (MARKET.RATE), the deal rate, the
notional amount of the deal and the FRA Period. The field HEDGE.REVAL.METHOD displays whether
the un-realised profit or loss is to be booked (Field Value: BOOK) or not (Field Value: CALC).
HEDGE.REVAL displays the status of the deal in terms of whether the deal is un-fixed, fixed, overdue
for fixing, reversed, or whether the profit/loss displayed against the field REVAL.PROFIT.LOSS is
realised or un-realised. For un-fixed deals, REVAL.PROFIT.LOSS holds the un-realised profit/loss.
For deals whose rates have been fixed during the day, the HEDGE.REVAL field is updated with the text
FIXED.REAL (during the Close of Business processing) and the field REVAL.PROFIT.LOSS then
records the realised Profit or Loss.
Post COB after rate fixing, Hedge Position is updated with FIXED.REAL
If the deal is in Foreign Currency, REVAL.PROFIT.LOSS displays the profit/loss in foreign currency
and the field PROFT.LOSS.EQUIV displays the Local Currency Equivalent of the same.
When a deal is reversed, the field HEDGE.REVAL is updated with a suffix “.REV”.
A FRA.HEDGE.POSITION record doesn’t exist for deals without a value in the field
CALC.OR.BOOK.
Accounting
The process flow for Hedge deals that have been subject to fair-value principle is as follows: -
Process Flow
During the UNFIXED stage, the un-realised profit or loss, if any, is booked to the accounts/PL heads in
terms of the definitions in the FRA.PARAMETER. On fixing, the un-realised Profit/Loss is reversed.
Depending on the definition on FRA.PARAMETER, the realised Profit/Loss is either booked to the
accounts/PL heads on Fixing Day or Amortized from Start Date as in the case of regular Hedge Deals.
Re-valuation Accounting
During the Close of Business processing on each day, these hedge deals are re-valued against the
Market Rate (Computed in the same way as for the TRADE Deals) and the Un-realised Profit or Loss
booked to the Categories defined in FRA.PARAMETER. On each day, the previous Un-realised
Profit or Loss is reversed and a new entry is booked as in the case of TRADE Deals. The re-valuation
is on a deal basis.
If the deal is reversed before fixing or immediately after fixing, the HEDGE.REVAL field on
FRA.HEDGE.POSITION is updated as UNFIXED.REV or FIXED.REV as the case may be. During
the Close of Business Processing, the previous Un-realised Profit or Loss of the reversed deal is
reversed and there is no further Re-valuation.
The above example illustrates the booking of Un-realised PL (Loss in this example) on each working
day, (30th Nov, 4th Dec and 15th Dec) and the reversal thereof on the following working day.
These deals are re-valued, but the un-realised Profit or Loss is not booked. The un-realised profit or
loss is indicated in the field REVAL.PROFIT.LOSS/PROFIT.LOSS.EQUIV on the
FRA.HEDGE.POSITION file.
These deals are not subject to fair-value principle and are handled as regular Hedge deals.
Amortization Accounting
The option exists to decide at the Parameter level whether to book the Realised Profit/loss on
settlement at one go (i.e. like the Trade deals) or to amortize it over the period of the FRA (i.e. like
regular Hedge deals). This option is exercised through the field AMORT.HEDGE in FRA.PARAMETER.
This field can be set to NO if HEDGE.REVAL has been set to YES and HEDGE.REVAL.METHOD to
BOOK. The value in AMORT.HEDGE on FRA.PARAMETER is defaulted into the field AMORT.HEDGE
on the application FRA.DEAL. If this is set to NO, then the Realised Profit/Loss on such hedge deals
is not amortized and is applied to the realised Profit/Loss categories on the Fixing date of the deal.
A Null value in the field AMORT.HEDGE on FRA.PARAMETER leads to amortization of the realised
Profit/Loss from the Start Date to End date as in the case of regular Hedge deals that have not been
subject to fair-value principle.
The realised Profit/Loss categories are defined in the fields P&L.RL.PFT.HEDGE (for realised Profit),
and P&L.RL.LOSS.HEDGE (for realised loss). During the Close of Business on the date the rate is
fixed, the realised profit/loss is booked by raising matching suspense account entries as per the
category codes defined in the PROD.RL.PFT.HEDGE and PROD.RL.LOSS.HEDGE fields of
FRA.PARAMETER. These Suspense entries are reversed at the Start day by appropriate debit or
credit to the customer account.
Between rate fixing date and settlement (start) date, the P&L for each deal is reversed and raised
again daily to keep the posted P&L converging to the settlement amount.
On Start Date, as the settlement takes place, the key of the Realised PL entry undergoes change.
Un-fixed deals
Sometimes, FRA deals are fixed on dates later than the Fixing Date as there could be a delay in
getting the rates. During the Close of Business Processing on the Fixing Date, the
FRA.HEDGE.POSITION record of such deals is updated with UNFIXED.DUE. The system
notionally arrives at the Market rate as hitherto, and books, or otherwise, the un-realised Profit/Loss as
per the definition on CALC.OR.BOOK field. Thereafter, there is no further re-valuation of the overdue
deals based upon subsequent rate changes, as these deals are eventually expected to be fixed with
the rates prevailing on the Fixing Date for the relevant FRA Period.
The report FR.HEDGE.REVAL is available to view the details of the Hedge deals that have been
subject to re-valuation. The report lists the Profit/Loss on each deal as at the end of previous day.
Deals with either CALC or BOOK in the field CALC.OR.BOOK are listed in the report
Reports
The following reports are released with this module:
Report Description
FRA.REVAL FRA positions revalued
FRA.HEDGE.DEALS List of outstanding hedges
FRA.MTH.ACCRUALS Accruals on hedge deals
FRA.RATE.SETTING.REPORT FRAs where rate is due to be fixed (as specified on
FRA.PARAMETER)
FRA.OVERDUE.REPORT FRAs where start date has passed, but rate not fixed
OUTSTANDING.FRAS List of all ‘live’ transactions
UNFIXED.FRAS FRAs where rate not fixed yet
CUS.UNCONFIRMED.FRAS List of FRAs still to be confirmed by the counterparty
BROK.UNCONFIRMED.FRAS List of FRAs still to be confirmed by the broker
FRA.REALISED.PL.REPORT P&L breakdown for each position
Enquiries
The following enquiries are released with this module: -