Forex

Foreign Exchange
Contents:
l Overview
l Main Setup
l Deal / Transaction Processing
l Non-Deliverable Forwards
l Enquiries
l Limits
l Reports
l Outward Delivery
l Close of Business Services
l Non-Stop Processing
l Accounting Process
l Revaluation
(c) Temenos Systems 2013
Foreign Exchange- Release R13.00 -Page 2 of 110 - (c) Temenos Systems 2013 05/07/2013
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
Ma in Pr oduc ts
The FOREX module encompasses the following 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 cus-
tomary 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 trans-
actions are usually, but not necessarily, done with the same Counterparty. T24 maintains the link between the spot and forward deals auto-
matically 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.
Multi-rate option contract
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.
This is usually a Non-Bank counterparty contract with the following features:
l Between the start date and the maturity date, there are defined time periods for which the transaction can be exercised by the counter-
party. These option periods are agreed upon at the start of the deal.
l After defining the option periods, no amendment to the first option period is possible. Amendments to the subsequent periods are pos-
sible only outside the current option period and after the farthest scheduled delivery date.
l Either the buy or sell currency is nominated as the option currency.
l The full contracted amount will be updated in the LIMIT application for the final maturity date of the deal even if no delivery is sched-
uled at the time when option contract is input. The limit will be re-instated to the extent of delivered amount on the delivery date.
l 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, Posi-
tion for the undelivered amount will be re-cycled to the last date of the next option period.
l In each option period there will be defined exchange rate(s).
l Multiple deliveries are allowed, which can take place at any time between the option date and the final (value) date. Each delivery (take-
down), uses the exchange rate pre-defined for that option period in which the value date of the delivery date falls.
l The total takedown amount cannot exceed the original amount bought or sold in the option currency.
l When takedown takes place it is possible to take a charge / fee.
l Confirmation is produced for initial contract entry.
l Confirmation is produced for each takedown.
l Confirmation is produced for contract amendment.
l 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.
l Each takedown (the delivered amount) will be revalued separately against the market rate till the delivery date.
l On the Value date of the contract, should there be any residual option amount that is undelivered. T24 will liquidate the contract dur-
ing COB by automatically scheduling a delivery for the residual option amount at the exchange rate applicable for the last option
period.
l A report containing the list of contracts that underwent such automatic scheduling of delivery on a day shall be produced during COB.
l 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.
l Market exchange profit/loss calculation is not supported for multi-rate options.
Non Deliverable Forwards
Ty pe s of Pr oduc ts
There are two types of NDF transactions to take into account:
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 set-
tlement 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
Othe r Ty pe s
Contract types such as Antespot, Tom-Next or Spot-Next are by-products of the above deal types.
D e a l Sub Ty pe s
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 auto-
matically 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 sub-
stitutes 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 con-
tract to be authorised. When the Counterparty name is known, the user will only need to erase 'BR' from this field and complete the Counter-
party 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.
Configuring T24 Foreign Exchange Tables

The FOREX module initiates all confirmations, payments, charges, commissions, advices, account entries and updates all relevant positions.
The detailed action to be taken by the module for a particular Foreign Exchange deal is defined in a series of user-controlled tables.
The following tables have to be set up to enable FOREX to function efficiently.
FX.PA R A METER S
A typical FX.MARAMETERS record.
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.
l Definition of the 'Spot' default value date.

l Definition of OFS.SOURCE and versions used for inputting Bulk Orders.
l Definition of product and profit/loss categories for neutralisation of forward interest.
l Definition of alternative FX trading holidays.
l Definition of currencies, which should be used in all spot date calculations.
FX.TR A N SA C TION .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.R EVA L.TYPE

Within the FX.REVAL.TYPE table are defined the revaluation types available in the Foreign Exchange application. The system caters for the fol-
lowing different Revaluation methods.
Interest Method (IN)
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
l GBP 1000 would yield GBP 120 interest.
Likewise, if exchanged (@1.25)
l USD 1250 would yield USD 175 interest.
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.
l USD 1425 / 1.2723 = GBP 1120
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).
Using the same example:
A loan of USD 1250 will yield USD 175 over 12 months. Over the same time a debit (revaluation) accrual is made of USD 25 (i.e. USD 1250 *
2%). Thus the net result is interest received of USD 150.
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.
Rebate Method (RB)
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, even-
tually 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 for-
ward contract viz.
l Interpolation.
l Next available rate.
l Rate at closest date.
Indicate your choice on the REVALUATION.PARAMETER table.
Interpolation of forward Exchange Rates:
l 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).
l The actual date that the forward rates apply to are calculated as the reporting date + 2 working days + number of months.
l If this date is not a working day, then the next working day is used.
l 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.
Straight Line Method(SL)
As previously stated, there is generally a difference between spot and forward rates. Under this method the difference, as an amount in local cur-
rency, 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:
RESFWDCR Forward deals credit.
RESFWDDR Forward deals debit.
RESSWAPCR Swap deals credit.
RESSWAPDR Swap deals debit).
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.
Straight Line Funding Method (SF)
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.
D EA LER .D ESK
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.
B R OK ER
The BROKER table allows the bank to identify its authorised Brokers.
A Broker record Example.
FX.D EA L.METH OD
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.
FOR WA R D .R A TES
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 pre-
mium 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 QUO-
TATION.PIPS, defined on the CURRENCY table for the ID currency, the system will automatically add/subtract this premium/discount from
the CURRENCY tablemiddle rate.
Forward rates are used by the Forward revaluation (Rebate method) and also to provide tolerance checks for forward rates on input of a For-
ward 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.
Configuring T24 Non Deliverable Forward Tables
Basic information about the way that Non Deliverable Forward deals are processed is held in a series of parameter files:
For NDF contract to be reported correctly and incorporated into the T24 General Ledger The parameter file CONSOLIDATE.COND needs to
be configured.
Sample record in CONSOLIDATE.COND
N D .PA R A METER
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 param-
eters for the processing of NDF transactions in a single SYSTEM record.
The SYSTEM record consists of the following details:
• A list of currencies allowed for NDF contracts.
• Fixing date related data such as default fixing date, specific fixing date for particular currencies etc.
• Accounting transaction codes to use on each NDF operations such as NDF fixing, settlement, deal reversal, etc.
A typical ND.PARAMETER record.
N D .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.
A typical ND.TYPE record.
EB .A GR EMEN T.TYPE
The EB.AGREEMENT.TYPEfile is used to store the types of agreements used in NDF contracts, e.g. ISDA, BBAIRS, MASTER etc. Each con-
tract must be linked to an agreement type. The field AGREEMENT.TYPE on the NDF contract is validated against the agreement type def-
initions on this file and enriched with the associated description.
MM-LU2 - MM Parameters
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, excep-
tionally, 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.
Ma in input
The majority of input in the FOREX module will comprise initial input of the contract with a limited amount of these contracts actually requir-
ing any changes. Where changes are required they tend to be to the settlement accounting details.
Spot de a l input
The examples below outline the main components of a typical spot deal. The amount of information required is quite limited, and the spot VER-
SION has been tailored to reflect this. In order to assist the dealer in inputting the deals, and to reflect the usual practice of buy and sell con-
tracts, the VERSION have been split into similar categories.
Forex Spot Buy Input (Example 1).
The main inputs required are the Counterparty, currency, amount, and the foreign exchange rate. Where the settlement details for the Counter-
party are stored on the system they will be set by default in the contract.
For wa r d c ontr a c t
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.
Forex Forward Buy.
Swa p c ontr a c t
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:
A FOREX Swap Buy (Example 1).
After validation of the spot contract you are automatically taken to the forward leg. Note that the static amount is now the sell amount.
A FOREX Swap Buy (Example 2).
B ullion c ontr a c t
The FOREX application allows for the input of metals if these are configured in the table CURRENCY inthe PRECIOUS.METAL field as fol-
lows:
Precious Metals field set to YES.
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:
Example table: Fields in FX for Bullion trades
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 (Met-
ricTonne), 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 DELIVERYmodule to produce the SWIFT messages MT600, MT604 and MT605.
Example of a Bullion trade to purchase GOLD.
A FOREX SPOT to purchase gold.
SWIFT MT600 Delivery produced based on the above transaction.
SWIFT MT600 with Sequence B.
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.A-
CCOUNT.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.
Example of a Bullion trade to sell GOLD.
A FOREX FORWARD to sell gold.
SWIFT MT600 Delivery produced based on the above transaction.
SWIFT MT600 with Sequence C.
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 CPAR-
TY.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.
N e utr a lis a tion of for wa r d inte r e s t

