T3TDX - Derivatives - R15 PDF

T24 Derivatives- T3TDX - R15 1
Introducing participants to T24 Derivatives module.

Learning about linkages with core tables including interest, charges and
commissions.
Learning to set up parameter tables connected with this module.
Learning to input, execute and complete different types of Derivative deals.
Learning about Closeouts and revaluations of Derivative deals.
Using enquiries relevant to this module.

Derivatives are financial contracts, or financial instruments, whose values are
derived from the value of something else known as the underlying.
Derivative module in T24 deals with Futures, options and other exotic
derivative structures.
A Futures contract is a standardized contract, traded on a futures exchange, to
buy or sell a standardized quantity of a specified commodity which, may be
foreign currencies, Bonds, or stock indices or other financial instruments at a
certain date in the future, at a price agreed at the time of trade based on the
instantaneous equilibrium between the forces of supply and demand in the
exchange at the time of the purchase or sale of the contract.
An option is a contract written by a seller that conveys to the buyer the right
— but not the obligation — to buy or to sell a particular asset, such as a piece
of property, or shares of stock or some other underlying security, foreign
currencies, etc. at a price agreed at the time of trade referred as Strike price. In
return for granting the option, the seller collects a premium from the buyer. It
can be exchange traded or Tailor made – OTC contracts.
A Combination of different options of different style and nature forms a
Derivative structure. Tailor made keeping in mind the buyer’s view on the
underlying.
Over The Counter or OTC deals are agreed upon by the concerned parties and

as a result of which a position is created. The buyer of the contract is said to be ‘Long’
in the contract, and the seller to be ‘Short’ when referred to Position. These kinds of
trades give more flexibility and are more customized.

The Dependencies of Derivatives are:
We need to have Customer records before opening Customer type of accounts
We need Accounts to handle various customer type transactions
Delivery is Core in T24 which is closely linked to transactions input through
the module. Predefined messages/advices are generated on authorisation of
transaction . The relevant messages are produced as per mapping and
formatting setup such that details from the field input in transaction are
mapped to the pre defined fields and SWIFT tags. They are sent through
appropriate channels like Print, SWIFT or Telex. The channel or mode of
delivery can be configured system-wide for each message type and also setup
at the customer or account level.
On authorisation of trade, accounting entries are generated.
When an account is debited, system checks for balance in the account. Limit,
if any, sanctioned and attached to the account, is checked for availability of
Limit.
Other than the abovementioned dependencies, Derivatives module depends
also on other Static tables like CURRENCY, HOLIDAY, etc.

The Category codes allocated for Derivatives are in the range 24000 to 24999.
What can be the nature of Foreign Exchange deal?
The Basic deal types of the Derivatives are Futures and Options
Both Futures and Options can be further classified
Futures can be classified as Bond Futures, Currency Futures, etc and similarly
Options may be classified as Stock Options, Currency options, etc

The different types of commissions that can be calculated for Derivatives
transactions are:
Commissions
Execution Fees
Clearing fees
Regulatory fees, and
Miscellaneous fees
FT.COMMISSION.TYPE defines these commissions used for various
transactions in DERIVATIVES application. Commission can be defined as a
flat amount or as a percentage, which varies according to the amount of
transaction. Percentages can be defined for different Bands or Levels of
transfer amounts also. A rate per Lot can be specified when using LOT
calculation type in CALC.TYPE Field. The value entered in the
UNIT.CHARGE Field will be applied for the corresponding amount per lot
traded.
Minimum and maximum commission can be specified for each Band or Level
together with overall minimum and or maximum amounts. Commission can
be defined Currency wise as well. When transaction currency is not defined in
FT.COMMSSION.TYPE, then default is taken from the Local currency or
specified default currency condition and appropriate equivalent amount is

calculated using the rates held on the CURRENCY file. Tax codes can also be
optionally attached.

T24 DERIVATIVES trade input is always double sided, but the account
postings resulting from the trade may well be asymmetric, e.g. the Bank may
pay a certain clearing fee to a broker, but impose a ‘mark-up’ on the fee it
charges to the external customer involved in the trade. ACCOUNT.CLASS
contains the definition of the suspense accounts or profit and loss categories
through which such postings are ‘washed’
Examples of such suspense accounts are
For Initial margin – SUSPDXIMCR and SUSPDXIMDR
For Futures variation margin – SUSPDXVMCR and SUSPDXVMDR
For Options variation margin – SUSPDXOMCR and SUSPDXOMDR
For Charges – SUSPDXCGCR and SUSPDXCGDR

At the time of inputting a Trade, Derivatives makes use of HOLIDAY table to
check whether maturity or other scheduled activity date is a working day or
not. HOLIDAY is used for a Country and region to determine the Spot dates
and value date of contracts. REGION and COUNTRY tables must be already
set up for this purpose.
Derivatives makes use of CURRENCY table to default transaction amounts
using exchange rates specified in this table. CURRENCY.PARAM contains
common details of each currency defaulting in the CURRENCY table.
Derivatives makes use of currency market defined in CURRENCY.MARKET
table .
It is possible to create different market rates for different purposes or different
instruments for the same currency namely separate rates for Notes, Travellers
Cheques etc. Up to 99 markets can be indicated in CURRENCY.MARKET
table.
Consolidation keys for reporting purposes are formed market wise. Markets
beyond 9 will be consolidated with the market type of the first digit, for
example market 10 will be consolidated as 1.

Parameter tables set-up during implementation can be grouped under three
broad classifications.
Derivative module relate general, Product related and customer related.
DX.PARAMETER, DX.PRICE.SOURCE, DX.EVENT.TYPE,
DX.MARGIN.CALC, DX.PRICE.SET and DX.MARGIN.RATES are general
parameter tables.
DX.EXCHANGE.MASTER, DX.CONTRACT.CLASS, DX.STRATEGY and
DX.CONTRACT.MASTER are product related parameters.
Customer related parameter tables include DX.CUSTOMER,
DX.COMMISSION, DX.GROUPING and DX.TRADING.CONSTRAINT.

DX.PARAMETER file is the central point of control for the derivatives
module. It is the top level parameter table. Information from this table either
controls, or is inherited by other applications in the derivatives module. It
should contain the single record SYSTEM, which is read by other applications
in Derivatives and their behavior controlled by the contents. We cannot
parameterise company wise presently. The pre and post End of Exchange
(EOE) processes are defined. It is set up file for special functionalities like
securities blocking, funds blocking, SC.POS.ASSET in DX. We will now
discuss important fields of the DX.PARAMETER file.

MARGIN.DIFFERENCE Field defines how the system should post initial and
variation margins. If this field is set to YES then when a new margin figure has
been calculated, the difference between the previous margin amount and the
new amount will be posted. If this field is set to NO then the previous margin
amount will be reversed and the new margin amount will be posted. Margins
are only posted during the End Of Exchange or the End Of Day processing .
Other re-valuations will report the new margin figures but no postings are
created.
PRICE.TO.STORE Field along with the associated PRICE.DAYS filed
specifies how long the prices should be stored in the system. The prices stored
in the DX.PRICE.SET should be deleted from the system. Unless specified no
prices will be deleted. After the specified number of days, the End of Day
routine will delete the specified price sets. The input to this field must be a
valid DX.PRICE.SET record.
The Derivatives module maintains the input and storage of historical prices,
thus enables the valuation of historical positions by Asset Management
Module. The historical values so calculated for the given positions are
updated in the Asset Management History files for its downstream processing.
For this purpose, existing live file DX.MARKET.PRICE.HISTORY allows
direct input of historical prices. However, records in
DX.MARKET.PRICE.HISTORY file can be changed or created only if the

price set is defined in the DX.PARAMETER and date stamp is within the period
defined in DX.PARAMETER to store historical prices.

SUPPRESS.IM.POST Field is used to suppress the initial margin posting, if
the flag is set to YES. Similarly SUPPRESS.VM.POST is used to suppress the
variation margin (profit and loss) and initial margin.

