Professional Documents
Culture Documents
Foreign Exchange
Foreign Exchange
Foreign Exchange
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.
Table of Contents
Overview.................................................................................................................................................. 5
Foreign Exchange ................................................................................................................................ 5
Main Products .................................................................................................................................. 5
Non Deliverable Forwards ................................................................................................................... 7
Types of Products ............................................................................................................................ 7
Main Setup .............................................................................................................................................. 8
Other Types ...................................................................................................................................... 8
Deal Sub Types ................................................................................................................................ 8
Configuring T24 Foreign Exchange Tables ......................................................................................... 9
FX.PARAMETERS ........................................................................................................................... 9
FX.TRANSACTION.TYPE.............................................................................................................. 10
FX.REVAL.TYPE............................................................................................................................ 11
DEALER.DESK .............................................................................................................................. 15
BROKER ........................................................................................................................................ 16
FX.DEAL.METHOD ........................................................................................................................ 16
FORWARD.RATES ........................................................................................................................ 16
FX.TEXT ......................................................................................................................................... 17
Configuring T24 Non Deliverable Forward Tables ............................................................................ 17
ND.PARAMETER ........................................................................................................................... 18
ND.TYPE ........................................................................................................................................ 19
EB.AGREMENT.TYPE ................................................................................................................... 19
Deal/Transaction Processing ................................................................................................................ 20
Foreign Exchange .............................................................................................................................. 20
Main input ....................................................................................................................................... 20
Spot deal input ............................................................................................................................... 20
Forward contract ............................................................................................................................ 21
Swap contract................................................................................................................................. 22
Bullion contract ............................................................................................................................... 23
Neutralisation of forward interest ................................................................................................... 29
Neutralization of forward interest (Amortising positions)................................................................ 29
Bulk Orders .................................................................................................................................... 30
Limit Orders .................................................................................................................................... 39
Confirmations ................................................................................................................................. 45
Charges and Commissions ............................................................................................................ 46
Revaluation .................................................................................................................................... 48
Allocation of Exchange Profit ......................................................................................................... 56
Overview
The Foreign Exchange module (FOREX) has been designed to meet the growing needs of current
day dealing operations in the Foreign Exchange Market. It covers the accurate recording of all types of
SPOT, FORWARD and FX.SWAP transactions, complete with limit exposure, position updating,
brokerage and delivery of the related advices, confirmations and payments.
Foreign Exchange
Main Products
Spot contract
The buying or selling of foreign currency (normally within seven calendar days of the date the contract
is made unless a shorter period is customary or required in the local market). The exchange rate
applied is called the spot rate.
Forward contract
A forward contract is the buying or selling of foreign currency for delivery in the future, i.e. at a date
later than the locally defined spot date. The exchange rate applied is called the forward rate.
Swap contract
A swap contract is the exchange of currencies at spot with one or more associated forward deals, or
"legs", where one currency amount is fixed. The different rates applied on the spot and forward deals
reflect the interest rates of the respective currencies. Both spot and forward transactions are usually,
but not necessarily, done with the same Counterparty. T24 maintains the link between the spot and
forward deals automatically and processes them as a unit.
Option contract
The buying or selling of foreign currency where the delivery may take place at any time between two
specified dates at the customer's choice without incurring any penalty costs. This option occurs when
the customer decides to take delivery of all, or part, of the transaction before the final value date. The
rate applied caters for the fact that the bank may need to conclude the deal at any date up to the
maturity date.
This is similar to the option contract above but different exchange rates may be set for periods within
the contract. A transaction type may be specified so as to differentiate it from Single Rate Option.
• Between the start date and the maturity date, there are defined time periods for which the
transaction can be exercised by the counterparty. These option periods are agreed upon at
the start of the deal.
• After defining the option periods, no amendment to the first option period is possible.
Amendments to the subsequent periods are possible only outside the current option period
and after the farthest scheduled delivery date.
• The full contracted amount will be updated in the LIMIT application for the final maturity date
of the deal even if no delivery is scheduled at the time when option contract is input. The limit
will be re-instated to the extent of delivered amount on the delivery date.
• As in Single Rate option, it is presumed that any undelivered portion will be delivered on the
final day of the option period. Position will therefore be raised for the last date of the first
option period initially. On crossing the last date of the current option period, Position for the
undelivered amount will be re-cycled to the last date of the next option period.
• Multiple deliveries are allowed, which can take place at any time between the option date and
the final (value) date. Each delivery (takedown), uses the exchange rate pre-defined for that
option period in which the value date of the delivery date falls.
• The total takedown amount cannot exceed the original amount bought or sold in the option
currency.
• It may be noted that all such confirmations will be produced only in the form of a PRINT
message even for contracts having a Bank as counterparty.
• Each takedown (the delivered amount) will be revalued separately against the market rate till
the delivery date.
• On the Value date of the contract, should there be any residual option amount that is
undelivered. T24 will liquidate the contract during COB by automatically scheduling a delivery
for the residual option amount at the exchange rate applicable for the last option period.
• A report containing the list of contracts that underwent such automatic scheduling of delivery
on a day shall be produced during COB.
• T24 will produce a report during COB to help the bank identify those contracts which have
residual balance of option amount, ‘n’ number of days before the Value date, where ‘n’ is
defined in the field OPT.OS.RP.DAYS in FX.PARAMETERS.
Vanilla
This is a standard NDF transaction type, which has an agreed rate fixing date (usually 2 working days
before settlement date). With this type the customer cannot change the fixing date.
Exotic
An exotic NDF is a variation that allows the fixing date to be set at any date during the life of the
transaction before the vanilla date. If the NDF is fixed and settled “early”, the fixing profit or loss is
discounted. The discount amount will be amortised from the settlement date to the value date of the
NDF.
A Non Deliverable Forward (NDF) is classed as an event where a currency is unable to be settled.
Because of this the deal must be fixed at a time and from a rate source arranged at the time of the
original trade. When the rate is fixed on the fixing date, the settlement will be a net settlement in the
deliverable currency only. This is calculated by using the difference between the original FX rate and
the fixing rate.
The Non Deliverable Forward functionality is incorporated into the LIMITS, ACCOUNTING and the
POSITION.MANAGEMENT modules.
Main Setup
Other Types
Contract types such as Antespot, Tom-Next or Spot-Next are by-products of the above deal types.
The FOREX module is capable of handling the following deal sub-types. The field DEAL.SUB.TYPE
is used to define deals which are internal or non-standard as they affect future validation/processing.
IN - Internal deal
Internal deals are handled differently from standard deals due to the fact their only purpose is to allow
transfers between different positions or dealer desks. Obviously, there is no need for accounting
entries, payments, advices etc. When an internal spot or forward deal is entered, the system will
automatically update the positions of both dealer desks entered into the contract.
NE - Negotiated deal
Departments other than Treasury may wish to book deals in advance and/or ‘negotiate’ a special (non-
default) rate for the customer with the Treasury.
This, for example, will be the case when a department wants to book a transaction involving
conversion of currencies for an amount greater than the negotiable amount defined on the currency
table. The FOREX module allows the dealer to record such deals, which are then automatically
reconciled with the departments' eventual input of the actual transaction. This ensures that the
Exchange position always reflects all committed deals even if the actual transaction has not yet been
entered. Negotiated deals cannot be authorised, as they are only temporary substitutes for the
departmental deal.
BR - Broker deal
Where a deal has been struck through a Broker and the Counterparty is not acceptable or known, 'BR'
can be entered as the sub-type.
The system will then expect Broker but not Counterparty details to be entered. As no Counterparty is
present it will not be possible for the contract to be authorised. When the Counterparty name is known,
the user will only need to erase 'BR' from this field and complete the Counterparty details.
A special ENQUIRY facility, FX.ENQ.BR allows the user to search, by Broker, those contracts where
the Counterparty is still missing.
This is to allow the banks position to be updated with the committed deal amounts.
FX.PARAMETERS
Within this table are defined parameters that determine some of the rules by which the system
operates. These are as follows:
Classification of the contracts between SPOT and FORWARD is dependent on the local Central Bank
and internal reporting rules.
FX.TRANSACTION.TYPE
The FX.TRANSACTION.TYPE tables define parameters for processing different types of FOREX
deals. Minimum details are supplied with the system for types SP, FW and SW deal types, which have
the same codes for their transaction types. Option deals should have the transaction types of the form
FWXX.
The ACTIVITY.CODE field relates to the codes in FX.ACTIVITY, which act as triggers for the
associated message types and formats. These will probably only be used with multi-rate option deals,
which will require more elaborate confirmations. The remaining fields describe rules to be applied to
the transaction type. The TRANSACTION.TYPE in the FOREX record will usually be input
automatically via the VERSION in operation.
A typical FX.TRANSACTION.TYPE.
The TRANSACTION.TYPE field defaults to the value of the DEAL.TYPE. The value of the field should
be set by the VERSION in use for input.
A FOREX Version.
FX.REVAL.TYPE
Within the FX.REVAL.TYPE table are defined the revaluation types available in the Foreign
Exchange application. The system caters for the following different Revaluation methods:
The primary factor, influencing the change of forward rates with time, is the difference in the interest
yields of the currencies.
Example:
Assume the yield on GBP is 12% and that on USD is 14% with a Spot rate of 1.25. Then, over 12
months
Thus, in order not to sustain a loss, the 12 month Forward USD sell rate should be (USD
1425/GBP1120) or 1.2723 i.e.
In practice, one of the amounts on the Forward deal is held at the same value as for the Spot deal. So,
in this example, if the forward deal is also for GBP 1000 the USD amount would be USD 1275 (i.e.
USD 1250 plus 2% interest differential thereon of USD 25).
Therefore, it is argued that the Discount on the forward USD 12 month rate is simply to offset the 2%
USD interest premium prevailing at the time of the deal. This apparent exchange Profit or Loss,
therefore, should be accrued over the life of the forward deal as in the manner of the straight line
method except that Profit and Loss Interest entries will now be booked for both the currency bought
(credit to Interest Received Exchange) and the currency sold (debit to Interest Paid Exchange).
As proof that this is correct, GBP 1000 at 12% would have given rise to GBP 120 interest, which
converted at spot of 1.25 is also USD 150.
The effect of this accrual (to discount the forward premium or discount) is to value the position at spot
rate so it is, therefore, necessary each day to perform spot revaluation.
This method is obviously most appropriate to the transaction type 'Swap' where an actual loan and
deposit could be booked with a spot and forward deal and the real interest rates can be used on the
forward leg, so rendering the deal entirely neutral. That is, the difference between interest paid and
received will be eliminated by the forward accrual and the spot deal will be cancelled, in its effect, by
the spot revaluation of the forward leg.
This is the most straightforward method as it is based (like the spot revaluation) on the cost or profit
attributable to closing the position i.e. to enter into a deal at today's rates to exactly cover each deal at
its maturity (buy back approach).
In the case of forward deals, the rate varies not only because of change in the market (supply and
demand factors) but also because rates vary with time. For any given forward deal, as it ages, the rate
to cover it, converges with the spot rate as it gets closer to maturity, until it will, eventually be covered
at spot rate.
Given a set of forward rates (FORWARD.RATES tables), you can still choose from 3 methods to find
the forward rate applicable to each forward contract viz.
• Interpolation.
• Next available rate.
• Rate at closest date.
• The rates on the forward exchange rate table (FORWARD.RATES) can be defined for any
period required by the user, (e.g. 1 week, 2 weeks, 15 days, 1 month, 2 months, 3 months etc).
• The actual date that the forward rates apply to are calculated as the reporting date + 2
working days + number of months.
• If this date is not a working day, then the next working day is used.
• When a rate is required for a date that falls between the dates of two rates on the table, then it
is calculated by linear interpolation.
As previously stated, there is generally a difference between spot and forward rates. Under this
method the difference, as an amount in local currency, is isolated as a profit or loss at the start of the
contract and then simply amortised over the life of the deal as a daily accrual between the appropriate
interest profit and loss category code (Interest Paid Exchange or Interest Received Exchange) and the
exchange reserve adjustment account.
(The following ACCOUNT.CLASS records are used to obtain the internal account category:
Effectively this deal is now being carried at spot rate (since the forward discount or premium is being
accrued) and therefore, it is necessary to revalue it each day just as if it was a spot deal using the
technique described in 'Spot Revaluation'. The rate at which it is re-valued is the REVAL.RATE if
specified on the CURRENCY table, else the MID.REVAL.RATE will be used.
This method is primarily for the Swap contract type and is similar to the SL method except that the
premium/discount of a Swap is amortised over the contract period in the currency in which the
premium/discount arises i.e. the currency, which differs in amount between the legs of the deal.
Like the interest method, this revaluation type takes into account the difference in the interest yields of
the contract currencies. However, the interest/hedged method bases its interest calculations not on
the actual amounts of the deal, but on a 'notional' principal amount on each side (buy and sell).
The notional principal amount is that amount which, given the interest rates applicable to each
currency of the contract, will yield the actual amounts of the deal over the contract term. In other words,
the deal amounts are effectively split into a principal and interest element and it is this interest element,
which is accrued on each side of the deal over its life.
The difference between the interest and interest/hedged methods can be illustrated by example.
In all cases, the USD interest rate is 14% and the GBP interest rate is 12%. The spot rate of exchange
between the two currencies is 1.25. The forward rates refer to a 12-month forward contract.
Example 1 illustrates the figures that have been described under the interest method of revaluation.
Example 2 shows a similar deal using the interest/hedged method. Finally, example 3 compares the
results of trading a round GBP deal amount, method 'IH', against the original example, method 'IN'.
Interest/Hedged Methods.
This method of calculating interest yields associated with a forward contract is appropriate to a
hedging situation where a forward foreign exchange deal is made in cover of balance sheet items.
Because the notional principal amounts correspond to an actual spot transaction and are not the same
as the resultant forward contract amounts, this revaluation type is not available for use on swap
contracts (DEAL.TYPE 'SW').
DEALER.DESK
The DEALER.DESK table allows the bank to specify to the system how its dealing room activity is
organised. For example, dealer desks can be defined for the major currencies. The dealer desk is
used as part of the key to the POSITION file. This enables the bank to view their currency position by
dealer desk, if required and to book the revaluation Profit/Loss at dealer desk level.
A DEALER.DESK example.
BROKER
The BROKER table allows the bank to identify its authorised Brokers.
FX.DEAL.METHOD
Foreign Exchange deals can be initiated in many different ways. They can be agreed through an
intermediary such as a Broker, in which case the BROKER needs to be identified, or through means
such as Reuters, Telex or telephone. The FX.DEAL.METHOD table allows users to define which
deal methods are applicable and to use this information on advices.
FORWARD.RATES
The FORWARD.RATES table allows the user to define, for each currency and market, forward
exchange rates. These periods can be defined either in months, e.g. 1 month, 2 months, 3 months, 6
months or in days, e.g. 7 days, 15 days, 30 days. The details are in the form of a premium or discount
(preceded by the minus sign).
This premium or discount must refer to the currency of the ID against the local currency. In
accordance with the value of the field QUOTATION.PIPS, defined on the CURRENCY table for the ID
currency, the system will automatically add/subtract this premium/discount from the CURRENCY
table middle rate.
Forward rates are used by the Forward revaluation (Rebate method) and also to provide tolerance
checks for forward rates on input of a Forward Foreign Exchange transaction.
FX.TEXT
FX.TEXT is a table of advice texts that will be printed on advices/confirmations when settlement
information for a Counterparty is not known. It is used where the Counterparty has not specified
settlement details and entries will be posted to an internal account if the settlement details are not
completed by the value date.
Nine options are available within this table and each one will have a unique text that will be printed on
the advice confirmation. The user can then choose which text to print by keying a number between 1
and 9 at the appropriate account field when loading a contract.
One record is used for payments (credits) the other for receipts (debits). Each can be posted to the
same or different suspense accounts (as defined in ACCOUNT.CLASS) by currency. Accordingly,
use of text 1 will default a different advice text if used in both the buy and sell account fields.
For NDF contract to be reported correctly and incorporated into the T24 General Ledger The
parameter file CONSOLIDATE.COND needs to be configured.
ND.PARAMETER
The ND.PARAMETER file is the main parameter record and must be set up before any data can be
entered. This file holds system level parameters for the processing of NDF transactions in a single
SYSTEM record.
ND.TYPE
The ND.TYPE file contains definitions of all types of NDF contracts allowed on the system. It also
holds the following details with regard to the NDF type:
• Description of NDF.
• The basic information to be defaulted to the NDF contract when the NDF type is used.
• Product Category code.
• An indicator to classify whether it is a Vanilla NDF or an Option NDF.
• The types of agreements used in NDF contracts, e.g. ISDA, BBAIRS, MASTER.
• Additional data such as delivery activity, currency market, etc.
EB.AGREMENT.TYPE
The EB.AGREEMENT.TYPE file is used to store the types of agreements used in NDF contracts,
e.g. ISDA, BBAIRS, MASTER etc. Each contract must be linked to an agreement type. The field
AGREEMENT.TYPE on the NDF contract is validated against the agreement type definitions on this file
and enriched with the associated description.
Deal/Transaction Processing
Foreign Exchange
Input of deals can be made by the dealers directly inputting the key elements of their deals (currencies,
amounts, value date and Counterparty). This avoids the need for hand-written deal tickets. It ensures
the real-time update of positions and risk (i.e. immediately after input by the dealer the Counterparty’s
liability/exposure, the exchange position and daily Foreign Exchange movements will reflect this deal).
Almost all elements of Foreign Exchange transactions, except the key information entered by the
dealer, have default values. Thus, for any given Counter party, payment methods and instructions are
loaded automatically from a user definable table and need only be confirmed or, exceptionally,
amended by the back-office.
The ability to arrive at intelligent defaults also has another benefit in that for swaps nearly all
information on the second and subsequent legs can be derived from the first leg. Information that
needs to be input by the dealer is thus reduced to a minimum.
After completion of the input by the dealer, deal slips can be printed for the back-office. Then, at the
authorisation stage, the system invokes the generation and delivery of confirmations, the passing of
any accounting entries such as brokerage, commissions and charges, and the issue of any required
pay/receive instructions. Otherwise, there are 'overnight' processes that handle eventual settlement,
revaluation and accruals and exception/maturity reporting.
Main input
The majority of input in the FOREX module will comprise initial input of the contract with a limited
amount of these contracts actually requiring any changes. Where changes are required they tend to
be to the settlement accounting details.
The main inputs required are the Counterparty, currency, amount, and the foreign exchange rate.
Where the settlement details for the Counterparty are stored on the system they will be set by default
in the contract.
Forward contract
Similarly to the input of a spot contract, the forward contract has VERSION for buy and sell. Naturally
these have the additional fields for the input of the forward rate, revaluation type and the buy/sell
interest rates.
Swap contract
The first leg of the swap contract is a straightforward spot deal, although the user also selects the
currency amount that will remain static (defined by the SWAP.BASE.CCY) as in the example below:
After validation of the spot contract you are automatically taken to the forward leg. Note that the static
amount is now the sell amount.
Bullion contract
The FOREX application allows for the input of metals if these are configured in the table
CURRENCY in the PRECIOUS.METAL field as follows:
Fields are available in the FOREX application to input the data required to be able to produce the
relevant SWIFT messages required for metal trades. Bullion trades can be for spot or forward value,
exactly the same as a normal currency trade. These fields are as follows:
Field Comment
IDENTIFICATION The user cannot enter into this field as its value
will be created by the concatenation of the next
4 new fields which the user will have to input
into if one or both of the entered currencies for
the trade is defined as a metal.
DELIVERY.DETAILS CIF or no entry producing a zero length string.
This is an optional field in the SWIFT message.
AVAILABILITY This is the location where the metal is available.
ALLOCATION ALLOC (allocated) or UNALL (unallocated)
TYPE Defines whether the trade is for a quantity of
metal or whether coins are being traded. The
list of metals consists of: GOLD, SILV, PLAT,
PALL, RHOD (Rhodium), RUTH (Ruthenium), OSMI
(Osmium), IRID (Iridium).
FURTHER.IDENT Options TRANSFER or DELIVERY
QUANTITY Options:
FOZ (Fine ounce), GOZ (Gross ounce), GRM
(Gramme), KLO (Kilo), LOT (Lot), TAL (Tael),
TON (MetricTonne), TOZ(Troy Ounce) TOL
(Tola), UNT (Unit)
These fields are mandatory if one of the currencies of the trade is configured in CURRENCY as a
metal. The data in these fields is needed for the DELIVERY module to produce the SWIFT messages
MT600, MT604 and MT605.
As this transaction is the purchase of GOL then Sequence B is evoked whereby we must pay USD for
the purchase. In this case the following fields are utilized.
:32F:(Quantity of the Metal) i.e. GOZ2500,00 values taken from fields QUANTITY and
AMOUNT.BOUGHT.
:87A, B or D:(Receiver of the Metal) i.e. Our Correspondent Nostro BKENGB2L - BANK OF
ENGLAND LONDON value taken from field OUR.ACCOUNT.REC.
:34P:(Consideration) i.e. DATE, CURRENCY and AMOUNT value taken from fields
VALUE.DATE.SELL, CURRENCY.SOLD and AMOUNT.SOLD.
:53A, B or D:(Senders Correspondence) Optional Tag i.e. Our Paying Nostro MLNYUS33 - MERRILL
LYNCH BANK NEW YORK value taken from field OUR.ACCOUNT.PAY.
:57A, B or D:(Account with Institution) i.e. The Counterparty receivers correspondent CITIUS33 –
CITIBANK NEW YORK value taken from field CPARTY.CORR.NO.
As this transaction is the sell of GOL then Sequence C is evoked whereby we will receive USD for the
sale. In this case the following fields are utilized.
:32F:(Quantity of the Metal) i.e. FOZ2352,94 values taken from fields QUANTITY and AMOUNT.SOLD.
:87A, B or D:(Deliverer of the Metal) i.e. Their Correspondent Agent MGTCBEBEECL – EUROCLEAR
BRUSSELS value taken from field CPARTY.CORR.NO.
:34R:(Consideration) i.e. DATE, CURRENCY and AMOUNT value taken from fields
VALUE.DATE.BUY, CURRENCY.BOUGHT and AMOUNT.BOUGHT.
:57A, B or D:(Account with Institution) i.e. Our receiving agent MLNYUS33 - MERRILL LYNCH BANK
NEW YORK value taken from field OUR.ACCOUNT.REC.
Setting the AMORTISE.POSITION field to ‘BOTH’ will amortise both foreign and local currency
positions. In this case the positions are written off to Profit and Loss on a daily basis. The existing
fields on FX.PARAMETER FWD.INT.PROFIT.CAT and FWD.INT.LOSS.CAT should be defined
as the interest receivable and interest payable category respectively.
Position amortisation may take place daily, monthly etc. according to the value of the
AMORTISE.CYCLE field. The AMORTISE.START.DATE field defaults to the spot date but can be
changed by the user unless amortisation has already started.
There are two options available with in the AMORTISE.POSITION field, one to amortise the foreign
currency (Y) and other to amortise the local and foreign currencies (BOTH) on a cyclic frequency e.g.
daily or weekly as selected in AMORTISE.CYCLE field on the deal record. The amortisation start date
defaults to the spot date (two working days forward from the TRADE.DATE).
Foreign Currency
For this option only the foreign currency amount is amortised and for this, the input to the field
AMORTISE.POSITION is Y. The accrual entries are raised on the FCY position only. The contra entry
is raised to reflect the exchange profit/loss and the other side entry is to clear the balance on the local
currency reserve account. The amortised positions are written to Profit and Loss on cyclic frequency.
The final adjustment entry is generated at the maturity.
Both Currencies
For this option the foreign and local currency amounts are amortised and for this, the input to the field
AMORTISE.POSITION is BOTH. The accrual entries are raised on both FCY and LCY positions. The
amortised amounts are posted to the Profit and Loss categories on the cyclic frequency day. In this
case, the contra entries to the local currency reserve accounts are not posted. The deal amount is still
shown on the dealer's position. The net of the FWD.INT.PROFIT.CAT and FWD.INT.LOSS.CAT
will be the exchange profit or loss. There is no adjustment entry on maturity as done in the case
Foreign Currency (AMORTISE.POSITION is YES).
The user has the ability to define the Profit and Loss category codes on the FX.PARAMETER file in
fields FWD.INT.PROFIT.CAT and FWD.INT.LOSS.CAT.
Bulk Orders
Bulk orders enable an account officer to request the purchase and sale of currency on behalf of
several clients in a single order.
The account officer defines the type of transaction (Spot or Forward), the value date and the currency
bought and sold by the bulk order. Then the account officer lists the clients who are using the bulk
order, with the amount of currency to buy or sell for each client.
When the bulk order is authorised, an FX.ORDER can be created. This allows the treasury
department and back office to complete the details required to create FX transactions for the bank and
the clients. The treasury department must input the rates and the covering Counterparty. The back
office must input the pay and receive settlement instructions.
When the FX.ORDER is authorised, if CREATE.RECORDS is set to Y, T24 creates FX deals in OFS
format. One 'master' deal is created for the bank side. When this deal is authorised, T24 creates a
deal for each customer who has specified an amount on the FX.BULK.ORDER. limits are checked.
FX Deals arising out of the Bulk Orders will be created through a Service (OFS.MESSAGE.SERVICE)
and by appropriate configuration of OFS.
OFS can be configured by adding a record called FX.BULK.OFS to OFS.SOURCE:
OFS.SOURCE record.
TSA.SERVICE – BNK/OFS.MESSAGE.SERVICE.
Authorising of the FX.BULK.ORDER will create a Consolidated FX.ORDER which when authorised
will create a FX Master Deal when service is running. FX Master Deal will create the corresponding FX
Child Deals.
BULK.ORDER.ID FXT0324100001 The 1st Bulk Order of the 29th August 2003
COVER.BULK.ID Blank Blank
ACCOUNT.OFFICER 90 George Hogen The account officer responsible for the customer
DEALER DESK 01 Forex Spot The position which will be updated by the new deals
DEAL.TYPE SP = Spot The deals will be forward deals (value date after spot)
DEAL.DATE 29 AUG 2003 The date on which the bulk order was made
CURRENCY.BOUGHT EUR The currency which is purchased
CURRENCY.SOLD USD The currency which is sold
VALUE.DATE 01 SEP 2003 The date when the deal matures
Once the FX.BULK.ORDER is authorised the system will pool this transaction and others and create
an FX.ORDER with a system generated ID.
TOTAL.CONTRA.AMT Empty
DEAL.SUB.TYPE Empty
COUNTERPARTY Empty
BUY.RATE Empty
SELL.RATE Empty
TREASURY.RATE Empty
FORWARD.POINTS Empty
BULK.ORDER.ID FXT0324100001 The ID of the bulk order which this FX.ORDER was
created from
CREATE.RECORDS NO The default
FX Order
ORDER.ID FXO0324100001 The 1st FX Order of the 29th AUGUST 2003
ACCOUNT.OFFICER 90 George Hogen The account officer from the FX.BULK.ORDER
record
DEAL.DATE 29 AUG 2003 The deal date from the FX.BULK.ORDER record
VALUE.DATE 01 SEP 2003 The value date from the FX.BULK.ORDER record
BASE.CCY EUR The BASE.CCY.RANK on CURRENCY.PARAM for
EUR is 1. For USD it is blank. Therefore the base
currency is EUR.
CONTRA.CCY USD As the base currency is EUR, the contra currency is
USD.
TOTAL.BASE.AMT T24 calculates this The sum of the amounts sold in the BASE.CCY, plus
the sum of the amounts bought in the CONTRA.CCY
converted to the BASE.CCY at the SELL.RATE =
1,000,000 + 1,333,333.33 + 500,000 = 2,833,333.33
EUR
TOTAL.CONTRA.AMT T24 calculates this The TOTAL.BASE.AMT converted at the SELL.RATE
= 2,833,333.33 × 0.9 = 2,550,000.00 USD
COUNTERPARTY 100550 The ID of the counter party to the master deal (the
bank side)
DEALER.DESK Blank Leave blank as the master deal will be with a counter
party
DEAL.SUB.TYPE Blank Leave blank as the master deal will be with a counter
party
BUY.RATE Blank Leave blank as it will not be used on this deal
(because the bought currency from the bulk order is
not the base currency)
SELL.RATE 0.9 EUR/USD The SELL.RATE is used because FX.BULK.ORDER
SOLD.CURRENCY = FX.ORDER BASE.CCY.
Note that this is the Sell rate from the client's point of
view and therefore is lower than the Buy rate.
TREASURY.RATE 0.9 Defaults to
the MID.REVAL.RATE of the
CURRENCY EUR.
FORWARD.POINTS 0.01 Treasury.rate + fwd.points + cust.spread =
CUST.RATE.
BULK.ORDER.ID FXT0324100003 The ID of the bulk order which this FX.ORDER was
created from
CREATE.RECORDS YES When the FX.ORDER is authorised, T24 will create
FX deals.
T24 creates the master deal. This is the deal between the bank and the counterparty specified on the
FX.ORDER.
Once the above master deal is authorised T24 creates the child deals. These are the deals between
the bank and the customers specified on the FX.BULK.ORDER.
Limit Orders
The underlying idea is that Relationship Managers can record requests from their clients for buying or
selling of Foreign Currency at a desired rate, for a specified value date. The orders will remain in the
system till either they are caused to be expired or executed or cancelled.
The application FX.LIM.ORDER will hold these Orders.
The executed orders will lead to creation of the appropriate FOREX deals automatically.
In the LIMIT.PARAMETER record a new limit has to be defined for the FX.LIMIT.ORDER
application. You can define different limits for different categories.
The application FX.LIM.ORDER is used to enter the orders received from the customer.
The following is an example order received and entered on the 4th June 2003 and expires on the 5th
June 2003 at 14:00 hours.
It is an SP type FOREX Contract with value date of 15th June 2003.
The order currency is GBP which is a buy of 15,000 against USD, the order type is SINGLE.
An FX.LIM.ORDER.
The order can be executed by setting EXECUTE.ORDER to YES and by supplying the rate at the
EXEC.RATE field.
If a rate of 1.865 is used on execution this will be populated in the new FOREX contract.
Note that the ORD.ITEM.STAUS is EXECUTED and ORDER.STATUS is DONE. Also note that the
Reference number of the FOREX Contract the Order has given rise to has been shown at FOREX.ID
field
The rate at which the FX.LIM.ORDER has been executed is NOT stored on the Contract but the
USD Equivalent has been arrived at 27,975.00 = (15,000 * 1.865)
FX CONTRACT
After order execution the FOREX contract is created in IHLD status ready for any further processing
by the user.
As shown below the FX.LIM.ORDER contract reference is stored on the contract created.
Confirmations
FOREX will automatically generate confirmations following the appropriate events (e.g. deal
authorisation, changes, replacement, etc.). Both Counter party and Broker confirmations received may
be matched to the deals input and ‘V’erified. This process automatically passes a user identification
date and time stamp into the corresponding field, CONFIRMD.BY.BROKER or CONF.BY.CPARTY
Special confirmation ENQUIRY facilities allow for the extraction of unconfirmed deals.
The standard T24 table FT.CHARGE.TYPE defines the conditions relating to various types of
standard flat charge that are available for use in FOREX.
Each Commission type can be defined as a Flat Amount or as one, which varies according to the
amount of the Foreign Exchange deal. In this latter case different percentages can be defined for
different Bands or Levels of deal amounts. Minimum and maximum Commissions can be specified for
each Band or Level together with overall min./max. Commission charges.
For Option contracts, which may involve partial deliveries, charges or commissions may be levied on
each delivery.
Commission Groups
FX.COMM.GROUP specifies the fee schedule for each currency and range of amounts. The fee
shown is a percentage; the fee charged is that percentage of the deal rate.
FX.COMM.GROUP 2.
FX.COMM.GROUP 2 is set up so that the cash amount from 0 to 1,000,000.00 USD a rate of
0.0005 is applied and from 1,000,001.00 and above a rate of 0.001 is applied.
Therefore the customer spread is:
First set = (treasury rate + forward points) × commission = (0.9 + 0.01) × 0.0005 = 0.000455
Second set = (treasury rate + forward points) × commission (0.9 + 0.01) × 0.001 = 0.00091
The Forex spread can also be expressed as a percentage of the FX commission of another group, by
using the GROUP.LINK field.
The amount is 120,000 USD, using commission from FX.COMM.GROUP 1. The commission rate is
50% of 4% – that is, 2%.
Revaluation
Introduction
The module provides a daily revaluation of the Foreign Exchange position, producing a daily profit for
each dealer or group of dealers. Forward positions can be re-valued either on a 'rebate' basis, (i.e.
cost to cover the deal today) or on a straight-line basis, (i.e. amortisation of the apparent exchange
profit/loss over the life of the deal). Exchange profit, as in the case of swaps, may also be treated and
accrued as interest.
These parameters allow the rebate revaluation method to be applied to currency positions arising from
non-FX applications such as SW – Swaps, SC – Securities and FT – Funds Transfer.
A point to note in the Rebate revaluation is that the module, according to the value defined in the
REVALUATION.PARAMETER table, can interpolate rates to the actual deal value date (i.e. it will
interpolate a rate between the known rates for the closest dates before and after a given date).
For further details of the revaluation process see chapter on the principles of contract revaluation.
Revaluation Rate
FOREX revaluation processing uses the REVAL.RATE, if defined, for a particular currency in the
same way as Asset and Liability revaluation. This is applied to both on and off balance sheet contracts,
i.e. FX Forward – ‘IH’, Swap, etc., except for those of RB revaluation type which are re-valued using
the MID.REVAL.RATE also found on the CURRENCY table.
All revaluation types except for rebates (RB) will use the REVAL.RATE field if it is populated. If it is
left blank, then the MID.REVAL.RATE field will be used.
Currency Input.
As seen above the REVALUATION.PARAMETER application indicates for other applications in the
system a revaluation method to be used by the revaluation process. If this field is set to ‘SP’ then spot
revaluation method is performed by the system otherwise if set to ‘RB’ the rebate revaluation method
is performed.
The system allows for the selection of a POSTING.STYLE for the entries to be raised for revaluation.
The difference between the previous revaluation amount and the latest is posted. In the case of
change from profit to loss the entire profit/loss figure is reversed and a new loss/profit amount posted.
The exact manner in which these methods work has been illustrated below with examples:
In many countries the posting of unrealised profits is not allowed. This option can be set by using the
field BOOK.PROFITS. If set to YES both unrealised profit and loss is posted, if not set only unrealised
losses will be booked.
The accounting rules in revaluation has been illustrated with two examples below:
Example 1
Day 1
Day 2
Day 3
Forward position becomes Asset and Liability and therefore needs to be reversed out of the Profit and
Loss and Reserve A/C and the POS.TRANSACTION record needs to be deleted.
Revaluation from now onwards will be done on the consolidated asset and liability amounts.
Example 2
Day 1
Day 2
After the first days revaluation we obtain two sets of Profit and Loss and reserve account entries as
shown under.
Day 3
Because the deal matures, it hits the Asset and Liability bucket and therefore needs to be reversed out
of the unrealised Profit and Loss and Reserve Account. The POS.TRANSACTION record has also to
be deleted.
Revaluation from now onwards is done on the consolidated asset and liability amounts.
The currency positions raised will reflect the true position on the dealer desk. In other words the local
equivalent figures raised in the currency positions would be at the TREASURY.RATE rather than the
deal rate in the case of TREASURY.RATE having been entered.
The transaction enters the Exchange position at the Treasury rate and, it therefore follows, that all
profit (or loss) arising from this position (through revaluation) will be allocated to the Treasury during
the revaluation process.
Under this system the Treasury should be responsible for setting the base (treasury) rates and
marketing units responsible for policy on customer rates. Treasury rates should reflect real market
rates.
Examples of both spot and forward revaluation processing are highlighted and the different revaluation
methods of forward contracts are illustrated.
For the purpose of illustration, assume that 2 deals have been input and authorized as follows:
Deal 1
Deal 2
At this stage, it is already important to understand how the local currency equivalents (BUY .LCY.AMT
and SELL LCY AMT) are established for SPOT Exchange contracts. The following rules will be
followed:
a) Where either the actual amount bought or amount sold happens to be in the local currency of the
country (Deal 1), this amount will be adopted as the local currency equivalent for the other currency
so that the fields BUY.LCY.AMT and SELL.LCY.AMT on the main FOREX contract will contain
this same value. It is also this local currency value, which will be used to update the foreign exchange
position once the deal has been successfully validated.
Where the local currency is neither the currency bought nor the currency sold (Deal 2), the system will
calculate the local currency equivalent of the BASE currency/amount and apply it to both currencies of
the contract so that fields BUY.LCY.AMT and SELL.LCY.AMT on the main FOREX contract will
also contain the same value. To calculate this local currency equivalent of the BASE amount, the
system will use the MID.REVAL.RATE for the given currency found on the CURRENCY application.
Rebate type revaluations use existing revaluation rate of the base currency as defined on the
CURRENCY table. For example, on the CURRENCY table the MID.REVAL.RATE GBP/USD is
equal to 1.50. As in the previous case it is also this local currency equivalent, which will be used to
update the foreign exchange position once the deal has been successfully validated.
Dealer Desk 01
Dealer Desk 02
The signs follow the accounting conventions, i.e. the '-' sign indicates a 'LONG' position (overbought)
while the '+' sign indicates a 'SHORT' position (oversold).
At the Close of Business, assuming that the deals have been fully authorized and that a complete
Close of Business has been performed, the position in each foreign currency will be revalued, by
dealer desk, against local currency. For SPOT contracts, the rate used for revaluation is that of the
REVAL.RATE from the CURRENCY table of the currency being revalued. Let us suppose the user
has entered the following REVAL.RATE on the CURRENCY table before the close of business.
CURRENCY REVAL.RATE
USD 1,5100
DEM 3,3100
Taking into account the new exchange rates, the revaluation process calculates the new local currency
equivalents i.e. the revalued amount with a Profit/Loss to date and a Profit/Loss today as detailed below:
It can be seen from the above example that a total loss of GBP (local currency) 6,815.93 has been
generated and is composed as follows:
Dealer Desk:
1. LOSS IN USD Position = GBP 4,415.02
2. LOSS IN USD Position = GBP 4,415.02
3. PROFIT in DEM Position = GBP 2,014.11
The system will then automatically generate the following entries (please see note at end of this section
regarding accounting entries):
CATEG ENTRY
DR 53001 SPOT REVALUATION
Amounts:
4,415.02 Desk 1 CCY USD
4,415.02 Desk 2 CCY USD
Amount:
2,014.11 Desk 2 CCY DEM
STMT.ENTRY
CR GBP 6,815.93 EXCHANGE ADJUSTMENT
(From ACCOUNT.CLASS file)
The next day, assume that we remain with the same 2 Spot contracts and that new REVAL.RATE has
been input to the CURRENCY table for both DEM and USD as detailed here below:
CURRENCY REVAL.RATE
USD 1,52
DEM 3,29
In the Close of Business process, these new exchange rates will be taken into account by the revaluation
process, which will calculate new local currency equivalents as indicated in the table below:
It can be seen from the above revaluation that a supplementary loss of GBP (local currency) 12,754.28
has been generated and that the total to date is equal to GBP 19,570.21 i.e. GBP 6,815.93 + GBP
12,754.28.
As can be seen from the figures, the overall Loss has been increased to GBP 19,570.21 DR on Day 1.
The principal adopted to reflect this change properly is that only the difference between the Profit/Loss to
Date from the previous day and the Profit/Loss to Date on the current revaluation is posted namely
'TODAY'S total' on the revaluation report i.e. GBP 12,754.28 DR.
The accounting entries will be generated as explained earlier, i.e. 3 Profit and Loss entries against a
total statement entry of GBP 12,754.28 in the Internal account corresponding to the EXCHANGE
ADJUSTMENT as defined on ACCOUNT.CLASS file.
On day 2, i.e. when the value date of the contract is reached, both contracts will be liquidated in the
Balance Sheet and the relevant entries passed over Customer accounts, Nostro accounts or Internal
accounts.
The net outstanding amount in the EXCHANGE ADJUSTMENT account (GBP 19,570.21 in our example)
will be reversed (i.e. credited in our case) against the original Profit and Loss Category code and the
transaction will now be part of the Asset/Liability position. It will be posted in the Balance sheet with its
original values (as defined in BUY.LCY.AMT and SELL.LCY.AMT of the contract) and from now on will
be revalued within the Asset/Liability revaluation process.
The Revaluation process within T24 allows the following five methods for the revaluation of Forward
contracts:
• Straight Line
• Interest Method
• Interest/Hedged
• Rebate
• Straight Line Funding
Rebate revaluations use the MID.RATE found on the CURRENCY table, while the other types use
the REVAL.RATE also found on the CURRENCY table. If there were no input to the REVAL.RATE,
then the MID.RATE for that CURRENCY would be used.
Assume that the following 2 deals have been input and authorised as follows:
Deal 1
Currency & Amount Bought USD 1,000,000.00
Rate of Exchange 1.48
(Spot Rate) (1.50)
Currency & Amount Sold GBP 675,675.68
Value Date 6 Months
Dealer Desk 01
Revaluation Type SL
SPOT LCY AMT 666,666.67
BUY LCY AMT - 666,666.67
SELL LCY AMT 675,675.68
Deal 2
Currency & Amount Bought USD 1,000,000.00
Rate of Exchange 2.18
(Spot Rate) (2.20)
Currency & Amount Sold DEM 2,180,000.00
Value Date 6 Months
Dealer Desk 02
BASE Currency USD
Revaluation Type SL
SPOT.LCY.AMT 666,666.67
BUY.LCY.AMT - 666,666.67
SELL.LCY.AMT 660,606.06
At this stage, it is important to understand how the local currency equivalent is established for FORWARD
Exchange contracts using the Straight Line revaluation method. The following rules will be followed:
The local currency amount of the contract will be kept to generate the local currency value in its
corresponding BUY LCY EQUIV or SELL LCY EQUIV i.e:
The foreign currency amount of the contract will be converted at the contract SPOT rate to generate the
local currency value in its corresponding BUY.LCY.EQUIV or SELL.LCY.EQUIV.
The BASE amount of the contract will be converted at the CURRENCY table MID.REVAL.RATE of
the BASE currency to generate the local currency value in its corresponding BUY.LCY.EQUIV or
SELL.LCY.EQUIV.
The other foreign currency amount of the contract will be converted at the contract SPOT rate and the
CURRENCY table MID.REVAL.RATE of the BASE currency to generate the local currency value in
its corresponding BUY.LCY.EQUIV or SELL.LCY.EQUIV.
These spot local currency equivalents will also be used to update the foreign exchange position once the
deal has been successfully validated.
Dealer Desk 01
| ACCRUALS |
9,009.01
Dealer Desk 02
For - 1,000,000.00 USD + 2,180,000.00 DEM
Against + 2,180,000.00 DEM - 1,000,000.00 USD
Local equiv. - 666,666.67 GBP + 660,606.06 GBP
| ACCRUALS |
6,060.61
Under the Straight Line revaluation method, this difference between the local currency equivalent of
the amount bought and the amount sold is isolated as a Profit or Loss amount at the start of the
contract and then simply amortized over the life of the deal as a daily accrual between an exchange
reserve adjustment internal account and an interest Profit and Loss Category code [Interest Paid
Exchange (defined in REVALUATION.PARAMETERS) if contract is done at a loss and Interest
Received Exchange (defined in REVALUATION.PARAMETERS) if contract is done at a profit].
At the close of business, assuming that the deals have been fully authorised, the position in each foreign
currency is be revalued at SPOT rate, by dealer against local currency. SPOT rates will be used for the
revaluation during the complete life of these 2 contracts because they have entered the Foreign
Exchange position also with SPOT rates as explained earlier. The revaluation process will then be the
same as a spot contract.
When the SPOT date is reached, an additional process will take place, namely the accruals on the local
currency difference. These accruals will continue up to the value date of the contract (6 months in our
example).
If we suppose that this 6-month period contains 181 days on Deal 1 a daily accrual of GBP 49.77 (i.e.,
9009.01 divided by 181) will take place while on deal 2 a daily accrual of GBP 33.48 (6060.61 divided by
181) will be booked. The following daily entries will be generated for these accruals:
Deal 1 (Loss)
Dr INTEREST PAID EXCHANGE 49.77 (CATEG 50000)
Cr EXCH RES ADJUSTMENT 49.77
Deal 2 (Profit)
Dr EXCH RES ADJUSTMENT 33.48
Cr INTEREST RECEIVED EXCHANGE 33.48 (CATEG 51000)
When the value date of the contract is reached, both contracts will be liquidated in the Balance Sheet and
the relevant entries passed over customer accounts, nostro accounts or internal accounts. In addition to
the process described for the liquidation of a SPOT contract, one supplementary statement entry will be
generated, i.e. the liquidation of the EXCH RES ADJUSTMENT account, which was used for the accruals.
This supplementary entry also allows the transfer of the FOREX position to the Asset/Liability Position
with movements balancing in local currency i.e.
Deal 1
Dr Nostro 1,000,000 USD <-----> 666,666.67 GBP
Dr EXCH RES ADJUSTMENT 9,009.01 GBP
Cr CLEARING/CASH 675,675.68 GBP
Deal 2
Dr Nostro 1,000,000 USD <-----> 666,666.67 GBP
Cr Nostro 2,180,000 DEM <--------> 660,606.06 GBP
Cr EXCH RES ADJUSTMENT 6,060.61 GBP
As illustrated, the Foreign Exchange transaction will be posted in the Balance sheet on value date with its
original values (Fields BUY.LCY.EQUIV and SELL.LCY.EQUIV of the contract) and from then on (i.e.
value date) will be revalued within the Asset/Liability revaluation process.
For the sake of simplicity, let us take as an example the same 2 deals as the one used for the straight-line
method. We will only exchange the value of the field REVALUATION.TYPE from 'SL' to 'IN' and indicate
the values of the interest rates applicable to both currencies (bought and sold).
The rate of exchange will be the REVAL.RATE if it is specified on the CURRENCY table; otherwise it
will use the MID.REVAL.RATE.
Deal 1
Currency & Amount Bought USD 1,000,000.00
Rate of Exchange 1.48
(Spot Rate) (1.50)
Currency & Amount Sold GBP 675,675.68
Value Date 6 Months
Dealer Desk 01
Revaluation Type IN
Interest rate buy 6.964504654
Interest rate sell 9.75
SPOT LCY AMT 666,666.67
BUY LCY AMT - 666,666.67
SELL LCY AMT 675,675.68
Deal 2
Currency & Amount Bought USD 1,000,000.00
Rate of Exchange 2.18
(Spot Rate) (2.20)
Currency & Amount Sold DEM 2,180,000.00
Value Date 6 Months
Dealer Desk 02
BASE Currency USD
Revaluation Type IN
Interest rate buy 6.00
Interest rate sell 4.191863385
SPOT LCY AMT 666,666.67
BUY LCY AMT - 666,666.67
SELL LCY AMT 660,606.06
Again, let us understand how the local currency equivalent (BUY.LCY.EQUIV and SELL.LCY.EQUIV)
is established for FORWARD Exchange contract using the Interest Revaluation Method. The same rules
as those defined for the Straight Line method will be followed i.e.
The foreign currency amount of the contract will be converted at the contract SPOT rate to generate the
local currency value in its corresponding BUY.LCY.EQUIV or SELL.LCY.EQUIV.
The other foreign currency amount of the contract will be converted at the contract SPOT rate and the
CURRENCY table MID.REVAL.RATE of the BASE currency to generate the local currency value in
its corresponding BUY.LCY.EQUIV or SELL.LCY.EQUIV.
These SPOT local currency values will also be used to update the Foreign Exchange position once the
deal has been successfully validated.
After the validation of the 2 deals, the position file will look exactly the same as in the case of the Straight
Line method i.e.
Dealer Desk 01
Dealer Desk 02
Under the Interest revaluation method, this difference between BUY.LCY.EQUIV and SELL.LCY.EQUIV
is also isolated as a Profit and Loss amount at the start of the contract. However, this reserve will now be
amortized between an exchange reserve adjustments internal accounts offset by two Profit and Loss
entries as follows:
The net between the two Profit and Loss entries will represent exactly the amount booked in Exchange
reserve adjustment, and also the single accrual amount booked under the Straight Line revaluation
method. As already explained in the main file documentation, the 2 daily Profit and Loss entries will
correspond exactly to one day's interest on the amount bought and the amount sold using the interest
rates generated in the contract record.
At the close of business, assuming that the deals have been fully authorized, the position in each foreign
currency will be revalued at SPOT rate against the local currency. SPOT rates will be used for the
revaluation during the complete life of these 2 contracts because they have entered the Foreign
Exchange position also with SPOT rates as explained earlier. The revaluation process will then be
identical to the one explained under the caption 'SPOT REVALUATION'. The same revaluation rates and
accounting entries will be produced.
When the SPOT date is reached, an additional process will take place namely the accruals on the local
currency difference. These accruals will continue up to the value date of the contract (6 months in our
example) and the daily accrual amount will be calculated as follows:
INTEREST BASIS OF CCY BOUGHT = Daily accrual amount for currency bought
When the contract involves local currency the foreign currency accrual amount will always be converted at
the contract FORWARD RATE (1.48 in our case). The daily accrual in local currency will therefore be
GBP 130.72.
This amount, being a local currency amount, does not need to be converted and represents the daily
accrual in local currency for the sold currency.
The equivalent local currency accrual will therefore be 253.84 ÷ 3.27 = GBP 77.63.
The following accruals accounting entries will therefore be generated by the system:
Deal 1
Cr EXCH RES ADJUSTMENT GBP 49.77
Cr INTEREST RECEIVED EXCHANGE GBP 130.72
Dr INTEREST PAID EXCHANGE GBP 180.49
Deal 2
Cr INTEREST RECEIVED EXCHANGE GBP 111.11
Dr EXCH RES ADJUSTMENT GBP 33.48
Dr INTEREST PAID EXCHANGE GBP 77.63
When the value date of the contract is reached both contracts will be liquidated and the relevant
entries passed over after customer accounts, nostro accounts or internal accounts. In the same way
as described for the Straight Line revaluation method, one supplementary statement entry will be
generated i.e. the liquidation of the EXCH RES ADJUSTMENT account which was used for the
accruals. This supplementary entry also allows the transfer of the FOREX position into the
Asset/Liability position on the value date of the contract with movements balancing in local currency i.e.
Deal 1
Dr Nostro 1,000,000.00 USD -----> 666,666.67
Dr EXCH RES ADJUSTMENT 9,009.01
Cr CLEARING/CASH 675,675.68
Deal 2
Dr Nostro 1,000,000.00 USD -----> 666,666.67
Cr Nostro 2,180,000.00 DEM -------------> 660,606.06
As illustrated, the Foreign Exchange transaction will be posted in the Balance Sheet on value date with its
original values (BUY.LCY.EQUIV and SELL.LCY.EQUIV of the contract) and from then on (i.e. value
date) will be revalued within the Asset/Liability revaluation process.
The example used for the straight line and interest methods can be modified slightly to illustrate the
interest/hedged revaluation method. The value of field REVALUATION.TYPE is 'IH'. The interest rate of
the currency sold (INT.RATE.SELL) is kept, but the calculation of the other currency's rate is, in this
case, performed differently.
Deal 1
Currency & Amount Bought USD 1,000,000.00
Rate of Exchange 1.48
(Spot Rate) (1.50)
Currency & Amount Sold GBP 675,675.68
Value Date 6 Months
Dealer Desk 01
Revaluation Type IH
Interest rate buy 6.836285
Interest rate sell 9.75
SPOT LCY AMT 666,666.67
BUY LCY AMT - 666,666.67
SELL LCY AMT 675,675.68
Deal 2
Currency & Amount Bought USD 1,000,000.00
Rate of Exchange 2.18
(Spot Rate) (2.20)
Currency & Amount Sold DEM 2,180,000.00
Value Date 6 Months
Dealer Desk 02
BASE Currency USD
Revaluation Type IH
Interest rate buy 6.00
Interest rate sell 4.137318
For example:
If AMOUNT.BOUGHT = Local currency, then AMOUNT.BOUGHT = BUY.LCY.EQUIV.
The foreign currency amount of the contract will be converted at the contract SPOT rate to generate the
local currency value in its corresponding BUY.LCY.EQUIV or SELL.LCY.EQUIV.
The other foreign currency amount of the contract will be converted at the contract SPOT.RATE and
the CURRENCY table MID.REVAL.RATE of the BASE currency to generate the local currency value
in its corresponding BUY.LCY.EQUIV or SELL.LCY.EQUIV.
These spot local currency values will accompany the eventual postings to the balance sheet in the same
manner as for straight-line or interest methods. However, the way in which the foreign exchange
positions are updated differs significantly from the other methods of revaluation. This difference can be
explained by first describing the other calculations which the system will perform for interest/hedged deals.
The interest/hedged method of revaluation is intended to account for a situation where the forward foreign
exchange contract is hedged against other items in the balance sheet. It follows that the various effects of
interest accruals and currency revaluations arising from the two sources should largely cancel one
another out.
The interest/hedged method is, in fact, based on the assumption that the foreign exchange deal can be
matched against a loan or deposit in the currency of the sold or bought currencies respectively. The
actual amounts of the deal are therefore considered to be the product of a matching loan or deposit in the
currencies concerned.
This means that the system must first calculate, given the applicable interest rate and term of the contract,
the principal amount which would give an interest yield exactly sufficient to generate the contract amount.
⎛ ⎞
⎜ ⎟
NP = ⎜
DA ⎟ * 100
⎜ ⎛ IR * STV ⎞⎟
⎜ 100 + ⎜ ⎟⎟
⎝ ⎝ IDB ⎠⎠
• NP = notional principal
• DA = deal amount
• IR = interest rate
• STV = spot-to-value number of days
• IDB = interest day basis
The figures calculated on the amount bought and the amounts sold are recorded in NOTIONAL.BUY.AMT
and NOTIONAL.SELL.AMT respectively.
The interest amount associated with each side of the deal is calculated by a simple subtraction:
IA = DA - NP
Where the following abbreviations are used:
• IA = interest amount
• NP = notional principal
• DA = deal amount
The interest figures calculated on the amount bought and the amount sold are recorded in fields
TOTAL.INT.BOUGHT and TOTAL.INT.SOLD respectively.
difference should be shown between the figures in these two fields. An adjustment is made by the system
in order to ensure this.
Another way of expressing this reasoning is to say that the local equivalents of the NOTIONAL.BUY.AMT
and NOTIONAL.SELL.AMT must, by definition, be the same according to the contract SPOT.RATE.
These additional system-generated fields take the following values for the current examples:
Deal 1 (USD/GBP)
NOTIONAL BUY AMT 966,770.81
NOTIONAL SELL AMT 644,513.88
TOTAL INT BOUGHT 33,229.19
TOTAL INT SOLD 31,161.80
EQUIV INT BOUGHT 22,152.79
EQUIV INT SOLD 31,161.80
INT BASIS BOUGHT B 366/360
INT BASIS SOLD E 366/365
Deal 2 (USD/DEM)
NOTIONAL BUY AMT 970,716.71
NOTIONAL SELL AMT 2,135,576.77
TOTAL INT BOUGHT 29,283.29
TOTAL INT SOLD 44,423.23
EQUIV INT BOUGHT 19,522.19
EQUIV INT SOLD 13,461.58
INT BASIS BOUGHT B 366/360
INT BASIS SOLD B 366/360
The interest day basis applicable to each currency is recorded for internal purposes.
After the validation of the 2 deals, the position file will be updated, not with the full amounts of the deal, but
with the notional principal amounts only:
Dealer Desk 01
Dealer Desk 02
Under the interest/hedged revaluation method, the local equivalent amounts that are positioned on each
side of the deal are identical at the outset because they correspond to the notional principal amounts at
their spot rates at the time of entering the deal.
The difference between the local currency equivalent of the AMOUNT.BOUGHT and the AMOUNT.SOLD is
also isolated as a Profit and Loss amount at the start of the contract. However, this reserve will now be
amortized between an exchange reserve adjustment internal account in the currency bought/sold offset
by 2 Profit and Loss entries as follows:
The two daily Profit and Loss entries will correspond to one day's interest on the notional amount bought
and the notional amount sold using the interest rates generated in INT.RATE.BUY and
INT.RATE.SELL respectively.
The local equivalent of each of these entries is calculated at the prevailing day's spot rate for each
currency. The foreign currency amounts are added into the currency position file as each accrual is made.
At the close of business, assuming that the deals have been fully authorized, the position in each foreign
currency will be revalued at SPOT rate against the local currency. SPOT rates will be used for the
revaluation during the complete life of these two contracts because they have entered the Foreign
Exchange position also with SPOT rates as explained earlier.
The revaluation process will then be identical to the one explained under the caption 'SPOT
REVALUATION'. The same revaluation rates and accounting entries will be produced.
When the spot date is reached, the system will start to process accruals on the interest bought and sold.
These accruals will continue up to the value date of the contract (6 months in our example).
On each side of the deal, the daily accrual amount can be calculated by the formula:
IR
DAA = NPA*
IDB
The system actually performs the equivalent calculation by subtracting the amount accrued to date from
the total interest due over the period since spot date. This calculation carries with it a running adjustment
and respects both non-working days and 360-day interest bases. In this way, the effects of a
corresponding loan or deposit in the balance sheet can be mirrored exactly.
When the value date of the contract is reached both contracts will be liquidated and the relevant
entries passed over after customer accounts, nostro accounts or internal accounts. In the same way
as described for the straight line and interest revaluation methods, supplementary statement entries
will be generated i.e. the liquidation of the EXCH RES ADJUSTMENT account, which was used for the
accruals. This supplementary entry also allows the transfer of the FOREX position into the
Asset/Liability position on the value date of the contract with movements balancing in local currency i.e.
Deal 1
Dr Nostro 1,000,000.00 USD -----> 666,666.67
Dr EXCH RES ADJUSTMENT 9,009.01
Cr CLEARING/CASH 675,675.68
Deal 2
Dr Nostro 1,000,000.00 USD -----> 666,666.67
Cr Nostro 2,180,000.00 DEM -------------> 660,606.06
Cr EXCH RES ADJUSTMENT 6,060.01
As illustrated, the Foreign Exchange transaction will be posted in the Balance Sheet on value date with its
original values (BUY.LCY.EQUIV and SELL.LCY.EQUIV of the contract) and from then on (i.e. value
date) will be revalued within the Asset/Liability revaluation process.
This is the most straightforward method as it is based (like the Spot Revaluation) on the cost or profit
attributable to closing the position i.e. to enter into a deal at today's rates to exactly cover each deal at its
maturity (buy back approach).
It is important to note that Rebate revaluation types use the MID.RATE and not the REVAL.RATE
found on the CURRENCY table.
Within this method, for any given forward deal as it ages, the rate to cover it, converges with the spot rate
as it gets closer to maturity, until it will eventually be covered at spot rate.
Given a set of forward rates (FORWARD.RATES table), the user can still choose between 3
methods to find the forward rate applicable to each forward contract i.e.:
• Interpolation
• Next Available rate
• Closest rate
The choice will be indicated on the REVALUATION.PARAMETER table. We will suppose in this
document the closest rate. Assume again, as an example, the same two deals as the ones used
previously. We are now changing the value of the field REVALUATION.TYPE to 'RB' to indicate the
Rebate Revaluation method.
Assume also that we have the following Spot and Forward rates loaded on the CURRENCY and
FORWARD.RATES table.
Deal 1
Currency & Amount Bought USD 1,000,000.00
Rate of Exchange 1.48
(Spot Rate) (1.50)
Currency & Amount Sold GBP 675,675.68
Value Date 6 Months
Dealer Desk 01
Revaluation Type RB
SPOT LCY AMT 666,666.67
BUY LCY AMT - 675,675.68
SELL LCY AMT 675,675.68
Deal 2
Currency & Amount Bought USD 1,000,000.00
Rate of Exchange 2.18
(Spot Rate) (2.20)
Currency & Amount Sold DEM 2,180,000.00
Value Date 6 Months
Dealer Desk 02
BASE Currency USD
Revaluation Type RB
SPOT LCY AMT 666,666.67
BUY LCY AMT - 672,839.51
SELL LCY AMT 672,839.51
Let us review again how the local currency equivalent BUY.LCY.EQUIV and SELL.LCY.EQUIV is
established for FORWARD exchange contracts using the REBATE revaluation method. The principle is
different from the other revaluation methods. The following rules will be followed:
These forward local currency values will also be used to update the Foreign Exchange position once the
deals have been successfully validated.
After the validation of the two deals, the Position file will look as follows:
Dealer Desk 01
Dealer Desk 02
At the close of business, assuming that the deals have been fully authorized, the position in each
foreign currency will be revalued, against the local currency. For forward contracts using the Rebate
Method used for revaluation, will be the middle rate from the CURRENCY table plus/minus the
premium/discount on the nearest rest period within the FORWARD.RATES table.
Let us suppose that the user has entered the following 6 months forward premium/discount on the
FORWARD.RATES table before the close of business:
And
GBP/USD: 1.50
GBP/DEM: 3.30
Based on these two tables, the system will establish the 6 months forward rates (1,4825 and 3.23
respectively) and calculate the new local currency equivalent i.e. the revalued amount with a Profit/Loss to
date and a Profit/Loss today as detailed below:
It can be seen from the above example that the revaluation process has caused a total loss of 1,525.77
GBP (local currency).
The accounting entries (CATEG.ENTRY and STMT.ENTRY files) will be generated in exactly the
same way, as the SPOT revaluation except that the Profit and Loss Category code used will now be
that defined in REVALUATION.PARAMETER. Any subsequent revaluation will be performed in the
same way.
It must be noted that in the Revaluation Profit report produced during the End of Day process, the
system will not segregate Spot and Forward deals with the same currency and done by the same
dealer. If for example, dealer 1 makes a Spot and Forward purchase of 1 million dollars, the USD
figure will be accumulated on the report to show only one total. The revaluation process, however, will
handle the two deals separately thus performing a spot and forward revaluation as described earlier. If
this individual deal posting is required the field REVAL.DEAL.POST should be set to YES in
REVALUATION.PARAMETER.
Rounding Rule
The field ROUNDING.RULE will accept any value defined in EB.ROUNDING.RULE and based on
this setting T24 will round the calculated currency amount accordingly.
EB.ROUNDING.RULE listing.
Whatever rule is defined in FX.PARAMETERS will be defaulted into the FOREX Application.
This however can be modified by the user. If modified an OVERRIDE will be generated notifying the
user of the change.
The standard T24 table FT.CHARGE.TYPE defines the conditions relating to various types of
standard flat charge that are available for use in FOREX.
Each Commission type can be defined as a Flat Amount or as one, which varies according to the
amount of the Foreign Exchange deal. In this latter case different percentages can be defined for
different Bands or Levels of deal amounts. Minimum and maximum Commissions can be specified for
each Band or Level together with overall min./max. Commission charges.
For Option contracts, which may involve partial deliveries, charges or commissions may be levied on
each delivery.
Commission Groups
FX.COMM.GROUP specifies the fee schedule for each currency and range of amounts. The fee
shown is a percentage; the fee charged is that percentage of the deal rate.
FX.COMM.GROUP 2.
FX.COMM.GROUP 2 is set up so that the cash amount from 0 to 1,000,000.00 USD a rate of
0.0005 is applied and from 1,000,001.00 and above a rate of 0.001 is applied.
Therefore the customer spread is:
First set = (treasury rate + forward points) × commission = (0.9 + 0.01) × 0.0005 = 0.000455
Second set = (treasury rate + forward points) × commission (0.9 + 0.01) × 0.001 = 0.00091
The amount is 120,000 USD, using commission from FX.COMM.GROUP 1. The commission rate is
50% of 4% – that is, 2%.
The default operation of the system spot date calculation is described below. The default calculation
will take place if the fields FX.LCL.REGION and SPOT.BASE.CCY are not specified in the
FX.PARAMETERS record.
When no SPOT.DATE or in the case of a Spot deal (or the first leg of a Swap), the
VALUE.DATE.BUY/SELL is not entered, the system will attempt to default the dates. The dates are
calculated by addition of the SPOT.MARKET number of days defined in FX.PARAMETERS to the
DEAL.DATE to give a common working day for the country of the two currencies involved in the deal.
Example 1
Local Currency GBP Local Country GB defined in CAMPANY
Spot Martek 2
System Date 2nd July Spot Deal USD/GBP
Holidays
Using the common holidays (Comm) 2 working days gives a spot date of 5th July.
The SPOT.DATE, VALUE.DATE.BUY and VALUE.DATE.SELL would therefore be 5th July; this is a
common working day in both countries and respects the Spot Market period for both.
Example 2
If the holidays were as follows for the same deal:
Using the common holidays in this case gives a spot date of 6th July. The default date would therefore
be 6th July.
A system with LOCAL.CURRENCY GBP is running in London, the local country is GB giving a local
holiday table of GB00. The system is also used to enter trades by the New York office. As a result the
system must be available to the New York users on UK holidays. This means that the local holiday
table is in fact a common table of working days between the two countries. Using the previous
example:
Both 4th July (holiday in US) and 5th July (holiday in UK) are working days in the system so that the
New York users can work on 5th July.
If a FX deal were done involving GBP and USD on 2nd July as in the previous example a spot date of
5th July would result. This date should not be defaulted in practice, as 5th July is not a true working day
in the UK; the correct date would be 6th July.
To avoid this problem, an alternative holiday table for the local currency can be defined, and if
specified in the FX.LCL.REGION field of the FX.PARAMETERS record this will be used instead of
the default holiday table for the currency (in this case GB00). It is recommended that a REGION be
created for the local currency for FX trading, a specific holiday table containing the true local holidays
can then be created for this region. The region code should then be defined in FX.PARAMETERS as
shown.
Region GB99
FX.PARAMETER Input.
Any deal involving the local currency will now use the FX.LCL.REGION defined GB99 rather than the
standard GB00. Using this definition the previous deal will give the following results:
Example 3
Holidays
The common holiday table between GB99 and US00 now give the correct spot date of 6th July.
date calculation, referred to as the SPOT.BASE.CCY, is controlled by the field of the same name in
FX.PARAMETERS.
If this mode of date calculation is used the following rules are followed:
The spot date for the NON-spot base currency is calculated. If an FX.LCL.REGION is defined this will
be used as per the rules in the previous section.
This date is then compared to the Spot Base Ccy holidays, if the date is a holiday it is adjusted to the
next common working day in both currencies after this date
A common spot date is obtained for the two currencies involved in the same way as the standard
processing. If an FX.LCL.REGION is defined this will be used as per the rules in the previous section.
The common date calculated will then be compared to the SPOT.BASE.CCY holidays. If the date is a
holiday it is adjusted to the next common working day for both currencies and the SPOT.BASE.CCY.
The common date calculated is compared to all the SPOT.BASE.CCY holidays. If the date is a holiday
it is adjusted to the next common date for both deal currencies and all currencies defined in
SPOT.BASE.CCY.
This method can result in a different date calculation to the standard calculation.
Example 4
Local Currency GBP Local Country GB
Spot Market 2 Spot Base CCY USD
System Date 2nd July
Holidays
Deal USD/GBP
GB spot date is 4th July.
This is a holiday in Spot Base Ccy so the date is adjusted to the next common working day in GB and
US, i.e. 6th July.
If this deal were done on 3rd July the spot date would also be 6th July. The spot date calculated for GB
would be 6th July, which is a working day in US. In the standard calculation the spot date would be
calculated as 9th July as 2 common working days would be taken between US and GB.
Example 5
Deal GBP/CHF on 2nd July
This gives a SPOT.DATE of 4th July. This is a holiday in SPOT.BASE.CCY so the date (4th July) is
adjusted to the next common working day for all three countries:
The next common day after 4th July for all three countries is 9th July.
Using the standard rules a spot date of 4th July would be generated, as the US holidays would not be
taken into consideration.
If the same deal were entered on 3rd July the spot date would also be 9th July using the
SPOT.BASE.CCY:
If the same deal were entered on 3rd July using the standard calculation would also result in a spot
date of 9th July.
The field CLS.CCY in CURRENCY needs to be set to YES to indicate participation into CLS.
The field CLS.CPARTY in CUSTOMER needs to be set to YES to identify a CLS participant.
The field CLS.DEAL in the FOREX contract defaults to YES, if a valid FX.CLS.CPARTY table has
been established which has matching CURRENCY fields.
An OVERRIDE will be given if a transaction is entered where the buy or sell value dates are over the
respected cut-off times in the FX.CLS.CPARTY tables.
When these type of contracts are entered the payment messages MT202/103 and advice to receive
messages (MT210) that would normally be generated will be suppressed.
If a deal is sent to CLS, CLS Nostro accounts needs to be used in place of the default nostro. This
means that a CLS Nostro should be identifiable.
It should be possible to book both “CLS” and “non-CLS” deals with the same counterparty, special
care should be taken on how on this should impact the NOSTRO.ACCOUNT and AGENCY tables.
DELIVERY
Currently the CLS support is as a ‘Third Party Member’ and as such there are two methods of CLS
delivery that can be done:
In the standard SWIFT header field 103 can be used to include the CLS Member code. This instructs
the SWIFT system to generate a duplicate message “T-Copy” to the bank CLS Member.
Alternatively, SWIFT fields 56 & 57 are used to identify the settlement member and that this is a CLS
message
Support for CLS is based on local modifications, as from feedback from clients indicates a mixed
variety of usage. Accordingly, you must add a few fields to FOREX to feed the relevant information to
delivery.
NB Delivery allows local mapping and population of the SWIFT Header fields and is detailed in the
delivery User
A value of NO or NULL will suppress the MT202 SWIFT message, a value of YES will always
generate the SWIFT message.
Non-Deliverable Forwards
ND.DEAL is the application that is used to enter transactions.
• Contract information
• Fixing and Settlement
• Settlement instructions
The key elements of NDF deals are currencies (deal ccy and settlement ccy), notional amounts, dates
(value date and settlement date), Counterparty, notional rate and buy/sell. Almost all elements of NDF
transactions, except the key information mentioned, have default values.
On validation, the system will automatically check and update the customer’s credit limit, raise
accounting entries and forward exposure entries, update the delivery fields on the contract and update
position management etc.
At the authorisation stage, the system will generate all the necessary accounting entries, populate and
send the messages in the delivery fields by SWIFT etc. The consol entry will only be raised during the
COB run.
In order to input the NDF vanilla deal, the NDF.METHOD field in ND.TYPE file must be set to ‘FIXED’.
Similarly, for the input of an exotic deal, the NDF.METHOD field in ND.TYPE file must be set to
‘OPTION’. This type then allows the fixing to be made on any date on or before the vanilla fixing date.
Fixing transactions
On the fixing date, the user needs to update the originally contract and enter a rate in the
FIXED.RATE field. The system will then calculate the settlement amount in field SETTLEMENT.AMT
based upon the notional rate and the fixing rate.
After the fixing rate has been entered, the FIXED.AMOUNT field will be automatically calculated. Profit
and Loss at this stage now becomes realised and is also automatically calculated. The value is
recorded in the field SETTLEMENT.AMT.
The settlement amount will be calculated differently between a Buy contract and a Sell contract for the
same deal currency and settlement currency.
For an Exotic transaction, which is fixed before a recognised fixing date, the discount factor will be
applied to the Settlement amount field SETTLEMENT.AMT to calculate the final Settlement Profit and
Loss. The discounted Profit and Loss DISCOUNT.PL will be amortised from the settlement date to the
value date of the transaction.
Settlement amount = Settlement amount * discount factor where discount factor is 1 / (1 – r)t.
Revaluation
To include the NDF contracts in FX forward position and create POSITION records, you need to set-
up a REVALUATION.PARAMETER record as shown below (this is only a guide line).
NDF contracts will be revalued as in the case of FOREX deals under the RB method and will be
included in the revaluation Report along with other FX deals.
Unfixed NDFs
Potential exposure amount field NOTIONAL.SETTL.AMT will be used to decrease the customer limit.
Fixed NDFs
Once the deal is fixed, there will be no more exposure. In other words, the customer’s limit will be
reinstated.
Sample Netting
Assuming that a new LIMIT.REFERENCE for an ND product is set as 1300 and 1320, where
FX.OR.TIME.BAND is set to ‘FX’.
Input contract 1 for Buy HKD 1, 000.00 Sell and USD transaction.
DEAL.CURRENCY: HKD
DEAL.AMOUNT: 1,000.00
SETTLEMENT.CCY: USD
NOTIONAL.RATE: 7.744677
NOTIONAL.AMOUNT: 129.12
Input contract 2 for Sell HKD 1,000.00 and Buy USD with the same counterparty, same value date as
the first contract.
The current available limit for customer 95003 HANG SENG BANK is $500 and two equal and
opposite deals take place for the same counterparty, for the same value date, then the available limit
will still be $500.
LIMIT displays the maximum amount, the available amount, and the outstanding amount with
currency.
Customer’s Limit.
LIMIT.DAILY.OS will retain the netting information for the entire equal and opposite deals, in which
case both contract 1 and 2 will be held in the same daily record.
Corresponding LIMIT.DAILY.OS.
LIMIT.TXNS displays both transactions which involve the same limit number.
Corresponding LIMIT.TXNS.
NDF Balances
The ND.BALANCES file is a read-only file, automatically updated and maintained by T24. For each
NDF contract there will be two separate records to keep buy and sell booking. This segregation is for
T24 G/L purpose, whereby the id of the buy side will consist of a contract id with ‘.B’ as a suffix, and
the sell side will be suffixed with ‘.S’.
Essentially this file will keep track of:
The information in ND.BALANCES is used to generate accounting entries and may be used to report
trade information as at the last close of business.
The history file ND.BALANCES.HIST is not only a backup file of ND.BALANCES for static change
process purposes, but also an archive of ND.BALANCES for contracts when the deal eventually falls
due (with MAT status).
Position Management
The NDF functionality is fully interfaced with the Position Management module. Essentially its PM
class will be categorized as an FX exposure type of class.
The PM.PARAMETER record needs to be amended and the value ND added where applicable.
The application PM.UPDATE.APPL needs to be used to add the ND value, to make this effective a
Close of Business needs to be run.
The FX positions in both the deliverable and non-deliverable currency will be updated with regular FX
forward contracts. On fixing date these positions will be unwound automatically.
The PM.POSN.CLASS record NDFXP will represent the FX exposure of unfixed NDF deals. It is
worth noting that this PM entry class will be raised for both DEAL currency and SETTLEMENT
currency.
Opening
From a T24 General Ledger point of view, the NDF CONSOL entry will be similar to a FOREX
forward entry. In which case, a buy side will raise FXFWDBUY and sell side will be FXFWDSELL.
For example, we have the detail of the deal as follows:
BUY.SELL.IND: BUY
DEAL.CURRENCY: HKD
DEAL.AMOUNT: 1,000,000.00
SETTLEMENT.CCY: USD
NOTIONAL.RATE: 7.744677
NOTIONAL.AMOUNT: 129,120.94
Fixing
Once the deal is fixed, the NDF will reverse CONSOL entries in correspondence to the entries raised
prior. The profit or loss will be realized immediately.
Fixed.RATE: 7.5
FIXED.AMOUNT: 133,333.33
SETTLEMENT.AMT: 4,212.39
Amortising
If there is a discount (this will only happen when NDF.METHOD is ‘OPTIONAL’), NDF will book the full
discount amount in suspense account and dip into P&L daily from SETTLEMENT.DATE until
VALUE.DATE. The suspense account category will be specified in ACCOUNT.CLASS. NDFTAKEN
and NDFGIVEN class will be classified as a credit bucket and a debit bucket respectively.
Assuming that the fixed rate is 8.0, the customer will take the profit with the discount from T24.
FIXED.RATE: 8.0
FIXED.AMOUNT: 125,000.00
SETTLEMENT.AMT: -4,120.94
SETTL.INT.RATE: 12%
SETTL.INT.BASIS: B 366/360
DISCOUNT.PERIOD: 10
DISCOUNT.PL: 13.74
Online Booking:
Activities
At present, NDF functionality provides 4 pre-defined activities in EB.ACTIVITY, which in turn can be
attached to the ND.PARAMETER these can be seen below.
Classes
For each message and receiver, it is represented by the message class EB.MESSAGE.CLASS.
These classes in turn will be attached to ND.TYPE.
Enquiries
In common with other T24 applications, all data can be enquired upon or selectively analysed and
researched. The Application maintains the overall exchange position for the bank with appropriate
enquiry facilities.
The exchange position can be viewed at several levels of consolidation. At the highest level the spot
and forward exposure for each currency are available and can then be selectively broken down and
studied on the basis of one or a combination of the following attributes:
Each of the above attributes is defined in tables maintained by the user in order that he may decide
their actual scope or special meaning.
This ENQUIRY allows details of the Bank's Foreign Exchange position to be shown by value date, i.e.
all the Foreign Exchange deals maturing on the same value date will be shown.
The selection criteria defined are:
VALUE.DATE
CURRENCY.FOR
CURRENCY.AGAINST
MARKET
This ENQUIRY will allow the bank to view those transactions, which have been made through the
mediation of a Broker. Both authorised and unauthorised deals can be displayed.
TRANSACTION.REF.NO
DEAL.TYPE
COUNTERPARTY
CURRENCY.BOUGHT
VALUE.DATE.BUY
CURRENCY.SOLD
BROKER
LIMIT.REFERENCE.NO
This ENQUIRY allows the bank to view Foreign Exchange deals using their own selection criteria. It
displays Foreign Exchange contracts according to the value of parameters defined by the user.
Unlike the other ENQUIRY facilities, only authorised deals will be selected in the retrieval process, i.e.
Foreign Exchange deals, which have not yet been authorised will not be shown on this ENQUIRY.
TRANSACTION.REF.NO
DEAL.TYPE
DEAL.SUB.TYPE
COUNTERPARTY
CURRENCY.BOUGHT
VALUE.DATE.BUY
CURRENCY.SOLD
BROKER
LIMIT.REFERENCE.NO
This ENQUIRY allows the bank to view Foreign Exchange deals using their own selection criteria. It
displays Foreign Exchange contracts according to the value of parameters defined by the user. The
ENQUIRY is aimed at users wishing to retrieve details of matured deals, which have been written to
history.
TRANSACTION.REF.NO
DEAL.TYPE
DEAL.SUB.TYPE
COUNTERPARTY
CURRENCY.BOUGHT
VALUE.DATE.BUY
CURRENCY.SOLD
BROKER
LIMIT.REFERENCE.NO
This ENQUIRY allows details of the Bank's Foreign Exchange position to be shown as one currency
in terms of another showing all the various dates on which FOREX transactions in the two selected
currencies exist. It displays, by value date, the currency position of the two selected currencies.
This is a general ENQUIRY, commonly used by both the FOREX and lending parts of the treasury
operations area. It displays the balances in the currency selected on NOSTRO ACCOUNT records
in that currency. The balances shown are for today and the next 4 days.
CURRENCY
LONG.POS.SIGN
This is also a general ENQUIRY commonly used by both the FOREX and lending parts of the
treasury operations area as well as the back-office staff. It displays the balances and movements on a
specific ACCOUNT and permits the user to obtain details of the entries shown down to the deal level.
ACCOUNT.ID
LONG.POS.SIGN
This ENQUIRY details position movements for the current business day. It will show the opening
position, today’s movements and the current position.
DEALER.DESK
CCY.SELECT
AGAINST.CCY.SELECT
MARKET
VALUE.DATE
Limits
Foreign Exchange
The application of Limits within the Foreign Exchange operation applies to all products handled by the
module.
The T24 LIMIT module provides a control mechanism for the FOREX module and when called at the
time of input will check the availability of an authorised credit line for the deal Counter party.
The LIMIT system is designed to monitor, in real-time, the availability and utilisation of customer
limits. Back end reports are available to allow the monitoring of limits for commodities, countries,
country group and currencies. The word limit describes a Facility or Credit Line available to a
customer or group of customers, while the term LIMIT.REFERENCE describes a type of LIMIT,
e.g. Foreign Exchange Limit.
For the Foreign Exchange type of limits, the limit amount can be associated with a 'Clean' risk, the
purpose of which is to allow the specification of a 'Delivery' or 'Settlement' risk on any particular day.
The LIMIT system covers two types of exposure as far as the Foreign Exchange application is
concerned. These are:
The system also allows netting of the Overall Foreign Exchange Limit for opposing deals with the
same Counter party when the two opposing deals involve the same two currencies and mature on the
same day. For example, if the bank buys USD 100,000 from a Counter party for GBP 70,000 to be
settled on 31st December and then sells USD 50,000 to the same Counter party for GBP 35,000 to be
settled on the same day (December 31st), the net effect would be an overall foreign exchange
exposure of USD 50,000. Note that within this approach the Clean Risk is never netted.
The overall Foreign Exchange Limit netting facility is controlled by the field NET.OUTSTANDING in the
LIMIT.PARAMETER application. This can be changed by using the application LIMIT.CHANGE.
Once the LIMIT has been established for a particular CUSTOMER, the system is then able to use
this information to ensure that the LIMIT is not exceeded, though an override facility is provided
whereby a duly authorised officer of the bank may permit a LIMIT excess.
If more than one LIMIT of the same type exists the Foreign Exchange module will default to the first
LIMIT (i.e. the LIMIT with serial number 01) unless the user specifically indicates otherwise by input
of a LIMIT.REFERENCE number in the field LIMIT.REFERENCE.NO provided for this purpose on
the Contract record.
Occasionally the required LIMIT does not exist or is already fully utilised. If it does not exist the user
must make a decision as to whether or not to generate a default LIMIT. If the transaction causes an
excess the user must decide whether the excess is to be allowed.
At the maturity of a Foreign Exchange transaction the module will provide notification of the event to
the LIMIT System, which will then reset the utilisation figures.
This methodology is also known in the market as ‘Current exposure’ which takes account not only the
Potential exposure calculated by multiplying a deal’s Principal by a configured fraction, but also the
transaction’s value in the market at current rates.
So the credit exposure for clients assessed under this method will be:
Replacement cost
This is the actual market value of the contract or the profit or loss if the open position is covered. The
replacement cost is positive if the client is showing a loss and negative if the client is in profit.
This is because if the client were losing money the contract is profitable for the Bank. If the client
defaults and therefore the deal has to be cancelled then the Bank will lose money by having to go into
the market and cover the trade at current levels.
This is a defined and configured percentage of the nominal (cash transactions) or underlying (option
transactions) contract amount. The percentage depends on the type of contract and the maturity of the
contract and is defined by the volatility of those asset types.
As well as FX these calculations could be applied to any asset (at present only FX forwards, the
forward legs of swaps, futures and long options are covered).
The relevant fields for configuring the percentages in this table are shown below:
The new method to calculate Credit exposure will use this table to derive the required add-on
percentages (Potential exposure) to build reports and enquiries for the Bank’s use to monitor and
report exposures to the relevant authorities.
The application, FX.CURRENT.EXPOSURE allows users to request a revaluation and report on the
credit usage using the new current exposure method.
FX.CURRENT.EXPOSURE has fields for entering details of which reporting method (which ‘add-on’
percentages configuration) they wish to use and which customer or customers (multi-valued list of
customers or ‘ALL’) to report usage for.
There is an option for the user to run an ad hoc revaluation on the requested customer or group of
customers or whether to use the data held in POS.TRANSACTION. This is because the revaluation
may have been run recently so the marked to market value of the transactions will be relatively up to
date. There will be no need to re-run the process and use system resources unnecessarily.
In the case where a revaluation is being run all the contracts for the counter party or group of counter
parties will be re-valued using the ‘Rebate’ methodology for FX contracts regardless of what
methodology was initially entered for the transaction. For accounting purposes the original
methodology will be used but FX.CURRENT.EXPOSURE will use ‘RB’.
The profit or loss of the trade in local currency will be determined. This figure is the Current exposure
(Replacement Value) of the trade. It will be negative if there is a loss on the trade from the Banks
perspective (i.e. the customer is making money on the transaction) and positive if there is a gain on
the trade from the Banks perspective (i.e. the customer is losing money on the transaction).
Examples
User has configured add on percentages for FX:
<6MTH = 2%
>6MTH & <12 MTHS = 4%
Example 1
Trade at outset = Bank buys £1 million against -$1,520,000 at 1.5200, 8 months outright
Re-valued at entry rate so Current exposure (Replacement Value) = zero
Add-on = £1 million X 1.5200 X 0.04 = $ 60,800
Utilisation = MAX ([$60,800+ $0], ZERO) = $ 60,800
Example 2
Trade at outset = Bank buys £1 million against -$1,520,000 at 1.5200, 6 months outright
Re-valued at entry rate so Current exposure (Replacement Value) = zero
Add on = £1 million X 1.5200 X 0.02 = $ 30,400
Utilisation = MAX ([$30,400+ $0] , ZERO) = $ 30,400
Revaluation after 1 month @ 1.4800: -£1 million against +$1,480,000.
Bank P/L in local ccy ($) = -$40,000 (loss of $40,000 i.e. Customer is making money)
Current exposure (Replacement Value) = -$40,000
Add on = £1 million X 1.4800 X 0.02 = $ 29,600
Utilisation = MAX ([$29,600+ (-$40,000) ] , ZERO) = ZERO
The system will use REVAL.ADDON.PERCEN to calculate the required ‘add-on’ percentage for the
product (FX), timeframe and reporting type, before applying the add-on percentage to the Principal of
the trade and calculating the notional utilisation.
The timeframe of the deal is calculated from the system date (today) up to the maturity date of the
trade. Then this number of days is compared to the time buckets in the REVAL.ADDON.PERCEN
table to determine the add-on percentage. The deal principal is converted to local currency at the mid
rate defined in CURRENCY table and then multiplied by the add-on percentage to find the notional
add on amount in the local currency.
E.g. An FX trade with a principal of 10 million Euro, an exchange rate of 0.95 and with a ‘add-on’ of
0.01 (1%) will give a notional utilisation of USD 0.095 million ($10 million X 0.95 X 0.01= $0.095
million).
This figure will be added to the Current exposure (Replacement Value) value obtained from the
revaluation process. If the Current exposure figure is negative the resultant figure will be a net figure,
but it can never be negative.
I.e. if the Current exposure value is a greater negative amount than the ‘add-on’ calculation is positive
then the utilisation will be zero.
The information, collated and stored in the revaluation table POS.TRANSACTION can be accessed
by enquiries, which can be easily set up and implemented.
Each record in this table can only be input into once. After that the record can only be viewed in ‘SEE’
mode. This is for audit purposes and at the Close of Business all authorised records are destroyed,
as there is no point in keeping the data and no history files will exist for records in this table.
Local implementation of versions should be used to make sure there is a ‘Zero authorisation’ version
so that users can quickly call the routine and get data on Total utilisation without having to have the
record authorised.
REPORT.METHOD
Defines the record in the add-on table to search for the add-on percentages. Can be any valid entry in
<add_on_table> E.g. ‘INTERNAL’, ‘REGULATORY’ etc.
CUSTOMER.GROUP
Incorporates any valid entry from the CUSTOMER table. Accepts either the 8-digit customer number
or the customer MNEMONIC a multi-value for inputting several customers. Will also accept ‘ALL’ to get
the data for all customers in the CUSTOMER file. The system will warn the user if ‘ALL’ is selected
so that the user can be sure that they want to select a revaluation for all customers, which will take
longer.
RUN.REVAL
Determines whether there will be a new revaluation done using the latest FX rates or whether the
latest figures, which are stored in POS.TRANSACTION for Current exposure plus add-on, will be
used again. The default will be ‘NO’.
However, this functionality does not cover FX SWAPS and contracts of subtypes BR (broker), IN
(internal), NE (negotiated).
For this purpose the application FX.CLOSING.GROUP can be used and will contain the list of FX
contract IDs which match with the specified counterparty and value date and have not already been
included in any other closing group nor matured. Further, grouping of FX contracts is not allowed, if
there is balance in more than one currency. FX.CLOSING.GROUP records will also move to history
as per DAYS.POST.MATURITY definition in FX.PARAMETER.
Also, a new field CLOSING.ID has been added to FX contract which will hold the ID of
FX.CLOSING.GROUP record under which the relevant FX contract has been grouped. So, a FX
contract can’t be reversed so long as it contains a value in the field CLOSING.ID.
Example
Assuming that the local currency and limit currency is USD, and that the currencies involved in the
trades are USD and GBP with a USD amount of 1,000,000. If the current available limit for customer A
is $5,000,000 and two equal and opposite deals take place for the same customer for the same value
date at the current mid revaluation rate, then the available limit will still be $5,000,000.
If limit netting is not enabled, then the available limit will be $3,000,000.
Similar to FX netting, to enable NDF limit netting the NET.OUTSTANDING field on LIMIT.CHANGE
should be set to Y. To disable this functionality the same field can be set to N.
This flag can only be set to the opposite value to the NET.OUTSTANDING field on the
LIMIT.PARAMETER SYSTEM record.
The actual change will take place during the next T24 close of business run. For more detail set-up,
please refer to the Netting section in the LIMIT chapter.
Reports
Foreign Exchange
The System also provides comprehensive reporting facilities such as:
Outward Delivery
Foreign Exchange
Throughout the life of a deal, the Foreign Exchange module will automatically recognise when the
various events associated with a contract (e.g. new contract, change in liquidation instructions etc.)
occur. The module will then pass control to the T24 Delivery module with the appropriate information,
which will be interpreted by Delivery. This module will then transform the information into the
appropriate message - either advice, payment or confirmation which will then be sent by SWIFT, Telex
or Print (Mail). The following message types are supported:
The FOREX application is now set up to select new bullion messages in favour of the usual FX trade
confirmations when one or both of the currencies traded is configured as a metal.
• Revaluation of all contracts for which revaluation parameters have been specified.
• Generation of reports.
Non-Stop Processing
This application is now fully integrated with the Non Stop Process and its usual work flows.
FX deals can be processed at start of day. The deal is processed in the overnight batch before the
system goes live to within day activities on the day of maturity/taking value. This means that the
customer has access to funds from a purchased currency and is liable for a sold currency at the start
of day on the maturity or value dates. In this way funds are available to meet other requirements as
soon as the system is live on the day in question.
This happens if the field SOD.MAT in FX.TRANSACTION.TYPE is set to YES.
The FX.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 BATCH
jobs FX.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 records 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.
Accounting Process
Product Category Codes
Range 20000 - 20999 has been assigned to the Foreign Exchange application. Default category
codes must be defined on the FX.PARAMETERS table for SPOT, FORWARD and SWAP.
The following two codes have been predefined:
The product category codes used in Spot and Rebate revaluation may be varied using the appropriate
fields in REVALUATION.PARAMETERS.
Transaction Codes
Examples:
a) Spot Contract:
Buy 10M $ @ 1,70 --> Sell 17M DEM
On Deal Date
FXSPOTBUY NEW -10M FXSPOTSELL NEW +17M
On Value Date
FXSPOTBUY MAT +10M FXSPOTSELL MAT -17M
+Entries in the Our Account Pay and Receive
b) Forward Contract:
Buy 10M $ @ 1,68 --> Sell 16.8M DEM
On Deal Date
FXFWDBUY NEW -10M FXFWDSELL NEW +16.8M
On Spot Date
FXFWDBUY SPT +10M FXFWDSELL SPT -16.8M
FXSPOTBUY SPT -10M FXSPOTSELL SPT +16.8M
On Value Date
FXSPOTBUY MAT +10M FXSPOTSELL MAT -16.8M
+ Entries in the Our Account Pay and Receive
Contingent Entries
Contingent entries will be raised in the Close of Business process for any contract, which has been
created with a value date greater than the System date. These contingent entries will be raised for both
the amount bought and the amount sold. All contingent entries are of the type 'Special Consolidation
Entries' and will use the Transaction codes and C.R.F. Asset Types described earlier in accordance with
the contract type. The following table summarizes all contingent entries.
The foreign current amount(s) will be taken directly from the contract (AMOUNT.BOUGHT and/or
AMOUNT.SOLD) and the local currency equivalent will be taken respectively from the fields
BUY.LCY.EQUIV and SELL.LCY.EQUIV also directly from the contract.
It must be noted that in the case of option contract with multiple deliveries, contingent entries will be raised
individually for each delivery set.
1. Brokerage, Charges, Commissions, Taxes and Marketing exchange Profit entries are raised on
line at authorization of the contract.
2. Our Account Receive and Pay entries are generated in the Close of Business process on the value
date. However, for any contract value, same day entries will be raised on-line on authorization of the
contract.
3. Forex accrual entries are generated in the Close of Business process and will start on the Spot date
of the contract.
4. Revaluation entries (Forex and Assets and Liabilities) are also generated during the Close of
Business process.