A dealer may wish to sell the interest from a deposit or placement in foreign currency through a forward deal. Setting the AMOR-
TISE.POSITION field to ‘YES’ will amortise the position to reflect the interest accruals. Setting this field to ‘NO’ will raise the whole position
on input of the deal.
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.
N e utr a liza tion of for wa r d inte r e s t (A m or tis ing pos itions )
A dealer may wish to sell the interest from a deposit or placement in foreign currency through a forward deal. This optional facility allows the
position arising from such deals to be amortised and reflect the interest accruals. This differs from a normal forward contract where the whole
position would be raised immediately after input.
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 deal-
er'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.
B ulk Or de r s
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.
Configuring T24 Bulk Orders
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.
Edit FX.PARAMETERso that:
Field Content Example
BULK.OFS.SOURCE The OFS.SOURCE record FX.BULK.OFS
BULK.MASTER.VER The FX deal version FOREX,SP.BUY
BULK.CHILD.VER The FX deal version FOREX,SP.BUY
Services can be defined Company wise.
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 Example

For example, a bulk order contains these details:
BULK.ORDER.ID FXT0324100001 The 1 st 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
CUSTOMER.ID SEC.ACC.NO AMOUNT.BOUGHT AMOUNT.SOLD BUY.OR.SELL
OUR.ACCTOUNT.PAY
50060 Airboure 50060-1 EUR 100,000 Blank BUY Blank Blank
(The counter party to the transaction) (The customer's portfolio)
100020 Bank Bumiputra Blank Blank USD 120,000 SELL 26751 100020
TOTAL.BOUGHT.AMT 1,200,000 1,200,000 USD bought
TOTAL.SOLD.AMT 1,500,000 1,000,000 + 500,000 = 1,500,000 EUR sold
FX Bulk Order example.
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.
FX.ORDER (with defaults)

The FX order contains these details:
ORDER.ID FXO0324100001 The 1 st 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 Empty
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
Example FX.ORDER with defaults.
FX.ORDER (with more information)

The user must fill in more details:
FX Order
ORDER.ID FXO0324100001 The 1 st 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 The sum of the amounts sold in the BASE.CCY, plus the sum of the amounts bought in the
this 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 The TOTAL.BASE.AMT converted at the SELL.RATE = 2,833,333.33 ´ 0.9 = 2,550,000.00
this 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.
FXT0324100003 The ID of the bulk order which this FX.ORDER was created from
BULK.ORDER.ID
CREATE.RECORDS YES When the FX.ORDER is authorised, T24 will create FX deals.
FX.ORDER with more information.
The FX master deal

T24 creates the master deal. This is the deal between the bank and the counterparty specified on the FX.Order.
It contains the following details (amongst others):
DEAL.TYPE SP From FX.BULK.ORDERDEAL.TYPE
COUNTERPARTY 100550 From FX.ORDER COUNTERPARTY or FX.ORDER. DEALER.DESK
DEALER.DESK 01 From FX.BULK.ORDERDEALER.DESK
CURRENCY.BOUGHT EUR From FX.ORDERBASE.CCY
AMOUNT.BOUGHT 231,147.54 From FX.ORDERTOTAL.BASE.AMT
VALUE.DATE.BUY 01 SEP 2003 From FX.BULK.ORDERVALUE.DATE
CURRENCY.SOLD USD From FX.ORDERCONTRA.CCY
AMOUNT.SOLD 209,188.52 From FX.ORDERTOTAL.CONTRA.AMT
VALUE.DATE.SELL 01 SEP 2003 From FX.BULK.ORDERVALUE.DATE
SPOT.RATE 0.905 From FX.ORDERTREASURY.RATE
FORWARD.RATE DEFAULT From FX.ORDERTREASURY.RATE + FX.ORDERFORWARD.POINTS
DEAL.DATE 29 AUG 2003 From FX.BULK.ORDERDEAL.DATE
FX.BULK.ORDER.ID FXT0324100003 From FX.BULK.ORDER ID
FX.ORDER.ID FXO0324100003 From FX.ORDER ID
A FOREX master deal.
The FX child deals

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.
Lim it Or de r s
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.
Configuring T24 Limit Orders
To facilitate automatic creation of FOREX records on execution of the order, an OFS.SOURCE records needs to be created.
An example records is shown below.
OFS.SOURCE record OFS.FX.LIM.ORDER.
A company wise record for OFS.MESSAGE.SERVICE in TSA.SERVICE is necessary for generation of FX deals from FX.LIM.ORDER.
An Example record is shown below:
TSA.SERVICE with BNK/OFS.MESSAGE.SERVICE.
The OFS.SOURCE record needs to be entered in the field TRADE.ORD.OFS.SRC in the FX.PARAMETERS file.
FX.PARAMETERS with OFS.SOURCE record attached.
In the LIMIT.PARAMETER record a new limit has to be defined for the FX.LIMIT.ORDER application. You can define different limits for dif-
ferent categories.
LIMIT.PARAMETER with FX.LIM.ORDER defined.
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 5 th June 2003 at 14:00 hours.
It is an SP type FOREX Contract with value date of 15 th 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.
Note that the ORD.ITEM.STAUS is OPEN and ORDER.STATUS is ACTIVE
ORDER after EXECUTION
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.
The same FX.LIM.ORDER after execution.
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.
A FOREX contract created after execution.
C onfir m a tions
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.
l FX.UNCONF.BROKER - Unconfirmed Broker deals

l FX.UNCONF.CPARTY - Unconfirmed Counter party deals
External packages can be used for confirmation matching.
C ha r ge s a nd C om m is s ions
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 is used to define commission groups. The COMM.GROUP.ID field on a SEC.ACC.MASTER record identifies the
FX.COMM.GROUP for a portfolio.
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 per-
centage 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
Linked Commission Groups
The Forex spread can also be expressed as a percentage of the FX commission of another group, by using the GROUP.LINK field.
For example, FX.COMM.GROUP 1 is set up like this:
COMM.CCY USD
START.AMOUNT 0
END.AMOUNT 100,000.00
SPREAD 0.6
GROUP.LINK 2
START.AMOUNT 100,000.01
END.AMOUNT
SPREAD 0.5
GROUP.LINK 2
FX.COMM.GROUP2 is set up like this:
COMM.CCY USD
START.AMOUNT 0
SPREAD 0.04
GROUP.LINK
END.AMOUNT
SPREAD 0.01
GROUP.LINK
The amount is 120,000 USD, using commission from FX.COMM.GROUP1. The commission rate is 50% of 4% – that is, 2%.
A lloc a tion of Ex c ha nge Pr ofit

The relationship between Treasury and other units can be established very easily. Any transaction processed for a non-Treasury customer can
have exchanges between the Treasury and that department at one rate (treasury rate) and between that department and the customer at
another. Exchange Profit is passed to the department as the spread between these two rates and a balancing entry is passed to a suspense
account at the time of contract entry. The suspense account entry is then reversed when the contract matures effectively leaving a profit or loss
on the department’s Profit and Loss category.
It is necessary to have an ACCOUNT.CLASS record MARKETING if you are using marketing exchange within FOREX . The category code
entered on this record will be used for the suspense account for dealer desk’s marketing exchange profit and loss.
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 cus-
tomer rates. Treasury rates should reflect real market rates.
Accounting
Conventionally, the marketing exchange in a Forex contract has been accounted for as under.
On Input :
Debit : Internal Suspense A/c
Credit : P&L Marketing Exchange
On Maturity :
Debit : Customer a/c *
Credit: Customer A/c *
Credit : Suspense a/c
The difference between the Debit and credit entries for customer a/c would reverse the Suspense a/c balance on maturity.
Alternative Method of Accounting:
An alternative method of accounting for marketing exchange is available to make it compatible with the overall working where the Position
Accounting is switched on. The same works as under.
System raises two category entries to post the Marketing Exchange Profit/loss. For this, the field MKT.EXCH.ACCT.METHOD in FX.P-
ARAMETER has to be set to P&L. The other value that can be given against this field is INTERNAL which means the conventional method of
Accounting wherein the entries are raised between and Internal Suspense Account and P&L. Under the alternative method, CATEGORY entries
will be raised in the following way.
Debit P&L Marketing Exchange of Treasury USD 1000
Credit P&L Marketing Exchange of Customer USD 1000 (Customer Marketing Dept Category).
The impact of this method on POSITION is that the LCY Equivalent of the FCY will be built at the contract rate and not at the Treasury Rate.
As a result, the BUY.LCY.EQUIV and SELL.LCY.EQUIV in FOREX will be identical so long as the Revaluation method is SP or RB.
Since no internal suspense account is involved, there will be no need for any reversal entries to be posted during the maturity of the deal.
Through ACCOUNT.CLASS, one or two P&L category codes can be defined for marketing exchange depending on whether the credit and debit
should go to one category or to different categories.
Pr inc iple s of c ontr a c t r e v a lua tion

The purpose of this section is to explain and illustrate the revaluation process applicable to foreign exchange contracts performed by the end of
day activities of the FOREX application. The revaluation process applicable to balance sheet items (assets and liabilities) is described else-
where and is therefore not included in this section.
Examples of both spot and forward revaluation processing are highlighted and the different revaluation methods of forward contracts are illus-
trated.
SPOT CONTRACT REVALUATION
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 andSELL.LCY.AMT on the main FOREX con-
tract 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.
b) Where the local currency is neither the currency bought nor the currency sold (Deal 2), the system will calculate the local currency equiv-
alent of the BASE currency/amount and apply it to both currencies of the contract so that fields BUY.LCY.AMT andSELL.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
REVAL.RATE for the given currency found on the CURRENCY application. For example, on the CURRENCY table the revaluation 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.
Before the Close of Business process the Position file is as follows:
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
CR 53001 SPOT REVALUATION
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:
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.
This supplementary loss is composed as follows:
l Dealer Desk 1: LOSS IN USD Position = GBP 4,356.92