VM.POST.STYLE Field is used to specify the posting of calculated variation
margin. In addition to the standard method of posting the calculated Variation
margin (P&L Category in the currency of the contract), several other choices
are available.
The choices are PL, PLLCY, PLRP and PLLCCYRP.
If the choice is PL, P&L is calculated in contract currency and posted to P&L
Category specified in DX.EVENT.TYPE "VM" .
If the choice is PLLCCY, P&L is calculated in contract currency, then
converted to Local Currency and posted to P&L Category specified in
DX.EVENT.TYPE "VM" .
If the choice is PLRP, P&L is calculated in contract currency and posted to
P&L Category specified in DX.EVENT.TYPE "VM“. Sign reversed, the
amount is posted to Premium Payment account (maintains "replacement
value").
If the choice is PLLCCYRP, P&L is calculated in contract currency and then
converted to Local Currency and posted to P&L Category specified in
DX.EVENT.TYPE "VM“. Sign reversed, the amount is posted to Premium
Payment account in Premium CCY (maintains "replacement value").

Derivatives module in T24 offers you the choice of two styles in which the
contingent asset/liability can be posted for own-book trading vide the field
CONT.ULYING.VAL .
YES: This option can be used for all trades. Please note the entries for Forex
Derivatives and Other Derivatives.
No: This option can be used for Futures and Options with un-posted premiums.
Please note the entries for Forex Derivatives and Other Derivatives.
The CRF Asset types used are DXFUTBUY, DXFUTSELL, DXOPTBUY and
DXOPTSELL.

Fees: EST.METHOD field is used to specify the method by which the
Estimation and Regulatory fees are calculated. The choice 1 will make the
system exclude the Contract size and a 2 will make it include the contract size.
PRICE.CHECK.SET field specifies the DX.PRICE.SET record that will be
checked to ensure that all the prices required for the end of exchange
revaluation have been updated. The Input to this field must be a valid
DX.PRICE.SET record. When the end of exchange process is started, prices
defined in this field which is required for revaluation, but which are not
present or have not been updated on the run date will be listed in a warning
report for any further action.

EOE.PRICE.SET Field specifies the default DX.PRICE.SET record that will
be used for the end of exchange process. When the end of exchange process is
started this will be the default price set to use, for revaluation. However it may
be overridden.
Revaluation can be run online as well. So the field ONLINE.PRICE.SET
specifies the default DX.PRICE.SET record that will be used when an on-line
revaluation process is run.

USE.MARGIN.ACCT Field specifies if the initial and variation amounts
should be posted to a separate “Margin" account or to the Customers "normal"
account. A YES would mean that all initial and variation margin postings
created by an End Of Exchange or End Of Day revaluations will be posted to
the Margin account specified in the associated MARGIN.ACC.CCY and
MARGIN.ACCOUNT fields in the application DX.CUSTOMER. If this field
is set to NO then the initial and variation margin amount will be posted to the
normal customer accounts. Posting the margin to a separate Margin account
facilitates the use of the maintenance margin so as to reduce the payments
required by a customer.

Blocking: BLOCK.AUTH Field is used to control whether the blocking of the
Security position happens during the Authorised or the Unauthorised stage. If
set to YES, it will facilitate the position blocking during authorisation. If set to
NO, blocking of securities happens while committing the record. Whether it is
YES or NO, a record is created in authorised stage in SC.BLOCK.SEC.POS.
Limits: LIM.AMT.VAL.CONT Field specifies which value associated to a
trade will update the Limits. The choices are CONTINGENT and VALUE.
The choice CONTINGENT calculates a value for the trade by multiplying
value specified in CONTINGENT.VALUE Field in
DX.CONTRACT.MASTER with number of lots.
The choice VALUE will calculate limit in the following manner:
For Futures the limit is number of lots * internal price
For the buyer side of Options the limit is number of lots * internal price
For the seller side of Options, the limit is number of lots * internal strike
price.

Alternate Name : ALT.IND.NAME Field indentifies the alternate for contracts
in this system like CUSIP, ISIN etc. It is possible to use up to 35 alpha
numeric characters. Once an ALT.IND.NAME has been entered and
committed, it cannot be changed or removed but a new ALT.IND.NAME can
be added. So what can be done if you don’t desire the usage of a particular
ALT.IND.NAME? If you want to restrict the use of a particular
ALT.IND.NAME, then the associated ALT.IND.VAL which identifies a routine
for validating an alternate index routine entered into a contract, can be
removed.
In order to stop an ALT.IND.NAME from being used, for example if CUSIP's
stopped being used in the system then the associated ALT.IND.VAL can be
removed. It is possible to use upto 35 alpha numeric characters.
It identifies a routine used to validate a alternate index routine entered into a
contract. In order to stop an ALT.IND.NAME from being used, for example, if
CUSIP is not being used in the system, then the value in this associated field
can be removed

ORD.ASSIGN.PGM Field is used to select a valid routine which can be tested
using DX.GET.OBJECT. The object should be attached to the application
DX.ORDER
SC.POS.ASSET: SC.ASSET.UPD Field defines how the user requires to
update the SC.POS.ASSET tabe. The choices are firstly Transactional which is
transaction by transaction, secondly Positional which is by Positions and
thirdly BUY.SELL.POS which updates SC.POS.ASSET for total long and
short positions separately.
COST.CALC.API Field holds the name of a valid routine from
DX.OBJECT.LIBRARY which calculates values to be shown in NET.COST
Field in DX.TRANSACTION.
CR.EXP.CALC.API Field is used to store the Credit exposure calculation API
routine, DX.BB.CREDIT.EXPOSURE which should be defined in
DX.OBJECT.LIBRARY. This is used in ASSET MANGEMENT module. If
the Credit exposure calculation is needed, then this field should hold the API
routine DX.BB.CREDIT.EXPOSURE.

By checking YES in ORD.CREATE.TRADES, DX trades will get
automatically created at average price, on the filling of a DX order itself. A
NO would specify the opposite.
You have learnt in an earlier page about close out trades. So to parameterise
automatic Back to back close out trade for derivatives, prevailing over other
applications like DX.CONTRACT.CLASS, DX.CONTRACT.MASTER etc,
you can check B2B.ACTIVE Field as YES.
Further COPY.LOCAL.REF Field is used to control the mechanism which
copies the LOCAL.REF Field on DX.ORDER into the generated records in
DX.TRADE, thereby creating an audit trail. This is irrespective of whether a
trade gets created automatically on the filling of the order or otherwise.

How the system should calculate the average price of a position can be set by
either AVE.PRICE.METHOD Field in DX.PARAMETER or at
DX.CONTRACT.MASTER level in AVERAGE.PRICE Field . The number of
decimal places required can be specified in AVERAGE.DPS Field in the
DX.CONTRACT.MASTER. This average price is shown on reports and
enquires for each specific contract held by a customer.
The choices are:
NORMAL: in which weighted average of absolute value of prices of trades is
used. The weights allotted are by the number of lots traded.
UNWEIGHTED: in which Straight average of absolute value of prices of
trades is used by the number of trades.
PURCHASE: in which Average of buy prices is used which is weighted by the
number of lots traded.
NONE: in which no average price will be calculated. This will apply mainly
for options with deferred premium payments and for futures contracts, as for
these contracts, average price is not applicable.
OPENING: in which Average of buy prices of OPEN trades weighted by the
number of lots traded is used.

You can do the settings to test all the trading restrictions that are created using
DX.TRADING.CONSTRAINT using this CONSTRAINT.FAILURE Field.
The two options available are
SINGLE – As soon as one restriction test failed, the restriction test will
transfer the control to the main application. Ie. It skips further testing
MULTIPLE - Each restriction test that fails will be displayed to the user in
turn, hence if 5 tests fail the user will see 5 error messages. ie. It process all of
them and then displays all the overrides/error messages

The events IN T24 may be like Contract inception, Internal transfer and
Contract Maturity. The application that defines these events in the T24
Derivatives module is the DX.EVENT.TYPE. By default this application does
not come pre-setup as the user must consider the impact of each events setup.
The DX.TRANSACTION table which is a live table recording the transactions
in Derivative module is built with one or more events that have occurred
relating to the Derivatives. For e.g. A futures trade between a broker and the
Bank’s Own book, with execution and clearing commission due at trade input
time would generate two DX.TRANSACTION records, one for the broker and
one for the Own Book portfolio. Each transaction would then be tested and
have the following events assigned:
CI standing for Contract Initiation which triggers posting of contingent
liability for Own-Book portfolio. FC standing for Clearing Fee which posts
clearing fee calculated, to Broker account and P&L category for Own Book
portfolio. And lastly FE standing for Execution Fee which posts execution fee
calculated, to Broker account and P&L category for Own Book portfolio.
The DX.EVENT.TYPE file parameterises features like Transaction codes,
Category codes, etc. for the prescribed event.
CATEGORY code used for posting the entries. This can be either an internal
account category code or a profit and loss category code range depending upon
the type of contract event. A field validation is provided to determine whether

a profit and loss category code to be accepted as an internal account category code.

Let us take an example of a futures trade between a broker and Bank’s own
book with execution and clearing commission due at trade. This would
generate two DX.TRANSACTION records, one for the broker and one for the
own book portfolio. Each transaction would have the following events
assigned.
CI (Contract Initiation) – This event will trigger posting of contingent liability
posting for own-book portfolio.
FC (Clearing Fee) – This event posts clearing fee calculated to broker account
vs. P&L category for own book portfolio.
FE (Execution Fee) – This posts execution fee calculated to broker account vs.
P&L category for own book portfolio.

DERIVATIVES module is able to store multiple prices for any unique contract
traded in the system. The price can be manually entered, extracted
automatically from an external source like Reuters or call a price model
routine and store the returned price. These various sources that Derivatives
takes its price from are defined in the application DX.PRICE.SOURCE.
PROGRAM field specifies the routine that returns the price for a unique
contract, irrespective of how the routine obtains the price, whether as an
extraction from a data file, a link to an external source or as a price calculation
routine. Input must be a valid program name in the PGM.FILE application. It
must exist as an OBJECT.TYPE of "BLACK BOX" for application
DX.PRICE.SOURCE.
If you want to restrict information from any automatic feed, you can use the
UPDATE.AVAIL field. A choice of YES will require a manual update to take
place in the DX.MARKET.PRICE file.

You have now learnt that DX.PRICE.SOURCE defines the source from where
the different prices for Derivatives contracts are extracted. In this page you
will learn about DX.PRICE.SET, which is used for entering or amending these
prices in the Derivatives module.
The Derivatives module is able to store multiple prices for any unique contract
traded in the system. The price sets allows the storage and subsequent
valuation of positions against various different prices. For example, one leg
price can be called "CLOSING" and could be used to store the official market
closing price for exchange traded futures and options. The other leg price can
be called "CURRENT" and could be used to store the latest price a unique
contract was traded for. Valuations for a position can then be performed using
any of these prices sets. Multiple price sets can be created to allow for various
"what if" scenarios. The prices stored can be updated from multiple
DX.PRICE.SOURCE records which can be updated by manual input, internal
calculation routines (e.g. Black & Scholes), external data feed (e.g. Reuters) or
client specific routines.
The DX.PRICE.SET key is used to validate the key of the
DX.MARKET.PRICE records. The Module cannot function without at least
one DX.PRICE.SET being set-up, as the Revaluation and End of Exchange
processing requires that a Price Set exist to revalue the open positions.

After defining prices, it is now the turn of Margins. DX.MARGIN.CALC
allows entry or amendment of margin calculation routines in the
DERIVATIVES module.
The actual margin rates for calculation of initial margin are defined in
DX.MARGIN.RATES on a contract and client basis. The
DX.MARGIN.CALC application holds descriptions of the calculations that
may be used, and points to the PGM.FILE record defining the actual routine to
be called as part of the revaluation process. The PROGRAM.NAME field
defines the routine that will be called from the re-margin process which will
calculate the margins for any contracts that are specified to use this margin
calculation method. The TYPE field defines the type of margin as in INITIAL
(Deposit) margin and VARIATION (Profit/Loss) margin, that will be
calculated by the routine specified in the PROGRAM.NAME Field.

In the previous page itself, you learnt that the rate for the Initial margin
calculation contract-wise and client-wise is defined in the application
DX.MARGIN.RATES. Going further let us see this application in detail.
Though the rates are defined in DX.MARGIN.RATES, the amounts are
actually calculated by Initial Margin routines, controlled by the application
DX.MARGIN.CALC. Since some of these routines require rates to be entered
on which calculations are to be performed, DX.MARGIN.RATES provides
these rates.

Key is made from four separate elements separated by a “–“ (hyphen).
These elements are: A Contract Class from DX.CONTRACT.CLASS,
a Contract Code from the DX.CONTRACT.MASTER,
a Group from the DX.GROUPING and a Customer from DX.CUSTOMER.
This may optionally have an effective date at the end of the key in the form –
YYYYMMDD. I.e. -19- -100163-20090115, this margin rate will become
effective on the 15 January 2009. Only one of contract class and contract may
be entered and only one of customer grouping and customer may be entered.
A few examples:
CU100018 Customer 100018 (CU = Customer Code)
CGINT2 Customer Group INT2 (CG = Customer Group)
CT100 Contract Code 100 (CT = Contract Code)
CCGILTS Contract Class GILTS (CC = Contract Class)
CU100018-CT100 Customer 100018, Contract 100
CU100018-CCGILTS Customer 100018, Contract Class GILTS
CGINT2-CT100 Customer Group INT2, Contract 100
CGINT2-CCGILTS Customer Group INT2, Contract Class GILTS

The RATE.TYPE field defines the type of margin rate to be applied i.e. should
it be a flat rate or a percentage of contract value. It is a mandatory Input.
The FULL Field defines the margin rate to be applied to lots which are not
involved in any spread, spot or straddle calculations. This is also a mandatory
Field.
APPLY.SPREAD.RATE defines whether the system should apply a special
margin rate to the trades that form a time (maturity) spread.

If YES is chosen, the rate input in SPREAD will be applied to the number of
lots involved in a valid spread.
MINIMUM field defines the floor margin amount to be taken on a single trade.

Extension of the core DX functionality with a list of APIs that can be attached
using DX.OBJECT.LIBRARY
Few examples are given below
DX.CO.AM.FIFO - Auto matching of exercise closeouts - matches selected
transactions against least recent opposite positions first
DX.CO.AM.FIFO.DAY - Auto matching of exercise closeouts - matches
selected transactions against today's opposite positions first and then least
recent opposite positions
DX.CO.AM.LIFO - Auto matching of exercise closeouts - matches selected
transactions against most recent opposite positions first
DX.CO.AM.LIFO.DAY - Auto matching of exercise closeouts - matches
selected transactions against today's opposite positions first and then most
recent opposite positions
DX.CO.PGM.NOACTION - 'Dummy' routine to be called on option
closeout/exercise, suppressing the generation of any underlying asset
DX.XO.CREATE.FX - Routine to create a FOREX trade on exercise of a
Derivatives exotic option if the exotic event flag is set.

The order in which these files should be created, in the ascending build
reference order, is given in the left.
The mandatory and optional files are shown by different colour codes.
Wherever there are dependencies to fill up values in the tables in build
sequence, the dependencies are shown on the right.

The role of an exchange in the trading of derivatives cannot be
overemphasized. In T24, the application that parameterises the exchange
where the trading of derivatives is carried on, is the
DX.EXCHANGE.MASTER which sets information about the Exchange like
the name of the Exchange, its address and the region where it is located along
with other characteristics of its processing.

GENERAL INFO: The first few fields in the application gives us an insight
about some general information about the exchange like the name
(GB.SHORT.NAME), the full address (GB.DESCRIPT to GB.COUNTRY)
and the Region where it is located (REGION). The reason why the region is
specified is not only to tell us about the exchange’s geographic location but
also to identify the region within a country where the public holidays differ
from other parts of the Country, thus enabling a separate HOLIDAY table to be
used for this region for delivery purposes. All Exchanges assign codes or
mnemonics to firms or Banks who operate through them, which facilitates
them in the capture and reporting of products traded by the particular
firm/Bank. This identifier is also fed into this application in FIRM.CODE
Field. In the earlier Learning unit, you have already come across the difference
between a normal trade and an OTC or Over the Counter trade. The Exchange
can also be defined as one trading in normal trades or OTC trades by choosing
NORMAL or OTC in EXCHANGE.TYPE Field.

The time when this Premium and charge is posted can be either on the Trade
date or the Settlement date which can be parameterised in PREM.POST.TIME
and CHG.POST.TIME Fields. The Option Premium is payable by the buyer,
following a transaction. The number of Offset days required to post an
accounting entry for this is set in PREM.POST.OFFSET Field. Then the
number of Offset days required if the CHG.POST.TIME is populated with
"TRADE + n“ is set in CHG.POST.OFFSET Field. MAX.MONTHS.FWD
Field sets the available months forward to trade set by the relative exchange.
The default value is OPEN which gives infinite months forward for the
contracts. The number of days after close out/maturity of contracts on this
exchange that posting of the realized P&L should take place is set in
SETT.POST.OFFSET Field.

The numeric entry for the number of Offset days is required to post an
accounting entry is defined in PREM.POST.OFFSET
Calculation of margin for certain exchanges can be defined using
NETT.GROSS Field
There are two options to choose from
1.Nett
2.Gross
The default value is Nett

VAR.MARGIN.CALC field is a valid record in DX.MARGIN.CALC with
margin type as variable.
At the end of each trading day, open positions are revalued against the day's
settlement price, using the 'mark to market' process.
The profit and loss calculated in this revaluation is known as variation margin.
94.15 - 94.20 = 0.05
5 Ticks @ 12.50 per tick = 62.50 Profit. It will default from
EXCHANGE.MASTER if Null.
INIT.MARGIN.CALC field defines the deposit required by the clearing-house
from clearing members as protection against default on futures or options
contracts that they trade. This must be a valid record in DX.MARGIN.CALC
with MARGIN.TYPE as "INITIAL".

SETT.ALLOWED is used to confirm business traded on this exchange is
allowed to settle/close out with another contract or left open as a held position.
SETT.POST.OFFSET is the number of days after close out/maturity of
contracts on this exchange that posting of the realized P&L should take place.
e.g. Euro BUND Futures, Last Trading day = 2 exchange trading days prior to
Delivery DAY of the relevant delivery month

The purpose of REGION table is to segregate a Region within a Country
where the public holidays differ from other parts of the Country.
This enables a separate HOLIDAY table to be defined for the Region, to allow
delivery to be controlled within the T24 system
The REGION must exist within the REGION application. Multiple exchanges
may exist within the same REGION. Must be unique for each
DX.EXCHANGE.MASTER record.

TRADING.OPEN Field defines the Open trading time of the exchange as
listed by contract according to the trading sessions.
Multi-value field and set for multiple trading sessions, part of
TRADING.CLOSE, EXCHANGE.SESSION and EXCH-MNEMONIC
The available months forward to trade according to the contract specifications
set by the relative exchange Open is suggested for this field as in
TRADING.CLOSE Field is the Closing trading time of the exchange as listed
by contract according to the trading sessions.
Multi-value set for multiple trading sessions, part of TRADING.OPEN.
MAX.MONTHS.FWD Field define the available months forward to trade
according to the contract specifications set by the relative exchange
Open is suggested for this field as in CONTRACT.MASTER this field is
populated to the contract specification related to the Contract.

DX.CONTRACT.MASTER is the main application that defines the
characteristics of future, stock or option contracts that can be traded in the
Derivatives product. The most basic contract information like name,
mnemonic, exchange on which the contract is traded, type of contract, price
related information, contract size information, maturity date validation and key
contract dates. The CONTRACT.TYPE may be FUTURE or OPTION.

Information already defined in DX.EXCHANGE.MASTER
PREM.POST.TIME
PREM.POST.OFFSET
CHG.POST.TIME
CHG.POST.OFFSET
SETT.POST.OFFSET
GEN.DATA.NAME
TRADING.OPEN
TRADING.CLOSE
SETT.ALLOWED
VAR.MARGIN.CALC and INIT.MARGIN.CALC are defaulted from
DX.EXCHANGE.MASTER but can be overridden to apply special margin
calculations to individual contracts.

The general information about the Description, Short name, etc. is shown in
the first few fields. In this table, the field EXCHANGE.CODE is the code
provided by the Exchange to the Derivatives Contract for clearing and
reporting purposes. The EXCHANGE Field used to set the Exchange where
the contract is traded and it should point to a valid record from the
DX.EXCHANGE.MASTER.
Whether the contract is a Future or an Option is decided by the field
CONTRACT.TYPE and the type of instruments being traded on the relative
exchange like Bond or Precious metals is defined in the field
CONTRACT.CLASS.

SUB.ASSET.TYPE identifies the group of like Contracts, which are reported
together. The field is validated with a record in SUB.ASSET.TYPE which in
turn is linked to ASSET.TYPE . ASSET.TYPE interfaces to the DX module
for the purpose of valuation.
Delivery method for specified contract at maturity
CASH – Net settlement of the profit/loss
PHYSICAL - Physical delivery of underlying instrument
NONE - No delivery method specified (defaults to NONE)
DELIVERY.CURRENCY field is the currency to be delivered on maturity of
the contract.

MULTI.FACTOR is the price multiplication factor. It defaults to 1 if null.
Example: LIFFE 3 Month Short Sterling contract price quoted referring full
years interest- MULT.FACTOR = 0.25
PRICE.BASIS field is the basis on which the price for this contract is quoted.
The choices are INTEREST or NORMAL. e.g. 3-month Short Sterling; 100-
Libor rate = Quote Price, therefore is interest rate based.
The default value is normal.
PRICE.DPS field provides the number of decimal places for the price quote.
This also changes the number of decimal places in the multi-value set of Price
Band. Reformat the other prices e.g. PRICE BAND.

PRICE.SCALE field define the scale of which the price is denominated in.
ie. Decimal prices are in 100's. e.g. Short Sterling Future 94.59 Fraction's
could be in 32
PRICE.UNIT field is the unit of measure relative to which the price is quoted.
Example Lots
PRICE.BAND field works in conjunction with Tick Size, Tick Value, and
Minimum Price Movement. Some contracts are subject to a price band,
specified on the contract specification set by the relative Exchange. An
example of price band contract is the 3 Month Short Sterling Option.
<7(not equal too) price units the Tick Size is 0.01, Tick Value is 12.50(6.25 1/2
tick) and the minimum price movement is 0.005
>7 price units the Tick Size is 0.01, Tick Value is 12.50 and the minimum price
movement is 0.01
This equates; the movement up to 7 price units will be per half tick and above
7 price units per one tick.

TICK.SIZE field is the amount that the exchange has defined as being 1 tick. A
tick used to be the minimum movement in the price of a contract. This is no
longer the case as half tick (and other) contracts have been modified or
introduced. To avoid potentially infinitely small price fluctuations, the relative
exchange limits the minimum amount by which prices may change
TICK.VALUE Field is the resultant change in the value of a contract by a
movement of 1 tick in the price. Derived from the "Tick Size" is the "Tick
Value". Since the contract has a fixed size the smallest price movement can be
given a monetary value
MIN.PRICE.MVMT is the amount by which prices may change. To avoid
potentially infinite small price fluctuations, an exchange limits the minimum
amount by which prices may change. The tick size of a 3-month Short Sterling
Contract is 0.01; therefore the quote will change by 0.01 tick.
e.g. 93.95, 93.96, 93.97 and so on. The minimum price movement does not
necessarily move by the tick size, as half and quarter price movements are
practiced in the markets of today.

If the price input on a trade is more than the PRICE.TOLERANCE percentage
different to the latest input market price, an override will be raised at trade
entry. So, if the market feed is not available it will take the last known market
price. First, the basis on which the price is to be calculated is defined in
PRICE.BASIS Field which can be Normal or Interest. For e.g. if you want the
Quote price to be 100-LIBOR, the basis is Interest. Then the unit of measure
relative to which the price is to be quoted is set in the field PRICE.UNIT like
LOTS and the unit in which it is measured is set in UNITS.OF.MEASURE.
The scale of which the price is denominated in is set in PRICE.SCALE Field.
The number of decimal places for the price quote is defined in PRICE.DPS
Field. Some contracts are subject to a price band which is defined in
PRICE.BAND Field working in conjunction with the Tick Size, Tick Value,
and Minimum Price Movement.

The Derivatives module provides as much flexibility as is practical in the main
contract set-up application DX.CONTRACT.MASTER when it comes to
setting up pricing information. However this is limited to the case where the
tick size and/or value for a contract is constant within a price band. The
module provides an API hook for routines that will use exchange- or client-
sourced algorithms to calculate internal prices in the Derivatives module for
‘non-standard’ contracts. Typically these would be contracts where the tick
size and/or value varies continuously with the external price according to the
algorithm used. As most of the calculations are similar for every transaction
and price, T24 holds a figure called the “Internal Price”. This is:
IP = QP / TS * MF * TV. (IP = Internal Price, QP = Quoted Price, TS = Tick
Size, MF = Multi Factor, TV = Tick Value). This greatly simplifies and speeds
up the calculations of the other figures.

T24 Derivatives uses a range of keywords, codes and modifiers to represent
the exchange rules when determining the dates. For e.g. MO for Monday, TU
for Tuesday, WE for Wednesday, M for Month, W for Week, CD for Calendar
days, etc. Let us look into the various field related to dates in the
DX.CONTRACT.MASTER.
MAT.MONTHS field holds maturity/Delivery months set by the Exchange to
meet the needs of the underlying cash market. MATURITY.TYPE field is the
contract maturity type as set on the contract specifications by the relative
exchange which can be either DAILY, MONTHLY or OTHER

AVAIL.PERIODS Field holds the number of months available for trading
e.g. LIFFE Cocoa Futures - maturity on March, May, July, September,
December cycle such that 10 trading months are available:
AVAIL.MONTHS = 10
MONTHS.FORWARD = OPEN
MATURITY.MONTHS = 03,05,07,09,12
MAT.MONTHS Field holds maturity/Delivery months are generally set to
meet the needs of the underlying cash market. A traded contract has a specified
delivery month set by the relative exchange within the contract specifications.
This field is used to populate the said month for that period.
The drop down menu allows the choice of numeric (1-12) or alpha ALL to
populate this field. The numeric of 1-12 represents the twelve calendar
months. e.g. 3-month Short Sterling :
March, June, September, December and two serial months, such that 22
delivery months are available for trading, with the nearest 3 delivery months
being consecutive calendar months. This equates to, trading 3 months
consecutively and then quarterly up to 22 periods.
MATURITY.TYPE Field is the contract maturity type as set on the contract
specifications by the relative exchange. MATURITY.TYPE is part of the setup
for trading periods on a contract specified to the relative exchange. This field
works in conjunction with AVAILABLE PERIODS, MONTHS FORWARD,
MATURITY MONTHS AND MATURITY DAYS.

LAST.TRADE.DATE is the last day on which trading can take place in a
particular delivery month for a given contract. This will generally relate to a
particular business day in the month and not necessarily the last day of the
month. LAST.NOTICE is the day on which notice can be given that physical
delivery is intended or expected on a futures contract. FIRST.DELIVERY is
the delivery date which for cash settled contracts is known as the 'final
settlement day'. You have to remember that for Options, once the option is
exercised, unless cash settlement applies, the delivery day is the day on which
the underlying instrument must be delivered. LAST.DELIVERY is the last day
delivery can take place.

DEC.DATE gives the Last Date by which a customer can exercise an option.
OVR.YEAR.MONTH Field allows the use of a manual input date to override
the date formula given in fields like LAST.TRADE, FIRST NOTICE, etc. This
is a multi-set field including OVR.LAST.TRADE, OVR.FIRST.NOTICE,
OVR.LAST.NOTICE, OVR.FIRST.DLV, OVR.LAST.DLV,
OVR.SPOT.DATE, and OVR.DEC.DATE.

A standard formula must be input to allow T24 to automatically calculate
various events during the life of a contract e.g. First Notice day, Last trading
day etc. The Exchange presets the conditions for the various ‘events’ and as
one contract expires it is automatically replaced by the next contract in the
sequence date structure.

Keyword Meanings
MO (Monday) TU (Tuesday) WE(Wednesday) TH (Thursday)
FR (Friday) SA (Saturday) SU (Sunday)
Maturity Period will be after the last trade date. Last Business day is based on
the Maturity Date not the TRADE.DATE
The following are only valid with multiplier/operator in same field
M (Month) W (Week) CD (Calendar days) BD (Business days)
LBD (Last business day of the month)
LCD (Last calendar day of the month)
FBD (First business day of the month)
FCD (First calendar day of the month)
MF*(Move forward) If the date obtained is not a business day,
the move forward until a business date is found.
MB*(Move backward) If the date obtained is not a business day,
then move backwards until a business date is found.
CAL*(Calendar Date) Return the date obtained, even if it is not a business
date.

VAR.MARGIN.CALC Field is defaulted from the EXCHANGE.MASTER if
not populated. Since Variation margins are always calculated contract-wise,
this field will be contract specific.
INIT.MARGIN.CALC Field is defaulted from the EXCHANGE.MASTER if
not populated and it is used for the initial margin calculations.
UNDERLYING Field is the underlying asset upon which a futures or options
contract is based.
For margining and reporting purposes, the contracts can be grouped together in
the application DX.CONTRACT.CLASS along with the product category for
accounting.
These may be a specific instrument, as in the case of stock options, or maybe a
notional instrument, as in the case of the Euro Bund futures.
In the case of many Options, such as the Long Gilt and Euro Bond options on
LIFFE, the underlying instrument is a corresponding futures contract.
This field requires to be set as 'OTHER' for Interest rate Caps, Floors and
Swaptions
If underlying is cash Delivery currency field is mandatory . Input must be a
valid record on either DX.CONTRACT.MASTER or SECURITY.MASTER,
or 'CASH' or 'OTHER‘.

OPTION.STYLE field provides the rule of settlement of an option according
to the type populated in this field, choose from the drop down menu:
AMERICAN; An option that may be exercised at any time prior to its expiry
date
EUROPEAN; An option that may only be exercised on its expiry date.
CARRIBEAN: A type of option that can only be exercised on predetermined
dates, usually every month.
IP = QP / TS * MF * TV. (IP = Internal Price, QP = Quoted Price, TS = Tick
Size, MF = Mult Factor, TV = Tick Value)
INT.RATE.CONTRACT field is to differentiate, whether this is an Interest
rate based contract or a normal contract.
LIFE.UNDERLYING field specifies the original life of the underlying of this
contract in days ,or months or years
This field is inputtable , only if the
INT.RATE.CONTRACT , DX.CONTRACT.MASTER Should be specified in
number of days or months or years. Eg :- 20D, 5M, 2Y and so on
ALT.IND.NAME field identifies a list of possible alternate Id Names that can
be used to identify this contract in the system.

ALT.IND.ID Field is Alternate Index Id related to the listed ALT.IND.NAME.
The contents of this field will be validated against using the routine identified
in the DX.PARAMETER record when the list of ALT.IND.NAMES is taken
from.
CONTINGENT.VALUE Field is the value per lot to be used in calculating the
off-balance sheet liability/asset posting to be made when contract traded.
If left blank, system will use 'contract value' i.e. internal price per lot to make
posting.

The ASSET.TYPE is classified as Futures and Options.
The SUB.ASSET.TYPE represents the type of future or option (e.g. Currency
Future or Bond Option)
DX.CONTRACT.MASTER is used to define the contract type which is further
classified to specific instruments like Bond Futures, Currency Options etc.
Using DX.CONTRACT.CLASS
DX.MARGIN.RATES used to allow initial margin rates entry for various
trades
DX.EXCHANGE.MASTER is used to define exchanges in which the trades
can be done
DX.MARGIN.CALC is used to define the method for initial and variation
margin calculations

DX.CONTRACT.CLASS defines groups of contracts for margining and
reporting purposes. It also stores the product category relating to the contract
class that is passed to the accounting application.
It is used to define commission and margin classes. The CATEGORY.CLASS
Field defines the product category code for contracts in this group. Must be
valid entry in the category application.
O.BUY.CALL, O.BUY.PUT, O.SELL.CALL, O.SELL.PUT fields are used to
define the product category. These are multi value fields.

No activity in the DX module is possible for any customer type, unless defined
in DX.CUSTOMER.
Specific information required for trading derivatives information must be
entered for each customer that will be used in the Derivatives product.
The application DX.CUSTOMER acts as a supplement to the main
CUSTOMER application to record this information. The customer could be
“Customer”, “Broker”, “Counterparty” “Dealer” or, “Exchange”. Customer
and Dealer are equivalent and are simply for reporting purposes.
Counterparty, Exchange and Broker are also basically equivalent and are
separated for reporting purposes. However, these three customer types have
significance for margining purposes. As the DX module is double sided for
every buy or sell by a customer/dealer, the equal and opposite position is held
for with a broker, dealer or exchange. Therefore when initial margins are
calculated by the system, all positions held by brokers, counterparties and
exchanges will be reversed, therefore ensuring the margin results are
calculated correctly and maybe reconciled. Brokers and exchange customer
types are not expected to have portfolios when trading. The Customer and
Dealer types represent the majority of the Bank’s clients and own-book
trading, and must have SEC.ACC.MASTER portfolios set up before trading.
Finally, the Exchange type customer is used solely when associated with a
DX.EXCHANGE.MASTER record and is used to hold the exchange’s

positions when trading direct with the exchange.

CUSTOMER.TYPE Field illustrates the capacity in which a client is acting. A
client may well act in one of these capacities. Only 'CUSTOMER', 'BROKER',
'COUNTERPARTY‘ and 'EXCHANGE' may be entered. CUSTOMER would
either Own-book or a customer of the bank. BROKER someone who executes
or clears trades on behalf of the bank/customer. Broker does not require any
portfolio. COUNTERPARTY is used in the same way as Broker although
portfolio's can be set-up. EXCHANGE if an Exchange member then the
Exchange on which the user has membership need to be set-up in
DX.CUSTOMER. EXTERNAL.FREQ records the statement frequency
desired by the client. This is a default frequency and is to be used in
conjunction with the multi-value EXTERNAL.REPS Field to define the
various reports required by a particular client and the frequency of those
reports. INTERNAL.FREQ Field specifies the frequency a particular report is
to be produced for internal purposes. The type of reports are detailed in
INTERNAL.REPS. EXCHANGE Field, the Investment Exchanges available
to populate this field. Use SHORT.NAME from DX.EXCHANGE.MASTER
or 'ALL' for all possible exchanges. If in DX.PARAMETER
ALLOW.ALL.EXCH Field is populated with 'Y' (YES), then this field will
default to 'ALL' if left null/blank.

SPEC.OR.HEDGE field choices are speculative or Hedge trading, the type of
business this customer trades within the market of the Investment Exchanges.
Speculative: Dealing in a commodity or financial asset with a view to
obtaining a profit on the prospective change in the market value of the item in
question
Hedge: Dealing in a commodity or financial transaction, tending to the
opposite effect of another transaction engaged to minimize a potential loss on
the latter.
EXCH.MEMBER field is used to define that the customer a member of the
relative Investment Exchange of Exchanges.
CLEARING; This allows the members to clear all trades through the Clearing
House appointed by the Investment Exchange.
TRADING; This allows the members to only trade on the Investment
Exchange without the clearing facility.
NONE; This customer is of neither stature above, neither a member of any
Investment Exchange nor Clearing House.
MARG.WEIGHTING field is for the 'Bump-UP-Factor' or additional margin
requirement from a customer of whom we the bank/broker do not have the
utmost confidence in. The figure is calculated in percentage terms.

AU.CT.CLASS Field allows this user to define how a customer wishes to
automatically closeout different classes of contract.
For example, for all BOND class contracts they may wish to use first in first
out (FIFO) processing. And for all others last in first out(LIFO)
There in multivalue one the user should setup BOND and in multivalue two
ALL with FIFO and LIFO associated with these items.
AU.SETT.TYPE Field is defined how a customer wishes to have the trades
automatically closedout for a particular DX.CONTRACT.CLASS, the user
may choose to enter a DX.CLOSEOUT.METHOD or leave the item blank. If
the user leaves this field blank then for the chosen DX.CONTRACT.CLASS
no automatic closeouts will take place.
MAN.SETT.NAR Field provides any added text settlement instructions for
information purposes.

First the details of the customer are captured through CUSTOMER table. The
customer is attached as private customer through CUSTOMER.SECURITY.
After that accounts are opened through ACCOUNT application. Then the
portfolio is created for the customer. Then the customer is attached as
DX.CUSTOMER for trading in futures and options. The commissions are set
up through DX.COMMISSION table. DX.TRADING.CONSTRAINTS table
is used to create DX constraints. Client groups are formed through
DX.GROUPING table.

The DX.TRADING.CONSTRAINT application allows different data fields
held on DX.TRADE and DX.ORDER to be tested alone or in combination to
determine whether the customer or portfolio is allowed to trade based on the
details entered or not. More than one constraint may be defined for a particular
portfolio. Id of DX.TRADING.CONSTRAINT contains a reference number
that differentiates between multiple constraints for the same portfolio. By
setting up multiple constraints for a client or portfolio, you can apply special
rules for alternative products. For example if the exchange is offering a new
contract and this is being offered to the Bank’s customers with constraints that
normally would preclude the customer. To do this the trading constraint fields,
PRI.CONSTRAINT and SEC.CONTRAINT on each side of the trade in
DX.TRADE will manually have to be entered rather than relying on the
default of constraint 01 or SYSTEM being used. If the SYSTEM record in the
DX.TRADING.CONSTRAINT application exists then this will be applied to
all sides of the trade in the system, unless alternative trading constraints have
been set up for the client or portfolio. This can be used to close the system to
all customers apart from those specified in the DX.TRADING.CONSTRAINT
application, or to open the system under a specific constraint, such as
customers can only trade contracts of LIFFE. Setting up a constraint in
DX.TRADING.CONSTRAINT allows you to constrain the system on only
fields in DX.EXCHANGE.MASTER and DX.CONTRACT.MASTER.
CONSTRAINT.TYPE Field acts in conjunction with the MESSAGE.TYPE

Field to decide on the action of the constraint.
Options available for this Field are PERMISSION and RESTRICTION.

DX.GROUPING is an application that allows generic heirarchical group
structures to be defined. Group id's defined in DX.GROUPING may be used to
group DX.CUSTOMER records into entities for reporting or revaluation
purposes.

The Derivatives system allows trading commission to be calculated
automatically dependent on certain criteria set up in DX.COMMISSION. This
facility allows commission and charges to be based on a number of decision
levels. ‘System’ level default for all conditions. Group level defaults for
groups of customer set up within DX.GROUPING.
Group level defaults for groups of contract set up within
DX.CONTRACT.CLASS. Individual level defaults for a specific customer set
up within DX.CUSTOMER. Individual level defaults for a specific contract
set up with DX.CONTRACT.MASTER. Commission can therefore be set up
for the following range of customer/group/contract combinations. These
elements are separated by ‘-‘and combine together to create the commission
code. Codes, which denote a narrower scope of grouping, are selected in
precedence to those with greater generalisation.

In each search to calculate commission, the order of priority (and list of valid
combinations) is given below:
1. Customer and contract. 2. Customer and contract class.
3. Customer. 4. Customer group and contract.
5. Customer group and contract class. 6. Customer group.
7. Contract. 8. Contract class. 9. System default.
The procedure used to determine when a correct commission table has found
can be controlled by the field SEARCH.ALL.COMMSN in the application
DX.PARAMETER record SYSTEM. If this field is set to NO then once a
record has been matched with the key then no further records will be searched.
If the field is set to YES, then each record found will be searched to find
matching extra criteria.

The Id is system for system level rules. CONTRACT.CLASS-
CONTRACT.CODE-CUSTOMER.GROUP- CUSTOMER Combination of
any 2 . It can input in any order provided suitable prefix is mentioned.
Example CC for contract class validated with DX.CONTRCT.CLASS .
System knows how to interpret the input, a two-character prefix is used to
identity each element, the application also recognises mnemonics used by the
source applications.
CU for customer validated with DX.CUSTOMER Example CU100018 implies
customer 100018. CU100018-CT1 implies customer 100018 for the contract
master 1 and the Id generated by T24 will be -1- - 100018

Some examples of DX.COMMISSION records are shown above.

More than one commission code can be entered for each commission type, but
there is only one commission currency per type. If a commission currency is
specified then this will override whatever currency is defined on
FT.COMMISSION.TYPE or FT.CHARGE.TYPE.
Commission on the trades, Execution fess, clearing fees ,Regulatory fees and
miscellaneous fees.

PAY.RECEIVE Field defines if the amount of charges and commission will be
paid to or received from the CUSTOMER, BROKER or EXCHANGE.
Must be either PAY or RECEIVE.
FIELD.NAME defines the field name from the application DX.TRADE. The
contents of which will be used in a test to determine what commission should
be applied to the relevant customer on the trade. Because DX.TRADE is
double sided and a customer may be entered as 'primary' on one trade but
'secondary' on another trade depending on the bank's requirements, only
common fields (common to both primary and secondary customers) or
'primary' fields may be entered here. The 'secondary' field to be tested if
appropriate will be defaulted into SEC.FLD.NME.
Input must exist on STANDARD.SELECTION for the DX.TRADE
application .Fields DX.TRA.SEC.CUST.NO to DX.TRA.SEC.RESERVED1
are not allowed
OPERATOR Field is the operator in the logical test to be performed on the
contents of the field in FIELD.NAME or SEC.FLD.NAME.
Input must be one of the logical operators.

COMM.CHARGE is the Field defines the commission that will be paid or
received for the relevant trades. Input must exist on FT.COMMISSION.TYPE
or FT.CHARGE.TYPE. EXFEE.CHARGE, CLFEE.CHARGE,
RGFEE.CHARGE and MISC.CHARGE fields can be used for specific types
of commissions/charges. All fields can be sub valued to accommodate more
than one type of commission/charge
FIELD.FROM is a numeric constant or text string to compare the contents of
the field in FIELD.NAME or SEC.FLD.NAME against. The OPERATOR will
be used to perform a logical test. FIELD.TO is when a 'range' type logical test
is being performed this field contains the upper value in the range that the field
contents will be tested against.

Dx Trade and Order have fields to capture the exchange type and channel of
trade/order which will be used to determine variable commission rates based
on the type of customer, the trading exchange, the product etc. The
multivalued fields Exchange Type and Channel are linked to the EB.LOOKUP
table to get the values to be listed to the front end user.
Differential rates are defined using FT Commission Type and linked to DX
Commission table for different exchange type and Channel.

When trading derivatives, it is used to link individual transactions to form a
strategy to achieve a desired result. Examples are CALL/PUT spreads, range
forward, forward extra, seagull, participating forward, etc. where combinations
of many options together forms the derivative structure or trade. profit and loss
characteristics of a portfolio to be constrained as required.
Individual banks may define their own “combination” to form a derivative
structure. This application allows that strategy to be defined along with its own
valuation methods. Field PRI/SEC.LINK on DX.TRADE will generate a
unique sequence number if left blank. If however a user-defined value is
entered, this becomes the key to a file DX.STRATEGY.LINK. This
functionality can be used for multiple reasons, one of which is the initial
margin calculation.

After you have parameterised all the applications for working in the
Derivatives module, you are ready to trade. The application that allows you to
trade in the Derivatives module is DX.TRADE which is used for capturing
trades. Let us learn how we can use this application.
A few features of the Derivatives module has been discussed already and to
recollect, they are:
The trades may be between:
Bank’s customer and Bank’s own book
Bank’s own book and broker
Bank’s customer and broker
Brokers as transfer trades
DX.TRADE is always double sided and also allows bulk trading. You may
remember from the Securities course, that many brokers can facilitate trade of
a single customer and one broker can also facilitate trades of multiple
customers. That holds good in Derivatives module as well. Further, this
application also allows the flexibility to enter the customer and broker details
on either side of the trade. But, you as a T24 Bank can also configure the
secondary side to represent the Broker.

The DX.TRADE record is rather large to allow a wide variety of trading
information to be recorded. Users could create versions of the application to
allow fast input where required. DX.TRADE is designed to handle all these
cases, and so unlike SEC.TRADE, it allows the entry of customers or brokers
on either ‘side’ of a trade rather than having a ‘customer’ and a ‘broker’ side
per se. A Bank may of course choose to establish a convention that the
secondary customer on the trade will always be for example, a clearing broker

You parameterised the contracts in DX.CONTRACT.MASTER. Now you can
input this contract record (CONTRACT.CODE) in the DX.TRADE to get the
default values for those contracts in the fields EXCHANGE.CODE,
SUB.ASSET.TYPE, TRADE.TYPE, CONTRACT.CCY, TRADE.CCY and
REGION. These defaulted values cannot be amended at trade level. The
TRADE.STATUS will be either ACTIVE/CLOSED, updated by the system.
The next fields which are important for the trade are those relating to dates,
namely TRADE.DATE, MATURITY.DATE and in case of Options,
DEC.DATE. You already know the significance of these dates to a trade.
Forward dates are not allowed for TRADE.DATE. Further the input into
MATURITY.DATE will depend on the MATURITY.TYPE of the contract. If
the Maturity type is monthly, the input will only be accepted in the format
NNNYY like MAR08 or MM-YY like 11-08. If the Maturity type is Daily,
then the allowed input can be in the format of YYYYMMDD.
Further, for Options, there are additional two fields which define the character
of the contract, which are OPTION.TYPE, which can be CALL or PUT and
STRIKE.PRICE which is the price at which the option can be exercised.

The primary details captured are from PRI.PRICE to PRI.LOTS in the multi
valued set.
PRI.PRICE Field is the price for the number of lots traded. For 'OPTION'
trades, the 'PREMIUM' price
PRI.BUY.SELL Field indicates whether the Customer is buying or selling.
PRI.CUST.NO identifies the Customer(s) with whom the trade is made. Multi-
value set available is to enable the processing of trades with more than one
customer.
PRI.SEC.ACC identifies the SECURITY.ACCOUNT of the Customer. Must
be a DX.CUSTOMER of the Customer.
PRI.ACCOUNT Field identifies the Customer's Account, over which financial
entries relating to the trade are to be passed.
PRI.LOTS is the number of lots/contracts traded by this customer.
Similarly secondary details are available for a single entity in similar fields
prefixed with SEC.
The following fields cater to the requirement of collection premium in any

currency other than the contract currency for FX OTC Options contracts:

PRI.PREMIUM.CCY: Currency in which the premium is denominated. If not
defined by User, the currency of the PRI.ACCOUNT will be defaulted.
PRI.PREM.PRICE: Premium quoted in PIPS in premium currency
PRI.PREM.EXCH.RATE: Exchange rate between premium currency and
contract currency. Defaulted from the currency table if not defined by the User
PRI.TOTAL.PREM: Total premium amount denominated in premium currency
(Premium amount X Contract size X No. of lots)
System will allow the user to input premium quoted in PIPS in the premium
currency/contract currency or the total premium in premium currency/contract
currency. System will update the other related fields using the exchange rate
which can be user defined/defaulted, contract size and number of lots.

Per customer, trades may be flagged as opening or closing a position
(OPEN.CLOSE), or as speculative or hedge trades. If a trade is designated as a
hedge for a customer, the user is obliged to enter a description or reference of
the hedged product or instrument in the LINK Field.
PRI.OPEN.CLOSE Field defines open or Close of a transaction, information

to Notify an Exchange of the status of the transaction and calculation of the
commission.PRI.HEDGE.TRADE Field denotes, is this a Hedge or Trade
(Speculative) transaction?
HEDGE: A transaction tending to the opposite effect of another transaction,
engaged in to minimise loss on the latter.
TRADE: Dealing in a commodity or financial asset with a view to obtaining a
profit on the prospective change in the market value of the item in question.
PRI.ALLOW.SETT Field allow settlement or close out of this trade? Choose
from the drop down menu 'YES' or 'NO'. PRI.STRATEGY Field is Trading
Strategy on futures or stock transactions for reporting purposes.
e.g. Straddle, Strangle, Butterfly, Spreads, etc. Input must exist on
DX.STRATEGY application. PRI.CONSTRAINT Field is used to input the
DX.TRADING.CONSTRAINT Id relating to this customer. This will apply
the set level of constraints for the portfolio or individual trades according to
the relationship between the bank and this customer.

In a Derivatives trade, you can either apply commission based on an automatic
criteria using the settings in DX.COMMISSION or you can manually override
the commission fields. This can be parameterised for the Principal and
Secondary Customer separately by using the field PRI.AUTO.MANUAL and
SEC.AUTO.MANUAL respectively which can be chosen as AUTOMATIC or
MANUAL. This choice will determine your choice of commission, i.e.
Automatic or Manual. Let us see the Automatic method of Commission first.
With the PRI.AUTO.MANUAL set to Automatic, the DX.COMMISSION
finds a suitable commission set up for the transaction and applies the execution
and clearing commission to it.
Now for the Manual option. If you choose Manual in PRI.AUTO.MANUAL
and SEC.AUTO.MANUAL, one of the four different commission types must
be selected. Each commission type can be input only once per customer. The
fields PRI.COMM.CDE (or SEC.COMM.CDE) can allow either:
• A commission code from FT.COMMISSION.TYPE or
FT.CHARGE.TYPE, or
• “OVERRIDE”.
If “OVERRIDE” is entered instead of a commission code, then it is possible to
enter the commission currency, the amount and the posting account in the
trade.

PRI.CHARGE.DATE is the date which could be TRADE or SETTLEMENT,
on which to charge commissions, fees, and taxes. Default will come from the
commission setup for the related customer.
PRI.NET.COST field is the cost to the primary customer of DX .TRADE
expressed in trade currency equivalent.
The net cost is calculated as (Lots * Pri. Int. Price) +/- (Commissions and
Charges)
SY.DEAL.REF Field is used to store the deal Id generated while inputting
Structured products deal.

To provide treasury rate functionality the Customer (Primary) and Broker
(Secondary) prices/premiums on the derivatives trading application can now
be decoupled. This will allow the user to enter a Customer rate and an internal
rate for the trade.
TREASURY.CUSTOMER Field will control the decoupling of the rates, if set
as “NO” to denote that Customer Price (usually PRI.PRICE) and the
Bank/Broker Price (usually SEC.PRICE) are different, thus allowing
SEC.PRICE to be input, then Bank/Broker customer must be an own book.
An error message is raised if neither or both sides are own book and the
TREASURY.CUSTOMER Field is set to NO.
The broker/exchange profit produced by the different prices will be posted to
an internal account. This will be defined by the category on a new derivatives
accounting event type (DX.EVENT.TYPE, BP Broker/Exchange Profit).

Now you can create Swaption trades by making use of these fields
Trade application supports multiple premium payments, trade capture and
delivery confirmations.
Underlying Bond(UNDERLYING SECURITY) is a mandatory field and holds a
valid SECURITY.MASTER record.
Bond Ccy (AS.CURRENCY) is a NOINPUT field and gets defaulted with trade
currency.
Bond Value (AS.PRINCIPAL) is a mandatory field and holds the principal
amount of the bond in asset currency.
Prem Pay Future is set to YES, a live file DX.PREMIUM.DETS gets created
with premium payment details
DX.PREMIUM.DETS.HIST,which acts as a history file for
DX.PREMIUM.DETS is created.
On reversal of trade, the records in DX.PREMIUM.DETS and
DX.PREMIUM.DETS.HIST table are deleted and updated respectively. On
archival of trade and transactions, the premium details from
DX.PREMIUM.DETS are archived and updated in
DX.PREMIUM.DETS.HIST respectively.
DX.PREM.DETS.PAID premium is paid at SOD, a live file

DX.PREM.DETS.PAID gets created with paid premium details
DX.PREM.DETS.PAID.HIST acts as a history file for DX.PREM.DETS.PAID is
created.
On archival of trade and transactions, the premium detail from
DX.PREM.DETS.PAID gets updated to DX.PREMIUM.DETS.PAID.HIST
respectively.

Using DX.trade , now we can capture Swap by using the below fields
SWAP.DELIVERY determines whether settlements is cash or physical
PAY.TYPE and RECEIVE.TYPE defines fixed or floating rate contracts
For floating rate contracts spread and rate reset frequency fields will be used

DX.ORDER is the main order input routine for the Derivatives module. All
orders in the Derivatives module are double-sided. Each order will have one or
more Primary counterparties like customers, own-book dealers or brokers
versus a single Secondary counterparty.
Order entry system will record individual orders from either internal traders or
external clients
Orders can be entered either manually or by an interface from a front office
system
After an order has been entered it can be amended, deleted or executed, either
manually or automatically .
Once fully or partially executed the order becomes a trade. Therefore one
order may create multiple trades
In some cases the order may never be executed or maybe only partially filled.
At the end of exchange all orders remaining unfilled will be checked for their
validity.

All orders will be reported and those that have expired will be cancelled.
Most of the fields are taken from, or, have been amended from DX.TRADE
There are few fields like ORDER. DATE, ORDER. TIME,
DATE.TO.BROKER, TIME.TO.BROKER, etc. which are required for
DX.ORDER but not sourced from DX.TRADE. These are replicated into any
trade that represents the fill of an order.

DX.ORDER is the main order input application for the Derivatives module.
All orders in the Derivatives module are double-sided. Each order will have
one or more Primary counterparties like customers, own-book dealers or
brokers versus a single Secondary counterparty.
Order entry system will record individual orders from either internal traders or
external clients through interfaces provided by the T24 Bank.
Orders can be entered either manually or by an interface from a front office
system
After an order has been entered it can be amended, deleted or executed, either
manually or automatically .
Every fully or partially executed order will become a trade, thereby resulting
in one order creating multiple trades.
In some cases the order may also never be executed or maybe only partially
filled. At the end of exchange processing all orders remaining unfilled will be
checked for their validity and the expired ones will be automatically cancelled.
SY.DEAL.REF Field is used to store the deal Id generated while inputting
Structured products deal.

Transactions are stored using the key of the parent trade or other entity, a
portfolio/customer number to identify the ‘side’ of the parent transaction it is
associated with, and a version number to keep track of changes to the
transaction. Old versions are retained.
DX.TRANSACTION is the main transaction reporting and logging file for
Derivatives
The main principle of the application is that all transactions in the Derivatives
module are recorded in DX.TRANSACTION
When recording trades, most of the customer dependant data in the trade
record is reproduced in DX.TRANSACTION for reporting purpose
The following activities raises an entry
DX.TRADE
DX.ORDER
DX.CLOSEOUT
END.OF.EXCHANGE processing
ONLINE REVALUATION processing

DX.TRANSACTION is the main transaction reporting and logging file for
Derivatives.
Transactions are stored using the key of the parent trade or other entity. It
contains a portfolio/customer number to identify the ‘side’ of the parent
transaction it is associated with, and a version number to keep track of changes
to the transaction. Old versions are retained.
The main principle of the suite is that all transactions in the Derivatives
module are recorded in DX.TRANSACTION. When recording trades, most of
the customer dependant data in the trade record is reproduced in
DX.TRANSACTION for reporting purposes.
For example, the initial entry and validation of a derivative trade involving
three customers and one broker would produce records in
DX.TRANSACTION as follows:
Portfolio 100018-1:DXTRyydddnnnnn.100018-1.1
Portfolio 100032-2: DXTRyydddnnnnn.100032-2.1
Broker 110010: DXTRyydddnnnnn.110010.1

If the trade were deleted before authorisation, all the DX.TRANSACTION
records raised would also be deleted. The transactions remain unaltered on
authorisation of the trade. If the trade were then amended, on validation of the
amendment a new set of transactions would be created as follows:
Broker 110010: DXTRyydddnnnnn.110010.2
New transactions are created for all participants in a trade with consistent
sequence numbers, even if the ‘side’ of the trade associated with a particular
customer/portfolio has not changed. The ‘old’ set of transactions on the trade
would have REVERSAL.DATE set to the current bank date and would remain
in the file. If the amendment were to add a further portfolio to the customer
side of the trade, a new transaction would be created as follows: Added
portfolio 100060-5: DXTRyydddnnnnn.100060-5.2 . A portfolio added to a
trade generates a new transaction with the same version number as the rest of
the trade’s transactions. If an authorised trade is amended, but the unauthorised
amendment is itself deleted, only the new transactions that have been raised
for the unauthorised amendment should be removed from the transaction files.

This file is designed to record activity against derivative transactions. It shows
both the current and all previous status’s of the transaction.
The Id for each record on this file corresponds to the underlying DX.TRADE
that is being recorded i.e. DXTRA060101234.
Each activity that reports to DX.ITEM.STATUS creates a new multi valued
data set on the record. The activity corresponds to a defined
DX.ITEM.STATUS.TYPE where enrichments can be added to describe the
status. With each new status update (e.g. NEW, AUT, AMD), the application
also records the DATE, TIME, USER and APPLICATION i.e DX.TRADE,
DX.ORDER or DX.CLOSEOUT associated to the activity.
The CURR.STATUS is shown in the first multi valued set with previous
activities shown in chronological order thereafter by STATUS.
For example when the trade is in INAU the Curr Status: This field denotes the
last status of the application e.g. NEW, AMD, AUT, REV, AUR
Curr Date: Denotes the date when the trade is punched
Curr Time: Denotes the time of the trade
Curr User: The user who input the trade
Curr application: Denotes which application has been used.

DX.REP.POSITION is updated online when trades are verified, deleted or
reversed. The key is made up of customer or portfolio number, contract
number, currency, maturity date, option type if that is applicable and price in
internal format. It holds details of the summary trading position for the
customer/contract/date including net lots open and separate buy and sell lot
figures. Futures and options occupy separate sets of fields within the position
record, to allow further analysis of the option position by option types like call
or put and strike price.
DX.REP.POSITION is a useful starting point for many enquiries, since it holds
lists of the DX.TRANSACTION records that make up the future or option
positions in the fields FUTURE.TRANS.ID and OPT.TRANS.ID. These can
be used in drilldown fields to allow access to the underlying transactions and
hence the original trade record if required.
The average price of the position is also calculated and held on the
DX.REP.POSITION record, using the calculation specified in
DX.PARAMETER AVE.PRICE.METHOD.

There are three Customer/Portfolio, Contract information and Exotic option
information . The three components are separated by “*”
Customer/Portfolio 50030-1
Contract Information the 6 Fields separated by “/”
Option type
Contract Id
Trade Currency
Maturity Date
Call/Put
Strike Price (External)
Exotic Option Information
Defined by the user
Used to add increased granularity to the position keeping

This is a live file, which holds a full diagnostic breakdown of how the trading
commission figures charged are paid to customers or brokers. The code to
DX.COMMISSION.DIAGS is a combination of the key to DX.TRADE
suffixed with the customer number. The respective commission records are
updated every time a trade is input or amended by DX.TRADE. No history of
individual changes is maintained so once a change to commission is saved on
the trade, the new diagnostics will overwrite the previous details for that
customer. The live file holds commission irrespective of whether the
commission was input manually into the trade or generated automatically by
matching criteria on DX.COMMISSION. In the latter case, the field
COMMISSION.CODE is filled with the key from DX.COMMISSION.
To make reporting easier the commission is displayed by each of the different
commission types. For COMMISSION COMM…
For EXECUTION EXFE , For CLEARING CLFE…
REGULATORY RGFE , MISC MISC…
Each type holds the information on Commission currency, Account where
commission has been posted, Currency of the posting account, Exchange rate
(if commission currency is different from the account currency), Commission
or Charge code and any taxes associated with the commission.

The standard CUSTOMER.POSITION includes derivatives transaction It is
important to remember that the DXVM items will only be available after an
end of exchange revaluation has taken place and the DXIM figures will not
take into account any transaction not included in the last end of exchange
revaluation. There are three types of entry into the CUSTOMER.POSITION
file
Plain DX items report contingent value of a transaction, maturity date, value
date, and category.
The DXVM items report Variation Margin figure generated by the end of
exchange revaluation process.
The DXIM items report Initial margin figures for a client and there will only
be one of these items per client.
This is because, Initial Margin cannot be broken down into transaction by
transaction as it relies on a group of trades

Position management module in T24 is to provide real-time reporting on a
bank’s cash flows, currency and interest rate exposure across all products.
Position Management reports reflect bank’s exposure to interest rates and
currencies arising from trades in financial futures.
The term financial futures refers to exchange traded futures on interest rates,
currencies and bonds for the bank’s own book . When a financial futures trade
record on the bank’s own book is committed or amended, cash flow entries and
position entries will be created or updated, so that the impact is reflected in
PM. When the futures trade reaches maturity or is ‘closed out’ by another
event (e.g. matching purchase against sale) the futures exposure will be
removed from the PM files, and the realised profit or loss impact reflected in
the bank’s cash flow.

Data for all transactions will be available for the PM reports. All ‘hedge’
transactions will be reported in the PM files, but ‘trade’ type transactions may
be excluded and are driven by parameterisation.
the Contract Value is found using the below mentioned formula,
Value in the PRI.LOTS field in DX.TRADE is multiplied by the value in

CONTRACT.SIZE field in DX.CONTRACT.MASTER.
Position entries based on a Notional amount for the Interest Mismatch (Gap)
are reported for:
1. Interest rate futures
2. Bond futures
FX position entries for currency futures, are in both:

The buy currency and The sell currency

The interest rate exposure resulting from a trade in interest rate futures will be
displayed in the Interest Mismatch (Gap) Position enquiry.
When the transaction is ‘closed out’, the exposure will no longer be displayed.
Currency indicated in the position management as contract currency is picked
up from the CONTRACT.CCY in DX.TRADE
Start date indicated in the position management as start date of the GAP is
same as maturity date and for monthly maturity contracts it is same as the first
delivery date
End date of the GAP is derived from the start date plus number of days defined
in the LIFE.UNDERLYING field in DX.CONTRACT.MASTER
Interest rate = 100 – Price (percentage) e.g. 100 – 98.80 = 1.20%

There are a number of field values from the DX module are picked up and
utilized for updating the GAP in position management.
The list of fields are ID, PRI.BUY.SELL from DX.TRADE and ID,
CONTRACT.CCY, FIRST.DELIVERY, LIFE.UNDERLYING from
DX.CONTRACT.MASTER
LIFE.UNDERLYING field in the DX.CONTRACT.MASTER needs a
mandatory input if the contract is an interest rate future contract.

The field FIN.INT.RT.FUT is used to indicate the DX.CONTRACT.CLASS
record that denotes the Interest rate futures.
The field FIN.BOND.FUT is used to indicate the DX.CONTRACT.CLASS
record that denotes the Bond futures.
The field FIN.CCY.FUT is used to indicate the DX.CONTRACT.CLASS
record that denotes the Currency futures.
The field TRADE.GAP decides whether the trade type of transactions have to
be reported in position management or not. By default all the hedge
transactions are reported and the user has a choice regarding the trade type of
transactions in this parameter table.

Closeouts (or settlements) are used to match opposing buy and sell positions
within the same contract to effectively close the open positions and realise any
profit or loss due. Once the settlement has occurred the position will be closed-
out and any profit/loss will be realised. Commission and charges also due to be
paid at settlement time will also be posted. Within the DERIVATIVES module
there are two methods of closing out trades. The first involves matching
opposing buy and sell positions within the same contract to effectively close
the open positions and realise any profit or loss due. The second form of
closeout occurs when a position is held until maturity. This also results in a
position being closed and subsequent cash or physical delivery-taking place,
this is also known as a "cash" or "maturity" settlement. In this case the open
trades are in effect settled against a pseudo trade. For futures, this trade would
be performed at the EDSP i.e Exchange Delivery Settlement Price. For
options, no pseudo trades are created. For trades where premium was not paid,
trades/transactions are closed out against each other on the same way as a
manual closeout. Where the premium has already been paid, these are cash
settled against the Original Premium Price. Once the settlement has occurred
the position will be closed-out and any profit/loss will be realised.
Commission and charges due to be paid at settlement time will also be posted.

Closeouts can be performed manually, automatically or by the system. In the
case of manual closeouts, the user selects a customer and a unique contract.
For futures, this would involve the specification of a contract code and a
delivery period. For options this would involve the selection of a contract
code, a delivery period, a strike price and the option type. Additionally, other
fields may be entered to further restrict the selection of trades. All the open
trades matching these criteria will then be displayed. The user may then select
which trades and how many lots from each trade are to be settled. As long as
the total numbers of buy lots is the same as the total numbers of sell lots, the
close out may be confirmed.
Two DX.CO.MANUAL enquiries exist one for options and the other used for
stocks and futures. DX.CO.MANUAL.OPTION.BRWS and
DX.CO.MANUAL.FUTURE.BRWS are in essence the same apart from
validation and field layout differences.

To process a new manual closeout, run the relevant enquiry, for example ENQ
DX.CO.MANUAL.FUTURE.BRWS for Futures. Then select a Customer and
a unique Contract. Transactions that do not form closeout lots will not be
processed as part of this closeout, and will not appear in the final closeout
record.
You will then be presented with a screen illustrating the total profit/loss on the
trades being “closed out” and an option to create an authorised or unauthorised
DX.CLOSEOUT record.
If you select to create an unauthorised DX.CLOSEOUT record, you will
subsequently need to authorise the record to generate realised profit and loss
entries. However, an authorised record will automatically generate these
entries. Once the settlement is confirmed the closeout engine will report back
the current closeout id, profit or loss , and any commission charged as part of
this closeout.

The close out application is then launched. The user may then select which
trades and how many lots from each trade are to be settled. As long as the total
number of buy lots is the same as the total number of sell lots, the settlement
may be confirmed. Transactions that do not form closeout lots will not be
processed as part of this closeout, and will not appear in the final closeout
record.

The DX.CLOSEOUT application is the application for the processing of
closeouts within the T24 derivatives module. Once a closeout has been
performed, a DX.CLOSEOUT record is created, which holds all details of the
closeout like
the current closeout id, profit and loss and any commission charged as part of
this closeout
You cannot directly input into the DX.CLOSEOUT application unlike other
T24 applications but you can only Authorise, Delete, or Reverse a Closeout.
After authorising the closeout the number of open lots on the DX.TRADE and
DX.TRANSACTION records will be decremented and the closeout details
moved to TRASETTNOS field of DX.TRANSACTION and PRI.SETTNOS
/SET.SETTNOS fields on DX.TRADE.
Once the run closeout button is clicked on the form, the closeout engine will
take over. If the run closeout button is “greyed” out, it indicates that the
number of buy lots and sell lots do not match.

Automatic closeout by the System depends on whether the Closeout is allowed
for the contract or the customer or the trade or the exchange
Fields for this can be set as in the various tables.
In DX.EXCHANGE.MASTER Field SETT.ALLOWED may be set to YES (or
NULL) to allow settlement or closeout on a particular exchange, or NO to
disable the same.

In DX.CUSTOMER, AU.CT.CLASS Field may be set to FUTURES,
OPTIONS, BOTH OR NONE ,
AU.SETT.TYPE Field may be set to FIFO (first in first out), LIFO (last in first
out) or FIFO.DAY (today trades take precedence)
AU.SETT.DELAY Field may be set to the no of days after trade when
settlement/closeout can occur.
IN the DX.CONTRACT.MASTER table ,SETT.ALLOWED Field may be set
to YES to allow settlement or closeout, NO not to allow or Blank to default to
the Exchange Master setting.

In the DX.TRADE table XXX.ALLOW.SETT Field may be set to YES to
allow settlement or closeout, NO to prohibit auto or system settlement for this
trade out. This may be overridden by Manual closeout. The Hedge trade it is
always NO.
Automatic closeouts are initiated through the selection criteria from
DX.CO.AUTO.INPUT.
If done through an End of Exchange process, only trades for that exchange are
considered for settlement. The system will select all the customers who have
automatic settlement enabled for either Futures or Options positions. For each
unique contract (position) that also has auto settlement enabled, the system
will try to match any trades following the rules specified for auto closeout.
SYSTEM.EXERCISE Field if set to YES enables automatic system exercise of
options when a routine is included as a part of END.OF.EXCHANGE process.
SYSTEM.EXPIRY Field if set to YES enables automatic system expiry of
options when a process routine is included as a part of END.OF.EXCHANGE
process.

Two DX.CO.MATURITY enquiries exist, one for options and the other used
for stocks and futures. ENQ DX.CO.MATURITY.OPTION.BRWS and ENQ
DX.CO.MATURITY.FUTURE.BRWS like the DX.CO.MANUAL enquiries
are in essence the same apart from validation and field layout differences. In
order to process a new maturity/cash settlement closeout, run the relevant
enquiry - for example ENQ DX.CO.MATURITY.FUTURE.BRWS.

Exercise, expiry, and assignment of Options can be manual process, where the
user selects the trades and lots to be processed .
It can be automatic process where the system does the selection. Regardless of
the method used to select the transactions, the underlying processing will be
identical.
If the options are being exercised or assigned, the appropriate underlying
transaction will also be created. Routines for these are stored in
DX.OBJECT.LIBRARY.

Enquiry consists of DX.CO.MANUAL.EXPIRE.BRWS,
DX.CO.MANUAL.EXERCISE.BRWS and
DX.CO.MANUAL.ASSIGN.BRWS.
This involves the selection of a Portfolio or Customer Id, a Contract Code, a
Maturity Date, an Option type (Call or Put) and a Strike Price. As this is a
standard T24 enquiry, other fields may be added to restrict the selection of
trades. All the open trades matching the selection criteria will be displayed for
the user to select, which trades and how many lots from each are to be
processed. It can take place at any time of the day with the restriction that only
one session is in progress.

Automatic Closeouts are performed on line. The process enables the system to
automatically select all the trades for the contract specified that are due to
expire or exercise. The input programs DX.CO.EXPIRE.AUTO or
DX.CO.EXERCISE.AUTO to process the trades for each customer or
portfolio initiate these. Processing is similar to the equivalent manual
application, except that the user may wish to automatically authorise the
closeout.

The Derivatives module will automatically closeout a secondary (Broker)
position to mirror a closeout performed for a primary (Customer) position
Whenever a secondary CO cannot be performed, there will be a message to
that effect. If a Close Out occurs specifying a secondary side, a primary side
CO will not happen. If there is primary side CO reversal, then the system will
perform a reversal at the secondary side also. The PRI. OPEN. CLOSE Field
in DX.ORDER/TRADE will have to be set to CLOSE (only for open
positions) and deal will have to be through the same Broker.

The standard SC.POS.ASSET includes derivatives items where the Derivatives
(“DX”) module is installed. SC.POS.ASSET can be configured to include
derivatives items. The SC.POS.ASSET records will now include items relating
to transaction-based deals within the Derivatives module. Every trade relating
to a portfolio requested will be included. Only portfolio trades will be
included. The DX module data will be the latest updated data from the last end
of exchange process, and, therefore, transactions will only be included once
they have been re-valued by the system
The Enquiry SC.VAL.COST (SC.VAL.MARKET) is to run for the update to
this file.
For this purpose the ASSET.TYPE record linking the SUB.ASSET.TYPE
defined in the DX.CONTRACT.MASTER has to be included with interface to
DX
Every trade relating to a portfolio requested will be included.

Apart from DX.EVENT.TYPE table, tables ACCOUNT.CLASS, CATEGOTY
for storing in the DX.CONTRACT.CLASS and TRANSACTION table.
T24 derivatives trade input is always double sided, but the account postings
resulting from the trade may well be asymmetric, e.g. the bank may pay a
certain clearing fee to a broker, but impose a ‘mark-up’ on the fee it charges to
the external customer involved in the trade.
All trade-related postings are therefore washed through suspense accounts or
P&L categories to allow this to happen. ACCOUNT.CLASS contains the
definition of the suspense accounts or profit and loss categories through which
postings are ‘washed’.
It is advisable to use the same CATEGORY for the debit and the credit
ACCOUNT.CLASS so that the funds wash in and out of the same suspense
account. DX.CONTRACT.CLASS stores the product category relating to the
contract class that is used by the accounting module.
TRANSACTION codes should be set aside for Derivatives accounting for the
entry of debit and credit transactions.

For external clients, all entries are posted directly to their account Initial
Margin, Variation margin, Commissions. After Authorisation, entries are
posted to the client’s account. For customer side of contracts, the customer
accounts are operated by the system by debiting/crediting for buy/sell and the
corresponding entries to the accounts defined in ACCOUNT.CLASS records
for example, SUSPDXPRCR/SUSPDXPRDR (in the case of Options)

PREMIUM.DUE Field indicates whether option premium is to be collected at
TRADE or SETTLEMENT and defaults from the DX.CONTRACT.MASTER.
Accounting entries for premium payments are raised accordingly. The fields
PRI.CHARGE.DATE and SEC.CHARGE.DATE are used similarly to indicate
collection of charges either at TRADE or SETTLEMENT.

3 types of entry:
STMT.ENTRY – Customer or Bank – actual account entries. Pass account key
(internal or external) to EB.ACCOUNTING
CATEG.ENTRY – Bank only – unrealised and realised P&L. Pass P&L
category to EB.ACCOUNTING.
RE.CONSOL.SPEC.ENTRY – Bank Own Book only – ‘special’ entries
including contingents + accruals

Revaluation process is done in order to arrive at the profit/loss of the futures
and options contracts that are in position.
This forms part of the Derivatives module core functionality and maybe
invoked in different modes to produce different events. Revaluation forms
part of the end of exchange process and therefore will form the part of the end
of day processing of the Derivatives module.
The re-valuation process has been developed to allow the valuation,
accounting and reporting of futures and options held
in the T24 derivatives system. The re-valuation process may be initiated for
the following purposes:
1. End of Day batch re-valuation/End of Exchange revaluation/processing
(Customer and Exchange combination only) to know the marked to market
(MTM) values of the trades at end of trading day.
2. On-line ad-hoc re-valuations to know the MTM values at any given point of
time which helps in decision making with reference to unwinds/closeouts.
The re-valuation calculations performed will remain the same whatever the
purpose might be. However, the rates that are taken for the calculation and the
accounting entries may differ according to the revaluation purposes; hence
along with the core revaluation process there may be additional processes
written around it, which will be utilised as per requirement.

The revaluation process manages three major functions.
1. Initial margin calculation
2. Variation margin calculation
3. Collateral allocation
Additional processes include retrieval/calculation of prices, retrieval of trades,
posting of accounting entries and reporting of current status of the trade.
These additional processes can be added into close of business
(DX.COB.WORKFILE) as required.

The initial margin (or deposit) is required by counter parties in order to ensure
their financial stability in case the opposite party defaults. The initial margin
calculation methods vary from exchange to exchange and from broker to
broker. In the case of exchange based futures and options, each clearing-house
or exchange publishes its initial margin calculation method.
DX.CONTRACT.MASTER. Associated with each method will be related table
maintenance or data extracting modules to enable each method to be fully
implemented. Full reporting functions, based on the exchanges own reports if
applicable, will be included in all initial margin calculations. This will allow
the user to easily check all the margin figures including SPAN, spreads and
hedges. The method used to calculate the variation margin (profit/loss) of a
position is determined from a parameter held in the contract master file.
Initially only the regular contract method (unit price * price differential) will
be used, but alternatives can be easily added. In the case of options the
separate figures will be produced depending when the premium for each
contract is paid. If the premium is paid at settlement time then Option variation
margin is calculated using the market price or a fair value price. If the
premium on the contract has already been paid then the figure is classed as
unrealised option profit/loss. This unrealised profit/loss will be reported
separately and can often be used in the initial margin calculations, e.g. SPAN
to reduce the initial margin requirements. Therefore the variation/unrealised
option value calculations must be performed before initial margin calculations.

The DX.REVALUE application allows the user to initiate an adhoc what if
revaluation. It can be done for ALL.CUSTOMERS, GROUP, CUSTOMER or
PORTFOLIO. If all customers are to be re-valued, the further “Who” selection
fields are not available. For selection of individual Customers, Groups or
Portfolios, set ALL.CUSTOMERS to “NO”. One can then identify a GROUP,
CUSTOMER(s) or PORTFOILO(s). One can choose only one field to
populate.
The section allows you to specify any number of DEALER.DESK(s)and/or
DEPT.ACCT.OFFICER. The selection of trade allows the user to choose
which kinds of trades from the customers selected to revalue. Either all, a
particular CURRENCY, EXCHANGE, CONTRACT.CLASS or CONTRACT.
The parameters allow the user to define which DX.PRICE.SET is to be used
during revaluation. RE.CALCULATE.IM asks whether or not to calculate
initial margin and is used to speed up the processing if only variation margin
figures are needed. It is impossible to only calculate initial margin without
running the variation margin routines, as initial margin often requires variation
margin figures to be present. RE.VALUE.LEVEL asks at which level the top-
level summary information in DX.REVALUE.SUMMARY and
DX.REVALUE.EXCHANGE is to be stored. This allows the system to
calculate the total margins for either a PORFOLIO, a CUSTOMER, or a
CUSTOMER group .

This is the controlling mechanism for the Close of Business routines. This
application provide an access point for starting online valuations as well as a
work file for the Close of Business to process the end of day valuations. This
End of Exchange processing will be multi-threaded to a lower level than
before with the Customer/Exchange being the valuation level. Most of the
processing work will be passed to an online revaluation engine, designed to
process both online and during the Close of Business. An exchange is no
longer blocked whilst the valuation processes online, instead its processing is
only blocked if one of the customers on a transaction is doing something that
may impact the valuation for them on the exchange being processed.
That is, both the Close of Business and Online Valuations will be Multi-
Threaded, by using the tSA services For example, a System with two
exchanges and three customers would result in six discrete threads being
processed, one for each Customer/Exchange combination. Possibility of one
customer’s valuation failing and requiring a re-run of an entire exchange is
removed. With large numbers of customers, this shortens the time taken for
any close of business processing.

As part of the end of exchange processing a revaluation takes place across all
positions held on a particular exchange. The details of the revaluation are kept
in the same files as the on-line ad-hoc revaluation, but are identified by their
record id. Records prefixed with DXEOE… are revaluation records that relate
specifically to an end of exchange run. For example, DXEOE010024*… is an
end of exchange run (DXEOE) on the second day of 2001 (01002), for
exchange 4 (4). It is during processing of an end of exchange revaluation
against the EOE.PRICE.SET specified in DX.PARAMETER that revaluation
accounting postings take place.

Does not require any request unless a new price change has occurred after an
on-line revaluation. In that case, any Customer/Exchange affected needs to be
manually requested again. The COB will check the status of the
DX.COB.WORKFILE to pickup the combination which requires revaluation
While in day-to-day processing the status should be “Completed” or
“Running“,
COB will revalue any Combination of Customer/Exchange with the following
status , New, Ready, Re-Run, and Completed, with next run date less or equal
to today. Any messages, errors or warnings generated during the process will
be displayed in the work file record.

Derivatives module re-calculates the value of clients or portfolios after the
exchanges have closed.
This file details the total margin amounts for a client, portfolio or group.
Derivatives module re-calculates the value of clients or portfolios after the
exchanges have closed. Details figures held in the currencies in which they
were calculated and in the BASE.CURRENCY for that customer held in
DX.CUSTOMER REPORTING.CCY Field.
Depends on which event has triggered the revaluation for a standard ad-hoc
revaluation this key can be the revaluation Id followed by a
Customer/Portfolio/Group depending on the revaluation level set in
RE.VALUE.LEVEL Field in DX.REVALUE file for an EOE the key is
structured using a customer id. EXCHANGE.KEYS Field holds the keys of the
DX.REVALUE.EXCHANGE records that combined to make this
DX.REVALUE.SUMMARY record.

This file details the total margin amounts for a client, portfolio or group, in a
currency on an exchange. This key is dependent on what event has triggered
the revaluation. For a standard ad-hoc revaluation this key can be the
revaluation followed by a Customer/Portfolio or Group. For example,
DXRVL003644*4*GBP*50030-1, DXRVL003644*4*GBP*AA.BB or
DXRVL003644*4*GBP*50030.
For an end of exchange the key is structured using a customer id. Eg.
DXEOE003644*4*GBP*50030

This file details the total margin amounts for a client, portfolio or group, in a
currency on an exchange.
This key is dependent on which event has triggered the revaluation. For a
standard ad-hoc revaluation this key
can be the revaluation key followed by a Customer ID/Portfolio or Group No.
For example, DXRVL003644*4*GBP*50030-1,
DXRVL003644*4*GBP*AA.BB or DXRVL003644*4*GBP*50030.
For an end of exchange the key is structured using a customer ID. E.g.
DXEOE003644*4*GBP*50030
The record in this table holds details of various grouped information.
A link to the revaluation detail maintains the keys, and the application names
relating to those keys.
It also maintain the Total margin figures for this currency and exchange.
It also maintains the margin totals on a contract by contract basis for
Commodities used and their constituents
in the DX.CONTRACT.MASTER

The lowest level files within the revaluation derivatives module’s revaluation
suite are the revaluation detail files. For each record on the
DX.MARGIN.CALC application, an application DX.REVAL.DET should
exist. These files detail the data and calculations used to create the totals in the
DX.EXCHANGE.MASTER file. For a SPAN DX.MARGIN.CALC record
there must be a live file application called DX.REVAL.DET.SPAN existing in
the system

There are currently two standard margin routines provided with the derivatives
module. They are STAND.VM and STAND.IM. Their detail filenames are
DX.REVAL.DET.STAND.VM and DX.REVAL.DET.STAND.IM.
DX.REVAL.DET.STAND.VM detail file holds the data required to calculate
the standard variation margin on a transaction in the derivatives system. The
constituent transactions are grouped in batches by exchange, by strategy, by
contract, and by customer/group/portfolio. This information is held on a
contract-by-contract basis, with a total variation margin and unrealised option
profit and loss. The figure for each transaction is shown along with its
transaction reference and a pointer to the version of transaction copied to the
DX.REVAL.TRANSACTION file as a historical record. For each transaction
the record details the number of lots and the traded price and the current
market price for that contract. DX.REVAL.DET.STAND.IM detail file holds
the data required to calculate the standard initial margin on a group of
transactions in the derivatives system; these transactions are grouped by
exchange, by strategy, by contract, and by customer/group/portfolio.

DX module is required to accept and store prices in the following situations
Manual price input
Automatic price feeds (e.g. Reuters, Telerate, Telekurs)
Batch based price downloads (e.g. SPAN risk parameter files), ability to call a
price model routine and store the returned price
(e.g. Black Scholes), User created speculative or “What If” prices.
The sources of the prices are set-up using the application
DX.PRICE.SOURCE. Prices that need to be updated, called as price sets
are defined using the application DX.PRICE.SET.
The system will value all the portfolios during the revaluation process using a
closing or “fair value” price.
For exchange-based contracts all the exchanges provide an official settlement
price also called EDSP (Exchange Delivery Settlement Price).
For OTC options the prices are often manually input, calculated or received
from an external source.
During the trading day, when the contracts are being traded, current (or last)
prices might be received and the prices
when stored will allow on-line revaluations to take place.

Additionally, users may want to change prices based on market news and then re-
value a portfolio based on these speculative prices.

DX.MARKET.PRICE application is to store the current prices for
Futures/Stocks and Options within the derivatives system. Each of these prices
is related to a price set defined in DX.PRICE.SET. To record the current
market price for a Future or Stock contract the system requires simply that the
price be entered into the contract record, with the optional update of the
INTEREST.RATE and VOLATILITY of the contact. To record the current
price for an Option contract the system requires that Strike prices for that
option be updated as well as the Call Price and Put Price. There is also the
opportunity for that strike price to enter the DELTA, GAMMA and VEGA for
the contract. Again there is the optional update of the INTEREST.RATE and
VOLATILITY of the contact. The DELTA of a contract represents the rate of
change of the option price with respect to the underlying asset. The GAMMA
of the contract represents the rate of change of the delta with respect to the
underlying asset. The VEGA represents the rate of change of the value with
respect to the volatility of the underlying asset. To record the current market
price for a Future or Stock contract the system requires simply that the price be
entered into the contract record, again with the optional update of the
INTEREST.RATE and VOLATILITY of the contact. Therefore the current
price of 94.50 for a December 2007 3MTH EURIBOR Future (12), the
CONTRACT.CODE and PRICE.SET should be entered; the application will
then display the price for that contract and price set etc.

The purpose of the automated price capture suite is to provide the system with
a means to request prices from one of any number of price sources without
user intervention. This means that where a price source such as Black and
Scholes Garman Kohlhagen FX option prices can be update automatically at
the end of exchange.
Examples Black Scholes is the most commonly used method-used to calculate
the value of an European call stock option.
Cox, Ross & Rubinstein (Binomial), Used for equity options - both American
and European style . Prices can be generated with or without dividend
adjustments. Garmen Kohlhagen required data can be input either manually or
through a build routine

Contracts like OTC Options that are required to be priced by a particular price
source will need to be set up on the DX.CONTRACT.MASTER record. The
multi-valued PRICE.SET Field must be filled for current or closing or both
can be set one after the other. The contract must then be linked to the model
(e.g.., Garmen Kohlhagen) through the associated multi valued
PRICE.SOURCE Field. Once this is setup, the system uses the data held in
DX.PRICE for calculating the theoretical option value.

Due to varying time zones, reconciliation takes place at the ‘Intra Day’ rather
than ‘Close of Business’ basis
Settlement prices for each contract (and each maturity month and each strike)
on the exchange are input using DX.MARKET.PRICE
The application DX.COB.WORKFILE used to trigger a valuation

Intraday valuation operates as an online service. You should ensure that the
TSM (Service Manager) is active.
To trigger a valuation , set the Status as “Ready” for valuation and then verify
the record. After a short time re-enter the record and the valuation should have
been processed. You will not be able to enter a deal during the time the
valuation is running (for that customer/exchange pair).
You can “Re-Run” the valuation of previous working day at any time during
the current day.

The item is marked ready for valuation.

The DIARY.TYPE application in Securities module, has corporate actions
defined
For using these records for the Derivatives module, the “DERIVATIVES” flag
is to be set as “Y” on the concerned DIARY.TYPE record
If an event affecting contracts is defined in the derivatives module then it can
be setup as an event in the DX.DIARY application Function of the DX.DIARY
application is essentially the same as the Securities DIARY application, but is
tailored for Derivatives corporate actions Includes options to alter the
lots/strike price/contract size/contract number etc

The derivatives entitlement application DX.ENTITLEMENT acts in much the
same way as the Securities ENTITLEMENT application. DX.ENTITLEMENT
shows Customer/portfolio entitlements per DX.DIARY event. Each maturity
and strike is shown with the new strike, contract size and number of lots.
Records are created via DX.DIARY. They will be created as unauthorised. The
authorisation of these records is controlled by DX.ENT.ACTION. Entitlement
authorisation takes place, using DX.ENT.ACTION, which runs an automated
authorisation of DX.ENTITLEMENTS as per DX. DIARY event. Once the
EX.DATE has arrived or passed then DX ENTITLEMENT records can be
authorised.

While processing corporate actions such as stock splits, to enable specifying of
the type of rounding and rounding factor, DX.CONTRACT.MASTER
contains two fields ROUNDING and RND. FACTOR. DX.DIARY too ,
contains these rounding factor fields. If a new series has been created, then
LINK.CONT.ID Field will contain the new contract Id . These values will be
defaulted in DX.DIARY.

To automatically create new contract master record for the new series due to
such actions, CREATE. CONT Field in DX.DIARY can be set to Y NEW.
CONT. MNE and NEW. EXCH. CODE fields can also be defined for the new
contract master record. Entitlement authorisation takes place, using
DX.ENT.ACTION, which runs an automated authorisation of
DX.ENTITLEMENTS as per DX. DIARY event. Once the EX.DATE has
arrived or passed then DX ENTITLEMENT records can be authorised.

Customer DX position details provides information on maturity date, strike
price, call or put option, exotic type ,brought sold information and other
details. The options in the money, at the money and out of the money provides
information under three groups. Orders Not filled/ Partly filled provides with
the list of DX Orders not filled or partially filled. F&O Trades done today
provides the details of Futures and options done today. List of F&O Trades
provides a list of Futures and Option Trades. Futures by maturity enquiry
provides the list of futures by maturity. Exchange Rates information provides
with details of the currency rates for a specific currency or for all currencies.
The Delivery messages can be viewed by providing the transaction details.

Exotic options have additional rules governing their existence, valuation and
processing.
Knock In is a latent option contract that begins to function as a normal option
only once a certain price level is triggered before expiration.
Knock Out is an option which seizes to exist when a price level is triggered.
Knock Out With Rebate is a barrier option that offers a predetermined rebate,
should the option be 'knocked-out.‘
Double Knock Out is a double barrier option, which is a combination of two
different knock-out levels on either side.
If one of the barriers is reached in a double knock-out option, the option seizes
to exist.
No Touch is an option, which gives an investor an agreed upon payout if the
price of the underlying asset does not trigger a particular price level.
Double No Touch is a type of exotic option that gives an Investor an agreed
upon payout if the price of the underlying asset does not
trigger the two barrier levels, which means the rate has to necessarily remain
within a particular range.
Double One Touch is a type of exotic option that gives an investor an agreed
upon payout if the price of the underlying asset reaches or surpasses one of

two predetermined barrier levels.

Knock Out with Rebate is a barrier option that offers a predetermined rebate,
should the option be 'knocked-out.‘
Instant One Touch Option is an option which gives an investor a payout once
the price of the underlying asset reaches or surpasses a predetermined price
level. Payout immediate.
European Digital is an option that can be exercised only at maturity date. Pays
out fixed amount of asset or cash if the option is in the money at maturity date
European Double No Touch is an Option that can be exercised only at maturity
date. An option which gives an investor an agreed upon payout if the price of
the underlying asset does not reach or surpass either of two predetermined
price levels
European Double One Touch is an Option that can be exercised only at
maturity date. An option which gives an investor an agreed upon payout if the
price of the underlying asset reaches or surpasses one of two
predetermined price levels.
An investor using this type of option pays a premium to his/her broker

depending on the spot, strike, barrier levels, volatility of the underlying,
Forward Reference Rate, maturity date and the payout to be received, if the
price fails to breach either barrier.

Exotic events are not automatically triggered by the system, and all actions
that have been set up for an exotic option type will be triggered only when
EXOTIC.EVENT Field in DX.TRADE or DX.ORDER is set. If any further
automation required, they need to be locally implemented. In this case we can
recommend constructing enquiries that list eligible exotic option deals that
which can be triggered by exotic events.
Many routines have been introduced for downstream processing of Exotic
Options.
The option processing routine needs to be attached to the CO.PGM Field of
DX.OPTION.TYPE. The attached routine will be launched when the
EXOTIC.EVENT flag on DX.TRADE is set.
FX OTC Options premium/price can either be denominated in the contract

currency or any other valid currency. System will allow the user to input
premium quoted in PIPS in the premium currency/contract currency or the
total premium in premium currency/contract currency. System will update the
other related fields using the exchange rate which can be user
defined/defaulted, contract size and number of lots.

For FX OTC Options, a Single Generic Contract Master would suffice. This
Contract Master should have a Contract Class that is FX-Option and Exchange
as OTC. A Contract class will be considered an FX Option if the new field
Contract Type is set as FX-Option. An FX OTC Contract Master would be
easy to create with several fields not requiring any input.
At the time of Trade Input, user will need to fill in the Trade Currency and
Delivery Currency that form the Currency Pair. User will also have to fill the
Strike Quote and the Currency in which the Strike is Quoted, which can be
either the Trade Currency or the Delivery Currency. The Option Style,
whether American or European would default from the Generic Contract
master but can be altered at the Trade level.
The Market Price record will now hold the Delivery Currency and Option
Style, thus enabling one to record prices for different currency pairs eg USD
GBP and GBP USD. Similarly DX Positions will be recorded separately for
different Currency pairs.

There are standard routines available to process the exotic options. Some of
them are discussed here.
DX.XO.CREATE.EURO routine can be used for a vanilla European style.
DX.XO.CREATE.FX routine can be used to create an underlying FX deal.
DX.XO.CREATE.FX.KNOCKOUT can be used to create the underlying FX
deal in case of knockout options
The derivatives price application DX.MARKET.PRICE holds a list of “Greek”
values in the option pricing. Delta, Theta, Gamma, Vega and Rho values are
available, as well as volatility.
Values are available for both call and put positions.

Upto 9999 records can be created in INDUSTRY and SECTOR.
It is very likely that a Bank may wish to make changes from time to time in
Industry and / or Sector classification. New industries may emerge. It is also
likely that a Customer engaged in a particular industry may change his line of
activity.
In these cases, the new reports have to reflect the current picture. T24
automatically takes care of these changes incorporated in respective
CUSTOMER records.

activity.
CUSTOMER records.

The Sector is one of the main elements for classifying customers. It is purely
descriptive and the additional sectors may be added by direct input to the
SECTOR table. It is however, very significant in that in many
grouping/classification definitions, as in CONSOLIDATE.COND,
CONDITION.PIORITY, ACCOUNT.CLASS etc., SECTOR is used.
Mention of Department Account Officer aids in determining the departmental
profit and loss from this customer.
Industry identifies the Industry in which the Customer is trading and can be
used for several purposes including checking commodity limits.
For determining Nationality and Residence, Country table is used.
Customer status indicates the status of the customer like for example, sound,
bankrupt, deceased etc.

activity.
CUSTOMER records.



activity.
CUSTOMER records.



activity.
CUSTOMER records.

activity.
CUSTOMER records.

activity.
CUSTOMER records.

activity.
CUSTOMER records.

activity.
CUSTOMER records.

activity.
CUSTOMER records.

activity.
CUSTOMER records.

activity.
CUSTOMER records.

activity.
CUSTOMER records.

activity.
CUSTOMER records.

activity.
CUSTOMER records.

activity.
CUSTOMER records.

activity.
CUSTOMER records.

An interest rate cap with a single settlement date is called an interest rate
guarantee (IRG).
The purchaser of an interest rate cap is the party to whom any such difference
will accrue.
The purchaser pays a premium for this entitlement. This premium is expressed
in basis points
of the notional amount and is paid once the contract is agreed. The price
premium is influenced by the following elements: Current market interest rate,
Strike, Duration and volatility.
Buying an interest rate cap is comparable with buying a call option with
reference to an interest rate.
Buying of Caps is done with a view that the interest rates will raise over a
period of time.
Once purchased, a cap cannot be sold; it can only be “closed” by the sale of a
comparable interest rate cap.
A floor is nothing but the opposite to a cap. DX.TRADE fields like
CAP.FLOOR are built to handle such requirements.

An Interest Rate Swap is an agreement between two parties to exchange
interest payments based upon a specified notional principal amount for a
specified term. One interest payment is typically calculated using a floating
rate index
such as LIBOR or Prime. The other interest payment is based upon a fixed rate
or a different floating rate index.
The deal is done on notional basis.
A swaption is nothing but an option granting the buyer the right but not the
obligation to enter into an underlying swap. Although options can be traded on
a variety of swaps, the term "swaption" typically refers to options on interest
rate swaps.
Swaptions can be of two types
In the Payer Swaptions, the buyer obtains the right during a predetermined
period or at a predetermined date to enter into an Interest Rate Swap for which
the life, currency and notional amount are stated in the contract.
In the Receiver Swaptions, the buyer obtains the right during a predetermined
period or at a predetermined date
to enter into an Interest Rate Swap for which the life, currency and notional
amount are stated in the contract.

DX.TRADE and DX.ORDER cater to such transactions.
This product needs some configuration based on the need.

The separate tab on swaption can be used to store the information related to
swaptions
SWAP.DELIVERY field is used to define whether the delivery will be CASH
or PHYSICAL
SWAP.MAT.DATE field is used to define the maturity date for the swap
transaction
PAY.TYPE field is used to define whether we pay FIXED or FLOATING
RECEIVE.TYPE field is used to define whether the counterparty receives
FIXED or FLOATING
AS.PRINCIPAL and LB.PRINCIPAL are used to define the asset and liability
side notional
AS.DAY.COUNT and LB.DAY.COUNT are used to define the day basis for
the asset and liability side
AS.FIXED.RATE and LB.FIXED.RATE are used to define the asset side or
the liability side fixed rate
AS.FLOAT.KEY and LB.FLOAT.KEY are used to define the asset side or the
liability side floating rate key from BASIC.INTEREST
AS.SPREAD and LB.SPREAD are used to define either the asset or the
liability side spread when floating rate is defined

AS.INTEREST.FREQUENCY and LB.INTEREST.FREQUENCY are used to define
the asset and liability side interest frequency
AS.RR.FREQUENCY and LB.RR.FREQUENCY are used to define the rate reset
frequency for the asset or liability side
SWAP.REFERENCE field is used to link swap contracts that are created by exercising
the swaption. This need to be done manually

Derivatives module in T24 uses ‘Soft Delivery’ which enables the user to
define the output of the delivery messages in S.W.I.F.T. or printed output. This
used a core routine EB.HANDOFF to initiate and pass information to the
Delivery system.
Delivery messages are generated whenever a derivatives DX.EVENT.TYPE
event is processed, i.e. DX.TRADES are entered, amended or reversed.
Delivery messages are also generated when a DX.CLOSEOUT is performed.
The content of all delivery messages will be based on the
DX.TRANSACTION file. Messages can be produced for any action including
corporate actions/option exercise/ assignments etc… Any new event added to
the module will therefore be automatically available as having a possible link
into the deliveries module.
Until the DX.EVENT.TYPE field EB.ACTIVITY field is populated with a
delivery activity to perform, the system will not generate any delivery
messages.

For Delivery to work properly the following EB.ACTIVITY records should be
created.
Once a selection of a DX.EVENT.TYPE has been populated within
EB.ACTIVITY then processing can take place for those events.
The following delivery messages are generated
DX-4000 (Trade Confirmation)
DX-4010 (Trade Amendment)
DX-4020 (Trade Reversal)
DX-4040 (DX.CLOSEOUT confirmation)
A description is all that is needed for each item
Once created they should be assigned to the relevant DX.EVENT.TYPE
records in EB.ACTIVITY Field.

DX.TRADE and DX.ORDER applications include delivery instructions fields
used for FX options. These fields take the form of the field held on the T24
FOREX application and are associated with each possible side of the trade.
These fields include beneficiary information, counter party information, inter-
bank information, using the same basic defaulting as the FOREX application.
This information is used as part of the derivatives originated Swift Messages.

The LIMIT system is designed to monitor, in real-time, the availability and
utilization of customer Limits. End-of-day reports are available to allow the
monitoring of limits for commodities, countries, country groups and
currencies.
The term LIMIT describes a facility or credit line available to a customer or
group of customers, while the term LIMIT.REFERENCE describes a type of
LIMIT, e.g. Futures and Options Limit.
T24 Limits structure allows a hierarchy of Limit Products, such that Limits
can be set up for different classes of contracts, e.g. Bonds, Shares, Currencies
or Commodities. You can set the amount to be used for updating Limit
utilisation by setting the LIM.AMT.VAL.CONT Field of DX.PARAMETER
to either CONTINGENT or VALUE.
The Limit Reference conditions for DX.TRADE are defined using
LIMIT.PARAMETER, for example Currency Futures can be set to a different
Limit Reference and Currency Options a different one. Whenever a trade
takes place for a relevant derivative product and portfolio, then a limit check
will take place, which will generate an override if the Limit has been exceeded
or not created.

If CHECK.CUST.FUNDS on DX.PARAMETER is set to ‘YES’, a ‘best
estimate’ initial margin amount for each transaction input (order or trade) will
be calculated. Customer funds will be blocked until the next Initial Margin
calculation run (when the funds are physically removed from the customer’s
account in any case) and also a forward dated (to the notional maturity date)
‘unblocking’ will be posted.

This function would typically be used where one bank entity was taking
customer orders, but for regulatory reasons only a separate bank entity was
allowed to trade the instrument in question with an exchange/broker.

The effect of setting the TRANSFER.TYPE flag to one of the above values is
as follows: Postings to accounts that would normally be made at trade time
will NOT occur. These include:
• Option premiums (if premium post time set to ‘TRADE’)
• Commissions and fees (if charge post time set to ‘TRADE’)
• Contingent entries for own-book portfolios
• No update to LIMIT will be performed.
• No DELIVERY messages will be produced.
Apart from these changes, the trade will behave as a normal derivatives trade,
i.e. will be subject to revaluation during DX.COB.WORKFILE processing,
and any postings that are due when the trade is closed out or matured will also
be made.

Blocking deals introduces an automated mechanism for equity options. If the
underlying asset (shares or possible bonds) has been used to ‘cover’ one or
more option contracts, then that asset cannot be sold via the Securities module
whilst the option contract is still active.
Margin requirements for written (sold) option trades can be reduced if the
counter party, selling the option, is in possession of the underlying asset . This
has all been achieved using a new development of OFS to drive the main
Securities position blocking utility (SC.BLOCK.SEC.POS).
In order to activate this functionality a valid OFS.SOURCE should be entered
in the DX.PARAMETER OFSSOURCE field.
In order to block a securities position on short covered call position
HEDGE.TRADE on DX.TRADE must be set to COVERED.
If the requirement cannot be met the deal will be marked as UNCOVERED in
HEDGE.TRADE and the user informed.

The replacement cost of the derivative is the actual market value of the
contract whereas add-on is a certain percentage of the nominal or underlying
contract amount. For Derivative trades, this percentage depends on the sub
asset type and remaining time to maturity of the contract. However in case of
interest rate derivatives alone, original life of the underlying applies.

Calculation of credit exposure – Methodology Routine
DX.BB.CREDIT.EXPOSURE created for calculating credit exposure, requires
to be attached in CR.EXP.CALC.API Field in DX.PARAMETER. An interest
rate derivative can be indicated as YES in INT.RATE.CONTRACT Field in
DX.CONTRACT.MASTER, along with input in LIFE.UNDERLYING Field.
Add on percentage applicable for regulatory and credit reporting needs to be
defined in a REVAL.ADDON.PERCEN table record, based on the sub asset
type.
The replacement cost of the derivative is the actual market value of the
contract whereas add-on is a certain percentage of the nominal or underlying
contract amount. For Derivative trades, this percentage depends on the sub
asset type and remaining time to maturity of the contract. However in case of
interest rate derivatives alone, original life of the underlying applies.
the derivative module has been enhanced to allow the valuation of historical
positions passed by Asset Management module using the historical prices input
and stored in derivatives module. The historical values so calculated for the
given positions are passed back and updated in the files of Asset Management
module for downstream processing at that end.
For this purpose, existing live file DX.PRICE.HISTORY has been enabled to
allow direct input of historical prices. However, records in
DX.PRICE.HISTORY file can be changed or created only if the price set is

defined in the DX.PARAMETER and date stamp is within the period defined in
DX.PARAMETER to store historical prices

Trade transfer allows transfer of trades between portfolios and customers -
both internally and externally. The transfer can be performed with or without
account postings or any confirmations being generated. It can be parameterised
on individual transfer basis
Fields added to DX.TRADE, DX.TRANSACTION and DX.CLOSEOUT.
DX.CO.XFER.MANUAL and DX.CO.EXT.XFER.MANUAL applications to
handle such transfers .New DX.EVENT.TYPE records to be set up for this
purpose like CN – Internal Transfer (Transferor Side), II – Internal Transfer
(Transferee Side) CO – External Transfer (Outgoing) , CT – External Transfer
(Incoming)

It is possible to transfer deals from one customer to another or from one
customer’s portfolio to another
New DX.TRADE transfer transaction will be automatically generated between
the transferor and the transferee for the number of lots defined in the
DX.CO.XFER.MANUAL record at the price defined in PRICE.TRADED
Field
On committing the transfer, new DX.CLOSEOUT record will also be
generated which when committed, removes the position on the Transferor’s
side . Positions held will now be between the Transferee and the original
counterparty.
For external transfers, DX.CO.EXT.XFER.MANUAL application is used. On
authorising the DX.CLOSEOUT record, the internal position for the transferor
is removed, and, a delivery message is generated.

We have so far seen how the Derivatives module in T24 can be setup. We have
seen the functionality of the module to handle the varied requirements of
derivatives trading


T3TDX - Derivatives - R15 PDF

Uploaded by

Copyright:

Available Formats

T3TDX - Derivatives - R15 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

T3TDX - Derivatives - R15 PDF

Uploaded by

Copyright:

Available Formats

T24 Derivatives- T3TDX - R15 1

Introducing participants to T24 Derivatives module.

T24 Derivatives- T3TDX - R15 2

T24 Derivatives- T3TDX - R15 3

T24 Derivatives- T3TDX - R15 3

T24 Derivatives- T3TDX - R15 4

T24 Derivatives- T3TDX - R15 5

T24 Derivatives- T3TDX - R15 6

T24 Derivatives- T3TDX - R15 6

T24 Derivatives- T3TDX - R15 7

T24 Derivatives- T3TDX - R15 8

T24 Derivatives- T3TDX - R15 10

T24 Derivatives- T3TDX - R15 11

T24 Derivatives- T3TDX - R15 12

T24 Derivatives- T3TDX - R15 12

T24 Derivatives- T3TDX - R15 13

T24 Derivatives- T3TDX - R15 14

T24 Derivatives- T3TDX - R15 15

T24 Derivatives- T3TDX - R15 16

T24 Derivatives- T3TDX - R15 17

T24 Derivatives- T3TDX - R15 18

T24 Derivatives- T3TDX - R15 19

T24 Derivatives- T3TDX - R15 20

T24 Derivatives- T3TDX - R15 21

T24 Derivatives- T3TDX - R15 22

T24 Derivatives- T3TDX - R15 23

T24 Derivatives- T3TDX - R15 24

T24 Derivatives- T3TDX - R15 25

T24 Derivatives- T3TDX - R15 25

T24 Derivatives- T3TDX - R15 32

T24 Derivatives- T3TDX - R15 33

T24 Derivatives- T3TDX - R15 34

T24 Derivatives- T3TDX - R15 35

T24 Derivatives- T3TDX - R15 36

T24 Derivatives- T3TDX - R15 37

T24 Derivatives- T3TDX - R15 38

T24 Derivatives- T3TDX - R15 39

T24 Derivatives- T3TDX - R15 40

T24 Derivatives- T3TDX - R15 42

T24 Derivatives- T3TDX - R15 44

T24 Derivatives- T3TDX - R15 45

T24 Derivatives- T3TDX - R15 46

T24 Derivatives- T3TDX - R15 47

T24 Derivatives- T3TDX - R15 48

T24 Derivatives- T3TDX - R15 49

T24 Derivatives- T3TDX - R15 50

T24 Derivatives- T3TDX - R15 51

T24 Derivatives- T3TDX - R15 52

T24 Derivatives- T3TDX - R15 53

T24 Derivatives- T3TDX - R15 54

T24 Derivatives- T3TDX - R15 55

T24 Derivatives- T3TDX - R15 56

T24 Derivatives- T3TDX - R15 57

T24 Derivatives- T3TDX - R15 58

T24 Derivatives- T3TDX - R15 59

T24 Derivatives- T3TDX - R15 60

T24 Derivatives- T3TDX - R15 61

T24 Derivatives- T3TDX - R15 62

T24 Derivatives- T3TDX - R15 63