l Dealer Desk 2: LOSS IN USD Position = GBP 4,356.92
l LOSS IN DEM Position = GBP 4,040.44
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.
DAY 0 (deal date) Profit/Loss to date 6,815.93 DR
DAY 1 (next day) Profit/Loss to date 19,570.21 DR
------------
TODAYS TOTAL 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 andSELL.LCY.AMT of the contract) and from now on will be revalued
within the Asset/Liability revaluation process.
FORWARD CONTRACT REVALUATION
The Revaluation process within T24 allows the following five methods for the revaluation of Forward contracts:
l Rebate
l Straight Line Funding
Rebate revaluations use the MID.REVAL.RATE found on the CURRENCY table, while the other types use the REVAL.RATE also found on the
CURRENCY table. The system can be made to use REVAL.RATE in CURRENCY table instead of MID.REVAL.RATE for calculating the Reval-
uation Rate for Rebate revaluations, by inputting a value YES in the field REVAL.RATE in the REVALUATION.PARAMETER for RB Method. If
there was no value entered in REVAL.RATE, then the MID.REVAL.RATE for that CURRENCY will be used.
An example will be given for each one of these methods.
Straight Line Revaluation ('SL')
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
(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:
When the contract involves local currency
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:
If AMOUNT BOUGHT islocal currency, then AMOUNT.BOUGHT = BUY.LCY EQUIV
If AMOUNT.SOLD is local currency, then AMOUNT.SOLD = SELL.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 cor-
responding BUY.LCY.EQUIV or SELL.LCY.EQUIV.
When the contract does not involve local currency
The BASE amount of the contract will be converted at the CURRENCY table MID.REVAL.RATE of the BASE currency to generate the local cur-
rency 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.
After the validation of the 2 deals, the POSITION file is as follows:
Dealer Desk 01
For - 1,000,000.00 USD + 675,675.68 GBP
Against + 675,675.68 GBP - 1,000,000.00 USD
Local equiv. - 666,666.67 GBP + 675,675.68 GBP
| 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
| ACCRUALS |
6,060.61
The signs follow the accounting conventions.
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 REVAL-
UATION.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 con-
tract.
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 cus-
tomer accounts, nostro accounts or internal accounts. In addition to the process described for the liquidation of a SPOT contract, one sup-
plementary 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 cur-
rency 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 reval-
uation process.
Interest Revaluation (IN)
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
(Spot Rate) (1.50)
Value Date 6 Months
Dealer Desk 01
Revaluation Type IN
Interest rate buy 6.964504654
Interest rate sell 9.75
BUY LCY AMT - 666,666.67
Deal 2
(Spot Rate) (2.20)
Value Date 6 Months
Dealer Desk 02
BASE Currency USD
Revaluation Type IN
BUY LCY AMT - 666,666.67
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 local currency amount of the contract will be kept to generate the local currency value in the corresponding BUY.LCY.EQUIVor
SELL.LCY.EQUIV i.e.
If AMOUNT.BOUGHT = Local currency, then AMOUNT.BOUGHT = BUY.LCY.EQUIV
If AMOUNT.SOLD = Local currency, then AMOUNT.SOLD = SELL.LCY.EQUIV
The BASE amount of the contract will be converted at the CURRENCY table middle 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 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
FOR - 1,000,000.00 USD + 675,675.68 GBP
AGAINST + 675,075.68 GBP - 1,000,000.00 USD
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
Please note that the signs follow the accounting conventions.
Under the Interest revaluation method, this difference between BUY.LCY.EQUIVand SELL.LCY.EQUIVis 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:
A Credit to Interest Received Exchange for the currency bought.
A Debit to Interest Paid Exchange for the currency sold.
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:
For the currency bought
Amount bought x INTEREST RATE BUY
INTEREST BASIS OF CCY BOUGHT = Daily accrual amount for currency bought
I.e. in our example deal 1
1,000,000.00 USD X 6.964504654 = USD 193.46
36000
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.
In our example deal 2
1,000,000.00 USD x 6 = USD 166.67
36000
When the contract does not involve the local currency of the country, the BASE currency accrual amount will always be converted at the CUR-
RENCY table REVAL.RATE.
For the currency sold
Amount sold x INTEREST RATE SELL
INTEREST BASIS OF CCY SOLD = Daily accrual amount for currency sold
i.e. in our example deal 1
675,675.68 GBP ´ 9.75 = GBP 180.49
36500
This amount, being a local currency amount, does not need to be converted and represents the daily accrual in local currency for the sold cur-
rency.
In our example deal 2
2,180,000.00 ´ 4.191863385 = DEM 253.84
36000
When the contract does not involve the local currency of the country, the NON BASE currency accrual amount will always be converted at the
contract FORWARD RATE and the CURRENCY table reval rate of the BASE currency.
In our case, this rate will be 2.18 ´ 1.50 = 3.27.
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 bal-
ancing 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.
Interest/Hedged Revaluation (IH)

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 cur-
rency's rate is, in this case, performed differently.
Deal 1
(Spot Rate) (1.50)
Value Date 6 Months
Dealer Desk 01
Revaluation Type IH
BUY LCY AMT - 666,666.67
Deal 2
(Spot Rate) (2.20)
Value Date 6 Months
Dealer Desk 02
BASE Currency USD
Revaluation Type IH
BUY LCY AMT - 666,666.67
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/ Hedged Revaluation Method. The same rules as those defined for the Straight Line and Interest methods will be fol-
lowed i.e.
The local currency amount of the contract will be kept to generate the local currency value in the corresponding BUY.LCY.EQUIV and
SELL.LCY.EQUIV
For example:
If AMOUNT.BOUGHT = Local currency, then AMOUNT.BOUGHT = BUY.LCY.EQUIV.
If AMOUNT.SOLD = Local currency, then AMOUNT.SOLD = 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 cur-
rency 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.
The formula for calculating this figure is as follows:
Where the following abbreviations are used:
l NP = notional principal

l DA = deal amount
l IR = interest rate
l STV = spot-to-value number of days
l IDB = interest day basis
The figures calculated on the amount bought and the amounts sold are recorded in NOTIONAL.BUY.AMT and NOTION-
AL.SELL.AMTrespectively.
The interest amount associated with each side of the deal is calculated by a simple subtraction:
l IA = interest amount

l NP = notional principal
l 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.
An equivalent value of these interest amounts is recorded in fields EQUIV.INT.BOUGHT and EQUIV.INT.SOLD. Because the entire difference
in BUY.LCY.EQUIV and SELL.LCY.EQUIV is attributable to forward discount or premium implied by the difference in interest rates, it follows
that same 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
FOR - 966,770.81 USD + 644,513.88 GBP
AGAINST + 644,513.88 GBP - 966,770.81 USD
Dealer Desk 02
FOR - 970,716.71 USD + 2,135,576.77 DEM
AGAINST + 2,135,576.77 DEM - 970,716.71 USD
Note that the signs follow the accounting conventions.
Under the interest/hedged revaluation method, the local equivalent amounts that are positioned on each side of the deal are identical at the out-
set 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.SOLDis 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:
l A Credit to Interest Received Exchange for the currency bought.
l A Debit to Interest Paid Exchange for the currency sold.
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:
l DAA = daily accrual amount

l NPA = notional principal
l IR = interest rate
l IDB = interest day basis
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 state-
ment entries will be generated i.e. the liquidation of the EXCH RES ADJUSTMENT account, which was used for the accruals. This sup-
plementary 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
andSELL.LCY.EQUIV of the contract) and from then on (i.e. value date) will be revalued within the Asset/Liability revaluation process.
Rebate Revaluation (RB)

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).
Rebate revaluation types use the MID.REVAL.RATE found on the CURRENCY table by default. The system can be made to use REVAL.RATE
in the CURRENCY table instead of MID.REVAL.RATE for calculating the Revaluation Rate, by inputting a value YES in the field REVAL.RATE
on the REVALUATION.PARAMETER for RB Method. If there was no value entered in REVAL.RATE, then the MID.REVAL.RATE for that
CURRENCY will be used.
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.RATEStable), the user can still choose between 3 methods to find the forward rate applicable to each
forward contract i.e.:
l Interpolation
l Next Available rate
l 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 indi-
cate the Rebate Revaluation method.
Assume also that we have the following Spot and Forward rates loaded on the CURRENCY and FORWARD.RATES table.
SPOT GBP/USD = 1.50
SPOT GBP/DEM = 3.30
FWD 6MTH GBP/USD = 1.48
FWD 6MTH GBP/DEM = 3.24
Deal 1
(Spot Rate) (1.50)
Value Date 6 Months
Dealer Desk 01
Revaluation Type RB
BUY LCY AMT - 675,675.68
Deal 2
(Spot Rate) (2.20)
Value Date 6 Months
Dealer Desk 02
BASE Currency USD
Revaluation Type RB
BUY 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:
It is always the local currency amount [bought or sold], which will be used to generate the local currency value in BOTH fields
BUY.LCY.EQUIV and SELL.LCY.EQUIV.
The BASE amount of the contract will be converted at contract FORWARD.RATE and the forward rate of the other currency (non-base cur-
rency) to generate the local currency value in BOTH fields BUY.LCY.EQUIV and SELL.LCY.EQUIV.
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
FOR - 1,000,000.00 USD + 675,675.68 GBP
AGAINST + 675,675.68 GBP - 1,000,000.00 USD
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
Note that the signs follow the accounting conventions.
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 either the MID.REVAL.RATE or the REVAL.RATE
on the CURRENCY table (according to the configuration in the field REVAL.RATE in the REVALUATION.PARAMETER table for the
APPLIC.ID “FX.RB”) 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:
GBP/USD: - 175 PIPS (Discount on the GBP)
GBP/DEM: - 700 PIPS (Discount on the GBP)
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 cur-
rency 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 per-
formed 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.
R ounding R ule
A Rounding Rule can be specified in the FX.PARAMETERS file.
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.
FX.PARAMETERS with ROUND.UP specified.
In the EB.ROUNDING.RULE application other rounding types can be defined.
Rounding rules are defined in the ROUNDING.TYPE field.
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.
C ha r ge s a nd C om m is s ions
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 is used to define commission groups. The COMM.GROUP.ID field on a SEC.ACC.MASTER record identifies the
FX.COMM.GROUP for a portfolio.
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 per-
centage 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
Linked Commission Groups

The Forex spread can also be expressed as a percentage of the FX commission of another group, by using the GROUP.LINK field.
For example, FX.COMM.GROUP 1 is set up like this:
COMM.CCY USD
START.AMOUNT 0
SPREAD 0.6
GROUP.LINK 2
END.AMOUNT
SPREAD 0.5
GROUP.LINK 2
FX.COMM.GROUP2 is set up like this:
COMM.CCY USD
START.AMOUNT 0
SPREAD 0.04
GROUP.LINK
END.AMOUNT
SPREAD 0.01
GROUP.LINK
The amount is 120,000 USD, using commission from FX.COMM.GROUP1. The commission rate is 50% of 4% – that is, 2%.
D a te C a lc ula tions in For e x
Sta nda r d Spot D a te C a lc ula tion
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
Holidays
Using the common holidays (Comm) 2 working days gives a spot date of 5 th July.
The SPOT.DATE, VALUE.DATE.BUY and VALUE.DATE.SELL would therefore be 5 th 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 lte r na tiv e Loc a l C ur r e nc y FX H olida y s

There may be cases where an alternative holiday table is required for FX trading in the local currency. A possible scenario is described as fol-
lows:
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 5 th July (holiday in UK) are working days in the system so that the New York users can work on 5 th July.
If a FX deal were done involving GBP and USD on 2 nd July as in the previous example a spot date of 5 th July would result. This date should
not be defaulted in practice, as 5 th 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
Local Currency GBP Local Country GB (defined in COMPANY)
Spot Market 2
System Date 2nd July Spot Deal USD/GBP
Holidays
(Note that GB00 is shown for information only).
The common holiday table between GB99 and US00 now give the correct spot date of 6th July.
Spot B a s e C ur r e nc y
Some Banks and markets operate on the principal that Spot Dates should always fall on a working day in a certain currency, e.g. USD, even if
the deal does not involve that currency. This method of spot date calculation, referred to as the SPOT.BASE.CCY, is controlled by the field of
the same name in FX.PARAMETERS.
Spot Base Currency.
If this mode of date calculation is used the following rules are followed:
Deal Involves SPOT.BASE.CCY
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 cur-
rencies after this date
Deal does not involve SPOT.BASE.CCY
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.
Both sides of the deal are SPOT.BASE.CCY
A common working day is obtained for both currencies.
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 9 th July as 2 common working days would be taken between US
and GB.
Example 5
Deal GBP/CHF on 2nd July
Neither currency is a SPOT.BASE.CCY so a common spot date is obtained for GB/CH:
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:
Common Spot GB/CH is 9th July
In US 9th July is a working day.
If the same deal were entered on 3rd July using the standard calculation would also result in a spot date of 9th July.
C LS for Thir d Pa r ty Se r v ic e s
CONTINUOUS LINKED SETTLEMENT (CLS) allows banks to eliminate Foreign Exchange Settlement Risk. Sold or bought currencies are set-
tled on a “payment versus payment” (PVP) basis – simultaneously and irrevocably – ensuring that the principal of each counterparty is pro-
tected.
The field CLS.CCY in Currency needs to be set to YES to indicate participation into CLS.
A CURRENCY record with CLS.CCY set to YES.
The field CLS.CPARTY in CUSTOMER needs to be set to YES to identify a CLS participant.
A CUSTOMER record with CLS.CPARTY set to YES
A valid FX.CLS.CPARTY record needs to be established per counterparty detailing the CURRENCY and Nostro accounts to be used for CLS net-
ting.
A FX.CLS.CPARTY record for GBP and USD currencies.
The field CLS.DEAL in the FOREX contract defaults to YES, if a valid FX .CLS.CPARTY table has been established which has matching CUR-
RENCY fields.
FOREX contract with CLS.DEAL defaulted to YES.
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.CP-
ARTY 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 iden-
tifiable.
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
Ge ne r a tion of MT2 0 2 m e s s a ge s for N os tr o
The field NOSTRO.202.MSG in application FX.TRANSACTION.TYPE can be used to control whether a MT202 SWIFT message is generated
when a trade is transacted directly with the banks own Nosto agent.
FX.TRANSACTION.TYPE with OVERRIDE and a setting of YES.
A value of NO or NULL will suppress the MT202 SWIFT message, a value of YES will always generate the SWIFT message.
Delivery Overview
Non-Deliverable Forwards
ND.DEAL is the application that is used to enter transactions.
An NDF contract input screen consists of 3 major parts:
• 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), Counter-
party, notional rate and buy/sell. Almost all elements of NDF transactions, except the key information mentioned, have default values.
A typical NDF Contract screen.
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.
Fix ing tr a ns a c tions
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.
Pr ofit a nd Los s c a lc ula tion

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 cur-
rency.
For a Vanilla Buy contract
Settlement amount = Fixed amount – Notional settlement amount.
For a Vanilla Sell contract
Settlement amount = Notional settlement amount – Fixed amount
For an Exotic transaction, which is fixed before a recognised fixing date, the discount factor will be applied to the Settlement amount field SET-
TLEMENT.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.
For an Exotic contract
Settlement amount = Settlement amount * discount factor where discount factor is 1 / (1 – r)t.
r is annual interest rate and t is time in a year
U nfix e d N D Fs
Potential exposure amount field NOTIONAL.SETTL.AMT will be used to decrease the customer limit.
Fix e d N D Fs
Once the deal is fixed, there will be no more exposure. In other words, the customer’s limit will be reinstated.
Sa m ple N e tting
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 first contract.
Input contract 2 for Sell HKD 1,000.00 and Buy USD with the same counterparty, same value date as the first contract.
Input second contract.
The current available limit for customer 95003 HANG SENG BANK is $500 and two equal and opposite deals take place for the same counter-
party, 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.
N D F B a la nc e s
The ND.BALANCES file is a read-only file, automatically updated and maintained by T24. For each NDF contract there will be two separate rec-
ords 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:
• contract status - OPE, FIX, MAT or REV.
• exposure - value date, buy / sell currencies and amounts.
• settlement - settlement date, pay currency, PL amount and discount (if any).
• accrual - (amortisation) to date.
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.BALANCESfor contracts when the deal eventually falls due (with MAT status).
Pos ition Ma na ge m e nt
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.
PM.PARAMETER with ND added.
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.
NDFXP - PM.POSN.CLASS record.
Ope ning
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
The account will post:
DB FXFWDBUY HKD 1,000,000.00
CR FXFWDSELL USD 129,120.94
Fix ing
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
DB FXFWDSELL USD 129,120.94
CR FXFWDBUY HKD 1,000,000.00
DB Customer Acct USD 4.212.39
CR NDF-PL USD 4,212.39
A m or tis ing
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:
DB FXFWDSELL USD 129,120.94
CR FXFWDBUY HKD 1,000,000.00
DB NDF-PL USD 4,120.94
CR NDF-PL USD 4,107.20
CR NDF-TAKEN USD 13.74
Amortised during COB for 10 days:
DB NDF-TAKEN USD 1.374
CR NDF-PL USD 1.374
A c tiv itie s
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.
EB.ACTIVITY records for NDF.
Activity records attached to ND.PARAMETER.
C la s s e s
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.
The message class attached in ND.TYPE.
A dv ic e s a nd Pa y m e nt Me s s a ge s
After the NDF deals have been fixed and authorised, the system invokes the generation and delivery of any required pay/receive instructions
(depending on the message type and class attached in EB.ADVICES in accordance with activity). The following message types are supported:
List of Delivery messages supported by NDF
SWIFT Type Description
103 Bank Transfer –Client
202 Bank Transfer –Bank
210 Advice to receive
900 Confirmation of Debit
910 Confirmation of Credit
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.
FOR EX pos ition by da te (FX.B Y.D A TE)

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
Forex Position by date enquiry.
FOR EX B r ok e r D e a ls (FX.EN Q.B R )

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
Forex Position by broker enquiry.
FOR EXTr a ns a c tion de ta ils (FX.EN Q.SU MMA R Y)

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
Forex Transaction details.
FOR EX Tr a ns a c tion de ta ils (FX.EN Q.H ISTOR Y)

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
Forex Transaction details (FX.ENQ.HISTORY)
FOR EXPos ition C ur r e nc y A ga ins t C ur r e nc y (FX.GA PS)
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.
CCY.SELECT
CCY.CCY
MARKET
Forex Position Currency Against Currency (FX.GAPS)
N OSTR O Pos itions (N OSTR O.POSITION )

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
Nostro Positions (NOSTRO.POSITION).
N OSTR O For wa r d B a la nc e s (N OSTR O.FWD .B A L)
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
NOSTRO Forward Balances (NOSTRO.FWD.BAL).
FOR EX pos ition m ov e m e nts for toda y (POS.MVMT.TOD A Y)

This ENQUIRYdetails 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
FOREX position movements for today (POS.MVMT.TODAY).
N on D e liv e r a ble For wa r ds – Lis t of N D D e a ls e nte r e d toda y - (N D .TOD A Y)
ND deals today (ND.TODAY).
N on D e liv e r a ble For wa r ds – Lis t of N D de a ls fix e d toda y - (N D .FIX.TOD A Y)
ND deals fixed today (ND.FIX.TODAY).
N on D e liv e r a ble For wa r ds – Lis t of N D de a ls due for fix ing- (N D .EOD .FIXED )
Deals will be included in the enquiry, on the basis of set up in the fields FIXING.REP.DAYS (for Vanilla Deals) and OPTION.REP.DAYS (for
Exotic Deals) in ND.PARAMETER
ND deals due for fixing (ND.EOD.FIXED).
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 avail-
able 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 spec-
ification 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:
Ov e r a ll For e ign Ex c ha nge Lim it

Each deal is monitored against the overall foreign exchange limit of the respective Counter party to ensure that the bank is not overly exposed
to this specific Counterparty.
C le a n R is k or D e liv e r y R is k Lim it
The clean risk limit is the maximum allowable value of foreign exchange transactions from the same Counter party to mature on any single day.
For example, the bank may be prepared to have an Overall Foreign Exchange limit of GBP 20 Million with a given Counter party, but may want
to limit the delivery risk on any one day to GBP 5 Million.
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.
C ur r e nt e x pos ur e c a lc ula tions for Lim it e nquir ie s

A new method of measuring Credit riskis to calculate the outstanding value of the contract and combine this with an estimate of the likely
movement of the asset (in this case currencies) over a configured timeframe. (This is a rough approximation of Volatility, which is called ‘Poten-
tial exposure’)
This methodology is also known in the market as ‘Current exposure’ which takes account not only the Potential exposure calculated by mul-
tiplying 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:
Credit exposure= Replacement cost/current exposure+ ‘Add-on’
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 can-
celled then the Bank will lose money by having to go into the market and cover the trade at current levels.
You could see this as ‘Profit at risk’ if the client defaults.
Add-on
This is a defined and configured percentage of the nominal (cash transactions) or underlying (option transactions) contract amount. The per-
centage 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).
C onfigur a tion ta ble for s e tting ‘a dd-on’ pe r c e nta ge s

Users can define several different sets of add-on percentages to be stored (for example one set for Regulatory Credit monitoring and another for
Internal Credit monitoring). These different sets of percentages can be configured in the table REVAL.ADDON.PERCEN.
The relevant fields for configuring the percentages in this table are shown below:
ID MODULE.SEQUENCE_NUMBER.METHOD_ TYPE. Where: MODULE = Allowed Modules (currently FX or DX),

SEQUENCE.NUMBER starts at 1 and is ascending, and METHOD.TYPE is either RM for Remaining Time or IN for
Initial Time. (N.B. ‘IN’ is for future use and currently only RM will be allowed.)
CURRENCY.CODE Specifies the CURRENCY to which the percentages specified under TIME.PERIOD would apply. Only required if the
Application is FX
SUB.ASSET.TYPE Not relevant to FX. Specifies the SUB.ASSET.TYPE to which the rates specified under TIME.PERIOD would apply.
Input only allowed if the Application is DX. Either, but not both CURRENCY and SUB.ASSET.TYPE must be pop-
ulated.
TIME.PERIOD Specifies the period for which the following rates would apply for the above-defined CURRENCY.CODE. The format
could be nnnD, nnnW, nnnM or nnnY where nnn>0 or it could be R to specify Rest Period. ‘R’ is mandatory being the
remaining period band (i.e. From the last defined band to ‘infinity’)
REG.PERCENTAGE Specifies regulatory add-on percentage should be greater than or equal to 0 and less than or equal to 100. Either
REG.PERCENTAGE or INT.PERCENTAGE should have a value greater than 0.
INT.PERCENTAGE Specifies Internal add-on percentage. Should be greater than or equal to 0 and less than or equal to 100. Either
REG.PERCENTAGE or INT.PERCENTAGE should have a value greater than 0.
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.
A pplic a tion for r e que s ting C ur r e nt e x pos ur e r e v a lua tion a nd r e por t
The application, FX.CURRENT.EXPOSURE allows users to request a revaluation and report on the credit usage using the new current expo-
sure 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
Revaluation after 3 months @ 1.5300: -£1 million against +$1,530,000.
Bank P/L in local ccy ($) = +$10,000 (profit of $10,000 i.e. Customer is losing money)
Current exposure (Replacement Value) = $10,000
Add-on = £1 million X 1.5300 X 0.02 = $ 30,600
Utilisation = MAX ([$30,600+ $10,000], ZERO) = $ 40,600
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 com-
pared 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 fig-
ure 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.
An explanation of the fields is as follows:
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’, ‘REG-
ULATORY’ 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.TRAN-
SACTION for Current exposure plus add-on, will be used again. The default will be ‘NO’.
A pplic a tion to gr oup For e x de a ls for r e por ting pur pos e s

When a client concludes a FX contract that closes one or several other open position(s) for the same value date, FX module has now been ena-
bled to perform the following:
l To define a “closing” group containing FX contracts closed against each others.

l To produce reports on a portfolio in such a way so as to display groups of closed FX contracts aggregated in a single line, with a cor-
responding realised PL figure. Other FX contracts are displayed normally.
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.

There will be new types of limits generated for NDFs which will separate limits from normal FOREX contracts. The core LIMIT application will
be used to set up new line for NDF.
There will be two scenarios in respect of NDF operations:
N D F Lim it N e tting
The limit netting will be active when all deals are equal and opposite deals, in which case an equal, is defined as follows:
• Value date is the same.
• Counterparty is the same.
• Both currencies are the same e.g:
• Deal 1 BUY.SELL.IND is BUY, deal currency A and settlement currency B.
• Deal 2 BUY.SELL.IND is SELL, deal currency A and settlement currency B.
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.CHANGEshould be set to Y. To disable this func-
tionality 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.PARAMETERSYSTEMrecord.
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:

Since T24 provides a reporting tool for an end user to create there own report at ease, only one sample report is given as a guideline. The
report ND.EOD.FIXED will display unfixed ND deals as on the day of report.
Deals will be included in the report according to the set up in the fields FIXING.REP.DAYS (for Vanilla Deals) and OPTION.REP.DAYS (for
Exotic Deals) in ND.PARAMETER
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 appro-
priate 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:
SWIFT Type Description
300 Forex Confirmation
103 Bank Transfer –Client
202 Bank Transfer –Bank
210 Advice to receive
600 Metals FX confirmation
604 Fund transfer order for metals
605 Fund entry pre-advice for metals
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 cur-
rencies traded is configured as a metal.
Close of Business Services
The Close of Business will process all records contained within the Foreign Exchange System. The processing will include:
l Processing of unauthorised contracts.

l Processing of accruals on Foreign Exchange contracts.
l Revaluation of all contracts for which revaluation parameters have been specified.
l Performance of any scheduled Delivery.
l Closure of completed contracts and the movement to History files.
l Generation of reports.
Non-Stop Processing
Both FOREX application and ND.DEAL applications are 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 BATCHjob 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.P-
ARAMETERStable for SPOT, FORWARD and SWAP.
The following two codes have been predefined:
20000 = SPOT REVALUATION
20001 = FWD REVAL and FWD ACCRUALS
The product category codes used in Spot and Rebate revaluation may be varied using the appropriate fields in REVALUATION.PARAMETERS.
Profit and Loss Category Codes

• Brokerage = 53005
• Marketing Exchange Profit = 53006
Charge and Commissions: as defined on the FT.CHARGE.TYPE and FT.COMMISSION.TYPE.
Accruals - Please refer to the Accounting chart below
Revaluation - Please refer to the Accounting chart below
Transaction Codes
C.R.F. Asset Types Applicable to Forex
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.
Local Currency Equivalent

The rules to calculate the local currency equivalent of the amount bought and amount sold and to convert foreign currency accruals from for-
ward contracts using the 'IN' revaluation method are summarized in the next table.
LOCAL CURRENCY EQUIVALENT - RULES SUMMARY
CONVERSION RATES APPLICABLE ON FCY ACCRUALS - 'IN' METHOD
= Middle Rate from the CURRENCY table
TMR
CSR = Spot Rate from the contract.
BMR = Middle Rate of Base Currency (from CURRENCY table).
TFR = Forward Rate from the FORWARD.RATES table.
CFR = Forward Rate from the contract.
Real Accounting Entries

Statement and Category entries will be raised both during the on-line and the Close of Business process.All these Assets and Liabilities entries
are summarized in the table, which follows. It must be noted that:
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.
Revaluation
Introduction
FOREX module provides the daily revaluation of the Foreign Exchange position, producing a daily profit for each dealer or group of dealers. For-
ward 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. amortization 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).
R e v a lua tion R a te
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. For FX contracts with RB and SP type methods of Revaluation, User has an option
to select either REVAL.RATE or MID.REVAL.RATE. Where the option is REVAL.RATE and the same does not contain a value, system goes
with MID.REVAL.RATE.
All revaluation types except for RB (Rebate) will use the REVAL.RATE field if it is populated. If it is left blank, then the value in
MID.REVAL.RATE field will be used from the CURRENCY table.
However, for both RB and SP type methods of revaluation, the User has the option to select either REVAL.RATE or MID.REVAL.RATE by
doing appropriate set-up in REVALUATION.PARAMETER.
Currency Input
FX Revaluation in T24 is categorized into SPOT and FORWARD based on the period - Revaluation date to Value date.
SPOT c ontr a c ts
For contracts falling within the spot period (contract inputted as a SPOT deal or a Forward contract moving into Spot period), the User has
two options.
1. Common rate for Tom and Spot periods - REVAL.RATE or MID.REVAL.RATE in CURRENCY record as per the set-up in REVAL-
UATION.PARAMETER.
2. Different rates for Tom and Spot periods.
If the User sets the field REVAL.WITHIN.SP in REVALUATION.PARAMETER to ‘YES’, system refers to FORWARD.RATES table, wherein the
Premium/Discount for ON and TOM are defined under the Rest.Period as -2D and -1D. Following is the screen shot of FORWARD.RATES
table.
The method of deriving the Revaluation rate is as follows:
l For TOM positions, the revaluation rate is derived by adding/subtracting the premium (or) discount for Tom Next (TN) (as mentioned
in the Rest.Period -1D) to the MID.REVAL.RATE or REVAL.RATE as the case may be.
l For SPOT Positions, either the MID.REVAL.RATE or REVAL.RATE will be applicable as per the parameter set-up.
l For TODAY’s position (which is essentially AL position), a provision is created to populate today’s rate in the field REVAL.RATE in
CURRENCY record if the User requires. Today’s rate is derived by adding or subtracting the Premium/Discount defined for both ON
and TN (-2D)+(-1D) to the MID.REVAL.RATE. User is required to populate the rate in REVAL.RATE field by a local routine.
l Revaluation results on account of TOM and SPOT positions can be subjected to discounting to find the PV. This is dealt under the
heading ‘Revaluation at Deal Level and at Net Present Value” as per IFRS Accounting.
For wa r d c ontr a c ts
For Forward positions, whose value date is greater than Spot date, the Revaluation rate is derived as below:
l The Forward Premium/Discount is added/subtracted from Spot rate. User can decide whether the Spot rate should be same as
REVAL.RATE or MID.REVAL.RATE. The option is available in REVALUATION.PARAMETER.
l When a Forward position moves into Spot position, it will be dealt with the same way as explained above in Spot Contracts. However,
such positions will be revalued with either REVAL.RATE or MID.REVAL.RATE as defined for RB method.
Se tting of R e v a lua tion Pa r a m e te r s

Revaluation is controlled through a set of parameters that are defined in the REVALUATION.PARAMETER file. The parameters can be spec-
ified at an application level and in the case of FOREX can also be defined for the ‘SP’ – Spot method or the ‘RB’ – Rebate method as illustrated
below.
Revaluation Parameter Input.
Revaluation Parameter Continued.
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 following fields in the REVALUATION.PARAMETER application deliver the functionality as explained below:
a. REVAL.WITHIN.SP (with values ‘Yes’ or ‘Null’) is meant to specify whether the contracts within the spot period have to be revalued at
different rates for TOM and SPOT or not. For Today’s Positions (AL), option is provided to populate the derived rate in the field
REVAL.RATE. If given ‘Yes’, system performs revaluation of Tom and Spot positions with different rates, provided the Forward Rates
table contains the values for TN (Tom Next) bucket.
b. REVAL.RATE (set up with values ‘Yes’ or ‘Null') in the Multi value field Appl.ID as FX.RB and FX.SP, provides an option between
MID.REVAL.RATE and REVAL.RATE.
c. IFRS.DISC.PERIOD (set up with values ‘SPOT’ or ‘TODAY’) provides an option on the discounting period which is either from
TODAY or SPOT date. This field accepts input only when IFRS.REVALUE is set to ‘Yes’. This works independent of the set-up in
REVAL.WITHIN.SP.
R e v a lua tion a t D e a l Le v e l a nd a t N e t Pr e s e nt Va lue

Under the guidelines for International Financial Reporting Standards (IFRS), users may book the revaluation profit or loss for the deal as an
unit at the Present Value by setting up REVALUATION.PARAMETER as shown below:
If the field IFRS.REVALUE is set to ‘YES’, then the re-valuation profit or loss will be booked at deal level after discounting. The discounting
rate shall be obtained from the PERIODIC.INTEREST table key defined in the field IFRS.DISC.RATE.KEY. For further details,refer to the chap-
ter REVALUATION under IFRS.
Posting Style of Revaluation Entries
The system allows for the selection of a POSTING.STYLE for the entries to be raised for revaluation.
The two types allowed are:
1. ‘I/O’ (Input – Output method) - The previous revaluation figure is reversed then re-posted.
2. ‘ADJ’ (Adjustment method) - 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:
Posting only unrealised losses
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.
A c c ounting R ule s in R e v a lua tion

The accounting rules in revaluation has been illustrated with two examples below:
Example 1
Day 1
Prevailing Exchange rates (Multiply figures)
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 of 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.
Revaluation - NDF
To include the NDF contracts in FX forward position and create POSITION records, you need to set-up a REVALUATION.PARAMETER rec-
ord as shown below (this is only a guide line).
Show NDF set-up in REVALUATION.PARAMETER.
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.
RB method of Revaluation uses the MID.REVAL.RATE found on the CURRENCY table by default. The system can be made to use
REVAL.RATE in the CURRENCY table instead of MID.REVAL.RATE for calculating the Revaluation rate, by entering a value 'Yes' in the field
REVAL.RATE in the REVALUATION.PARAMETER table for ND. If there were no value entered to the REVAL.RATE field, then the MID.RATE
for that CURRENCY would be used.
Revaluation Parameter for ND
Revaluation - IFRS
Due to regulatory requirements under International Financial Reporting Standards (IFRS), some users may prefer to reckon the re-valuation
profit or loss on Forex and NDF Deals at deal level rather than at currency level. Usually, such deal level profit or loss is booked at the present
value.
T24 provides that when the field IFRS.REVALUE in REVALUATION.PARAMETER is set to ‘YES’, the system will calculate the deal level profit
or loss by netting the re-valuation profit or loss of each leg in Local Currency and then discount the net amount. The discounting rate will be
obtained from the PERIODIC.INTEREST record for the key defined in the field IFRS.DISC.RATE.KEY in the REVALUATION.PARAMETER
file. The discount rate will be interpolated if no direct rate is available for the value date of the deal. So far as the discounting period is con-
cerned, the field IFRS.DISC.PERIOD in REVALUATION.PARAMETER with permitted values of ‘Spot’ or ‘Today’ provide the following func-
tionality.
l Spot Position : Discounting happens only when the value is set to ‘Today'.
l Forward Position : Discounting period is reckoned from today to Value date if the value set is ‘Today’ . Otherwise, from Spot to
Value date if the value set is ‘Spot’.
Example
If the rate key is ‘10’ and the Local Currency is EUR, then 10EURYYYYMMDD will be the curve used for calculating the discount rate.
Deal Level Profit or Loss
Example: (Cross Currency)
Consider a Cross Currency Forex Deal in CAD and INR. The Local Currency is EUR. CAD 1,000,000 is bought against INR 40, 000,000 and
the Local Currency Equivalent is EUR 702,619.16. The deal is under RB Revaluation Method.
Instead of reckoning the re-valuation profit or loss currency wise, the re-valuation profit will be taken as EUR 54,120.64
Example: (Involving Local Currency)
Consider a FOREX Deal in INR and EUR. The Local Currency is EUR. INR 55, 000,000 is bought against EUR 1,000,000 and the Local Cur-
rency Equivalent is EUR 1,000,000. The deal is under RB Revaluation Method.
Deal Loss is EUR -97,322.50 which will be reckoned as the Deal Loss.
Net Present Value of Re-valuation Profit or Loss
The revaluation profit or loss will be booked to the Profit Loss Account at the Net Present Value. The Net Present Value is arrived at by dis-
counting the deal level profit or loss at the appropriate discount rate for the period either from the Spot Date to the Value Date of the Deal
(only Forward contracts with RB method are eligible) or from Today to the Value date of the Deal (contracts in Spot period are also eligible)
Discounting from Spot to Value Date:
If the Value Date of the deal falls within the Spot Period for the currency pair, then no discounting is done.
Discounting from Today to Value Date:
Deals falling within the Spot period for the currency pair including those Forward contracts with Reval type other than RB are also considered
for discounting.
Basis for Applying Simple or Compound Formula for Discounting.
If the Value Date falls within one year from the Spot Date for the currency pair, discounting will be done under Simple Method. If the Value
Date falls beyond one year from the Spot Date for the currency pair, discounting will be done under Compound Method. This basis is appli-
cable in both the cases where the discounting period is reckoned either from Today or from Spot.
The Spot Date for the currency pair will be reckoned as on run date. The year is always calendar year.
Simple Method
Compound Method
(Where ‘ r ’ is the rate of interest from the PERIODIC.INTEREST Table and ‘ n ’ is the number of days the value date is from the Spot Date as
on run date and 365 is the basis (The basis is as applicable to the Local Currency.)
Forex deals under Re-valuation Method ‘RB’, and all NDF deals only will be subject to discounting.
When the IFRS functionality is turned on, the deals that had been re-valued earlier under regular method will continue to be re-valued as
before. Only the new deals will be subject to the IFRS method of re-valuation and discounting.
Any Option deal that has been once re-valued before the IFRS set-up, will be re-valued as before including any future take downs.
Each leg of a Swap deal will be treated as a separate deal.
Reports
The users are provided with two Revaluation reports as mentioned below:
REVAULATION.NPV.DETS Will give leg wise revaluation figures (for the date and up to the date) and the discounted NPV of the reval-
uation (for the date and up to the date).
REVALUATION.NPV.DEAL Will give deal wise netted revaluation figures (for the date and up to the date) and the discounted NPV of the
revaluation (for the date and up to the date).
IFRS.REVALUE Functionality
Based on the parameterization set up, the following list of options are available in T24 for revaluation and discounting:
a. Revaluation of TOM and SPOT positions at same rate and No Discounting.

b. Revaluation of TOM and SPOT positions at different rates and No Discounting.
c. Revaluation of TOM and SPOT positions at same rate and Discounting period from SPOT date for Forward Position and no discount
option for Spot Position.
d. Revaluation of TOM and SPOT positions at same rate and Discounting period from Today for both FWD and SPOT Positions.
e. Revaluation of TOM and SPOT positions at different rates and Discounting period from Spot for Forward Positions and no discount
option for Spot Position.
f. Revaluation of TOM and SPOT positions at different rates and Discounting period from Today for both Spot and Forward Positions.
Workflow of 'IFRS.REVALUE' based on the parameterization setup

Forex

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Forex

Caricato da

Copyright:

Formati disponibili

Foreign Exchange

(c) Temenos Systems 2013

Multi-rate option contract

This is usually a Non-Bank counterparty contract with the following features:

Non Deliverable Forwards

(c) Temenos Systems 2013

Configuring T24 Foreign Exchange Tables

The following tables have to be set up to enable FOREX to function efficiently.

A typical FX.MARAMETERS record.

l Definition of the 'Spot' default value date.

FX.TR A N SA C TION .TYPE

FX.R EVA L.TYPE

Interest Method (IN)

l GBP 1000 would yield GBP 120 interest.

Likewise, if exchanged (@1.25)

l USD 1425 / 1.2723 = GBP 1120

Using the same example:

Rebate Method (RB)

Indicate your choice on the REVALUATION.PARAMETER table.

Interpolation of forward Exchange Rates:

Straight Line Method(SL)

RESFWDCR Forward deals credit.

RESSWAPCR Swap deals credit.

RESSWAPDR Swap deals debit).

Straight Line Funding Method (SF)

Sample record in CONSOLIDATE.COND

The SYSTEM record consists of the following details:

• A list of currencies allowed for NDF contracts.

• Description of NDF.

• Product Category code.

• An indicator to classify whether it is a Vanilla NDF or an Option NDF.

• Additional data such as delivery activity, currency market, etc.

(c) Temenos Systems 2013

A FOREX Swap Buy (Example 1).

A FOREX Swap Buy (Example 2).

Precious Metals field set to YES.

Example table: Fields in FX for Bullion trades

AVAILABILITY This is the location where the metal is available.

ALLOCATION ALLOC (allocated) or UNALL (unallocated)

FURTHER.IDENT Options TRANSFER or DELIVERY

Example of a Bullion trade to purchase GOLD.

SWIFT MT600 Delivery produced based on the above transaction.

SWIFT MT600 with Sequence B.

Example of a Bullion trade to sell GOLD.

SWIFT MT600 Delivery produced based on the above transaction.

N e utr a lis a tion of for wa r d inte r e s t

Configuring T24 Bulk Orders

OFS can be configured by adding a record called FX.BULK.OFS to OFS.SOURCE:

Edit FX.PARAMETERso that:

Field Content Example

BULK.OFS.SOURCE The OFS.SOURCE record FX.BULK.OFS

BULK.MASTER.VER The FX deal version FOREX,SP.BUY

BULK.CHILD.VER The FX deal version FOREX,SP.BUY

Services can be defined Company wise.

Bulk Order Example

BULK.ORDER.ID FXT0324100001 The 1 st Bulk Order of the 29th August 2003

COVER.BULK.ID Blank Blank

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

50060 Airboure 50060-1 EUR 100,000 Blank BUY Blank Blank

(The counter party to the transaction) (The customer's portfolio)

TOTAL.BOUGHT.AMT 1,200,000 1,200,000 USD bought

TOTAL.SOLD.AMT 1,500,000 1,000,000 + 500,000 = 1,500,000 EUR sold