Derivatives Unlocked

Derivatives User Guide
Derivatives User Guide 1

Derivatives Overview 7
Design Principles 8
Derivatives Configuration 10
Accounting 11
Alternate Indexes 13
Commissions 15
Scenario 1 18
Scenario 2 20
Contracts 21
DX.CONTRACT.CLASS 22
DX.CONTRACT.MASTER 23
Basic Contract Information 24
Pricing Data 25
Contract Size Information 26
Maturity Date Validation and Key Contract Dates 28
Other Contract Information 31
Exotic Options 32
Setting Up Exotic Options 34
Black Box Routines 35
Example Setups 37
Credit Default Swap 40
Knock In Option 44
Knock out with Rebate 45
Calculation of Initial Margin 50
Calculation of Variation Margin 51
Customers 52
Events 54
Standard Event Types 55
Commissions and Charges Posting 57
Event Based Reporting 59
Full List of Event Types 60
Exchanges 62
Groups 64
Local Currency Conversion of DX Contracts 65
Margins 66
DX.MARGIN.CALC 67
DX.MARGIN.RATES 68
Parameters 70
Contingent Postings and Product Categories 71
Automatic Expiry or Exercise 72
Automatic Tidying of Cash Settlement Feeds 73
Average Price Positions 74
Back to Back Closeouts 75
Best Rate 76
Blocking of Securities Positions 77
Calculation of Credit Exposure 78
Customer Available Funds Checking 79
Derivatives User Guide- Release R12.00 -Page 2 of 303 - (c) Temenos Systems 2012
Revaluation P&L 80
Straight Through Processing 81
Pricing 82
DX.PRICE.SET 83
DX.PRICE.SOURCE 84
Routing 85
Strategies 86
Trading Constraints 87
Position Management DX entries 89
Derivatives Deal Processing 91
Trade Capture 92
Trade Data Common to All Parties to a Trade 93
Strategy Linking 98
Commissions and Charges 99
Contract Balances 103
Order Capture 104
Data Take-on 107
Price Capture 108
Futures and Stock Prices 110
Option Prices 111
Futures/Stock Contracts 111
Option Contracts 113
Automated Price Capture 115
Price Calculation 118
Price/Premium Terminology 119
Variable Tick Size Calculations 122
Australian Treasury Bill SFE Futures and Options 123
90-Day Bank Bill Futures Tick Value Calculations 123
90-Day Bank Bill Options 125
Australian Government Bond SFE Futures and Options 126
Australian Commonwealth Treasury Bonds 127
SFE 10-Year Treasury Bond Futures 128
10-Year Treasury Bond Futures Tick Value Calculations 129
10-Year Treasury Bond Options 130
Example Contract Key Date Calculation 133
Price Calculation Methods 134
Black and Scholes 135
Cox, Ross & Rubinstein (Binomial) 136
Garman-Kohlhagen 137
Closing Out Trades 142
Manual Closeout 145
Automatic Closeout 147
Maturity Closeout 148
Futures/Stock Cash/Maturity Closeouts 150
Option Maturity Closeout 151
Assignment, Expiry and Exercise 154
Manual Assignment 154
Manual Exercise 157
Manual Expiry 161
Automatic Processing 163
Trade Transfer 166
Corporate Actions 170
Strike Price Rounding and Creation of New Series 173
Exotic Options 175
Customer Position Reporting 176
Position Reporting 178
Transaction Reporting 180
Transaction Status 183
Trading Commissions Diagnostics 186
Revaluation and Margins 189
Revaluation Summary 190
Revaluation for Exchange 191
Revaluation Details 192
DX.REVAL.DET.CHREG.VM 193
DX.REVAL.DET.STAND.IM 194
DX.REVAL.DET.STAND.VM 195
Exchange defined Initial margin Requirements 196
Adhoc Revaluation 197
Initial Margin Methods 199
AEX Euronext 200
OCC/TIMS Margining 206
Securities Portfolio Valuation 211
Handling premiums in any currency for FX OTC Options trades 213
Derivatives Accounting 217
Taxes in Derivatives 218
Contingent Asset/Liability 221
Trade/Value Dated Accounting 222
Commissions and Charges 222
Initial Margin 224
Closeouts 225
Enhanced Unrealised P&L (Variation Margin) Postings 226
Derivatives Delivery 227
Outward Delivery 228
EB.ACTIVITY 229
DE.MESSAGE 230
DE.MAPPING 231
EB.ADVICES 233
DE.FORMAT.PRINT 234
Derivatives Limits 235
Example Limit Setup 238
Derivatives Limits 240
Limits Overview 243
Derivatives Non Stop Processing 244
Derivatives Services 245
DX.COB.WORKFILE 246
End of Exchange Day Processing 246
Revaluation 247
Derivatives API 249
Local Routine Insertion Points and API 249
Accounting Entries 251
Accounting Entries for Tax on Closeout 252
Alternate Index Validation 252
Automatic Closeout matching 254
Automatic Trade Assignment 254
Calculation of Exposure 255
Calculation of Initial Margin 256
Calculation of Net Cost 258
Calculation of Theoretical Prices 259
Calculation of Variation Margin 261
Exotic Option Closeout Processing 262
Exotic Option User-Field Validation 263
Order Lot Assignment 264
Price conversion to internal format 265
Valuation of Futures Position 266
DX.AI.CUSIP 267
DX.BB.CREDIT.EXPOSURE 267
DX.CALC.NET.COST 268
DX.CO.AM.FIFO 269
DX.CO.AM.FIFO.DAY 269
DX.CO.AM.LIFO 270
DX.CO.AM.LIFO.DAY 271
DX.CO.AS.FCFS 272
DX.CO.PGM.NOACTION 273
DX.FUT.EST.METHOD.THREE 274
DX.ORD.ASSIGN.FIFO 275
DX.ORD.ASSIGN.PRO.RATA 276
DX.PR.BINOMIAL 277
DX.PR.BLACK.SCHOLES 278
DX.PR.BUILD.BS 279
DX.PR.BUILD.GK 280
DX.PR.GARMAN.KOHLHAGEN 281
DX.RV.CHREG.VM 282
DX.RV.ENHANCED.IM 283
DX.RV.EURONEXT 283
DX.RV.FXOPT.VM 284
DX.RV.NO.IM 285
DX.RV.NO.VM 286
DX.RV.OCC.TIMS 287
DX.RV.STANDARD.IM 287
DX.RV.STANDARD.VM 287
DX.STAND.AS.RANDOM 288
DX.XO.CREATE.EURO 289
DX.XO.CREATE.FX 290
DX.XO.CREATE.FX.KNOCKOUT 290
DX.XO.CREATE.FX.REBATE 291
DX.XO.CREATE.SEC 292
DX.XO.CREATE.SEC.KNOCKOUT 293
DX.XO.FWDCASHPAYOUT 294
DX.XO.INSTANT.CASHPAYOUT 294
DX.XO.KNOCKIN 295
DX.XO.KNOCKOUT 296
Revaluation Black Boxes 297
Black Box Templates 299
Initial Margin Black Boxes 300
Variation Margin Black Boxes 302
Derivatives Overview
Derivatives is part of the Treasury suite of products.
Futures and options may be traded in two ways: through recognised derivatives exchanges or in OTC (‘Over the Counter’) transactions directly
between two parties.
Exchange traded futures and options must conform to the standard contract specifications published by the relevant exchange. Trades are
passed through a clearinghouse associated with the exchange, which assumes liability should one party default. They are relatively well reg-
ulated.
The specifications for contracts traded ‘Over The Counter’ are agreed between the parties to the trade, giving considerably more flexibility. OTC
trades are cheaper to execute since there are no exchange or clearing fees to be paid, but riskier since there is no insurance against one party
defaulting.
When a trade is agreed, a position is taken as a result. The buyer of the contract is said to be ‘long’ in the contract, and the seller to be ‘short’.
Exchanges and brokers require a ‘deposit’ called the Initial Margin to cover the risk to the exchange or broker of their counter party defaulting
on their commitment. The exchange supplies an algorithm that must be used to calculate this figure. When a position consists of many active
trades and new trades are being added or closed daily, this figure is recalculated each day.
Option contracts require the payment of a ‘premium’ by the buyer, which is effectively the cost of purchasing the right to buy or sell the under-
lying asset or product. This represents the maximum loss for the buyer of an option contract, since if the market moves against the buyer's
expectation they will allow the option to be expired (see below) and lose the premium amount rather than a much bigger loss had they taken up
their option.
During the life of a contract it is revalued. The most common form of valuation is ‘Mark to Market’, where the price at which the contract was
traded is compared with the current ‘fair value’ for the contract (typically the latest official market price for the product) to yield a profit or a
loss. An example would be a futures contract bought at USD110 per lot – a month into the life of the contract the market price for the same
contract is USD115 per lot. Using the mark to market valuation the buyer has an unrealised profit of (115-110) = USD5 per lot. This may also
be referred to as the ‘variation margin’.
An active futures contract may either mature with some form of delivery of the underlying asset, or be ‘closed out’ against another active con-
tract, i.e. a buy trade and a sell trade for the same contract that meets certain conditions can be linked and removed from the active position. A
realised profit and loss is generally produced at these times, based on the trade price vs. the latest ‘fair value’ for maturities or the difference
between the buy price and the sell price if two trades are closed out.
An active option contract may be closed out as above or at the option contract buyer’s discretion, may be ‘exercised’, (the option taken up and
the underlying asset or product delivered or activated) or ‘expired’ (the option simply abandoned – the buyer loses the premium amount but
nothing more).
l Design Principles
(c) Temenos Systems 2012
Design Principles
The Derivatives product has been developed to allow trading of futures and ‘vanilla’ options initially. The product supports trading, position
keeping, valuation and closing out of both exchange-traded and OTC contracts.
The Derivatives product may be used by: banks trading on their own behalf, by banks trading on behalf of their customers or by banks offering
their customers brokerage services.
Derivatives has been designed to cope with the rapid changes and developments experienced in the derivatives market by adopting a ‘black box’
architecture for certain key elements of the system such as margin and profit and loss calculations.
The philosophy of the Derivatives product is that a detailed static data set up will enable the bank to tailor the product to their needs and mini-
mise the amount of manual intervention required to run the system day-to-day. The Bank can input comprehensive data to define the products
and exchanges they or their customers may trade.
Derivatives perform on-line real-time updates of derivatives trading positions and cost of positions. Full revaluations may be performed at any
stage during the system day for reporting purposes, and the End of Exchange process may either be run online or during the main T24 batch
run to generate and post to the accounts the ‘official’ margin figures.
All operations carried out in Derivatives raise a record in the main derivatives transaction file. This file provides a comprehensive record of a
customer’s activities within the Derivatives module and is the basis for most client reporting/statements etc. Each transaction is also asso-
ciated with one or more ‘events’ in the life of a contract that form the basis of the module’s event-driven accounting updates.
Derivatives Configuration
This section describes the implementation and configuration of Derivatives, which is part of the Treasury suite.
The following areas will need to be configured when implementing Derivatives:
l Accounting
l Alternate Indexes
l Commissions
l Contracts
l Customers
l Events
l Exchanges
l Groups
l Local Currency Conversion of DX Contracts
l Margins
l Parameters
l Pricing
l Routing
l Strategies
l Trading Constraints
Accounting
In order for the application ccounting to operate correctly some static data set-up is essential. This section contains a list of tables to be
updated with guidelines for what should be included in the data set.
ACCOUNT.CLASS
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’, as fol-
lows:
ACCOUNT.CLASS ID Type Description
SUSPDXIMCR Account Suspense account for credit initial margin
SUSPDXIMDR Account Suspense account for debit initial margin
SUSPDXVMCR Account Suspense account for credit futures variation margin
SUSPDXVMDR Account Suspense account for debit futures variation margin
SUSPDXOMCR Account Suspense account for credit option variation margin
SUSPDXOMDR Account Suspense account for debit option variation margin.
SUSPDXCGCR Account Suspense account for credit derivatives charges
SUSPDXCGDR Account Suspense account for debit derivatives charges
SUSPDXPRCR Account Suspense account for credit option premium payments
SUSPDXPRDR Account Suspense account for debit option premium payments
SUSPDXRPCR Account Suspense account for credit realised P&L
SUSPDXRPDR Account Suspense account for debit realised P&L
DXCSNDUE P&L ‘Suspense’ P&L category for derivatives commission due not paid (not utilised until phase 2)
DXCSNEARN P&L ‘Suspense’ P&L category for derivatives commission earned not received (not utilised until phase 2)
DXCSNPAID P&L ‘Suspense’ P&L category for derivatives commission paid
DXCSNRCVD P&L ‘Suspense’ P&L category for derivatives commission received
ACCOUNT.CLASS records for Derivatives Accounting
Note when setting up the ACCOUNT.CLASS records, it is important to consider which categories are to be used. If different categories are used
for the Debit and Credit ACCOUNT.CLASS(s) then the two Internal Suspense accounts will net to zero, however the balances on the individual
accounts will continue to grow in a +ve or –ve direction. In many cases it would be 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.
CATEGORY
CATEGORY codes needing to be set up are divided into three types.
Inte r na l A c c ount C a te gor ie s
Should be set up for all non-P&L ACCOUNT.CLASS records (see the ACCOUNT.CLASS section).
Also required for TT – tax posting, PP – option premium posting and IM – initial margin posting DX.EVENT.TYPE records
A ‘dummy’ internal account CATEGORY code should be set up for entry onto DX.EVENT.TYPE records where the category code is not used
(CA, CC, CI, CR, UO) and also for DX.EVENT.TYPE records for commission/fee postings where the USE.FT.TXN.CODE flag has been set.
As with all applications using the T24 accounting suite, at least one internal account should be set up manually for each internal account cat-
egory code entered. The system will then be able to open internal accounts in all other currencies automatically.
It is possible to nominate a preferred wash account currency for posting option premiums to an internal account. This is controlled through
the WASH.ACC.TYPE field in DX.EVENT.TYPE. The possible values are blank, “Local” and “Trade”. This value can only be applied spe-
cifically to the PP record in DX.EVENT.TYPE attempts to utilise this functionality against any other records should produce an error
When no currency (Blank) type is defined the posting will occur in the reference currency for the customer
When “Local” type is selected, the postings occur in the system local currency
When “Trade” type is selected, the postings occur in the currency of the contract
Pr oduc t C a te gor ie s
A product category in the appropriate range should be set up for each DX.CONTRACT.CLASS defined by the bank (see the section on Con-
tracts).
P& L C a te gor ie s
Should be set up for the following DX.EVENT.TYPE RECORDS: CM – contract maturity (realised P&L), VM – variation margin, RP – realised
P&L, OM – option variation margin, RO – realised option P&L.
Also should be set up for commission/fee posting event types if DX.EVENT.TYPE category codes to be used for posting P&L rather than cat-
egory codes generated by CALCULATE.CHARGE.
It is possible to setup a P&L category for the PP event type. This will cause the Premium Posting for the own book transaction to be booked
directly to a P&L entry in CATEG.ENTRY
RE.TXN.CODE
Descriptions of transaction types used in the updating of the CRF are held in this table. The following new transaction codes are required:
RE.TXN.CODE Description
CLO Derivatives contract closeout
UOV Derivatives unrealised option value
TRANSACTION
Each DX.EVENT.TYPE record requires the entry of a debit and a credit transaction code (though these may be the same transaction code if
required). The user should set aside a range of transaction codes for Derivatives accounting.
Alternate Indexes
A standard T24 routine exists to generate the CUSIP number for options in DX. This routine which can be attached to a multi-value in the
Derivatives alternate index fields will generate a CUSIP for any option that has a CUSIP number assigned to an underlying securities contract.
The SECURITY.MASTER for the underlying Security must be setup with a CUSIP number in the CUSIP.NO field, this linked to a derivatives
DX.CONTRACT.MASTERrecord when the UNDERLYING field has the SECURITY.MASTER record selected. The first 6 digits of that CUSIP
are then taken as the stem of the derivatives extended CUSIP number.
For example IBM has a CUSIP of 459200101 therefore the stem of any CUSIP number assigned to an option in DX will begin 459200.
The extended CUSIP consists of a “stem” code (6 characters) plus 3 additional characters that identify the underlying product. For options on
IBM shares the suffix is changed to the pre–determined characters for the appropriate option, making this an extended CUSIP.
E.g. IBM March 95.00 Put Options @ 0.05 would be 4592009OS.
The seventh digit is always 9 to indicate that it is an option. Except when it is a LEAP contract, when the seventh digit may be an 8
Maturity & Call Put Indicator

The eighth character indicates the exercise month of the option and if it is a CALL/PUT option, according to the following table.
Month Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
CALL A B C D E F G H I J K L
PUT M N O P Q R S T U V W X
Str ik e Pr ic e C ode s
The ninth character indicates the strike/exercise price of the option, according to the following tables.
Key A B C D E F G H I J
Strike Prices 5 10 15 20 25 30 35 40 45 50
105 110 115 120 125 130 135 140 145 150
205 210 215 220 225 230 235 240 245 250
305 310 315 320 325 330 335 340 345 350
… … … … … … … … … …
Key K L M N O P Q R S T
Strike Prices 55 60 65 70 75 80 85 90 95 100
155 160 165 170 175 180 185 190 195 200
255 260 265 270 275 280 285 290 295 300
355 360 365 370 375 380 385 390 395 400
… … … … … … … … … …
Key U V W X Y Z
Strike Prices 7½ 12 ½ 17 ½ 22 1/2 27 ½ 32 ½
37 ½ 42 ½ 47 ½ 52 ½ 57 ½ 62 ½
67 ½ 72 ½ 77 ½ 82 ½ 87 ½ 92 ½
97 ½ 102 ½ 107 ½ 112 ½ 117 ½ 122 ½
… … … … … …
Options contracts can trade as LEAPS. Long Term E quity Anticipation S ecurities (LEAPS) are option contracts that expire more than 9
months in advance, and can last as long as 2 years. Normal options tend to last no longer than nine months. Equity LEAPS usually expire in
Jan, Index LEAPS expire in Dec/Jan. Interest LEAPS expire in Dec.
If equity LEAPS are trading at the same time as a normal equity option, with the same expiry month and strike prices, then the seventh digit of
the extended CUSIP will be an ‘eight’.
When a trade has been assigned an extended CUSIP number it will keep the same extended CUSIP number until the trade has been expired
Commissions
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:
l ‘System’ level default for all conditions.

l Group level defaults for groups of customer set up within DX.GROUPING.
l Group level defaults for groups of contract set up within DX.CONTRACT.CLASS.
l Individual level defaults for a specific customer set up within DX.CUSTOMER.
l 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.COMMSNin the
applicationDX.PARAMETER (SYSTEM record)If this field is set to NO then once a record has been matched with the key then no further rec-
ords will be searched. If the field is set to YES, then each record found will be searched to find matching extra criteria.
The commission codes may be entered in the following formats:
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- Customer 100018, Contract 100

CT100
CU100018- Customer 100018, Contract Class

CCGILTS GILTS
CGINT2-CT100 Customer Group INT2, Contract 100
CGINT2- Customer Group INT2, Contract Class
CCGILTS GILTS
SYSTEM System level defaults
So that the system knows how to interpret the input, a two-character prefix is used to identify each element, the application also recognises
mnemonics used by the source applications.
The extra criteria for determining the calculation of commission and charges are defined within DX.COMMISSION. The field FIELD.NAME con-
tains a drop down list of fields from DX.TRADE. When a field is selected, the contents from the trade will be compared, using the entry in the
OPERATOR field, against the values input into FIELD.FROM and FIELD.TO. These fields are sub valued so that one or more tests can be com-
bined for even greater refinement. Note that secondary side fields on the trade are not listed in FIELD.NAME. If a primary side trade field is
selected, then the corresponding secondary trade field name is displayed in SEC.FIELD.NAME. This will consequently be used in tests for cus-
tomers, which appear on the secondary side of the trade.
This screenshot shows a

test, which requires two
conditions to be sat-
isfied. These are:
1. The trade cur-

rency is equal to “USD”.
2. The number of
lots is between 10 and
20.
If either condition
proves to be false for the
trade, then the com-
missions specified in
this test set will not be
used.
DX.COMMISSION SYSTEM Record
Once the trade details
have been matched, up Commission Type Field Name
to five different types of
commission and charges Commissions COMM.CHARGE
can be calculated.
Execution fees EXFEE.CHARGE
Each type can contain a
commission/charge code Clearing fees CLFEE.CHARGE
linked to either FT.CO- Regulatory fees RGFEE.CHARGE
MMISSION.TYPE or
FT.CHARGE.TYPE. Miscellaneous fees MISC.CHARGE
The types of com-

mission/charges and
fields in which they are
entered in are given on
the right here.
More than one com-

mission code can be
entered for each com-
mission type, but there
is only one commission
currency per type. If a
commission currency is
specified then this will
override whatever cur-
rency is defined on
FT.COMMISSION.TYPE
or FT.CHARGE.TYPE.
The field CHARGE.PE-

RCENT contains a per-
centage multiplier to
apply to the charge
amounts calculated.
However this is per-
formed on types com-
mission, execution and
clearing fees only.
A couple of examples are presented to show some simple commission scenarios.
l Scenario 1
l Scenario 2
Scenario 1
A bank has set up a customer

group called GROUPEXT to
contain all relevant internal
(own-book) customers, and a
similar group GROUPINT for
all non-own-book customers.
On behalf of their internal

accounts and external client,
they trade European options
on EUREX and LIFFE.
They are not trading members

of either exchange, but instead
use an external broker, with
customer number 100324.
This broker charges different

rates for each exchange.
These have been created in

FT.COMMISSION.TYPE as
CISERXEXC and CISLIFFEEX
respectively.
The bank charges the internal

accounts the same rates, but
charges the private clients a
standard commission amount,
STDCUST.
Following standard exchange

rules, commission will only be
actually charged when a posi-
tion is closed out.
In examining the GROUPEXT DX.COMMISSION Input Record

client commission setup, it
can be seen that the PAY.R-
ECEIVE field is set to “PAY”,
indicating that the customer is
paying the commission to the
bank.
For the EXTERN1 client
group, FIELD.FROM is left
blank so that the test with
FIELD.NAME set to
“EXCHANGE.CODE” and
OPERATOR set to “NE” will
pick up all exchanges (LIFFE
and EUREX in this example).
DX.COMMISSION Input Record
The commission set-up for

Broker “A”, 100115, has the
PAY.RECEIVE field set to
“RECEIVE”, indicating that
the bank is paying the com-
mission to the broker.
Scenario 2
Another bank trades only Foreign

Exchange options. Assume that there are
no overriding commissions for brokers or
exchanges and a general system default
can be used.
The bank has two commonly traded cur-

rencies, USD and GBP, for which it
charges a percentage commission,
STDPCNT. If other currencies are traded
then extra charges, given as NONSTD, are
to be levied.
It is important to take care with the

sequence in which these tests are entered
into DX.COMMISSION. In this scenario
the test for non-standard currencies is
placed after the other two tests on the
TRADE.CCY.
Contracts
Futures and Options are defined in T24 Derivatives as standard contracts i.e. these contracts hold all 'static' information, but not 'dynamic'
information, such as pricing or dates (or call or put in the case of options).
DX.CONTRACT.CLASS
The DX.CONTRACT.CLASS
application will allow the def-
inition of a group of contracts.
This name may then be entered
in the DX.CONTRACT.CLASS
application and used to define
commission and margin classes.
The CATEGORY.CLASS field

defines the product category
code for contracts in this group.
DX.CONTRACT.CLASS Record
Counter Party Defaulting
DX.DEFAULT.CPARTY can be set up for each DX.CONTRACT.CLASS on the system. The purpose of the application is to allow the bank to
set which portfolio they want to be the default secondary customer on orders entered in a particular company for a particular group of prod-
ucts.
Within each record are slots

to allow the bank to set
defaulting secondary port-
folios for the following con-
ditions:
Buy trades (opening position)
Buy trades (closing position)
Sell trades (opening position)
Sell trades (closing position)
Counter party Defaulting
DX.CONTRACT.MASTER
DX.CO-
NTRACT.MASTER is the
main application that
defines the characteristics
of future, stock or option
contracts that can be
traded in the Derivatives
product.
DX.CONTRACT.MASTER Record
l Basic Contract Information

l Pricing Data
l Contract Size Information
l Maturity Date Validation and Key Contract Dates
l Other Contract Information
l Exotic Options
l Calculation of Initial Margin
l Calculation of Variation Margin
Basic Contract Information
The most basic contract information: name, mnemonic, exchange on which the contract is traded, type of contract, is entered first. The CON-
TRACT.TYPE may be FUTURE or OPTION.
The DELIVERY.METHOD of the contract may be CASH, PHYSICAL or NONE, for the cases where the contract is ‘delivered’ as a defined
amount of cash, the physical underlying product is simply removed from the option position with no further action within T24 . If DELIV-
ERY.TYPE is CASH, the DELIVERY.CURRENCY must be entered.
Pricing Data
T24 Derivatives contains powerful functionality to describe the format and calculation of contract prices, and to validate them on that basis. A
short glossary of terms and overview of the main calculations used with examples may be found in the Price Calculation section of the Deriv-
atives Deal Processing Guide.
Main pricing data such as the price basis (INTEREST for interest-rate based prices, NORMAL otherwise) are the same for all prices on a con-
tract, but in some cases values like tick size and value may vary when the contract price falls within different bands. This is catered for by
multi-valuing the PRICE.BAND to INT.PRICE.BAND set.
In rare cases, the tick size and value may vary continuously with the price of the contract, e.g. Swedish Government Bonds, Australian T-Bill
Futures. The pricing characteristics of these contracts cannot be accurately represented using the main price data fields in DX.CO-
NTRACT.MASTER, but the ability to handle anomalous pricing characteristics through creating specialised pricing routines has been designed
into the product.
The PRICE.TOLERANCE field allows the Bank to set a percentage tolerance for input checking of prices. 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
Contract Size Information
Table Cell Outside Table:

ed derivatives contracts (and most OTC contracts) are traded in ‘lots’.
Lots are specified by the exchange or by OTC agreement quantities of an underlying product or asset, in whichever unit of measure is appro-
priate.
The lot size for CME Frozen Pork Bellies futures, for example, is 40,000lb of frozen pork bellies of a standardised size and quality, whilst
that for the LIFFE 3-month Short Sterling interest rate future is GBP500,000.
This size is set in the CONTRACT.SIZE field, whilst the unit of measure used can be specified in UNITS.OF.MEASURE.
At present, this field is not validated but will later be linked to other applications to cope with physical delivery of commodities.
Contract Size Information.
Maturity Date Validation And Key Contract Dates
When a derivatives trade is agreed, a maturity date must be set. For many contracts, this
maturity date is specified only as a maturity month, during which the contract will Keyword Meaning Comments
mature. These are known as MONTHLY maturity contracts. Some other contracts spec-
ify a single day for maturity – DAILY maturity contracts (e.g. FLEX options). A few con- MO Monday
tracts specify a single day up until a certain forward date, and switch to a monthly
TU Tuesday
maturity after this time (e.g. LME copper futures). MATURITY.TYPE hence allows input
of MONTHLY, DAILY or OTHER. WE Wednesday
The fields MATURITY.TYPE and AVAIL.MONTHS and the multi- value set TH Thursday
MONTHS.FWD to MAT.DAYS allow the user to define valid maturity months for the FR Friday
contract using information supplied by the exchange.
SA Saturday
Contract specifications from exchanges quote monthly maturity date rules in one of two
SU Sunday
ways: either specifying which months are valid up until a certain number of months for-
ward, or specifying a total number of valid months. Either method may be combined with M Month Only valid with
a ‘cycle’ of valid months within year (e.g. March, June, September, and December). multiplier/operator
in same field
Setting MONTHS.FWD and any cycle required in the sub-multi-valued MAT.MONTHS
W Week Only valid with
fields will handle the first case, whilst setting AVAIL.MONTHS and any cycle required
multiplier/operator
will handle the second case. Examples of set ups for actual contracts are shown in the
in same field
section "Example Contract Maturity Rules".
CD Calendar Only valid with
For a monthly maturity contract, certain dates related to the maturity month are sig- days multiplier/operator
nificant; chief among these is the ‘last trading date’, i.e. the last date for which contracts in same field
maturing in that month may be traded. The exchange will publish rules to determine this
BD Business Only valid with
and other key contract dates, which can be set up in the fields LAST.TRADE.DATE to
days multiplier/operator
AMORT.DATE.
in same field
T24 Derivatives uses a range of keywords, codes and modifiers to represent the exchange LBD Last busi- Not valid with mul-
rules when determining the dates. ness day of tiplier/operator in
the month same field
*Note: these operators are only valid in the final input field of the date formula string LCD Last cal- Not valid with mul-
and only one of them is allowed. endar day tiplier/operator in
of the same field
Operators and multipliers can then be applied to any of the “keywords”, subject to the month
rules shown in the table. For example, +3BD indicates add 3 business days.
FBD First busi- Not valid with mul-
ness day of tiplier/operator in
Some keywords are only valid in the presence of operators or multipliers. It makes no the month same field
sense to put the keyword ‘BD’ into a field since it is only useful when describing a date
offset, i.e. +3BD or –2BD. FCD First cal- Not valid with mul-
endar day tiplier/operator in
Conversely, keywords such as FBD and LCD describe fixed points in a month and are of the same field
meaningless when combined with operators or multipliers. It is important to note that month
the scenario “the first business day in the month 2 months forward” is represented by MF* Move for- If the date
“+2M,FBD” and not “+2FBD”. ward. obtained is not a
business day, the
The ‘days of the week’ keywords are admissible with or without multipliers/operators, move forward until
because in certain circumstances is will be necessary for example to say that a date is a business date is
valid if it falls on any Monday in a given month. This would be represented by the key- found.
word ‘MO’ without any modifiers.
MB* Moveback- If the date
ward obtained is not a
Brief examples of the use of the keywords follow: business day, then
move backwards
until a business
Description Formula
date is found.
Last business day of the delivery month LBD Keyword Meaning Comments
Third Wednesday of the month prior to the delivery month -1M, +3WE CAL* Calendar Return the date
Date obtained, even if it
The Saturday following the third Friday of the delivery month +3FR, +1SA is not a business
date.
Ninth business day prior to the twentieth of the delivery month +20CD, -9BD
A ‘real-world’ example can be found in the section "Example Key Contract Date Calculation".
If an exchange modifies a particular key contract date (in the event of an unexpected public holiday, for example), then override key dates may
be entered for the month/year combination(s) set in OVR.YEAR.MONTH. All other month/year combinations will continue to use the main
rules.
Other Contract Information
The remaining fields on DX.CO-

NTRACT.MASTER perform various func-
tions. VAR.MARGIN.CALC and
INIT.MARGIN.CALC are defaulted from
DX.EXCHANGE.MASTER but can be over-
ridden to apply special margin calculations
to individual contracts.
The UNDERLYING field is very important

– for an option contract it specifies the ID
of the DX.CONTRACT.MASTER record
that the option will declare to. For a future
it represents the actual asset the contract
is based on, e.g. a stock. It may also rep-
resent the underlying Security No on the
SECURITY.MASTER.
The SETT.ALLOWED flag seen here will

override the main flag at DX.E-
XCHANGE.MASTER level to say whether
or not an eligible open position in the con-
tract should be automatically closed out in
the End of Exchange processing.
CONTINGENT.VALUE can be set to rep-

resent a value per contract lot to be used
in calculating and posting contingent
asset/liability when the contract is traded.
If left blank, the system will use the con-
tract value (No. Of lots * internal price) to
calculate the posting.
Contract Master Input
Exotic Options
In addition to processing of plain vanilla options, the Derivatives module supports handling of exotic options. These have additional rules gov-
erning their existence, valuation and processing. The following examples of exotic options can be handled by T24:
l Kick In or Knock In
A latent option contract that begins to function as a normal option ("knocks in") only once a certain price level is reached before expi-
ration.
l Knock Out
An option with a built in mechanism to expire worthless should a specified price level be exceeded.
l Knock Out With Rebate
A barrier option that offers a predetermined rebate, should the option be 'knocked-out.'
l Double Knock Out
A double barrier option is a combination of two dependent knock-out options. If one of the barriers are reached in a double knock-
out option, the option is killed.
l No Touch
An option which gives an investor an agreed upon payout if the price of the underlying asset does not reach or surpass a predetermined
price level
l Double No Touch
A type of exotic option that gives an investor an agreed upon payout if the price of the underlying asset does not reach or surpass one
of two predetermined barrier levels. An investor using this type of option pays a premium to his/her broker and in turn receives the
right to choose the position of the barriers, the time to expiration, and the payout to be received if the price fails to breach either bar-
rier. With this type of option, the maximum possible loss is just the cost of setting up the option.
l One Touch
A type of exotic option that gives an investor a payout once the price of the underlying asset reaches or surpasses a predetermined bar-
rier. This type of option allows the investor to set the position of the barrier, the time to expiration and the payout to be received once
the barrier is broken. Only two outcomes are possible with this type of option: 1) the barrier is breached and the trader collects the full
payout agreed upon at the outset of the contract, or 2) the barrier is not breached and the trader loses the full premium paid to the
broker
l Instant One Touch
An option which gives an investor a payout once the price of the underlying asset reaches or surpasses a predetermined price level.
Payout immediate.
l Double One Touch
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. An investor using this type of option is able to determine the position of both barriers, the time to expi-
ration, and the payout to be received if the price does rise above one of the barriers. Either one of the barrier levels must be breached
prior to expiration for the option to become profitable and for the buyer to receive the payout. If neither barrier level is breached prior
to expiration, the option expires worthless and the trader loses all the premium paid to the broker for setting up the trade.
l European Digital
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 (regard-
less of how deep in the money the option is), otherwise worthless.
l European Double No Touch
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
l European Double One Touch
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.
Exotic events are not automatically triggered by the system, and any actions that have been set up against an exotic option type will be trig-
gered when the field EXOTIC.EVENT in DX.TRADEor DX.ORDER is set. Any further automation required, would need to be locally imple-
mented, and it is therefore recommended to construct enquiries that show exotic option deals that are eligible for triggering of the exotic event.
l Setting Up Exotic Options
Setting Up Exotic Options
There are three tables associated with the processing of Exotic Options - DX.EVENT.TYPE, DX.OPTION.TYPE and DX.USR.FLD.OPT.
There must be a minimum default DX.EVENT.TYPE record with the key XO with a DX.OPTION.TYPE record defining the exotic event.
DX.EVENT.TYPE table can also contain specific exotic event, where the key starts with ‘XO-‘ which is created by prefixing XO- to the ID of
the corresponding DX.OPTION.TYPE record. This allows the specification of differing P&L categories, transactions etc for each exotic event.
Finally, the DX.USR.FLD.OPT table allows the definition of re-usable user defined fields for the DX.OPTION.TYPE record. For example, an
upper limit are used in many types of exotic options . A DX.USR.FLD.OPT record could specify the text, validation and field name for storing
this upper limit, and DX.OPTION.TYPE records set up for each type of exotic option would only need to reference this record. The User-
defined fields would then appear on the DX.TRADE or DX.ORDER record.
The DX.OPTION.TYPE record includes the field CO.PGM, which can specify an API or user-defined routine to be launched when the EXOT-
IC.EVENT flag on the DX.TRADE is triggered. This routine can be fed any data it requires from the user-defined fields mentioned.
Additionally, if the flag USR.FLD.PRICE is set, the user-defined field(s) against which the flag is set, form part of the positional and pricing rec-
ord keys for options of this type in T24.
l Black Box Routines

l Example Setups
Black Box Routines
The following Black Box routines have been introduced for downstream processing of Exotic Options. These routines should be attached to the
field CO.PGM of DX.OPTION.TYPE.
DX.XO.CREATE.FX - To
create the underlying FX
deal; no user fields required.
DX.XO.CREATE.SEC - To
create the underlying
SEC.TRADE; no user fields
required.
DX.XO.CREATE.FX.K-
NOCKOUT - To create under-
lying FX deal in case of
knockout options; no user
fields required
DX.XO.CREATE.SEC.K-
NOCKOUT - To create under-
lying SEC.TRADE in case of
knockout options; no user
fields required
DX.XO.FWDCASHPAYOUT
- To post accounting entry
for settlement on closeout,
value maturity date of option
adjusted for number of offset
days; Amount & Currency
user fields required.
DX.XO.-
INSTANT.CASHPAYOUT -
To post accounting entry for
settlement on closeout, value
closeout date adjusted for
number of offset days;
Amount & Currency user
fields required.
DX.XO.CREATE.F-
X.REBATE - To post
accounting entry for the
rebate amount in case of
Knock out options with
rebate; Amount & Currency
user fields required.
DX.USR.FLD.OPT settings for Amount and Currency fields
DX.XO.KNOCKOUT - Create
underlying of whichever type
unless the exotic event flag is
set when the Knock out level
is reached, then the option is
expired.
DX.XO.KNOCKIN - Create
underlying of whichever type
if the exotic event flag is set
when the Knock in Level is
reached.
Examples of field types used

to signify knock in/out of an
exotic option might be price
level e.g. a maximum price
barrier, rate level, e.g. a mini-
mum interest rate barrier and
narrative e.g. weather option
criteria
DX.USR.FLD.OPT settings for Price Level, Rate Level and Narrative fields
Example Setups
The following examples show setup of DX.OPTION.TYPE and DX.EVENT.TYPE for some example exotic option types. These utilise the user
fields as detailed in the section dealing with Black Box Routines.
Knock
In/Kick
In option
Knock
Out/Kick
Out
option
Euro Dig-
ital
Option
Case studies:
l Credit Default Swap

l Knock In Option
l Knock out with Rebate
Credit Default Swap
Consider a trade against an exotic option contract below, with an Option.Type as CRED.DEFAULT, with an instant payout of USD99000 on
closeout.
Setup
First the DX.OPTION.TYPE

for CRED.DEFAULT needs
to be set up, specifying that
a currency and an amount
are to be prompted when
this DX.OPTION.TYPE on
the DX.TRADE is validated.
Also note that the routine

DX.XO.-
INSTANT.CASHPAYOUT is
to be called when this trans-
action is exercised or
assigned.
CRED.DEFAULT Option Type
The DX.EVENT.TYPE rec-

ord also needs to be created
XO-CRED.DEFAULT Event Type
The contract master for the Credit Default Swap needs to be set up with the option type CRED.DEFAULT associated to it, before we can trade
on this exotic option.
DX.CONTRACT.MASTER as set up for a credit default swap contract
Dealing
After the DX.OPTION.TYPE, DX.EVENT.TYPE and DX.CONTRACT.MASTER records have been set up, the contract is ready to be traded.
The screenshots below show an example of a DX.TRADE for the above contract.
DX.TRADE of an Exotic Option
On input of the Exotic Type
and validation of the record,
the two fields
PAY.OUT.CCY and
PAY.OUT.AMT associated
with the exotic type
CRED.DEFAULT are
prompted for input and val-
idation.
In order to trigger this

Exotic option, the field Exot-
ic.event on DX.TRADE rec-
ord has to be set to Yes, and
then the transaction is
either exercised or assigned
using the enquiries
DX.CO.M-
ANUAL.EXERCISE or
DX.CO.MANUAL.ASSIGN.
DX.CLOSEOUT of a manual exercise
The cash payout is then

posted (in this case USD
$99,000) would then be
posted as shown here.
Entries posted for the transaction
Knock In Option
It should be noted that we would not normally expect to input DX.TRADE records into the system if they have not yet kicked in/knocked in.
The kick-in or knock-in deal would be input using a version of DX.ORDER, and an enquiry created to compare the kick-in price with the under-
lying market price and display records as appropriate*, with a drilldown to a version which automatically sets the exotic event flag and allows
generation of the deals themselves.
* The enquiry could select for contract code and exotic option type, and if the user then selects knock-in prices ³ or £ the market price of the
underlying (e.g. exchange rate), depending on whether selecting buy/sell, call/put and terms of knock-in. For example, if bought calls for deliv-
ery of Euro FX options kick in when the exchange rate exceeds a certain price, the enquiry could search for all knock-in prices set on orders at
and above the current exchange rate – all orders found could be kicked in.
Example Enquiry to monitor options eligible for knock in
Example Version to fill knock in orders - note exotic event flag automatically set
Knock Out With Rebate
Setup
Consider a trade against an exotic option contract below, with an Option.Type as KNOCK.OUT.REBATE, with an instant Rebate of EUR3500
on closeout.
First the DX.O-

PTION.TYPE for
KNOCK.OUT.REBATE
needs to be set up, spec-
ifying that a currency
other than the local cur-
rency and an amount are
to be prompted when this
DX.OPTION.TYPE on
the DX.TRADE is val-
idated.
Note that the routine

DX.XO.CREATE.F-
X.REBATE is to be called
when this transaction is
exercised or assigned.
Finally the
DX.EVENT.TYPE record
needs to be set up.
The screenshots below show a contract set up for a Knock Out with Rebate style option.
Dealing
A Trade is input against the exotic option contract, specifying the ccy and amount to be paid on closeout when the knock out level is reached.
When the
knock
level is
reached,
the trans-
action is
exercised
manually.
The close-
out is
created.
The closeout then posts the accounting entries as shown below.
Statement entries
Calculation Of Initial Margin
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 published its initial margin calculation method. These various methods can be implemented by using
the revaluation “black box” technology, and by using a parameter in the contract master file 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.
Calculations performed by the system will follow one of the following methods;
l Standard IM
l Naked (FULL) positions are margined Rate Per lot from DX.MARGIN.RATES
l Spread (SPREAD) positions are margined Rate Per lot from DX.MARGIN.RATES
l Straddle (STRADDLE) positions are margined Rate Per lot from DX.MARGIN.RATES
l Spot (SPOT) positions are margined Rate Per lot from DX.MARGIN.RATES
l (Where percentage is selected the system calculates the average price for the positions being margined then takes a percentage
of the total value based on the parameters in DX.MARGIN.CALC)
l Enhanced IM
l As above except it does not include bought positions in the Naked calculation.
l NO IM
l IM = 0
Calculation Of Variation Margin
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 by using the “black
box” technology.
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 set-
tlement 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 cal-
culations must be performed before the initial margin calculations.
Calculations performed by the system will follow one of the following methods:
l Standard VM
l For transactions with premium paid (Options)
VM = No Lots * Market Price
Otherwise
VM = (Market Price – Transaction Price) * No. Lots
l Ch Reg
l VM = (Market Price – Transaction Price) * No. Lots
l NO VM
l VM = 0
Customers
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.TYPE
field allows the customer to
be classed as Customer,
Counterparty, Dealer,
Broker or Exchange Type
customer.
Customer and Dealer are

equivalent and are simply
for reporting purposes.
Counterparty, Exchange and

Broker are also basically
equivalent and are separated
forreporting purposes. How-
ever, these three customer
types have significance for
margining purposes. As the
DX module is double sided DX.CUSTOMER Record
for every buy or sell by a cus-
tomer/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, counter-
parties and exchanges will
be reversed, therefore ensur-
ing the margin results are
calculated correctly and
maybe reconciled. Brokers
and exchange customer
types are not expected to
have portfolios when trad-
ing. The Customer and
Dealer types represent the
majority of the Bank’s
clients and own-book trad-
ing, and must have
SEC.ACC.MASTER port-
folios 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.
Reporting frequencies for derivatives reports may be set for the customer for Batch and End of Exchange reports in this application.
A multi-value set of fields EXCHANGE to MARG.WEIGHTING allow the definition of the interaction of the customer with one, several or all
exchanges defined in the Derivatives product. This lets the Bank define the customer as a speculative or hedge trader on each exchange, and
also whether the customer is a member of the exchange. The exchange membership may be set to Trading, Clearing, Both or None.
The MARG.WEIGHTING field may be set to force the Derivative product to apply a percentage weighting to any initial margin figure calculated
for the customer on the relevant exchange(s). This would typically be used if the Bank considers a particular customer to be a greater than nor-
mal trading risk, and wishes to apply more than the normal calculated initial margin requirement to that customer.
The multi-value set of fields headed by AU.CT.CLASS are used to define what contract class is going to be closed out by this particular method
as defined in AU.SETT.TYPE. The last field needs to be set to AUTO if automatic close out is to be allowed. Details may be found in the Helpt-
ext for these fields.
If the ID of a DX.GROUPING record is present in the GROUP field, this customer is treated as a member of that group for commission cal-
culation, margin calculation and reporting purposes.
The fields MARGIN.ACC.CCY through to TRADING.STATUS may be populated at this release but are available for information only. They will
be used by further developments released in later stages of the product development.
The customer’s REPORTING.CCY is used as the default currency for revaluation figures produced for the customer in the Derivatives reval-
uation. It is defaulted from the reference currency in the first active SEC.ACC.MASTER portfolio for the customer (if one exists) or otherwise
defaults to the company local currency.
The RENEWAL.FREQUENCY field allows a standard T24 frequency code to be entered to define when the document should be renewed. This
information is picked up by DX.CUSTOMER for information and reporting purposes.
Events
The DX.EVENT.TYPE application is crucial in the accounting behaviour of the Derivatives product. Events occurring during the life of a deriv-
atives contract are selected from a predefined list and associated with information that is used in accounting for the Bank’s own book port-
folios. The module then assigns one or more events to each activity performed on the system and logged in the DX.TRANSACTION file.
As an example, a simple futures trade

between a broker and the Bank’s own
book entered into Derivatives 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 port-
folio. Each transaction would then be
tested and have the following events
assigned:
CI – Contract Initiation – triggers post-

ing of contingent liability posting for own-
book portfolio.
FC – Clearing Fee – posts clearing fee cal- Derivatives Event Type Record
culated to broker account vs. P&L cat-
egory for own book portfolio.
FE – Execution Fee – posts execution fee

calculated to broker account vs. P&L cat-
egory for own book portfolio.
l Standard Event Types

l Commissions and Charges Posting
l Event Based Reporting
l Full List of Event Types
Standard Event Types
The event types that may be defined in the DX.EVENT.TYPE application are as follows:
Event Name Description

code
CI Contract inception Initial entry of trade
CC Contract can- Cancellation of an authorised contract i.e. contract reversal not part of an amendment – contract com-
cellation pletely cancelled
CD Contract deletion Deletion of an unauthorised contract
CU Contract unauth Amendment of an unauthorised contract.

amendment
CR Contract amend- Reversal of authorised trade details before amended details entered
ment reversal
CA Contract amend- Amendment of authorised trade – new details

ment
CM Contract maturity Trade maturity
CS Contract settlement Settlement of trade (close-out)
SR Settlement reversal Reversal of settlement (close-out)
PP Premium posting Posting of option premium
FC Commission posting Posting of ‘normal’ trading commission
FE Execution fee post- Posting of Execution fee

ing
FR Regulatory fee post- Posting of any regulatory fees

ing
FL Clearing fee posting Posting of clearing fees
FM Miscellaneous fee Posting of any other miscellaneous charges entered manually

posting
PO Open position Trade input forming opening leg of position
PC Close position Trade input forming closing leg of position
RP Realised P&L Realised P&L from settlement/maturity settlement or from revaluation using “nightly settlement” con-
ventions (e.g. LIFFE settlement and reopen process)
UO Unrealised option Unrealised option value generated by revaluation (not variation margin since not product of mark-to-mar-
value ket or similar)
OA Order amendment Amendment of authorised order – new details
OC Order cancellation Cancellation of an authorised order
OD Order deletion Deletion of an unauthorised order
OF Order fill Fill or Part-fill of an order, when the trade is created
OI Order input Input of an order and authorisation
Event Name Description
code
OM Option margin (Mar- Margin at Market Value

ket Value)
OX Order abandon After at least one partial fill, remaining lots are cancelled.
TT Tax Posting Posting of Tax
IM Initial Margin Initial margin generated from revaluation
VM Variation Margin Variation margin (unrealised P&L) generated and posted by revaluation for futures
Commissions And Charges Posting
For events referring to the posting of commissions and charges, the USE.FT.TXN.CODE flag may be set to use the CATEGORY or ACCOUNT
and TRANSACTION codes set on the FT.COMMISSION.TYPE or FT.CHARGE.TYPE records (if any) used in the commission set up.
The CATEGORY and TRANSACTION codes on the events are used for postings relating to own-book transactions only, for certain types the
CATEGORY code will be mandatory.
The records PP (premium posting) and UO (unrealised option value) in

DX.EVENT.TYPE can be assigned categories as:-
PP – A PL-category (50000-59999) or an internal account category (10000-

19999).
UO – A PL-category (50000-59999) or a product category between (24000-

24999).
If an internal account category is defined in the DX.EVENT.TYPE for PP, sys-

tem will raise a STMT.ENTRY for the premium amount to the internal account
category defined.
If a product category is mentioned in DX.EVENT.TYPE for UO, system will

raise RE.CONSOL.SPEC.ENTRY.
If a PL category is defined in the DX.EVENT.TYPE for PP & UO, system will

raise a CATEG.ENTRY.
For example, if a PL-category assigned, then on entering a DX.TRADE for

option contract, system will book the premium amount in PL by raising appro-
priate CATEG.ENTRY. It will raise debit or credit entry in CATEG.ENTRY for
long and short positions respectively and corresponding entry will be raised in
STMT.ENTRY for broker’s account.
Similarly, the UO amount generated on account of revaluation (for own-book

trades) will be posted to PL by raising debit or credit entry (depending upon
the position - long or short) in CATEG.ENTRY and corresponding entry will be
raised for internal account in STMT.ENTRY.
For an exam-
ple, if an own-
book trade has
been entered
for buying a
call option by
paying a pre-
mium of 15 for
10 lots (lot
size =1000).
After author-
izing the trade,
system will
raise a debit
entry in
CATEG.ENTR-
Y for the pre-
mium paid.
The cor-
responding
entry got gen-
erated in
STMT.ENTRY
to credit the
broker
account, along
with the two
wash through
entries.
On revaluation
of the position
with a new
price say 21 (in
this case), sys-
tem will cal-
culate the UO
amount and
will post it to
CATEG.ENTR-
Y.
The cor-
responding
debit entry will
be generated in
STMT.ENTRY
for an internal
account.
Similarly, the UO amount generated on account of revaluation (for own-book trades) will be posted to PL by raising debit or credit entry
(depending upon the position - long or short) in CATEG.ENTRY and corresponding entry will be raised for internal account in STMT.ENTRY.
Customer and broker transactions result in postings to the relevant accounts are entered on DX.TRADE.
Event Based Reporting
There are two reporting files that are designed to record activity by defined DX.EVENT.TYPE(s).
DX.REP.POS.ACTIVITY records events against positions and DX.TXN.ACTIVITY records events against transactions.
Event Based Reporting must be enabled via the REP.UPDATES field on DX.PARAMETER.
On the DX.EVENT.TYPE record, the field TX.ACT.UPD controls the decision as to whether a given DX.EVENT.TYPE should report to either
of these files.
Full List Of Event Types
The following constitutes a full list of the current DX.EVENT.TYPE records required for system processing. You may require all or some of
these depending on which products you are trading/processing.
ID Event Requires Generated By.

Description CATEG.CODE
BV Back Valuation NO Back Valuation
BP Broker Profit YES Trade
FL Clearing fee/csn posting YES Trade
PC Closed position YES Trade
FC Commission posting YES Trade
CA Contract Amendment YES Trade
CR Contract Amendment (Reversal) YES Trade
AS Contract Assignment NO Closeout
AR Contract Assignment (Rev) NO Closeout
CC Contract Cancellation YES Trade
EX Contract Exercise NO Closeout
ER Contract Exercise (Rev) NO Closeout
XP Contract Expiry NO Closeout
XR Contract Expiry (Rev) NO Closeout
CI Contract Inception YES Trade
CM Contract Maturity YES Trade
CS Contract Settlement YES Closeout
CP Corporate Action NO Corporate Actions
CX Corporate Action (Rev) NO Corporate Actions
FE Execution fee/csn posting YES Trade
CO External Transfer NO Tr/Pos Transfer
CT Incoming Transfer NO Tr/Pos Transfer
IM Initial Margin YES Re Valuation
II Internal Incoming Transfer NO Tr/Pos Transfer
CN Internal Transfer NO Tr/Pos Transfer
FM Misc fee posting YES Trade
PO Open position YES Trade
OM Option Variation Margin YES Re Valuation
OX Order Abandon YES Order
OA Order Amendment YES Order
OB Order Blocking YES Order
OC Order Cancellation (Reversal) YES Order
OD Order Deletion YES Order
OF Order Fill NO Order
OI Order Input YES Order
OR Order Stage Superseded NO Order
PP Premium Posting YES Trade
RP Realised P and L YES Closeout
FR Regulatory fee posting YES Trade
SR Settlement Reversal YES Closeout
TT Tax posting YES Trade
CU Unauth Contract Amendment YES Trade
CD Unauth Contract Deletion NO Trade
UO Unrealised Option P and L YES Re Valuation
VM Variation Margin YES Re Valuation
Exchanges
DX.EXCHANGE.MASTER defines the characteristics of exchanges on which customers defined in the T24 Derivatives module may trade.
The DX.EXCHANGE.MASTER application contains the following types of information:
l Details of the exchange/market itself (description, address, etc).

l Default rules and methods for trading on the exchange (margin calculations, premium posting times etc.).
l Links to customers/portfolios/accounts that represent the exchange in T24 for the purposes of posting fees and other account entries.
l Basic details about any relationships between the exchange and other entities, i.e. regulators.
Each exchange is uniquely asso-

ciated with a REGION, since
the module uses regions to rep-
resent exchanges for the pur-
pose of defining trading
calendars in the
HOLIDAYapplication.
The EXCHANGE.TYPE field

allows an exchange to be set
up as Normal, i.e. a ‘real’
exchange, or OTC for a
pseudo- exchange defined by
the Bank for the purposes of
defining OTC contracts in
DX.CONTRACT.MASTER.
The PREM.POST.TIME and

CHG.POST.TIME fields allow
the payment of option pre-
miums and charges or com-
missions to be defaulted to
trade or settlement (close-out)
time for all contracts on the
exchange. In both cases the cor-
responding OFFSET field DX.EXCHANGE.MASTER record
allows the postings to be
delayed by the number of days
set in the fields.
Basic default margining param-

eters can be set for all con-
tracts on the exchange.
VAR.MARGIN.CALC and
INT.MARGIN.CALC define the
default variation and initial mar-
gin calculation records in
DX.MARGIN.CALC , whilst
NETT.GROSS is a parameter
required by the margining algo-
rithms on certain exchanges.
For the most part, the valid days available for trading are read from the holiday record associated with the exchange region, but unusual trading
day rules (i.e. Monday to Thursday rather than Friday) may be defined on the DX.EXCHANGE.MASTER record in TRADING.DAYS. The
exchange’s specific trading opening and closing times can be recorded in TRADING.OPEN and TRADING.CLOSE. These fields may be multi-
valued if certain ‘sessions’ during the exchange day are available for trading certain products. If these sessions have particular titles they can
then be named in the EXCHANGE.SESSION field.
The MAX.MONTHS.FWD
field constrains the set up of
contracts on the exchange and
sets the maximum number of
months forward that any con-
tract may be traded.
The fields MUTUAL.OFFSET

to GEN.DATA.LIMIT allow
entry of data about the
exchange’s trading arrange-
ments with other exchanges,
electronic trading tools and
any regulatory reporting
schemes required. At this
stage these fields are used for
information purposes only.
The SETT.ALLOWED field

defaults the behaviour of all
contracts on the exchange
with regard to automated
closeouts (settlements). If set
to No, open positions in con-
tracts on the exchange that
would otherwise be eligible for
automatic close out during the
End of Exchange processing
will be kept open.
DX.EXCHANGE.MASTER record
If the Bank is a member of any
exchanges, it may wish to rec-
ord trades directly between
customers and the exchange.
To allow this, customers may
be associated with the
exchange for the purpose of
holding trading positions.
These customers must exist in
DX.CUSTOMER and are input
in one or more of the fields
EXCHANGE.CUSTOMER to
HOUSE.CUSTOMER depend-
ing on local regulatory require-
ments.
Groups
DX.GROUPING is a simple application that allows Derivative customers to be grouped together for commission calculation and mar-
gining/reporting purposes. The group is simply defined in DX.GROUPING and the group id added to the DX.CUSTOMER record in question.
DX Grouping Record
In later stages of the Derivatives product development, the revaluation suite will support the revaluation of hierarchical DX.GROUPING struc-
ture, i.e. performing a revalue on group AA will also revalue customers in groups AA.BB, AA.CC etc. The MARGIN.LEVEL field exists to define
an official margining level in such a group hierarchy, but is not used at present.
Local Currency Conversion Of DX Contracts
Functionality is included to enable Euro conversion of local currency commitments where by commitments are cash settled.
Cash settlement for the purpose of this functionality has been defined as:
For futures contracts the effective realisation of any profit and loss due to involved parties
For options contracts the payment of any outstanding option premium.
Refer to the Euro User Guide for more information
Margins
DX.MARGIN.CALC
The function of the DX.MARGIN.CALC application is to allow entry/amendment of margin calculation routines into the T24 derivatives mod-
ule.
The Derivatives module is

designed to use ‘black boxes’ to
return information that may be
obtained in several different
ways. In this way, the main appli-
cations need only worry about
calling one ‘shell’ routine, which
will select the correct algorithm,
routine or interface to use to
return the required data for that
margin calculation.
Margin calculations rely on this

technique. The Derivatives mod-
ule will call a single ‘grey box’ rou-
tine that will determine the DX Margin Calc Record
correct margin calculation to
apply by examining the exchange
and, if necessary, the contract
traded. 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.
Two default margining routines are provided. STAND.IM and STAND.VM these are the Standard Basic Initial Margin Calculation and the basic
Variation Margin calculation routines. There are two other Initial Margin Calculations currently available, namely Euronext-AEX and OCC-
TIMS and more may follow.
DX.MARGIN.RATES
Part of the functionality of the derivatives module is to calculate initial margin figures. The amounts are actually calculated by “Black Box” Ini-
tial Margin routines that are controlled by the application DX.MARGIN.CALC. However some of these routines require rates to be entered
depending on which calculations being performed.
The DX.MARGIN.RATES application will allow the entry of initial margin rates for various types of trades. These rates will be used, as
required, by various initial margin calculation routines. Further applications will be developed as required for specific initial margin calculation
routines, e.g. SPAN.
DX MARGIN.RATES record
Margin rates are entered on a contract and client basis.
The DX.MARGIN.RATE Key

The key is made from four separate elements separated by a “–“ (hyphen).
These elements are:
Contract Class A Contract Class from DX.CONTRACT.CLASS.
Contract A Contract Code from the DX.CONTRACT.MASTER.
Customer Grouping A Group from the DX.GROUPING.
Customer 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-20010615, this margin rate will
become effective on the 15 June 2001.
Only one of contract class and contract may be entered and only one of customer grouping and customer may be entered.
For example:
The rates for contract 19 (3 Month Sterling) for customer 100163 (Model Bank) would be -19- - -100163or, the default for all 3 Month Sterling
Contracts would be -19- - -
The codes may also be entered in the following formats:
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
So that the system knows how to interpret the input, a 2-character prefix is used to identity each element, the application also recognises mne-
monics used by the source applications.
Parameters
DX.PARAMETER is the main parameter control file for the Derivatives module. It should contain the single record SYSTEM, which is read by
other applications in Derivatives and their behaviour controlled by the contents.
DX.PARAMETER Record
Details of the effect of the data in DX.PARAMETER can be found in the helptext for the application.
Particular facilities that can be set up in DX.PARAMETER and other Derivatives product tables are outlined in the following sections:
l Contingent Postings and Product Categories

l Automatic Expiry or Exercise
l Automatic Tidying of Cash Settlement Feeds
l Average Price Positions
l Back to Back Closeouts
l Best Rate
l Blocking of Securities Positions
l Calculation of Credit Exposure
l Customer Available Funds Checking
l Revaluation P&L
l Straight Through Processing
Contingent Postings And Product Categories
Setting the flag CONT.ULYING.VAL on DX.PARAMETER allows the off-balance sheet postings made on entry of an own-book deal to be
based solely on the underlying value of the trade. This is particularly useful for own-book OTC Forex options, as the receivable and payable
cash amounts are calculated and posted as assets or liabilities in the appropriate currencies.
Forex Derivatives
(DX.CONTRACT.MASTER DELIV-
CONT.ULYING.VAL Description ERY.METHOD = ‘CASH’) Other Derivatives
NO Existing style CR or DB CRF asset type CR or DB CRF asset type
Only for futures and options with Amount – cost of position or contingent Amount – cost of position or
premium un-posted value contingent value
Currency – contract currency Currency – contract currency
YES New style CR CRF asset type CR and DB CRF asset type
All trades Amount – underlying receivable ccy amount Amount – cost of position
Currency – receivable currency Currency – contract currency
DB CRF asset type
Amount – underlying payable ccy amount
Currency – payable currency
To allow more detailed analysis of the off-balance sheet postings, product categories may now be assigned to sub-classes of Derivatives instru-
ment using the DX.CONTRACT.CLASS application.
Product categories can be defined for bought or sold futures, or bought or sold call/put options. They may be further subdivided into payable
and receivable.
For most purposes a value of “YES” in the CONT.ULYING.VAL is expected as this takes the price into consideration.
Automatic Expiry Or Exercise
Table Cell Outside Table: The automatic expire/exercise functionality is activated at the DX.CONTRACT.MASTER level. The fields; SYS-
TEM.EXERCISE and SYSTEM.EXPIRY have to be set to “YES” and a tolerance level needs to be defined (EXER.PRI.MEM,
EXER.PRI.NON and EXPIRY.PRI).
Automatic exercise expiry set up
Automatic Tidying Of Cash Settlement Feeds
The usage of the manual cash settlement functionality as shown previously will cause the system to write a record to the appropriate under-
lying file:
DX.CO.MATURITY.INPUT
DX.CO.ASSIGN.MANUAL
DX.CO.EXERCISE.MANUAL
DX.CO.EXPIRE.MANUAL
DX.CO.MANUAL.INPUT
These files may in the passage of time become overly large and may not be required by the user. Should the user not wish to retain these rec-
ords it is possible to set these files to be automatically cleared during the COB process. The multi value field FEEDS.TO.CLEAR held in the
DX.PARAMETER application allows feed files to be selected and cleared along with their related unauthorised and history files when the COB
runs. The job DX.COB.CLEAR.FEEDS has been added to the BATCH record DX.END.OF.DAY to run this process and may be set to run daily
to maintain these records.
Average Price Positions
The derivative module has two additional methods of average price calculations, namely OPENING and NONE. These methods can be defined
at contract level along with the number of decimal places required for average price.
In order to have this contract level control, two new fields, AVERAGE.PRICE and AVERAGE.DPS, have been added to the application DX.CO-
NTRACT.MASTER. These new fields will be used for average price calculation and the updating of fields AVG.PRICE, AVG.IPRICE in the file
DX.REP.POSITION.
The two methods of average price calculations work as follows:
NONE:
No average price will be calculated.
OPENING:
Average of buy prices of OPENING trades weighted by the number of lots traded.
Further, positional updates to SC.POS.ASSET can be parameterised in by setting the field SC.ASSET.UPD in DX.PARAMETER to
BUY.SELL.POS. This will then allow the illustration of the long and short positions separately.
Besides, the module creates DX.TRADE(s) on multiple filling of DX.ORDER, at the average price of different levels at which the order has been
filled. By keeping the CREATE.TRADE flag on the DX.ORDER set to “NO” until the final fill then set it to yes, and it should create 1 deal with
the price set as the average of all the fills for the order
In this connection, new fields FILLED.LOTS, FILLED.PRICE, FILLED.IPRICE and CREATE.TRADES have been added to DX.ORDER.
Field CREATE.TRADE in DX.ORDER defaults its value from DX.PARAMETER, which however should be set to YES for authorisation of
DX.ORDER record.
Every input to unauthorised DX.ORDER record on execution will create a new multi-value set of the abovementioned new fields, which will be
averaged to create the resultant DX.TRADE, on authorisation of DX.ORDER.
Back To Back Closeouts
Whenever a primary customer’s position is closed out the corresponding opposite position, of the secondary customer, is also closed out auto-
matically, which does not require any separate authorisation by the user.
Whenever an automatic secondary closeout cannot be performed for various reasons, there is a warning message to that effect.
However, a secondary closeout will not result in a back-to-back closeout for the corresponding primary customer.
For this purpose, the field B2B.ACTIVE in DX.PARAMETER is used, while field B2B.CO.OK in DX.CONTRACT.MASTER, is used to activate
the back to back closeout process.
Best Rate
As standard, any debit or credit to the customer account is computed by applying the middle exchange rate, if the derivative currency is dif-
ferent from the customer account currency.
It is also possible to apply the exchange rate that is most advantageous to the bank or the user defined exchange rate on the pre-
mium, charges and commission involved in DX trades, besides retaining the existing functionality of applying mid rates.
However, it may be noted that:
l This functionality is designed only for the Primary side of a DX.TRADE

l User defined rates can be applied to commission if the primary customer chooses the manual commission type for the said trade
l System will default the best exchange rate from Globus bank perspective, for conversion of commission/charges, based on the def-
inition in relevant DX.COMMISSION record, as to PAY or RECEIVE
l This functionality is designed only for a scenario when a DX.COMMISSION record does not have more than one multi-value set
l This best rate facility will be made available based on the class of the customers: Customers, Brokers, Dealers, Counter Party and
Exchange.
DX.PARAMETER
Field SPECIAL.RATE in DX.PARAMETER defines which class of customer will have special rates applied, which if left blank will default the
mid rates for calculations
DX.CUSTOMER
Field CUSTOMER.TYPE can accept input of “DEALER”
DX.TRADE
The rate at which conversion takes place will be populated in PRI.PREM.EXC and PRI.COMM.EXC based on the definition in DX.P-
ARAMETER. These fields can also be overwritten for user-defined rates, if the primary side of the DX.TRADE involves manual commission.
Blocking Of Securities Positions
This is 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 is achieved using 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.
Note, it is not possible to partially cover a deals position at present.
Calculation Of Credit Exposure
Derivative module enables the calculation of credit exposure on derivative trades as per the market method. Under this method, credit exposure
is equal to replacement cost plus an “add on” factor. This is required for purposes of regulatory reporting and credit monitoring.
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 under-
lying 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.
Fields on SC.POS.ASSET record reflect the credit exposure amounts calculated for regulatory reporting and credit monitoring separately.
So, whenever SC.POS.ASSET record is built/rebuilt, the black box routine ‘DX.BB.CREDIT.EXPOSURE’ is called and credit exposure amounts
are updated in SC.POS.ASSET record of the respective portfolio
DX.PARAMETER Field CR.EXP.CALC.API denotes the API ‘Black box’ routine DX.BB.CREDIT.EXPOSURE created for cal-
culating credit exposure.
DX.CONTRACT.MASTER The field INT.RATE.CONTRACT is used in order to identify an interest rate derivative. If it is set to “YES”,
input to field LIFE.UNDERLYING is mandatory
REVAL.ADDON.PERCEN Add on percentage applicable for regulatory and credit reporting needs to be defined in a REVAL.ADDON table
record, based on the sub asset type
Customer Available Funds Checking
If the new flag CHECK.CUST.FUNDS on DX.PARAMETER is set to ‘YES’, the module will calculate a ‘best estimate’ initial margin figure for
each transaction input (order or trade) and use the figure generated to block customer funds until the next Initial Margin calculation run (when
the funds are physically removed from the customer’s account in any case), and also to make an ‘unblocking’ posting forward dated to the
notional maturity date of the deal.
It is also possible to block customer funds in respect of the premium cost of a transaction; this is activated by defining a routine in
COST.CALC.API field in DX.PARAMETER
Revaluation P&L
For all external customers, revaluation P&L (variation margin) will be posted to the account input for that customer on DX.TRADE.
For Own Book portfolios unrealised P&L calculated by the Derivatives revaluation
process will be posted using the P&L category and transaction codes specified on
the appropriate DX.EVENT.TYPE record.
Posting of revaluation P&L for Own Book portfolios is controlled by the MAR-
GIN.DIFFERENCE parameter in DX.PARAMETER.
If this field is set to YES then when a new margin figure has been calculated, the dif-
ference 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.
When the field VM.REVERSAL.STYLE set to New and the MARGIN.DIFFERENCE

set to Yes, Reversal of Variation margin for foreign currency contracts during close-
outs will be posted at the exchange rate at which it was booked.
If the field is set to Old it will reverse the VM amount with prevailing exchange rate.
Straight Through Processing
filling Orders via DX.ORDER,

held DX.TRADE records are
automatically generated to
update the deal with respect to
the order fill. It is however pos-
sible to set these trades to be
created with their status set to
INAU. This functionality can be
activated via the STP.E-
NABLED.APP field in DX.P-
ARAMETER
DX.PARAMETER Record with STP enabled
The USER should designate the DX.ORDER application as a value in the field to activate the straight through processing of filled DX.ORDER
(s) such that the corresponding DX.TRADE (s) are created with their status set to INAU. This activates the use of OFS, hence the TSA.SER-
VICE manager TSM should be running, and corresponding OFS.MESSAGE.SERVICE and OFS.RESPONSE.QUEUE set to AUTO
In case of any problem, the

enquiry, DX.MO-
NITOR.STP.PROCESS, monitors
the state of DX.ORDER and
DX.CLOSEOUT generated OFS
transaction messages. It reports
any transactions that require oper-
ator intervention and if a timeout
period is specified, it also reports
on any transactions that have not
been handled within that time.
The enquiry reports the

DX.TRADE ID, the error message,
the date and time that the trans-
action was generated, the length of
time since the transaction was gen- Example DX.MONITOR.STP.PROCESS enquiry
erated and whether it is a timeout
related issue.
The field STP.TIMEOUT represents the number of seconds that a transaction can await processing before being deemed to have timed out in
the enquiry. This field is non-mandatory and if left empty, no timeout checking is made in the DX.MONITOR.STP.PROCESS enquiry.
Pricing
DX.PRICE.SET
The function of this application is for the entering/amendment of price sets in the Derivatives module. These “Price Sets” are predominately
used in the valuation of open positions (trades) using the revaluation process.
Examples of commonly used price sets would be “CLOSING” and “CURRENT”.
These price sets can be used to set-up “what if” price sets, allowing an ad-hoc revaluation to take prices from a notional price set. In this way
the system can be used to answer the question, “What would happen if the prices…?”
DX.PRICE.SET Record
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 position.
DX.PRICE.SOURCE
The function of the DX.PRICE.SOURCE application is to allow entry/amendment of price sources into the T24 derivatives module. A price
source should be considered as an identifier for the entry point of prices into the system. There are many different price sources:
l Manual, a user physically entering prices into the system.

l Automatic price feeds (e.g. Reuters, Telerate, Telekurs).
l Batch based price downloads (e.g. SPAN risk parameter files).
l Ability to call a price model routine and store the returned price (e.g. Black & Scholes).
DX.PRICE.SOURCE Record
A basic DX.PRICE.SOURCE record MANUAL is provided with the system to allow the entry of prices using DX.MARKET.PRICE.
Routing
As an aid to producing STP workflow the derivatives module provides the ability for orders and the subsequent trades to be routed between
T24 companies
Order Routing
The application
DX.ACC.MASTER
allows you to set
up inter-company
routing information
for a portfolio in
Derivatives. The
fields RT.PORT.ID
and RT.COMP.ID
allow trades and
orders to be rep-
licated to specific
portfolios in dif-
ferent T24 com-
panies.
Set up order routing
The fields PRI.RT.C-

OMPANY,
PRI.RT.PORT.ID,
PRI.RT.WHEN and
PRI.RT.LINK on
DX.TRADE and
DX.ORDER (also
present on the sec-
ondary side of the
deal) hold the rout-
ing information for
a deal.
Derivatives Trade Record (partial extracts from application shown)
If an order in company A is automatically routed to company B to be filled, fills made in company B can be auto-routed back to company A.
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.
Strategies
When trading derivatives, it is common to link individual transactions to form a strategy to achieve a desired result. Examples are caps, collars
and floors, where combinations of ‘simple’ derivatives trades together allow risk and profit and loss characteristics of a portfolio to be con-
strained as required.
Individual banks may define their own “combination” products, e.g. Structured Deposits. This application allows that strategy to be defined
along with its own valuation methods.
DX.STRATEGY Record
The strategies are defined in DX.STRATEGY and are used in the DX.TRADE application. A different strategy can be used for each side of the
trade in the PRI.STRATEGY and SEC.STRATEGY fields.
When transactions with a strategy are found as part of the revaluation process, these trades are valued together using the margin routine, if
specified, in the DX.STRATEGY record.
Trading Constraints
The Derivatives module includes a method of applying constraints to which contracts and/or exchanges customers or individual portfolios may
trade in the module. This is accomplished through the application DX.TRADING.CONSTRAINT and associated logic.
The 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
not allowed to trade
based on the details
entered.
More than one constraint

may be defined for a par-
ticular portfolio, as the
ID of DX.TRA- DX.TRADING.CONSTRAINT Records
DING.CONSTRAINTcon-
tains a reference number
that differentiates
between multiple con-
straints for the same port-
folio.
By setting up multiple
constraints for a client or
portfolio the system can
apply special rules for
alternative products, for
example if the exchange is
offering a new contract
and this is being offered
to the banks customers
with constraints that nor-
mally 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.
The System Record

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. You also could set up constraints which allow brokers to trade on any exchange they wish, whilst customers
remain constrained by the SYSTEM constraint.
Setting Up A Constraint
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.
The following example is of a customer who is only allowed to trade options apart from options traded on CBOT.
The logic reads as follows:
If the CONTRACT.TYPE on the

DX.CONTRACT.MASTER record
is equal to “FUTURE” then
produce an “ERROR” with NAR-
RATIVE “ONLY ALLOWED TO
TRADE OPTIONS”.
“or”
If the CONTRACT.CODE on the

DX.CONTRACT.MASTER record
is equal to “1” (CBOT) then
produce an “ERROR” with NAR-
RATIVE “NOT ALLOWED TO
TRADE CBOT OPTIONS”.
This shows that single con-

straints can be linked together
using AND/OR to produce a com-
plex constraint. There is no limit
to the number of constraints that
can be held this way within the
record.
Setting up a DX.TRADING.CONSTRAINT record

The constraint will manifest
itself by producing an override
message in both DX.TRADE and
DX.ORDER when a user
attempts to input restricted
values in any transactions.
Position Management DX Entries
Position Updates
CAS, GAP and FXP positions in PM module will be updated for finan-
cial future trades (viz. interest rate, currency and bond futures) done
for own book HEDGE transactions. However, TRADE type of con-
tracts can optionally be made to update PM, on parameterization.
The criterion for identifying the bank’s
o CUSTOMER.TYPE in DX.CUSTOMER is equal to ‘DEALER’.
An interest rate futures contract is identified from fields in DX.CONTRACT.MASTER:

o CONTRACT.TYPE equals ‘Future’ and
o PRICE.BASIS equals ‘Interest’
A currency futures contract is identified from fields in DX.CONTRACT.MASTER:

o CONTRACT.TYPE equals ‘Future’
A bond futures contract is identified from fields:

o CONTRACT.TYPE in DX.CONTRACT.MASTER equals ‘Future’ and
o There is a value available for the yield of the underlying.
CAS Position:
The commission/charges and realized P&L will impact the CAS positions. System updates the CAS position in PM.TRAN.ACTIVITY with rec-
ord ID of DX.TRADE. The commissions and charges will be updated for both primary and secondary customers of the trades. Update of CAS
position happens for all the trades, OWN book or otherwise.
GAP Position:
The DX trades of type INTEREST RATE future will update GAP position with the interest rate derived from the given PRICE and BOND future
will update the GAP position with the YIELD rate for START.DATE and END.DATE.
The START.DATE will be the FIRST DELIVERY DATE and the END DATE will be the summation of START DATE and LIFE UNDERLYING,
if the END.DATE happens to be a holiday, system will take the next working day.
FXP Position:
The DX trades of type CURRENCY future will update the FXP position for both DELIVERY CURRENCY and CONTRACT CURRENCY for the
FIRST DELIVERY DATE. If the same happens to be a holiday the next working day is considered.
The positions will also be updated as and when any amendment or settlement is done to DX.TRADE. The settlement can also be done partially
by a Partial closeout. When partial close out is done, system will update PM for the outstanding lots and also the realized P&L for the settled
lots.
PM.DX.PARAMETER table with ID as SYSTEM has to be set up for updating files of PM module for trade and hedge types of derivative trans-
actions.
Derivatives Deal Processing
This section describes Trade input and processing in Derivatives, which is part of the Treasury suite.
Deal processing in Derivatives covers the following functionality:
l Trade Capture
l Order Capture
l Data Take-on
l Price Capture
l Price Calculation
l Closing Out Trades
l Trade Transfer
l Corporate Actions
l Exotic Options
l Customer Position Reporting
l Position Reporting
l Transaction Reporting
l Transaction Status
l Trading Commissions Diagnostics
l Revaluation and Margins
l Back Valuation of Derivatives in Wealth Management
l Securities Portfolio Valuation
Trade Capture
DX.TRADE is the main trade capture application for the Derivatives product. It is designed to allow the maximum flexibility possible for trad-
ing on- and off-exchange futures and options. Trade entry in DX.TRADE is double sided, and allows ‘bulk’ trading; many clients trading with
one broker on a single trade.
Derivatives trading may occur in many different circumstances:
· Bank’s customer trades with Bank’s own book.
· Bank’s own book trades with broker.
· Bank’s customer trades direct with broker.
· Broker ‘transfers’ trade to another broker.
· Other scenarios…
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 cus-
tomer on the trade will always be for example, a clearing broker.
The DX.TRADE record is rather large to allow a wide variety of trading information to be recorded. It is recommended that users create a VER-
SION of the application to allow fast input where required.
The following sections cover trade capture in more detail:
l Trade Data Common to All Parties to a Trade

l Strategy Linking
l Commissions and Charges
l Contract Balances
Trade Data Common To All Parties To A Trade
Once the CON-

TRACT.CODE is
entered, DX.TRADE
defaults in all relevant
information from the
DX.CO-
NTRACT.MASTER rec-
ord, including the
exchange traded, type of
contract (future, option
or stock) and contract
currency.
The TRADE.DATE will

default to the Bank sys-
tem date, but may be
backdated if required.
Forward trade dates are
not allowed.
There are two basic

types of maturity date
entry, daily or monthly
corresponding to DX.TRADE Record
MATURITY.TYPE on
the contract record. For
a daily prompt the date
would be in the format
dd/mm/yy or mm/dd/yy
depending on the user
setting for the date for-
mat. For a monthly
period the date will be in
the format NNNYY or
MM-YY, where NNN in
the mnemonic for a
month e.g. MAR and
MM is the numeric
month. To avoid con-
fusion if a numeric
month is entered there
must be a separator
between the month and
the year.
The MATURITY.DATE
field will accept input in
any of these styles, and
will preserve the exact
input date in
MAT.DATE.INPUT for
input checking purposes.
The actual date stored in
MATURITY.DATE will
always be in the format
yyyymm for monthly con-
tracts and yyyymmdd for
daily maturity contracts.
The date entered will be
subject to validation
against the parameters
set for the contract on
DX.CO-
NTRACT.MASTER.
The EXECUT-
ING.BROKER for a trade
may be entered here if
applicable and can then
be used in commission
set-ups and for reporting
purposes.
For option trades, extra DX.TRADE Record

input fields are enabled.
The STRIKE.PRICE or
exercise price must be
entered here, its format
will be checked and an
internal strike price cal-
culated according to the
rules in Appendix “Price
Calculation Overview”.
The option type must

also be input in
OPTION.TYPE.
U pfr ont Pr ofit A lloc a tion For Options

In order to provide treasury rate functionality the Customer (Primary) and Broker (Secondary) prices/premiums on the derivatives trading appli-
cation can be decoupled. This will allow the user to enter a Customer rate and an internal rate for the trade.
The field TREASURY.CUSTOMER 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).
This will be used in conjunction with the Account Officer defined on the trading application.
C us tom e r -Spe c ific Tr a de D a ta
Although more than one customer can be entered on the primary side of a DX.TRADE record, the price traded and buy/sell flag is the same for
all customers. Because all fields are effectively the same on the primary and secondary sides of the trade, in the following descriptions the ‘stem’
field name is used without the preceding ‘PRI.’ Or ‘SEC.’
Depending on the
type of customer
entered (CUS-
TOMER.TYPE in
DX.CUSTOMER ),
the system will
require the input of
a
SEC.ACC.MASTER
portfolio number,
or will default the
first valid portfolio
for the customer if
no input is given.
This is not required
for Broker type cus-
tomers.
The customer
account is
defaulted using
standard T24 util-
ities for customers
and brokers, but is
displayed as an
internal account
taking the category
from
SEC.ACC.MASTER
ASSET.CAT for Derivatives Trade Input
Own Book
accounts. This is
indicative, rather
than the actual
account/category
code that will be
used to make own-
book postings.
Per customer,
trades may be
flagged as opening
or closing a posi-
tion
(OPEN.CLOSE), or
as speculative or
hedge trades. If a
trade is designated
as a hedge for a cus-
tomer, the user is
obliged to enter a
description or ref-
erence of the
hedged product or
instrument in the
LINK field.
The ALLOW.SETT
field lets the user
remove the par-
ticular trade from
consideration for
automatic closeout
of that customer’s
position. The trade
may of course still
be closed out man-
ually.
The STRATEGY
field allows groups
of trades to be
linked for reporting
or margining pur-
poses and links to
the DX.STRATEGY
application.
Strategy Linking
In order to allow the linking of complex trading strategies, T24 can stamp trades with an automatically generated Strategy Link number. The
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.
The file DX.STRATEGY.LINK holds a list of trade transactions

associated with a particular PRI/SEC.LINK. For example a group
of trades marked with BUTTERFLY001 in the PRI.LINK field
would all have their transaction id’s held in a record BUT-
TERFLY001 in DX.STRATEGY.LINK.
This functionality can be used for multiple reasons, one of which

is the initial margin calculation
Detailed information on other field inputs within DX.TRADE can

be obtained from the application helptext.
Strategy Linking
DX.TRADE Record
Commissions And Charges
The commission fields in DX.TRADE show a summarised form of the commission data. Once a trade has been committed, more detailed anal-
ysis of trading commission can be viewed in DX.COMMISSION.DIAGS.
There are two main methods of entering trading commission for a customer.
1. Automatically from criteria set within DX.COMMISSION.
2. Manually overriding the commission fields.
Selecting the desired method in the PRI.AUTO.MANUAL or SEC.AUTO.MANUAL fields controls thecommission collection method.
Automatic commission
Once this option has
been selected the
commission fields are
updated without
intervention from the
user. All the default-
ing of values is driven
by information set-up
within DX.CO-
MMISSION.
In the example below,

the commission sys-
tem has matched a
DX.COMMISSION
record to this trans-
action and applied
both execution and
clearing commission.
Commission amounts
are held in
PRI.COMM.AMT and
have been calculated
at $250 and $375 .
The ACCOUNT to
post the com-
missions to have
been established
(PRI.COMM.ACC).
If the account cur-
rency is different from
the commission cur-
rency then the
exchange rate used to
calculate
PRI.CACC.AMT will
be shown in
PRI.COMM.EXC.
The field
PRI.COMM.TAX
shows that there is
no tax duty levied on DX.TRADE Record
this commission.
If the customer for

whom commission
and charges are being
calculated is a broker,
and another broker is
marked in EXECUT-
ING.BROKER as the
executing broker for
the trade, then if any
execution fees are to
be paid, the
account/category for
posting the execution
fee only will be
changedto the execut-
ing broker’s account.
Because the values of
the trade can ulti-
mately affect the auto-
matic commission
calculations, the com-
mission fields are
cleared whenever a
change to a field on
the trade is made. If a
customer’s details fail
the selection criteria
then no commission
is calculated and an
override message
prompt is displayed.
Manual commission
For manual input of customer com-

mission, 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) allow either:
· A commission code from

FT.COMMISSION.TYPE or
FT.CHARGE.TYPE.
· Or the text “OVERRIDE”.
If “OVERRIDE” is entered instead of

a commission code, then it is pos-
sible to enter the commission cur-
rency, the amount and the posting
account.
The example here shows this

method being used for customer
number, 100163, who is on the sec-
ondary side of the trade.
DX.TRADE record
Contract Balances
For each DX.TRADE contract of Dealer type, a unique EB.CONTRACT.BALANCES record is updated. This holds details of the contract cur-
rency, balances by asset types, daily movements for each asset types and Consol key. This file is updated by core accounting process at author-
ization level.
The workflow is as follows-
l For each DX.TRADE contract, EB.CONTRACT.BALANCES is generated online upon authorization. However accrual of interest, sched-
uled payment are updated during close of business.
l For this purpose, entries are generated online instead of through CONSOL.ENT.TODAY during close of business.
l Consol key is allocated online and updated in EB.CONTRACT.BALANCES file.
l Link file, RE.CONSOL.CONTRACT is also updated during close of business.
Order Capture
The Order entry system will record individual orders from either internal traders or external clients; the orders are entered either manually or by
an interface from a front office system.
The derivatives module order entry allows the trader to check the validity of the order immediately, and record the time and date when the
order is given, input and executed. It checks the client‘s availability of funds / limits, therefore enabling a trader / credit officer to determine if,
as a result of the order being executed, any limits would be breached. It will alert the user if there are constraints applying to that particular
client / portfolio.
After an order has been entered it can then 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 deleted.
These examples show a DX.ORDER entry for two customers party

to the same deal which is to be filled by a broker.
DX.ORDER record
The deal is then partially filled via DX.ORDER, with only 20 lots
allotted to the second primary customer.
DX.ORDER Filling Entries
The part-filled order looks like this:
DX.ORDER – Part filled order
As a result of partially filling this order, a new instance of the

DX.TRADE is generated by the system in HOLD status, as shown
here.
DX.TRADE Record in HOLD status
Note that the remaining lots can be filled either partially or fully later on.
In the above illustrated flow the presumption was that all filled orders would be parameterised to create DX.TRADE(s) with their status set to
IHLD, however, it is possible to create these trades with a status of INAU. In order to do this, please see the section on Straight Through
Processing within the Derivatives Configuration guide.
Data Take-on
Using the TRANSFER.TYPE field, the DX.TRADE application allows 3 types of data takeon, TAKEON (for legacy trade entry),
TAKEON-CONT (for legacy own-book trade entry), and RVPDVP (for transfers of trades into a position without affecting account postings
etc.).
Where TRANSFER.TYPE has been set to TAKEON-CONT, the system posts contingent entries for the trade, so this is recommended for take-
on of own book trades.
Data Take On
All other fields on the trade are entered as normal (though narrative and external reference fields may be used to capture data about the trans-
fer/legacy system).
Price Capture
The major function of this application group is to allow the correct valuation of open positions (trades) using the revaluation group. The actual
method used to value a position can vary, however most methods rely on a Market or Fair Value price.
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 man-
ually input, calculated or received from an external source. Throughout the day, when the contracts are being traded, current (or last) prices
might be received which, if stored, will allow on-line real valuations to take place.
Additionally users may want to change prices based on what they think might occur in the market and then revalue a portfolio based on these
speculative prices.
The application is therefore 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, initially only MANUAL prices will be entered, additional feeds
can be added. The prices that need to be updated are known as price sets, and are defined using the application DX.PRICE.SET.
To understand pricing in Derivatives, it is important to understand the application DX.MARKET.PRICE.
The function of this 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.
Prices within the derivatives module are identified by a combination of factors e.g. their price set, contract, the maturity date or strike price etc.
of the contract.
For example:
The CLOSING price for a JUN04 LIFFE Short Sterling Future (FSS) would be identified as.
CLOSING*/19/GBP/200406//*
Where CLOSING is the price set, 19 is the contract, GBP is the contract currency and 200406 is the maturity year and month.
Similarly the CLOSING price for a JUN04 LIFFE Short Sterling Option (FSO) would be identified as.
CLOSING*/20/GBP/200309/CALL/97.50*
Where CLOSING is the price set, 20 is the contract, GBP is the contract currency, 200406 is the maturity year and month and 97.50 is the
strike price.
Thus it can be seen that the DX.MARKET.PRICE transaction id string can be seen as a dynamic id that is built to reflect the complexity of the
underlying transaction.
The following sections deal with specific instances of manual pricing as well as automatic pricing:
l Futures and Stock Prices

l Option Prices
l Futures/Stock Contracts
l Option Contracts
l Automated Price Capture
Futures And Stock Prices

To record the current market price for a Future or Stock contract the system requires simply that the price be entered into the contract rec-
ord, with the optional update of the INTEREST.RATE and VOLATILITY of the contact.
Therefore the closing price of 95.60 for a December 03, Three Month EURIBOR Future (12) would look like this.
Futures and Stock Prices
Option Prices

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.
So a strike price of 106.00 on a March 2004 EuroBond Option (15) with a call of 3.74 would look like this.
Note:
l The DELTA of a contract represents the rate of change of the option price with respect to the underlying asset.
l The GAMMA of the contract represents the rate of change of the delta with respect to the underlying asset.
l The VEGA represents the rate of change of the value with respect to the volatility of the underlying asset.
Option Prices
Futures/Stock Contracts
To record the cur-
rent 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 cur-

rent price of 94.50
for a December
2004 3MTH
EURIBOR Future
( 12 ), the CON-
TRACT.CODE and
PRICE.SET should
be entered; the
application will
then display the
price for that con-
tract and price set
etc.
Futures/Stock Contracts
In order to change
the December 02
price, search
through the record
for a maturity of
200212, if the
maturity date does
not exist then
simply add a new
multi-value set for
the particular
maturity date
(MAT.DATE).
Option Contracts
Again 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 INTER-
EST.RATE and
VOLATILITY of
the contact.
So the strike price

of 150 on a March
2003 5 Year “T”
note Option ( 2 )
with a call of 151
and a put price of
149 would be
updated as shown
here using DX.MA-
RKET.PRICE
Option Contracts
Automated Price Capture
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.
DX.CONTRACT.MASTER Setup
For contracts that the user wishes to have priced by a particular price source you will need to set this up on the DX.CONTRACT.MASTER rec-
ords.
Pricing DX.CONTRACT.MASTER Setup
This example shows that for the CLOSING price set the Garman Kohlhagen PRICE.SOURCE will be used to generate a price.
D X.PR IC E.SOU R C E
When a price source is set-up, the follow fields will need to be set-up.
Example price source set-ups
A PROGRAM, which generates the price or requests the price data from a price feed. This will required to be set-up in DX.OBJECT.LIBRARY
and the PGM.FILE.
UPDATE.AVAIL should also be defined. If for example an external price feed is deactivated, this switch will stop the derivatives system from
requesting information from it and will require a manual update to take place in the DX.MARKET.PRICE file.
D X.PR IC E.SET
Example Price Set Setup
The picture above shows an example of a DX.PRICE.SET that will only allow prices to be requested from a DX.PRICE.SOURCE if they have
not been updated in the last 30 minutes. It is possible to leave these fields blank, which will ensure that for the price set, prices will always be
requested.
Whe n A r e Pr ic e s U pda te d
End of Exchange
Prices are updated during the end of exchange processing using the routine DX.CHECK.PRICES. This process should be run, as an EOE pre
process to ensure that all prices are as up-to-date as the system requires.
Online
Prices can be updated online using a verify application DX.RV.CHECK.PRICES. This basic application checks the current position across the
derivatives system and will request a price for every open position that requires one. The normal validation rules apply.
Online Price Request
Once the application has opened a PRICE.SET should be selected. This has three options ONLINE, END OF EXCHANGE or OTHER. These
are not linked to the DX.PRICE.SET application, these relate to the price sets set-up in the DX.PARAMETER SYSTEM record which define
which price set should be used online and which end of exchange. If the user wishes to define which price set they want to use, they should
select OTHER then enter an ALT.PRICE.SET which links to the DX.PRICE.SET application.
Online Price Request with Output
Once the request has been completed, the system will report the status of the update. If all prices have been updated then the system will
report “All Prices are available”, if not it will warn that “Errors have been encountered whilst checking prices” and then list all of the
prices/strike prices that have not been updated.
To commit these updated prices to the database the record must be committed.
Price Calculation
Various factors are used in the calculation of prices and premiums to ensure, given the quoted prices of a contract; the correct cash value is gen-
erated. These factors are usually published by exchanges on a contract-by-contract basis. In the T24 system they are stored in the application
DX.CONTRACT.MASTER.
l Price/Premium Terminology
l Variable Tick Size Calculations
l Example Contract Key Date Calculation
l Price Calculation Methods
Price/Premium Terminology
Tick Size
This 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.
Tick Value
This is the resultant change in the value of a contract by a movement of 1 tick in the price.
Minimum Movement
This is a field added to T24 to allow for the validation of prices when a contract’s minimum movement is no longer a tick. For example, some
contracts are quoted having half tick prices. In this case the tick size maybe 0.01 and the minimum movement would be 0.005.
Price Scale
This is the divisor of the digits after the “decimal” point. For currencies and most futures and options contracts this is 100, i.e. decimal. Cer-
tain contracts trade in other units such as 32nd ’s i.e. A price of 118.20 means 118 and 20/32 units. As a decimal this would be 118.625. To
help distinguish the difference, the decimal point normally referred to as “spot”, i.e. “One hundred and eighteen spot six two five”.
Multiplication Factor
Also known as an “adjustment” factor. This accounts for that fact that many prices are quoted differently to the actual value. For example a
price maybe be quoted as £5.24 or 524 pence. This factor converts the quoted price to the real value.
Contract Size
This is the amount of the underlying product that is being purchased. For futures this could be, for example, 40,000lbs of frozen pork bellies,
or 500,000 dollars. For most exchange traded options the contract size is one futures contract.
Definitions
In the calculation section of this document the following abbreviations are used:
CV Contract Value. This is the total amount that will be payable for a futures contract. However as futures contracts are marked-to-mar-
ket. As the price varies daily some of the contract amount will be paid or received throughout the life of the contract. These pay-
ments are known as variation margin.
LOTS The number of contracts bought or sold in a transaction. For calculation purposes this is signed, with buys being positive and sells
being negative.
MF Multiplication Factor
OV Option Value. Also known as unrealised option profit/loss. This is the “contract value” of an option when the premium has been
paid at trade time.
PA Premium Amount. This is the actual cash amount paid or received for buying or selling an option.
PR The premium rate quoted for an option. This is the traded price of an option and is normally just called the premium.
QP Quoted price. This is used internally as the price as which to calculate the internal price. See next section.
TP Trade Price. This is the price agreed with the counter party when a transaction was performed.
TS Tick Size
TV Tick Value
VM Variation Margin. The profit or loss on the contract due to the change in the value price. This is calculated (normally daily) for
futures and options where the premium is not paid at trade time.
VP Value Price. This is the price at which a position should be valued. For exchange traded contracts this would normally be the mar-
ket price. For other contracts this could be calculated by a recognised formula such as the Black and Scholes theoretical option
value model.
Calculations
The basic calculations required by the system are:
CV = TP / TS * MF * TV * LOTS
OV = VP / TS * MF * TV * LOTS
PA = PR/TS * MF * TV * LOTS
VM = ABS(VP – TP) / TS * MF * TV * LOTS
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.
This greatly simplifies and speeds up the calculations of the other figures. QP (the Quoted Price) may be the TP, the VP or the PR.
Examples
LIFFE Long Gilt Futures Contract
Contract Size 100,000
Tick Size 0.01
Tick Value 10.00
Price Scale 100 (Decimal)
Minimum Movement 0.01
Decimal Places 2
Example Price 98.23
Internal Price (98 / 0.01 + 23) * 10 = 98230
Invalid Prices 97.223 Too many decimal places
LIFFEThree Month Sterling Futures Contract
Quotation 100.00 minus rate of interest
Tick Size £0.01
Tick Value £12.50
Price Scale 100 (Decimal)
Minimum Movement 0.01
Example Price 94.53
Internal Price (94 / 0.01 + 53) * 12.50 = 118162.5
Invalid Prices 102.23 Invalid for interest based contracts
BOTFive Year Treasury Note Future
Contract Size $100,000
Tick Size 1/32
Tick Value 31.25
Number of decimal places 3
Price Scale 32
Minimum Movement 0.5/32 (1/2 tick)
Price Tolerance 2 (%)
Example Price 112.25
Internal Price (112 / (1/32) + 25) * 31.25 = 112781.25
Invalid Prices 102.45 Cannot have 45 32nd’s
108.326 Invalid minimum movement
Example Market Price 113.00
Example Price 116.23 Override generated price difference > 2%
CBOTFive Year Treasury Note Option
Tick Size 1/64
Tick Value $15.625
Price Scale 64
Minimum Movement 1/64
Strike Price Scale 100 (Decimal)
Strike Price Interval 0.5
Example Price/Premium 9.12
Example Strike Price 112.5
Internal Price (9 / (1/64) + 12) * 15.625 = 9187.5
Variable Tick Size Calculations
Pricing conventions around the world may differ. In Europe and the United States, interest rate securities are traded in the cash market on the
basis of their capital price. In Australia, instruments are priced on the basis of yield with the futures price quoted as 100 minus the yield to
maturity.
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 vary continuously with
the external price according to the algorithm used.
SFE’s interest rate contracts, are traded on the basis of yield, with the futures price quoted as 100 minus the yield to maturity is expressed in
percent per annum. This means that the tick value on these products does not remain constant but rather changes with movements in the
underlying interest rate. The tick value decreases as interest rates rise and increases as interest rates fall.
Examples:
l Australian Treasury Bill SFE Futures and Options

l 90-Day Bank Bill Futures Tick Value Calculations
l 90-Day Bank Bill Options
l Australian Government Bond SFE Futures and Options
Australian Treasury Bill SFE Futures And Options
The SFE publishes an algorithm for the calculation of the value of one of their standard futures contracts on this instrument. This value will be
used as the TEMENOS T24™ internal price. In the following section, Temenos comments are highlighted, as is this paragraph.
Unlike its best known equivalent in the United States, the Eurodollar time deposit, the value of a physical 90-Day Bank Bill is calculated
according to a yield to maturity formula that discounts the face value to establish the appropriate interest cost over the 90 days.
The formula for the present value (P) of a bank bill is:
The face value represents the bill's future value, i.e. its value at the end of its 90-day term. Please note the Australian convention is to use a
365 rather than a 360-day year. In order to calculate the present value (P) of a 90-Day Bank Bill, which has a face value of $100,000 and is
trading at a yield to maturity of 5.50%, the following calculations are performed:
This same formula can be applied to value Bank Bills with varying maturities (i.e., 30, 60, 90, 180 days) and face values (i.e. $100,000,
$500,000, $1,000,000). These values would simply be inserted into the formula where appropriate.
This can be achieved by having different records with different parameters calling the same basic algorithm in the new ‘internal price calc’ appli-
cation.
For SFE 90-Day Bank Bill Futures, where the contract value is always $1,000,000, and the term to maturity is exactly 90 days, the bank bill
formula can be rewritten as:
Where the yield is the futures price deducted from 100
Therefore if a Bank Bill futures contract were trading at 95.00 (i.e. a yield of 5%), the value of the contract would be:
This value is in fact the Derivatives module internal price for the contract.
90-Day Bank Bill Futures Tick Value Calculations
The dollar value of a 0.01% change (the tick size) in yield does not remain constant but rather varies in accordance with changes in the under-
lying interest rate.
Accordingly, to establish what the dollar value of a futures tick will be at a given price, the following calculations are made:
1. Use the contract valuation formula (as described above) to calculate the underlying value of the contract at the nominated futures price.
2. Apply the same formula to that same futures price minus 0.01 (i.e., increase the yield by 0.01%).
3. The difference between the two contract values represents the dollar value of the tick at the nominated futures price.
To determine the dollar value of a 0.01% change in yield of a Bank Bill futures contract, which is trading at a price of 95.00 (i.e. a yield of
5.00%), the following calculations are performed:
1. Futures contract value at 95.00 (5.00%) = $987,821.38. (Rounded to two decimal places)
2. Futures contract value at 94.99 (5.01%) = $987,797.32. (Rounded to two decimal places)
3. Difference (value of 0.01% of premium)= $24.06
For TEMENOS T24™ purposes, the tick size will be returned as 0.01 and the tick value as whatever the above calculation yields.
90-Day Bank Bill Options
Premiums for options on 90-Day Bank Bill futures are quoted in terms of annual percentage yield (e.g. 0.60% pa or 1.05% pa) with the value of
a single point of premium (i.e. 0.01% pa) calculated by comparing its contact value at the exercise price (expressed as 100 minus annual yield)
and its value at that same exercise price less one point (0.01%).
For example, a 90-Day Bank Bill option with an exercise price of 95.00 and a premium of 0.065% pa would be valued as follows:
1. Futures contract value at 95.00 (5.00%)= $987,821.38 (rounded to two decimal places)
2. Futures contract value at 94.99 (5.01%)= $987,797.32 (rounded to two decimal places)
3. Difference (value of 0.01% of premium)= $24.06
Since we have 6.5 points of premium, the final premium in dollars is calculated as: $24.06 x 6.5 = $156.39
The premium and strike price will both be passed into the subroutine, allowing the above calculation to be made.
Australian Government Bond SFE Futures And Options
Although the algorithm and parameters required to produce the internal price for this contract are different from those seen with Australian
Treasury Bill SFE Futures and Options , the principle is exactly the same, i.e. the value of the future is the TEMENOS T24™ internal price for
the future, etc.
l Australian Commonwealth Treasury Bonds

l SFE 10-Year Treasury Bond Futures
l 10-Year Treasury Bond Futures Tick Value Calculations
l 10-Year Treasury Bond Options
Australian Commonwealth Treasury Bonds
The formula for calculating the price per A$100 of an Australian Commonwealth Treasury Bond as supplied by the Reserve Bank of Australia
is:
Where v = 1/ (1+i) where i is the annual percentage yield divided by 200.
f = the number of days from the date of settlement to the next interest payment date.
d = the number of days in the half year ending on the next interest payment date.
c = the amount of interest payment (if any) per $100 face value at the next interest payment date.
g = the fixed half-yearly interest rate payable (equal to the annual fixed rate divided by 2).
n = the number of full half-years between the next interest payment date and the date of maturity (equal to 2 times the number of years until
maturity).
an = v + v +……. + vn = (1 – vn)/i.
The convention adopted with Commonwealth Treasury Bonds is that interest is paid on the fifteenth day of the appropriate month with the
last interest payment made at maturity.
Using the Reserve Bank pricing formula, the calculations that would be performed to value a Commonwealth Treasury Bond with a maturity of
15 October 2007, a coupon rate of 10.00%, a market yield of 5.70% and a settlement day of 7 April 1998 would be:
i = 0.02850000
v = 0.97228974
f = (2/4/98 + T3 business (7/04/98) to 15/4/98) = 8
d = 182
g=5
n = 20
f/d = 0.04395604
c=5
Using the above inputs, the bond would have a value of A$136.04095670 per $100 face value (inclusive of accrued interest). This figure con-
sists of a capital price of $131.26073690 and accrued interest of $4.78021978.
SFE 10-Year Treasury Bond Futures
For SFE Treasury Bond futures, the pricing formula can be simplified because there is always an exact number of half years to maturity and
hence there is no requirement to calculate accrued interest.
The formula for the value (P) of a 10-Year Bond futures contract on SFE is written as:
Where: i = yield % pa divided by 200
v = 1/ (1+i)
n = 20
c = coupon rate/2.Thus to value a 6% coupon 10-Year Treasury Bond contract which is trading at a price of 95.500 (i.e. A yield of 4.50% pa.),
the inputs would be:
i = 0.02250000
v = 0.97799511
n = 20
c=3
When these inputs are included in the formula, the contract value for the above contract will be A$119,972.78.
Note that the mathematical convention is that multiplication and division take precedence over, addition and subtraction. In the futures for-
mula, this means that the division by 1 is performed before the addition of 100v20.
To exactly match the contract value as calculated by Sydney Futures Exchange Clearing-house (SFECH), steps C, D and G must be rounded to
exactly eight decimal places, with 0.5 being rounded up. No other steps are rounded except K, which is rounded to 2 decimal places. The Clear-
ing-house makes the calculation in the following manner:
Futures Price 95.500
A 100 - price 4.500
B I = A/200 0.0225
C v = 1/(1 + B) 0.97799511
D v20 0.64081647
E 1 - v20 = 1 - D 0.35918353
F 3(1 - v20) = 3 x E 1.07755059
G 3(1 - v20)/i = F/B 47.89113733
H 100v20 = 100 x D 64.081647
I G+H 111.972784330
J I x 1,000 $111,972.784330
K Rounded $111,972.78
The value calculated is used as the internal price in the TEMENOS T24™ Derivatives module.
10-Year Treasury Bond Futures Tick Value Calculations
The methodology used to calculate tick values for the 10-Year Treasury Bond Futures is identical to that outlined in the previous example for
90-Day Bank Bill Futures.
For example, to determine the dollar value of a 0.01% change in yield on a 10-Year Bond contract trading at a price of 94.360 (i.e. A yield of
5.64%), the following calculations are performed.
1. Futures contract value at 94.360 (5.64%) = $102,723.06023 (rounded to eight decimal places)
2. Futures contract value at 94.350 (5.65%) = $102,646.18658 (rounded to eight decimal places)
3. Difference (value of 0.01% of premium) = $78.87365 or $78.87 rounded to two decimal places.
10-Year Treasury Bond Options
Like Bank Bill options, 10-Year bond options are quoted in terms of annual percentage yield (E.g. 0.410% or 0.525%), with the value of a sin-
gle point of premium (i.e. 0.01%) calculated as the difference between the contract value at the exercise price (expressed as 100 minus the
annual yield) and its value at that exercise price less one point (0.01%).
Please note that when making these calculations, contract values are not rounded to the nearest cent before calculating this difference. Accord-
ingly, the dollar value of an option on a 10-Year Treasury bond option with an exercise price of 94.000 and a premium of 0.140% would be cal-
culated as follows:
1. Futures contract value at 94.000 = $100,000.0000 (rounded to eight decimal places).
2. Futures contract value at 93.990 = $99,925.6470014 (rounded to eight decimal places).
3. Difference (value 0.01% of premium) = $74.3529986.Since there is 14 points of premium, the final premium in dollars is calculated as:
$74.3529986 x 14 = $1,040.9420 which when rounded to the nearest cent gives $1040.94.Example Contract Maturity Rules
DX.CONTRACT.MASTER allows the Bank to set up maturity validation rules for trading using specifications distributed by exchanges. This
appendix contains some ‘real-world’ examples of how this is done.
Example 1: SIMEX Euroyen TIBOR Futures
March, June, September, December contracts on a 5-year cycle.
MV Field Contents
Number
AVAIL.MONTHS
1 MONTHS.FORWARD 60
MATURITY.MONTHS MARCH
JUNE
SEPTEMBER
DECEMBER
MATURITY.DAYS
Six consecutive months, plus two quarterly months on a March, June, September, December rotation
MV Field Contents
Number
AVAIL.MONTHS 8
1 MONTHS.FORWARD 6
MATURITY.MONTHS ALL
MATURITY.DAYS
MV Field Contents
Number
2 MONTHS.FORWARD OPEN
JUNE
SEPTEMBER
DECEMBER
MATURITY.DAYS
Example 2: LIFFE Cocoa Future
March, May, July, September, December cycle such that 10 trading months are available
MV Field Contents
Number
AVAIL.MONTHS 10
1 MONTHS.FORWARD OPEN
MAY
JULY
SEPTEMBER
DECEMBER
MATURITY.DAYS
Example 3: OTC Contract
A Contract can be traded every Monday for 6 consecutive months, then every first Monday in a January, April, July, October cycle for a 5-year
term.
MV Field Contents
Number
AVAIL.MONTHS
1 MONTHS.FORWARD 6
MATURITY.MONTHS ALL
MATURITY.DAYS MO
2 MONTHS.FORWARD 60
MATURITY.MONTHS JANUARY
APRIL
JULY
OCTOBER
MATURITY.DAYS +1MO
Example Contract Key Date Calculation
SIMEX Euroyen TIBOR Futures
· Today’s date – 22/06/00.
· Last trading date is the second business day preceding the third Wednesday in the maturity month. (DX.CONTRACT.MASTER
LAST.TRADE = “FCD,+3WE,-2BD”).
· Delivery date is the third Wednesday in the maturity month. If not a business day, step forward until a business day is found. (DX.CO-
NTRACT.MASTER DELIVERY.DATE = “FCD,+3WE,MF”).
Step 1 – calculate all valid trading months.
Use information stored on DX.CONTRACT.MASTER (see the previous section dealing with Price/Premium Terminology).
Is reference date in a valid maturity month? If so, then…
Is reference date past last trading date in current month?
June 2000 is a valid maturity month for the contract, but the last trading day in June 2000 (using the formula given) is the 19th . Take ref-
erence date to be 01/07/00.
Using reference date (01/07/00) calculate which month/year combinations are available for trading.
Valid trading months are:
SEP2000, DEC2000, MAR2001, JUN2001, SEP2001, DEC2001, MAR2002, JUN2002, SEP2002, DEC2002, MAR2003, JUN2003,
SEP2003, DEC2003, MAR2004, JUN2004, SEP2004, DEC2004, MAR2004
The system then loops through valid trading months applying key date formulas. If a formula for a particular key date is not defined, the system
assumes “LBD” (last business day of the month in question).
For the sake of this example, we will assume that the third Wednesday in December 2000 (20/12/2000) is a non-business day.
Using the formulas set in DX.CONTRACT.MASTER, the Last Trading Date for the contract maturing in September 2000 is 18th September.
The First Delivery Date is 20 th September.
Price Calculation Methods
Option pricing models can be used as requested by customers to calculate ‘fair values’ for non-exchange-traded contracts.
Examples of widely used pricing models would be 'Black and Scholes', 'Black76', 'Cox, Ross and Rubenstein', 'Binomial' and 'Garman
Kohlhagen'.
Values for option contract 'Greeks' generated by the models will be automatically uploaded into the relevant DX.MARKET.PRICE records.
The derivatives price application (DX.MARKET.PRICE) holds a list of “Greek” values required/generated as part of 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.
Using the derivatives pricing infrastructure the prices can be generated for any price set, at any time using DX.RV.CHECK.PRICES to generate
the prices online.
The application DX.VOLATILITY is used to input the volatilities to be used by the option pricing models.
The key for this file is CONTRACT.CODE – MATURITY.
Example contract 43 and the maturity 1 st May 2001 would be 43-20000501
Then enter the volatility rate for the Call and the Put: 1
FX. Rate
This is obtained from the application CURRENCY.
Time To Expiry
This is automatically calculated from the MATURITY.DATE.
Strike Price
This is obtained from DX.TRADE.
The methods which are supplied as standard are listed below:
l Black and Scholes

l Cox, Ross & Rubinstein (Binomial)
l Garman-Kohlhagen
Black And Scholes
The Black and Scholes method is used to calculate the value of a European call Stock option. Like the other models, it uses the stock price,
strike price, expiration date, risk-free return, and the volatility in generation of a fair value price.
Cox, Ross & Rubinstein (Binomial)
Cox, Ross and Rubinstein’s Binomial calculation is used to generate a fair value price for equity options. These prices can be generated with or
without dividend adjustment dependant on user requirements, and is designed for use with both European and American style options.
Garman-Kohlhagen
Garman-Kohlhagen is a price calculation for options. The Garman-Kohlagen option pricing routine obtains all the required parameters from the
relevant DX.MARKET.PRICE record. This data can either be input manually of via one of the supplied “build” routines. The following is a user
guide to show how to use and implement the Black-Scholes Garman-Kohlagen method of price calculation.
Initial Set-up
DX.PRICE.SOURCE
For the initial SET-UP the user needs to enter which price sources are available by using the application DX.PRICE.SOURCE.
Price source describes what sort of pricing model is to be used.
Enter Price source id GARMAN
Field 1SHORT.DESC GARMAN KOHLHAGEN
Field 2.1DESCRIPTION GARMAN KOHLHAGEN
The program to call the routine
Field 3PROGRAM PR.GARMAN.KOHLHAGEN
The constant name “INTSEQ” is required by the module and must not be changed.
The constant data item to use to identify the first two digits from PERIODIC.INTEREST will be fields 5.1 and 6.1.
Field 5.1CONS.DATA.NAME INTSEQ
Field 6.1CONS.DATA.ITEM 01
Field 9 UPDATE.AVAIL Yes
The routine that has been designed to fill in the Data in DX.MARKET.PRICE if required
Field 10.1BUILD.PGM PR.BUILD.GK
DX.PRICE.SOURCE Record
DX.CONTRACT.MASTER
Next the contracts and price sets that use this source should be entered. Within the application DX.CONTRACT.MASTER field PRICE.SET,
which is a multi-value field, needs to be defined as either Current, Closing or both. The user must link the price source to the contract
(PRICE.SOURCE).
PRICE.SET Current, Closing or multi-valued to include both.
PRICE.SOURCE GARMAN
DX.CONTRACT.MASTER Record
The price source, set and contracts have now been defined.
Data Required
The data required using the option-pricing model Garman Kohlhagen is held in DX.MARKET.PRICE.
The Garman-Kohlhagen Routine uses the following fields to calculate the theoretical option value. The fields need to be updated before the rou-
tine is run (as part of the end of exchange processing). Note that a build routine has been included to automatically populate this data (see sec-
tion 4 below).
INTEREST.RATE Contract Currency
SEC.INT.RATE Delivery Currency
INTEREST.BASIS The Interest Basis of the Contract Currency.
OPTION.STRIKE Strike
CALL Call Price
PUT Put Price
C.VOLATILITY Call Volatility
P.VOLATILITY Put Volatility
UND.PRICE Underlying Price / Exchange price of the two currencies
UND.I.PRICE Underlying Internal Price
DX.MARKET.PRICE Record
DX.MARKET.PRICE Record (continued)
Build Routine PR.BUILD.GK
The build routine extracts information from the following applications and automatically fills the relevant fields in DX.MARKET.PRICE.
The user would have to fill in DX.MARKET.PRICE manually if no routine was in place.
Spot Price CURRENCY (FX Rates)
Strike Price DX.TRADE
Time to exercise of options (days) Automatic
Interest. Basis CURRENCY (Currency Table)
Domestic currency risk free rate of interest PERIODIC.INTEREST
Foreign currency risk free rate of interest PERIODIC.INTEREST
Annual Volatility DX.VOLATILITY
Time to exercise of options (years) Automatic
PERIODIC.INTEREST
The fields CONS.DATA.NAME “INTSEQ” and CONS.DATA.ITEM, in PRICE.SOURCE look at PERIODIC.INTEREST
PERIODIC.INTEREST Record
Closing Out Trades
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. Com-
mission 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 (Exchange Delivery Settlement Price). For options, no pseudo
trades are created. For trades where premium was not paid at Trade Date, the 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.
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 (call or put). Additionally, other fields may be entered to fur-
ther 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.
DX.CLOSEOUT
The DX.CLOSEOUT application is the central application for the processing of closeouts within the T24 derivatives module. Once a closeout
has been passed to the closeout engine from one of the closeout enquiries, a DX.CLOSEOUT record is created; this record holds all of the
details of the closeout.
Users cannot directly
input closeouts into
the DX.CLOSEOUT
application; this must
be done from an exter-
nal source. Once a
closeout has been
created in the
DX.CLOSEOUT appli-
cation, it can be author-
ised, deleted or
reversed in the same
way as any normal T24
application function.
Because of the nature
of closeouts you can-
not rerun a history rec-
ord closeout; a new
closeout must be run.
From the closeout

application you have
access to information
regarding that specific
closeout. A closeout
marked as RUNNING
in the STATUS field
identifies that the close-
out has been created
and processing is still
running. An ACTIVE is
a closeout that has
occurred, i.e. the trades
have been matched and
the closeout is now
waiting for
authorisation.
STATUS DELETED
closeouts have been
reversed.
A Typical Closeout Record
The closeout type iden-
tifies what style of
closeout this closeout
is. SETTLEMENT
closeouts are basic
manual closeouts per-
formed by the system.
MATURITY closeouts
are cash maturity set-
tlements. Exercise,
Expiry and Assignment
are Option Actions,
which are to be han-
dled by the closeout
suite.
The creation of the

DX.CLOSEOUT record
identifies how the close-
out was creat-
ed/requested. Using
ENQ DX.CO.M-
ANUAL.BRWS& ENQ
DX.CO.-
MATURITY.BRWS is
considered a MANUAL
CREATION. AUTO
(Automatic) will be
run, by a user, when
they wish the system
to automatically close
out a position, avail-
able in later phases of
implementation. The
SYSTEM closeouts are
closeouts generated by
the system under a spe-
cific set of cir-
cumstances
The ACCOUNT iden-

tified on the record is
the account where the
profit and loss/option
premium will be posted
for this closeout.
Closeouts are performed against each leg of the closeout separately. T24 can also be configured to closeout both sides of the deal auto-
matically - see the section on back to back closeouts in the Derivatives Configuration guide.
The various types of closeout are discussed in the following sections.
l Manual Closeout
l Automatic Closeout
l Maturity Closeout
l Futures/Stock Cash/Maturity Closeouts
l Option Maturity Closeout
l Assignment, Expiry and Exercise
l Automatic Processing
Manual Closeout
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. In order to process a new manual
closeout, run the relevant enquiry, for example ENQ DX.CO.MANUAL.FUTURE.BRWS.
The user selects a customer and

a unique contract. For futures
this would involve the spec-
ification 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 (call or put). Additionally
other fields maybe entered to fur-
ther restrict the selection of
trades.
Futures Manual Closeout Enquiry
All the open trades matching

this criterion will then be dis-
played. Once the user is satisfied
that the trades selected are
those from which they want to
process the closeout, he selects
which trades and how many lots
from each trade are to be settled.
Futures Manual Closeout Enquiry List
As long as the total numbers of
buy lots is the same as the total
numbers of sell lots, the record
may be committed. The user
will then be presented with
another screen as shown here-
which will illustrate the total
profit/loss on the trades being
“closed out” and presenting
them with the option to create
an authorised or unauthorised
DX.CLOSEOUT record.
Should the user select to create

an unauthorised DX.CLOSEOUT
record they will subsequently
need to authorise the record to
generate realised profit and loss
entries. However, an authorized
record will automatically gen-
erate these entries.
Once the settlement is con-

firmed the closeout engine will Generated Manual Closeout
report back the current closeout
id, profit and loss of this close-
out, and any commission
charged as part of this closeout.
The closeout key reported is a

key to the master closeout rec-
ord held in DX.CLOSEOUT. Futures Manual Unauthorised Closeout record
The lots chosen to be closed and

be processed and the DX.TRAN-
SACTION TRA.PND.SETT and
TRA.PND.LOTS fields will hold
the closeout key and the number
of lots pending to closeout.
On the trade the

PRI.PND.SETT/SEC.PND.SETT
and Futures Transaction with Settled Primary Lots
PRI.PND.LOTS/SEC.PND.LOTS
will also be updated to show
how many lots are pending to be
settled.
It is worth noting that you cannot directly input into the DX.CLOSEOUT application using function I, 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 dec-
remented and the closeout details moved to DX.TRANSACTION TRASETTNOS and DX.TRADE PRI.SETTNOS /SET.SETTNOS fields.
Any Commissions, Profit or loss for the closeout will be posted at authorisation.
Similarly the ENQ DX.CO.MANUAL.OPTION.BRWS follows the same process as the DX.CO.MANUAL.FUTURE
except for the selection criteria, which requires the Option type and the strike of the option.
Options Manual
Closeout Enquiry
Automatic Closeout
The 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 on each of these levels may be set to control this i.e.:
DX.EXCHANGE.MASTER
Field SETT.ALLOWED may be set to YES to allow settlement or closeout on this exchange, or NO to disable or Blank defaulting to YES.
DX.CUSTOMER
Field AU.CT.CLASS may be set to FUTURES, OPTIONS, BOTH OR NONE.
Field AU.SETT.TYPE may be set to FIFO (first in first out), LIFO (last in first out) or FIFO.DAY (today trades take precedence).
Field AU.SETT.DELAY may be set to the no of days after trade when settlement/closeout can occur.
DX.CONTRACT.MASTER
Field SETT.ALLOWED may be set to YES to allow settlement or closeout, NO not to allow or Blank to default to the Exchange Master setting.
DX.TRADE
Field XXX.ALLOW.SETT may be set to YES to allow settlement or closeout, NO to prohibit auto or system settlement for this trade out. Note
this may be overridden by Manual closeout, and also note that for a Hedge trade it is always NO.
Automatic closeouts are initiated through the selection criteria from DX.CO.AUTO.INPUT.
Automatic Closeout Record
The closeout is part of the End of Exchange or End of Day process. Note that 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.
Maturity Closeout
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 lay-
out differences. In order to process a new maturity/cash settlement closeout, run the relevant enquiry - the examples below show sample
inputs for the enquiries DX.CO.MATURITY.FUTURE.BRWS and DX.CO.MATURITY.OPTION.BRWS respectively.
Futures Maturity Closeout Enquiry Option Maturity Closeout Enquiry
The user selects a customer,

unique contract and maturity
date; and for options, a strike
price and option type (Call/Put).
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 closeout application is essen-

tially the same as the one used
for manual closeouts, however
the number of buy and sell lots
Futures Maturity input for Market price
need not match, and a maturity
price field is present. The user
may then select which of the
trades and how many lots from
each trade are to be settled
before committing the record.
Once a maturity price has been
entered, the settlement may be
confirmed as either to produce
an Authorised or Unauthorised
Closeout record.
Once the settlement is author-

ised the closeout engine will
report back the current closeout
id, profit and loss of this close-
out, and any commission
charged as part of this closeout.
Maturity Futures Closeout Confirmation
Cash/Maturity settlements are

not closed out against other
“live” trades within the system,
but are closed out against
notional pseudo trades created
by the closeout engine; these
transactions and trades will not
appear on the live files. These
pseudo trades are only created
for futures and stocks but not
for options.
Futures Pseudo Transactions
Futures/Stock Cash/Maturity Closeouts
An example of a Futures / Stock maturity closeout in T24, the example identifies what constitutes a pseudo transaction/trade.
In the example you wish to close out a transaction of a Sell of 25 Lots of Dec00 (CME) GBP Currency Futures @ 1.4245
The EDSP at the time of the maturity closeout is 1.4400.
The original transaction is then Cash Settled against a Buy 25 Lots of Dec00 (CME) GBP Currency Futures on 13/12/00 @ 1.4400. This trans-
action is automatically created as a pseudo transaction; it does not physically exist as a position within T24.
The Short Position of 25 Lots is then Cash Settled against a Long Position of 25 Lots.
The Overall Position is now zero.
The Profit and Loss is calculated as the sum of the Sell values minus the sum of the Buy values:
25 Lots X Internal Price = USD 2,225,781.25
25 Lots X Internal Price = USD 2,250,000.00
A Loss of USD –24,218.75 is then calculated.
The processing/authorising of Pending Lots and Settled Lots is the same as the Manual Closeouts discussed earlier in the manual closeout sec-
tion.
Option Maturity Closeout
Pseudo transactions and trades are not created for option maturity closeouts. Like the manual closeout, the profit and loss is calculated as the
total sell value less the buy value for all of the transactions to be closed out.
It is important
to note that for
options con-
tracts there
will be no
maturity price
field available
in the closeout
application.
Unlike manual
closeouts, the
number of lots
closed out for
buys and sells Options Maturity Closeout Selection Application
does not have
to be equal.
The profit and

loss figure for
this closeout is
in fact the
amount of
option pre-
mium for this
contract
remaining out-
standing to be
paid at set-
tlement.
Option Closeout Confirmations
This screen-
shot shows the
number of lots
pending and
the closeout
for which they
are pending; it
also shows
what the
Charge Date
was at Trade
time, which
means that for
this trans-
action, there is
no profit and
loss to post.
Transaction Record of a Transaction Being Used As Part of the Closeout
This shows the
related
DX.CLOS-
EOUT record.
Maturity Option Closeout
The processing/authorising of Pending Lots and Settled Lots is the same as the Manual Closeouts discussed earlier in the manual closeout sec-
tion.
Assignment, Expiry And Exercise
Option exercise, expiry, and assignment can either be a manual process, where the user selects the trades and lots to be processed, or an auto-
matic 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 (note - automatic assign-
ment is not supported as T24 cannot intuitively understand how many lots have been assigned – this can only be done manually).
For details on setup, please see the Automatic Expiry or Exercise section within the Derivatives Configuration manual.
Once the functionality has been activated for a contract, any DX.TRADE(s) that remain ACTIVE past the defined contracts DEC.DATE will be
exercised / expired in the next COB.
Example 1
1. DX.CONTRACT.MASTER for 3mth Eurodollar Option has EXER.PRI.MEM set to a value of 1.0000
2. Customer buys 200309 3mth Eurodollar 95.00 Calls
3. No manual actions are performed against the DX.TRADE during its life and the DEC.DATE for the contract is reached
4. Assume the DX.MARKET.PRICE for the UNDERLYING Futures contract is defined as 96.00 (meaning the trade is in-the-money by
the defined tolerance)
5. During the next COB the system will automatically exercise the option and create a DX.TRADE for the underlying FUTURES contract.
Example 2
1. DX.CONTRACT.MASTER for 3mth Eurodollar Option has EXER.PRI.MEM set to a value of 1.0000
2. Customer buys 200309 3mth Eurodollar 95.00 Calls
3. No manual actions are performed against the DX.TRADE during its life and the DEC.DATE for the contract is reached
4. Assume the DX.MARKET.PRICE for the UNDERLYING Futures contract is defined as 95.50 (meaning the trade is NOT in-the-money
by the defined tolerance)
5. No processing will occur in the next COB and the DX.TRADE will remain ACTIVE.
If the underlying product is a futures contract, the appropriate derivatives trade will be automatically created by the system. If the underlying is
a stock, a system call to the SECURITIES module will be made to create the underlying stock transaction. If the option exercises to CASH, a
system call to the FOREX module is made to create a Spot FX transaction.
Manual Processing
The functionality is invoked as an enquiry selection under three enquiries DX.CO.MANUAL.EXPIRE.BRWS , DX.CO.M-
ANUAL.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 trades’ selection. 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.
Note that this process may take place at any time of the day with the restriction that only one session is in progress.
l Manual Assignment
l Manual Exercise
l Manual Expiry
Manual Assignment
Using the enquiry DX.CO.M-
ANUAL.ASSIGN.BRWS, the user
can manually choose which
options to assign.
DX.CO.MANUAL.ASSIGN.BRWS Enquiry
According to the selection crite-

ria, the trades are displayed, and
the number of lots assigned
before commitment.
Trades displayed from DX.CO.MANUAL.ASSIGN.BRWS Enquiry
Manual Assign record
The Closeout process, on author-
isation, will remove these options
from the open position and make
any necessary postings. Note
these postings include premiums
for contracts with posting at set-
tlement time.
Manual Option Assignment Closeout
Furthermore, depending on the

Underlying Product Trade
nature of the underlying product,
a corresponding transaction in Future A DX trade for the future
HOLD status, in its related mod-
ule will be generated. Cash A FX transaction
Bond or Stock A SEC trade
Transaction types created on closeout
Manual Exercise

ANUAL.EXERCISE.BRWS,
the user can manually choose
which options to exercise.
Manually choose and display trades
According to the selection

criteria, the trades are dis-
played.
The user can select the trans-

actions and the number of
lots to be expired before com-
mitting the selection.
Displaying trades for selecting lots to exercise
Corresponding closeout record
The Closeout process , on
authorisation, will remove
these options from the open
position and make any nec-
essary postings.
Note these postings include

premiums for contracts with
posting at settlement time.
Remove options from the open position
Furthermore, depending on
the nature of the underlying Underlying Product Trade
product, a corresponding
transaction in HOLD status, Future A DX trade for the future
in its related module will be
Cash A FX transaction
generated.
Bond or Stock A SEC trade
If a DX.CLOSEOUT record
resulting from an exercise Transaction type created on closeout
option with an underlying
future is reversed, the child
record for the underlying
future in IHLD is deleted, or if
it has already been authorised
it is set as RNAU.
Refer to the ENQUIRY

DX.MO-
NITOR.STP.PROCESS if
there is any problem.
Manual Expiry

ANUAL.EXPIRE.BRWS, the user
can manually choose which
options to expire.
Manually choose which options to expire
According to the selection crite-

ria, the trades are displayed.
Manual option enquiry – trades displayed
From the screen displayed, the

user can select the transactions
and the number of lots to be
expired, and then commit the
selection.
Unauthorised Manual Expiry record
On authorisation will remove
these options from the open posi-
tion and make any necessary post-
ings. Note these postings include
premiums for contracts with post-
ing at settlement time.
Remove options from open position
Automatic Processing
Automatic Closeouts may be performed on line. The process enables the system to automatically select all the trades for the specified contract,
which are due to expire or exercise. The input programs DX.CO.EXPIRE.AUTO or DX.CO.EXERCISE.AUTO are used to select eligible trades
by: PORTFOLIO, CUSTOMER, CONTRACT, MATURITY.DATE, STRIKE and CALL.PUT and then initiate the processing. Processing is sim-
ilar to the equivalent manual application, except that the user may wish to automatically authorise the closeout. Authorisation of DX.CLOS-
EOUT is needed for the processing to continue if Unauthorised was selected.
Automatic Expiry - DX.CO.-

EXPIRE.AUTO
Automatic Option Expiry
In DX.CO.EXPIRE.AUTO,
in the mandatory field CUST
OR PORT if the user selects
the value as ALL, then the
close out (expiry) is done
through the service
DX.CO.EXP.AUTO.-
SERVICE during COB.
Automatic Exercise -
DX.CO.EXERCISE.AUTO
Automatic Option Exercise
Automatic Assignment -
DX.CO.ASSIGN.AUTO
This differs from Exercise

and Expiry in that, as well as
specifying the unique con-
tract the user has to indicate
the total number of lots to
be allocated.
The system, using the

assignment method stated
on the contract master rec-
ord, assigns the lots to the
selected trades. The trades
and lot details are then
passed to the assignment
process in the same way as
the manual process.
Automatic Assignment
System Processing
This method is identical to the automatic Option Exercise and Expiry process except it initiates the end of exchange process rather by the user.
The system selects which options need processing by checking the last trade or declaration dates in the open trades, i.e. DEC.DATE =
“TODAY”. It also checks that the client or trade has not been set up to hold options open for a certain number of days. Then based on the
strike price, the underlying price and the price differences defined in the DX.CONTRACT.MASTER, the system determines if each option trade
should be exercised, expired or “left alone”.
Note that System assignment of Options is not supported, as it cannot automatically determine accurately the number of lots that the bank has
been assigned.
Trade Transfer
Derivatives module allows the transfer of trades between portfolios and customers, both internally and externally. These transfers can be per-
formed with or without account postings or any confirmations being generated, which can be parameterised on a transfer-by-transfer basis.
For this purpose, there are appropriate fields in the applications DX.TRADE, DX.TRANSACTION and DX.CLOSEOUT. Further, on author-
ization of the DX.CO.XFER.MANUALor DX.CO.EXT.XFER.MANUAL records, DX.CLOSEOUT record is created to reflect the trade transfers.
In this connection, new DX.EVENT.TYPErecords will need to be setup;
• CN – Internal Transfer (Transferor Side)
• II – Internal Transfer (Transferee Side)
• CO – External Transfer (Outgoing)
• CT – External Transfer (Incoming)
Internal Transfers
To run an Internal transfer

use application
DX.CO.XFER.MANUAL
It is possible to transfer
deals from one customer
to another or from one
customer’s portfolio to
another.
DX.CO.XFER.MANUAL
A new DX.TRADE
“TRANSFER” deal 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.
DX.TRADE Created by a Transfer
On committing the trans-

fer a new DX.CLOSEOUT
record will also be gen-
erated which when com-
mitted removes the
position on the Trans-
ferors side.
To action the transfer the

DX.CLOSEOUT record
generated must be author-
ised by another user.
The positions held will

now be between the Trans-
feree and the original
counterparty.
DX.CLOSEOUT record for the transfer
In order to perform an external
transfer of a transaction use
DX.CO.EXT.XFER.MANUAL
The method followed is the same

as for an internal transfer, includ-
ing the creation of a new
DX.CLOSEOUT record which
must be authorised.
On authorising the DX.CLOS-

EOUT record the system will
remove the internal position for
the transferor and generate an
delivery message setup in
DX.EVENT.TYPE CO and gen-
erate a message/payment.
Derivatives External Transfers
It is possible to transfer deals

from one customer to another or
from one customer’s portfolio to
another
New DX.TRADE transfer trans-

action will be automatically gen-
erated between the transferor
and the transferee for the
DX.CO.EXT.XFER.MANUAL Record
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 com-
mitted, removes the position on
the Transferor’s side. Positions
held will now be between the
Transferee and the original
counterparty.
For external transfers,

application is used. On author-
izing the DX.CLOSEOUT record,
the internal position for the
transferor is removed, and, a
delivery message is generated.
We make use of the

application to perform external
transfers
Corporate Actions
As per the Securities module,

new corporate actions are
defined in the DIARY.TYPE
application.
If an event affects contracts that

are defined in the derivatives
module then it can be setup as
an event in the DX.DIARY appli-
cation, this is defined by setting
the DERIVATIVES flag on the
DIARY.TYPE record.
A Diary Type Record
The function of the DX.DIARY

application is essentially the
same as the Securities
DIARY.TYPE application, but is
tailored for Derivatives corporate
actions.
This includes options to alter

the lots/strike price/contract
size/contract number etc…
Derivatives Corporate Action Diary
The derivatives entitlement appli-
cation DX.ENTITLEMENT acts
in much the same way as the
Securities ENTITLEMENT appli-
cation.
DX.ENTITLEMENT shows Cus-

tomer/portfolio entitlements per
DX.DIARY event.
Each maturity and strike is

shown with the new strike, con-
tract size and number of lots.
Records are created via

DX.DIARY. They will be created
as unauthorised.
The authorisation of these rec-

ords is controlled by DX.ENT.-
ACTION.
Derivatives Option Entitlements Record
Entitlement authorisation takes
place using DX.ENT.ACTION ,
which runs an automated author-
isation of DX.ENTITLEMENTS
as per DX. DIARY event
Once the EX.DATE has arrived

or passed then DX ENTITLE-
MENT records can be author-
ised.
DX Entitlement Authorisation
l Strike Price Rounding and Creation of New Series
Strike Price Rounding And Creation Of New Series
For certain stock markets, when processing corporate actions affecting the strike price of an option (e.g. dividends) the resulting strike price
can be rounded a specific way to suite the exchange.
After the normal calculation of the strike price, a routine to round up or down or no rounding will be called if required.
There can also be a need when the contract size changes as a result of the Corporate Action, that a new contract for the new option series
needs to be created to trade in the future, as the contract size is likely to be different for the original option series.
The keeping of the original series and creating a new one will eliminate the problem of not being able to do closeout because of the two dif-
ferent contract sizes.
If this option is chosen a new DX.CONTRACT.MASTER record based on the old one but with the new contract code will be generated.
D X.C ON TR A C T.MA STER
Fields used for this process are

ROUNDING, RND.FACTOR,
LINK.CONT.ID and
LAST.VALID.DATE.
Values allowed in field ROUND-

ING are STANDARD, ROUND
and UP.
When STANDARD is specified

RND.FACTOR is not required,
the system validates for this.
When UP or DOWN is specified

the value stored in RND.FA-
CTOR is the value the
STRIKE.PRICE will be rounded
to.
The fields LINK.CONT.ID is

used to specify the new option
series that the system creates DX.CONTRACT.MASTER Rounding Factor
and LAST.VALID.DATE indi-
cates the last trading date this
option series can be trade.
D X.TR A D E A nd D X.OR D ER
These applications will display a warning if a contract linked is traded that has been superseded with a new contract due to a corporate action,
thus ensuring that users know they are dealing on an old option series
D X.D IA R Y
When processing Corporate

Actions in the Derivatives Mod-
ule, the user creates one record
in DX.DIARY per Corporate
Action, in which the parameters
defining the Corporate Action are
set. This includes ratios describ-
ing changes in Contract Size,
Strike Price and Number of Lots.
The option to create a new con-

tract is also chosen here.
The fields include ROUNDING,

RND.FACTOR,
CREATE.CONT.Y.N, DX.DIARY Rounding Factor
NEW.CONT.MNE and
NEW.EXCH.CODE.
The fields ROUNDING and RND.FACTOR take defaults from DX.CONTRACT.MASTER record.
The field CREATE.CONT.Y.N is the trigger for a new options series to be created and accepts a value of YES or NO. The generation of a new
option series will depend on whether the original contract size of the option is changed as a result of the corporate action.
If this field is set to NO then do the following -
l Ensure using the ratios input, that if the amended contract size is not an exact multiple of the original one, a warning will be displayed
to tell the user to create a new contract.
l The processing of the fields NEW.CONT.CODE and NEW.CONT.SIZE stays unchanged.
If this field in set to YES the do the following -
l If a NEW.CONT.MNE was input, ensure that it does not already exist.

l If the New Cont Code is generated through a user routine, again the same check is done.
l Ensure that the Tick Value = Contract Size * Multiplication Factor * Tick Size when the contract size is changed.
l Use OFS to generate a Contract record with the new Contract code, Mnemonic Exchange code and new Contract size if any, with all
other fields defaulted from the original contract record
The user must populate the NEW.CONT.MNE and NEW.EXCH.CODE fields.
On authorisation of the DX.DIARY record, if a new contract is to be created it is written at this stage, calculating the new contract size (if the
ratio for Contract Size has been set). At the same time, the DX.ENTITLEMENTS records are set up.
Finally, the corporate action is run using the process DX.ENT.ACTION, in which the DX.DIARY key(s) for the corporate action(s) to be run
are given.
D X.EN TITLEMEN T
On Authorisation of these records created from the DX.DIARY the individual DX.TRADEs and their underlying DX.TRANSACTION records
are picked up from the DX.ENTITLEMENTS records and are then amended with respect to changes in contract size, strike price and number
of lots.
Fields ROUNDING and RND.FACTOR display the values that were used and specified in the DX.DIARY.
Exotic Options
Setup of Exotic Options is covered within the Derivatives Configuration guide.
The following case studies illustrate how Exotic Options are traded and accounted for.
l Credit Default Swap

l Knock In Option
l Knock Out with Rebate
Customer Position Reporting
The standard CUSTOMER.POSITION has been amended to now include derivatives transactions where the Derivatives module is installed.
There are three types

of entry into the CUS-
TOMER.POSITION
file - DX, DXVM and
DXIM , these being
the transaction values,
the variation margin
values for the trans-
action and the initial
margin value for the
customer, respec-
tively.
Plain DX items report Example CUSTOMER.POSITION Listing

the contingent value
of a transaction, the
maturity date, the
value date, and cat-
egory along with many
other data.
The DXVM items

report the Variation
Margin figure gen-
erated by the end of
exchange revaluation
process, along with
other data.
The DXIM items

report the Initial mar-
gin figures for that
client, there will only
be one of these items
per client as Initial Example CUSTOMER.POSITION record
Margin cannot be
broken down into
transaction by trans-
action based figure as
it relies on a group of
trades.
It is important to
remember that the
DXVM items will only
be available after an
end of exchange reval-
uation has taken place
and the DXIM figures
will not take into
account any trans-
action not included in
the last end of
exchange revaluation.
Position Reporting
DX.REP.POSITION is updated online when trades are verified, deleted or reversed.
It is keyed in by: customer or portfolio number, contract number, currency, maturity date, option type (if applicable) and price in internal for-
mat.
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 type
(call or put) and strike (exercise) 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 trans-
actions 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.P-
ARAMETER
AVE.PRICE.ME-
THOD (see help text
for details).
DX.REP.POSITION Record
Transaction Reporting
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, a port-
folio/customer
number to identify
the ‘side’ of the par-
ent 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.TRAN-
SACTION.
When recording
trades, most of the
customer depend-
ant data in the
trade record is
reproduced in
DX.TRAN-
SACTION for
reporting purposes.
DX.TRANSACTION record
DX.TRANSACTION holds trade details on a customer-by- customer basis i.e. a simple trade between two customers will generate two
DX.TRANSACTION records, whilst a bulk trade between ten customers and one broker will build 11 DX.TRANSACTION records.
As a general example, the initial entry and validation of a derivative trade involving three customers and one
Portfolio DXTR
broker would produce entries in DX.TRANSACTION as shown on the right.
100018- yydddnnnnn
If the trade were deleted before authorisation, all the DX.TRANSACTION records raised would also be 1: .100018-1.1
deleted.
Portfolio DXTR
The transactions remain unaltered on authorisation of the trade. 100032- yydddnnnnn
2: .100032-2.1
Portfolio DXTR
100055- yydddnnnnn
1: .100055-1.1
Broker DXTR
110010: yydddnnnnn
.110010.1
Portfolio DXTR
If the trade were then amended, on validation of the amendment a new set of transactions would be created 100018- yydddnnnnn
as shown on the right. 1: .100018-1.2
Note that new transactions are created for all participants in a trade with consistent sequence numbers, even Portfolio DXTR
if the ‘side’ of the trade associated with a particular customer/portfolio has not changed. 100032- yydddnnnnn
2: .100032-2.2
Portfolio DXTR
100055- yydddnnnnn
1: .100055-1.2
Broker DXTR
110010: yydddnnnnn
.110010.2
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
i.e. 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. The set of transactions ‘belonging’ to the authorised (unchanged) ver-
sion of the trade should be reinstated – that is REVERSAL.DATE and REVERSAL.TIME should be set to null.
In the case of the
reversal of an
authorised trade
(or settlement,
etc.), updating of
the transaction file
and the associated
routines occurs
only at author-
isation of the rever-
sal. When this
happens, the cur-
rent set of
DX.TRAN-
SACTION records
associated with the
DX.TRANSACTION list showing history of the record
parent trade have
their REVER-
SAL.DATE fields
updated with the
current bank date
and REVER-
SAL.TIME fields
set to the current
time, but are NOT
removed from the
DX.TRAN-
SACTION file.
If a reversed record
is restored from his-
tory (goes into
status HNAU in
unauthorised file
on verification of
history restore),
the latest set of
transactionsbelong-
ing to the trans-
action should have
REVERSAL.DATE
and REVER-
SAL.TIME set to
null.
Transaction Status
DX.ITEM.STATUS records activity

against derivative transactions and
shows both the current and all pre-
vious status’s of the transaction.
The ID for each record on this file cor-

responds 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 ( DX.TRADE ,
DX.ORDER or DX.CLOSEOUT) asso-
ciated to the activity.
The CURR.STATUS is shown in the

first multi valued set with previous
activities shown in chronological
order thereafter by STATUS.
DX.ITEM.STATUS.TYPE(s)
The screenshot on the right shows a
DX.ITEM.STATUS record resulting
from a NEW trade which has been
entered and kept in INAU status.
When the trade is in INAU status, the

following holds true:
Curr Status: Denotes the

last status of
the application
e.g. NEW,
AMD, AUT,
REV, AUR
Curr Date: Denotes the

date when the
trade is
punched A View of the DX.ITEM.STATUS Record for a trade
Curr Time: Denotes the

time of the
trade
Curr User: The user who

input the trade
Curr Application: Denotes which

application
has been used.
Once the trade has been amended a
few times, committed and authorised,
the DX.ITEM.STATUS record looks
like this:
DX.ITEM.STATUS Record for a trade after a number of changes to the underlying transaction
Trading Commissions Diagnostics
DX.COMMISSION.DIAGS is a live file which holds a full diagnostic breakdown of how the trading commission figures charged are paid to cus-
tomers 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 main-
tained 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 match-
ing 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 com- Commission types Diagnostic field descriptions
mission is displayed
by each of the dif- COMMISSION COMM…
ferent commission
EXECUTION EXFE…
types.
CLEARING CLFE…
Each type shows the
following infor- REGULATORY RGFE
mation: MISC MISC…
l Commission
currency. Commission/Fee Diagnostic Information
l Account
where com-
mission has
been
posted.
l Currency of
the posting
account.
l Exchange
rate (if com-
mission cur-
rency is
different
from the
account cur-
rency).
l Commission
or Charge
code.
l Any taxes
associated
with the
com-
mission.
This example shows
the commission
charges relating to
customer number
110018 for trade
DXTRA032410000-
1.
Field names begin-

ning with “EXFE…”
indicate that these
charges were cat-
egorised as com-
mission type
EXECUTION.
The commission was

automatically gen-
erated for this cus-
tomer with charges
taken from a cus-
tomer group DX.CO-
MMISSION record, -
-DEALERS-.
Derivatives Trading Commission
The other customer
involved in the trade,
100163 , has 3 dif-
ferent types of com-
mission charges
entered:
EXECUTION,
CLEARING andREG-
ULATORY.
These were input

manually into the
trade.
Derivatives Trading Commission
Revaluation And Margins
Part of the functionality of the derivatives module is to re-calculate the value of clients or portfolios after the exchanges have closed. This can
either be done as part of the overnight batch utility or as an on-line process. Revaluation may be invoked in many different modes and produce
different events. The base of this module forms part of the end of exchange process and therefore will form the part of the end of day processing
for the module.
The revaluation module has been developed to allow the valuation, accounting and reporting of futures/stock and options held in the T24
derivatives system. The revaluation process maybe called for three different reasons:
l End of Day batch revaluation/processing.

l End of Exchange/Centre revaluation/processing.
l On-line ad-hoc revaluations.
In all three cases the revaluation calculations performed are the same. The differences are the products to be valued, the prices they should be
valued against, and the resultant accounting treatment of the figures produced. Therefore along with the core revaluation process additional
modules will be written around it, which will be called as required.
The core revaluation process consists of two major functions: initial margin and variation margin allocation. Additional processes include
retrieval/calculation or prices, retrieval of trades, posting of accounting entries and reporting of results. These additional processes can be
added into close of business (DX.COB.WORKFILE) as required.
Further details on how to configure Initial Margin calculation and Variation Margin calculation can be found in the Derivatives Configuration
User Guide.
l Revaluation Summary
l Revaluation for Exchange
l Revaluation Details
l Adhoc Revaluation
l Initial Margin Methods
Revaluation Summary
The DX.REVALUE.SUMMARY file details the total margin amounts for a client, portfolio or group. This is dependent on what event has trig-
gered the revaluation:
l For a standard ad-hoc revaluation this key can be the revaluation followed by a Customer/Portfolio or Group depending on the reval-
uation level RE.VALUE.LEVEL set in DX.REVALUE.
l For an end of exchange the key is structured using a customer id.
The screenshot on the

right defines the margins
for all contracts held by
Customer 110018.
This record details figures

held in the currencies in
which they were cal-
culated and in the
BASE.CURRENCY for
that customer held in
DX.CUSTOMER
REPORTING.CCY.
It also holds the exchange

rates used to convert
these amounts.
Detailed in the record is

also a link down to the
next level of reporting.
EXCHANGE.KEYS holds
all the keys of the DX.R-
EVALUE.EXCHANGE
records that combined to
make this DX.R-
EVALUE.SUMMARY rec-
ord.
DX Revaluation Summary Record
Revaluation For Exchange
The DX.REVALUE.EXCHANGE 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:
l For a standard ad-hoc revaluation, this key can be the revaluation followed by a Customer/Portfolio or Group depending on the reval-
uation level RE.VALUE.LEVEL set in DX.REVALUE. For example, DXRVL003644*4*GBP*50030-1, DXRVL003644*4*GBP*AA.BB
or DXRVL003644*4*GBP*50030
l For an end of exchange, the key is structured using a customer id. E.g. DXEOE003644*4*GBP*50030
Therefore the margins on USD

contracts held on Exchange 2
for Customer 110018 are
detailed here.
The exchange record details a

number of groups of infor-
mation.
l A link to the reval-

uation detail files, the
keys of and the appli-
cation names relating
to those keys.
l The total margin fig-
ures for this currency
and exchange.
l The combined com-
modities used and
their constituent
DX.CO-
NTRACT.MASTER
contracts.
l The margin totals on
a contract- by- con-
tract basis, and a list
of the transactions of
that contract.
Revaluation Exchange Details Record
Revaluation Details
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 beginning with 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. Without this,
revaluation cannot complete.
There are currently two standard margin routines provided with the derivatives module: STAND.VM and STAND.IM; their detail filenames are
DX.REVAL.DET.STAND.VM and DX.REVAL.DET.STAND.IM.
l DX.REVAL.DET.CHREG.VM
l DX.REVAL.DET.STAND.IM
l DX.REVAL.DET.STAND.VM
l Exchange defined Initial margin Requirements
DX.REVAL.DET.CHREG.VM
A Variation Margin (revalue P&L) calculation ‘black box’ CHREG.VM has been released. This behaves in a similar way to the original
STAND.VM calculation, except that P&L is now calculated on options where the premium has already been paid, rather than the ‘Unrealized
Option Value’ calculated by STAND.VM.
CHREG.VM is available for selection in the VAR.MARGIN.CALC field of DX.CONTRACT.MASTER.
Margin Calculation Shell Record
DX.REVAL.DET.STAND.IM
This detail file holds the data required to calculate the standard initial margin on a group of transactions in the derivatives system; these trans-
actions are grouped by exchange, by strategy, by contract, and by customer/group/portfolio.
Initial Margin Revalue Details Record
The information held is predominately held on a contract by contract basis, apart from the total initial and maintenance margins, and whether
this exchange NETT’s its transaction against each other or is a GROSS(ing) exchange. The contract based information details the Initial Margin,
Maintenance Margin. For each contract, the Rates found by the derivatives module to apply to this position, the type of rate, and data extracted
from the DX.MARGIN.RATES record, such as the FULL.RATE, SPREAD.RATE, STRADDLE.RATE, are stored. The number of lots to be
charged at a specific rate is also detailed. For example 25 Lots at 3000 per lot, gives an initial margin figure of 75000.
DX.REVAL.DET.STAND.VM
This 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.
DX.REVAL.DET.STAND.VM Record
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.
Exchange Defined Initial Margin Requirements
There are two other initial margin routines currently available with the derivatives module: EURONEXT -AEX and OCC. TIMS; their detail fil-
enames are DX.REVAL.DET.EURONEXT and DX.REVAL.DET.OCC.
The details will be grouped within the revaluation or the end of exchange run, in their respective strategies for the customer.
The calculation’s used by these black box routines are defined by the exchanges that use them, for example the AEX exchange uses the EURON-
EXT method as do a number of other exchanges throughout the world.
The example shows a list of EURONEXT margin calculation.
EURONEXT Margin Calculation
As with the previous methods the DX.REVAL.DET (NNN) application files provide the user with details of which values are used in the cal-
culation of the margin, therefore if there are any discrepancies the user can do a manual check back to ensure the validity of the figures.
Adhoc Revaluation
The DX.REVALUE application allows the user to initiate an ad-hoc “what if” revaluation.
The DX.REVALUE application allows the entry of the selection criteria defining the trades/positions to be revalued. Once the entries have been
input and authorised, the revaluation process passes control to the “Grey Box” processes.
DX Revaluation
The selection criteria is broken down into four sections, “who”, “by who”, “which trades”, and parameters.
l The “Who” consists of ALL.CUSTOMERS, GROUP, CUSTOMER and PORTFOLIO. If all customers are to be revalued, 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.
l The “By Who” section allows you to specify any number of DEALER.DESK(s)and/or DEPT.ACCT.OFFICER.
l The “Which Trades” 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.
l The parameters allow the user to define which PRICE.SET is to be used during revaluation.
l 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.
l RE.VALUE.LEVEL asks at which level the top- level summary information in DX.REVALUE.SUMMARY and DX.R-
EVALUE.EXCHANGE is to be stored. This allows the system to calculate the total margins for either; a PORFOLIO, a CUS-
TOMER, or a CUSTOMER group.
To set-up a revaluation, create a new DX.REVALUE record, and then define which customers/trades should be revalued. Revaluation records
cannot be re-used. The processing will begin once the record is authorised.
Initial Margin Methods
The revaluation suite has a “black-box” design, which allows new initial margin calculations to be developed easily to a published standard and
added to the Derivatives module with the minimum of effort. As well as simplifying Temenos development of future margining algorithms this
will allow flexible local and client-driven development of new routines without core development involvement.
For all margining algorithms used, diagnostic information will be created and stored to allow easy justification of the figures produced.
l AEX Euronext
l OCC/TIMS Margining
AEX Euronext
Margin requirements apply to investors who write uncovered options. No margin is required for the writing of covered call options or the pur-
chase of options.
Amsterdam Exchanges option market (Euronext) prescribes minimum margin requirements for uncovered writing of options. Margin require-
ments are calculated daily. If the outcome of this calculation rises, an additional deposit may be required.
Options can be bought or written. Buying options creates a long position, while writing options results in a short position.
Writing call options (short call) means that the writer may be assigned to deliver the underlying value at the option’s exercise price. This exer-
cise price will generally be lower than the market price of the underlying value. If the writer of the call option has deposited the underlying value
with the bank, this is referred to as covered writing because the writer is at all times able to meet the obligations. When the underlying value is
not deposited with the bank, this is known as uncovered writing and the writer must therefore satisfy the minimum margin requirements.
Writing put options (short put) means that the writer may be assigned to accept delivery of the underlying value at the option’s exercise price.
This exercise price will generally be higher than the market price of the underlying.
A margin percentage is generally used to calculate the margin requirements. The margin percentage is related to the volatility of the underlying
value. Margin percentages are published monthly in the Euronext Bulletin. Margin percentages and initial margins are calculated monthly. There-
fore monthly changes are possible. However, Euronext may decide to change margin percentages at other times. In this event Euronext will pub-
lish details via a Euronext announcement
AEX Euronext Setup
1. DX.MARGIN.CALC - to
set up AEX Margining.
DX.MARGIN.CALC to set up AEX Margining
2. DX.E-
XCHANGE.MASTER - to set
up AEX as an exchange.
DX.EXCHANGE.MASTER to set up AEX as an exchange.
3. DX.STRATEGY - to set
up SPREAD, STRADDLE,
STRANGLE, SYN-
THETIC.SPREAD,
TIME.SPREAD,
DUTCH.SPREAD.
DX.STRATEGY to set up SPREAD, STRADDLE, STRANGLE, SYNTHETIC.SPREAD, TIME.SPREAD,

DUTCH.SPREAD.
4. DX.MARGIN.RATES -
for using Futures Rate and
for using Options Percentage.
DX.MARGIN.RATES for using Futures Rate and for using Options Percentage
5. DX.CO-
NTRACT.MASTER in
INIT.MARGIN.CALC - input
should be EURONEXT
DX.CONTRACT.MASTER in INIT.MARGIN.CALC input should be EURONEXT
6. DX.TRADE - remember
to input the Strategy and
note the PRI.LINK number
to link strategies together.
DX.TRADE remember to input the Strategy and note the PRI.LINK number to link strategies together
7. DX.MARKET.PRICE
for closing
DX.MARKET.PRICE for closing
8. DX.REVALUE - run an
adhoc revaluation
DX.REVALUE
9. DX.REVAL.DET-
.EURONEXT to view the
margins on the trade.
DX.REVAL.DET.EURONEXT to view the margins on the trade.
OCC/TIMS Margining
The Options Clearing Corporation (OCC) is responsible for clearing the trades performed on the following exchanges:
AMEX American Stock Exchange
CBOE Chicago Board Options Exchange
NYSE New York Stock Exchange
PHLX Philadelphia Exchange
PSE Pacific Exchange
The main function of the clearing organisation is to guarantee any confirmed trades by assuming the role of the counter party to all the trans-
actions. In order to be able to fulfil this role, the clearing organisation requires an initial margin or deposit. In the case of default by any
member, the clearing-house can close out any open positions and the initial margin held by the clearing-house should cover any losses
incurred.
The clearing-house therefore calculates, at least once a day, an initial margin amount for each clearing member. This figure is based on each
member’s open positions and does the clearing-house define calculated using the methodology.
It is also a requirement of any exchange member to charge their customers (including other non-clearing brokers) at least the amount charged
by the clearing-house. It is also a requirement for non-clearing firms and brokers to charge their customers at least the amount charged by the
clearing
OCC.TIMS Margin Set Up

DX.MARGIN.CALC to set up
OCC Margining.
DX.MARGIN.CALC to set up OCC Margining
DX.STRATEGY to set up
SPREAD, STRADDLE and
RISK.SPREAD
DX.STRATEGY to set up SPREAD, STRADDLE and RISK.SPREAD
DX.CONTRACT.MASTER
NOTE input values for Gen Data

Code = STOCK, STOCKINDEX,
FOREX, or INTEREST
DX.CONTRACT.MASTER
DX.MARGIN.RATES:
STOCK CONTRACT
Stock Contract
STOCK INDEX CON-

TRACT
Define by “band” i.e.

broadband 20 (percent)
narrow- band 15 (per-
cent)
Stock Index Contract
FOREX CONTRACT
FOREX Contract
INTEREST CONTRACT
Define T-BILL, T-NOTE

and US T BOND con-
tracts respectively by
percentage e.g. 0.35, 3
and 3.5 and minimum
e.g. 0.05, 0.5 and 0.5
Interest Contract
LINKING OF TRANSACTIONS
This is done by first noting the

link number generated from the
first transaction for the strategy
being used. Then for the other
transaction that is being stra-
tegically linked to the first one,
the same link and strategy must
be input. This is the way the sys-
tem identifies the strategy link-
age. DX.TRADE (linking transactions)
UseDX.REVAL.DET.OCC.TIMS (List) to view the margin details
The derivatives module maintains the input and storage of historical prices, thus enables the valuation of historical positions by the Wealth
Management module. The historical values so calculated for the given positions are updated in the Wealth 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.MA-
RKET.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
The table DX.BV.PRICE.CHANGE.TODAY holds the ids of DX.MARKET.PRICE.HISTORY records whose values are changed on any given
day. Again, this record is held only in the system up until the greatest of the PRICE.DAYS from DX.PARAMETER.
The event type BV is used for the back valuation of derivatives positions. Whenever, a back valuation happens, new DX.TRANSACTION record
gets created with id 'DXBV…'
Securities Portfolio Valuation
The standard SC.POS.ASSET includes derivatives items where the Derivatives (“DX”) module is installed.
Example SC.VAL.MARKET enquiry
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.
Example SC.POS.ASSET listing
The data extracted from the DX module will be the latest up-to-date data all transactions will only be included once they have been
authorised. Where it is possible to update on a Position / Transactional basis it is anticipated that a Positional update will be used
Example SC.POS.ASSET record
The update to this enquiry/file can be done on a Positional or Transaction basis; this is defined in the DX.PARAMETERrecord SC.ASSET.UPD
field.
Handling Premiums In Any Currency For FX OTC Options Trades
Premium/price for FX OTC Options can either be denominated in the

contract currency or any other valid currency.
System will identify that an order or a trade is a FX OTC Options
based on the following:
- EXCHANGE.TYPE field of DX.EXCHANGE.MASTER is ‘OTC’
- UNDERLYING field in DX.CONTRACT.MASTER is set to CASH
- Value in fields, CONTRACT.CCY and DLV.CCY in DX.ORDER or
DX.TRADE are currencies and not precious metals
The following fields cater to the requirement of collection of premium
at Trade level:
- PRI.PRICE: Premium quoted in PIPS in contract currency
- PRI.TRADE.COST: Total premium amount in contract currency
- PRI.PREMIUM.CCY: Currency in which the premium is denom-
inated. 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 pre-
mium currency (Premium amount X Contract size X No. of lots)
- PRI.ACCOUNT: Account used to pay/receive the total premium
amount (can be in any currency). If not defined by User, Account cor-
responding to the Premium Currency will be defaulted. If no Account
exists in the premium currency, the first Account in
SEC.ACC.MASTER will be defaulted. User can override the system
defaulted value.
At DX.ORDER level, input is allowed only in SEC.PREMIUM.CCY
field and the rest of the premium related fields are no input fields.
At DX.TRADE level, the fields, PRI.PRICE, PRI.PREM.PRICE and

PRI.TOTAL.PREM are interrelated. The user is expected to input value
in any one of the fields only and the system will update the other
related fields. The following defaults/validations will be done by the
system:
- PRI.PREMIUM.CCY should be inputted by the user and if left blank,
will be defaulted with the currency of the PRI.ACCOUNT.
- When PRI.PREMIUM.CCY is input by the user, PRI.ACCOUNT will
be defaulted by locating the PRI.PREMIUM.CCY account in
SEC.ACC.MASTER record. If no such account exists in premium cur-
rency, the first account in SEC.ACC.MASTER will be defaulted.
- Override will be generated by the system if the user input PRI.PR-
EMIUM.CCY and PRI.ACCOUNT currency differs.
- PRI.PREM.EXCH.RATE will be defaulted as “1” when the PRI.PR-
EMIUM.CCY and the CONTRACT.CCY are same and will be a no
input field.
- PRI.TOTAL.PREM field will accept value in terms of amount denom-
inated in PRI.PREMIUM.CCY. In this case, system will populate
PRI.PREMIUM.PRICE and PRI.PRICE.
- When either PRI.PREMIUM.CCY or PRI.PREM.EXCH.RATE is
amended, the price/premium related fields will be cleared by the sys-
tem prompting the user to input the values again.
- Primary side of DX.TRADE or DX.ORDER will not accept more than
one customer ID and error will be thrown by the system if input by the
user.
Depending on which side the CUSTOMER represents in the
DX.TRADE, the above mentioned fields should be related either to PRI
or SEC.
For treasury customers, the premium related field values at the sec-
ondary side will get defaulted from the primary side. For non-treasury
customers, the premium related fields at the secondary side must be
input.
Derivatives Accounting
This section describes the accounting process for Derivatives, which is part of the Treasury suite.
T24 Derivatives accounting is event-based. All significant events that may occur in the life of a contract are assigned an event code. Accounting
details are associated with these event codes, allowing the Derivatives account entry routines to make the appropriate postings to the appro-
priate accounts, categories or CRF types at the appropriate times.
l Taxes in Derivatives
l Contingent Asset/Liability
l Trade/Value Dated Accounting
l Commissions and Charges
l Initial Margin
l Closeouts
l Enhanced Unrealised P&L (Variation Margin) Postings
See also the following sections from the Derivatives Configuration guide:
l Revaluation P&L
l Contingent Postings and Product Categories
Taxes In Derivatives
As part of tax requirement, there are tax related fields in DX.ORDER, DX.TRADE and DX CLOSEOUT applications. The tax fields accept man-
ual input or usage of API (in case of DX CLOSEOUT ), core will raise appropriate accounting entries for the tax amount depending on the
nature of the trade.
The four multi-

valued fields
which appear in
the three above
mentioned appli-
cations are
TAX.CODE,
TAX.TYPE,
TAX.AMT.ACY
and
TAX.AMT.LCY.
The tax details

are also reg-
istered in the
DX.TRAN-
SACTION file for
reporting
purposes.
The field
TAX.AMT.TCY
is a no-input field
that shows the
equivalent
amount in trade
currency.
Where this
relates to cus-
tomer deals, four
sets of entries are
generated.
Customer
account is deb-
ited with the tax
amount and an
internal account
is credited, with
the help of wash
though entries.
For A D e a le r -book
As a part of set-up a DX.EVENT.TYPE record of type TT is required with a PL category code linked to it.
A
CATEG.ENTRY
is raised to debit
the PL category
defined in
DX.EVENT.TY-
PE (TT) for tax
payable and a
corresponding
entry is raised to
credit the inter-
nal account.
This process
also raises two
wash through
entries.
STMT.ENTRY
CATEG.ENTRY
The same set of fields provided in DX.ORDER application to capture tax at the time of order-execution. The DX.TRADE record generated
through order filling will carry those details.
It is also pos-
sible to compute
taxes at the time
of closeout with
the help of an
API to populate
tax details in
DX.CLOSEOUT
application.
This API can be

specified in
DX.P-
ARAMETER in
the field CLOSE-
OUT.API.
The tax entry or

entries as passed
back in the rel-
evant fields on
the DX.CLOS-
EOUT record
will then be
raisedas account-
ing entries as the
DX.CLOSEOUT
record is author-
ised.
Contingent Asset/Liability
Own Book portfolios only. On contract initiation (DX.EVENT.TYPE CI) a CRF posting is made representing an off-balance sheet asset/liability
active during the contract’s life.
Own Book portfolio buys contract – debit CRF type DXFUTBUY
Own Book portfolio sells contract – credit CRF type DXFUTSELL
On reversal or complete close-out/maturity of the trade the postings are backed out. For partial closeouts, a pro-rata amount based on the
ratio of lots closed to total lots on the trade is backed out.
Trade/Value Dated Accounting
Due to the nature of Derivatives trading, the trade/value date accounting setting only really affects postings of option premiums, com-
missions/fees or ‘settlement’ P&L when posting offsets are set on DX.CONTRACT.MASTER. These are the only occasions where forward-
dated ‘real’ accounting entries are made to customer or internal accounts.
The Derivatives module utilises T24 standard core accounting, so the flag VALUE.DATED.ACCTNG in ACCOUNT.PARAMETER controls the
way that the forward-dated account entries from the module are handled.
As an example: a customer of the bank buys an option versus a broker and the option in question has premium and fees posted at trade time.
When the PREM.POST.OFFSET on the DX.CONTRACT.MASTER for the instrument is set to ‘2’ (i.e. a two-day offset between premium date
and posting) T24would behave as follows:
Trade Dated:
DR Customer a/c Option premium Value date ‘today’
i.e. the premium hits the customer’s account immediately and is shown on his/her statement
Value Dated:
DR Customer a/c Option premium Value date ‘today’ + 2 working days
i.e. the premium is booked as a forward dated entry and will not appear on the customer’s statement until ‘today + 2 working days’
Note that the trade/value date flag does not affect whether premiums or commissions are posted at trade or closeout time for a contract – this
is a basic characteristic of each instrument.
Even in a trade-dated accounting environment if a Derivatives instrument is set to have premiums and commissions charged on settlement (or
close-out), the sums will not be posted until a trade on that instrument has been closed out
Commissions And Charges
Commissions and charges payable by customers or to brokers are simply posted to the customer account specified in the commission fields for
that customer on DX.TRADE.
For Own Book portfolios, com-

missions and charge postings are
handled differently.
The flag USE.FT.TXN.CODE on

DX.EVENT.TYPE is crucial,
since this decides whether the
P&L should be posted using the
category and transaction codes
set on the commission posting
event type, or whether the cat-
egory and transaction codes
assigned by the T24 standard
charge routine CAL-
CULATE.CHARGE should be
used. DX Event Type Record
It is also possible to introduce the concept of a treasury rate whereby the rate applied to the customer side of the transaction may vary to that
incurred by the bank. This is achieved by setting the treasury customer flag to “NO” and applying the differing rates to the primary and sec-
ondary sides of the transaction. Appropriate accounting entries are then passed by the application to reflect the resultant profit/loss due to the
bank.
As part of tax requirement, there are tax related fields in DX.ORDER, DX.TRADE and DX CLOSEOUT applications. The tax fields accept man-
ual input or usage of API (in case of DX CLOSEOUT ), core will raise appropriate accounting entries for the tax amount depending on the
nature of the trade.
Initial Margin
Initial margin is posted in a similar fashion to revaluation P&L – to the customer/broker account for external customers, and to an internal
account specified by the category code in DX.EVENT.TYPE for Own Book portfolios.
See also margins in the Derivatives Configuration User Guide.
Closeouts
Closeouts are posted for Own Book portfolios using the category and transaction codes specified in DX.EVENT.TYPE.
For customer or broker closeouts, a choice of account for posting must be confirmed at closeout time.
In a multi book environment, when the DX.RV.SERVICE and automatic COB Closeout is processed, the Customer’s SAM Company context is
loaded for the Customer transaction and the Lead Company context is loaded for the broker transaction. As a result, during COB the Closeout
record for the Customer side and the Broker side (B2B) will be generated in the Customer’s SAM Company. For Online processing, the Close-
out record will be generated in the Company where the Closeout is manually executed.
The Intercompany Accounting entries will be posted as described below:
Customer (SAM, Account) Broker (Account) Comments
Lead Company Branch Company Interco entries for Broker
Branch Company Lead Company No Interco entries
Branch Company Branch Company Interco entries for Broker
Enhanced Unrealised P&L (Variation Margin) Postings
Revaluation P&L postings may be completely suppressed by setting the new field SUPPRESS.VM.POST on DX.PARAMETER to ‘YES’. The
Derivatives revaluation will still calculate figures for reporting purposes but they will not be posted to the accounts.
Where P&L is calculated and is to be posted, the new field VM.POST.STYLE allows the bank to select how they wish the posting to be made
for the bank’s own book.
The selections behave as follows:
VM Posting style VM Posting behaviour
PL (default) P&L calculated in contract currency. Posted to P&L Category in DX.EVENT.TYPE ‘VM’
PLLCCY P&L calculated in contract currency, then converted to Local Currency
Posted to P&L Category in DX.EVENT.TYPE ‘VM’
PLRP P&L calculated in contract currency.
Sign reversed, posted to Premium Payment account (maintains ‘replacement value’)
PLLCCYRP P&L calculated in contract currency, then converted to Local Currency
Sign reversed, posted to Premium Payment account in Premium ccy (maintains ‘replacement value’)
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:
l Option premiums (if premium post time set to ‘TRADE’)

l Commissions and fees (if charge post time set to ‘TRADE’)
l Contingent entries for own-book portfolios (unless TRANSFER.TYPE is set to TAKEON-CONT).
l Contingent entries for own-book portfolios
l No update to LIMIT will be performed.
l 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.
Derivatives Delivery
This section describes the Delivery features of Derivatives, which is part of the Treasury suite.
Outward Delivery
The 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) by calling 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 proc-
essed, i.e. DX.TRADE is entered,
amended or reversed.
Delivery messages are also gen-

erated 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/ assign-
ments etc…
Any new event added to the mod-

ule will therefore be auto-
matically available as having a
possible link into the deliveries Derivatives Event Type Record
module.
Until the DX.EVENT.TYPE field

EB.ACTIVITY field is populated
with a delivery activity to per-
form, the system will not gen-
erate any delivery messages.
Once a selection of a
DX.EVENT.TYPE has been pop-
ulated within EB.ACTIVITY then
processing can take place for
those events.
EB.ACTIVITY Record
The 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 FOREXapplication. This information is used as part
of the derivatives originated Swift Messages.
Note that it allows the customization of which messages are sent and when they are sent locally. Any messages not currently provided can be
added locally by setting up an activity on a particular event (DX.EVENT.TYPE); whenever this event is raised a message will be passed to the
T24 delivery suite.
l EB.ACTIVITY
l DE.MESSAGE
l DE.MAPPING
l EB.ADVICES
l DE.FORMAT.PRINT
EB.ACTIVITY
For each event to send a Delivery message, an EB.ACTIVITY record must exist. Each record determines the various lifecycles that may exist.
For basic a basic set the following EB.ACTIVITY records should be created.
Activity ID Description DX Event
DX-4000 Trade Confirmation CI
DX-4010 Trade Amendment CA
DX-4020 Trade Reversal CR
DX-4040 Closeout confirmation CS
A description is all that is needed for each item.
Once these have been created they should be assigned to the relevant DX.EVENT.TYPE records in field EB.ACTIVITY.
Every time that the event is processed in the central DX transaction processing a message will be produced in the delivery module.
DE.MESSAGE
This application holds the contents of each basic message type. It lists the available fields, whether the fields can be multi-valued and states
whether the fields are mandatory or optional. Some basic example DE.MESSAGE records have been released as follows:
Message Record Details
4000 Trade Input
4010 Trade Amendment
4020 Trade Reversal
4040 Closeout Confirmation
DE.MAPPING
This application defines where the data for outward messages and message headers are located within the raw message passed to Delivery from
the banking applications.
All the fields from DX.TRANSACTION and fields common to both

customers in DX.TRADE are mapped in records 4000.DX.1 to DE.MAPPING records Details
4040.DX.1. These example records have been released as shown
here. 4000.DX.1 Trade Input
4010.DX.1 Trade Amendment
4020.DX.1 Trade Reversal
4040.DX.1 Closeout confirmation
Additionally to fully support all the mandatory SWIFT messages

required for Futures & Options processing it is possible to structure
and configure other messages by capturing the data record passed to
DE.MAPPING.
DE.MAPPING record showing the data record set to capture
DE.MESSAGE calling “FINAL.SETT.DATE”
DE.MESSAGE from DE.MAPPING record DX 305.DX.1
The data records that can be captured (as described in the illustration above as “EXTRA.FIELDS”) are all pre-formatted for use within a SWIFT
message and are as follows:
Field 1 - Final Settlement Date Field 21 – Intermediary Address.
Field 2 - Premium Date Field 22 - Confirmation Narrative
Field 3 - Buy Currency Field 23 - Payment Narrative
Field 4 - Buy Amount Field 24 - Record Advice Narrative
Field 5 - Sell Currency Field 25 - Bank To Bank Info
Field 6 - Sell Amount Field 26 - Delivery Currency
Field 7 - Related Reference Field 27 - Delivery Amount
Field 8 - Code Field 28 - Trade Amount
Field 9 - Option Style Field 29 - Common Reference
Field 10 - Earliest Exercise Date Field 30 - Swift Customer
Field 11 - Option Time Field 31 - Lots Transfer
Field 12 - Location Field 32 - Destination Customer
Field 13 - Premium Pay/Receive Field 33 - Destination Portfolio
Field 14 - Settlement Type Field 34 - Destination Customer or Portfolio
Field 15 - Beneficiary Customer No. Field 35 - Bank Name
Field 16 - Beneficiary Address Field 36 – Bank Address
Field 17 - Counterparty No Field 37 – Bank Sort Code
Field 18 - Counterparty Address Field 38 - Advice
Field 19 - Counterparty Account Field 39 - Fee
Field 20 – Intermediary No. Field 40 - Customer Counterparty
EB.ADVICES
The EB.ADVICES application holds the MESSAGE.TYPE, MESSAGE.CLASS and MAPPING.KEY. By defining the records on this file, the
user may control the type and format of the eventual output. Users are also able to use their own mapping records instead of the standard rec-
ords supplied with T24.
DE.FORMAT.PRINT
This application uses information from DE.MESSAGE and DE.MAPPING to format messages that are to be sent.
DE.FORMAT.PRINT Record
Example DE.FORMAT.PRINT records are available in the system.
Derivatives Limits
The inclusion of Derivatives within the T24 Limits module adds an extra element of risk control for clients trading in derivatives instruments.
The application of Limits within the Derivatives operation applies to all products handled by the module. The LIMIT module provides a control
mechanism for the DX.TRADEmodule and when called at the time of input will check the availability of an authorized credit line for the cus-
tomers involved with the trade. The LIMIT system is designed to monitor, in real-time, the availability and utilization of customer limits. Back
end reports are available to allow the monitoring of limits for commodities, countries, country group and currencies. The word limit describes a
facility or credit Line available to a customer or group of customers, while the term LIMIT.REFERENCE describes a type of LIMIT, e.g. Futures
and Options Limit.
As well as allowing for different products, Limits also allows fine-tuning of products into sub-products. Therefore limits can be set up for dif-
ferent classes of contracts, e.g. Bonds, Shares, Currencies or Commodities.
The Limit Reference conditions for DX.TRADE are defined using LIMIT.PARAMETER, for example Currency Futures can be set a different
limit reference to Currency Options. 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 a limit has been exceeded.
Choosing an option from

LIM.AMT.VAL.CONT on DX.P-
ARAMETER sets the amount
used to update limit utilisation.
l Contingent
Calculates a value based

on the amount specified
in CONTINGENT.VALUE
Selecting calculation type for updating Limits
on DX.CO-
NTRACT.MASTER
Number of lots x con-

tingent value
l Value

on the following prin-
ciples:
Future: Number
of lots x internal price.
Option Buyer: Number

Option Seller: Number

of lots x internal strike
price.
DX.TRADE links a limit reference
to each customer on both ‘pri-
mary’ and ‘secondary’ sides of the
trade - PRI.LIMIT.REF and
SEC.LIMIT.REF respectively.
Before any derivatives trades can

be entered, all the proposed types
of limit (global, product and sub-
product) must first be defined in
LIMIT.REFERENCE.
The two screens on the right

show a basic limit structure for
Bond Futures linked under a more
general product definition of
Futures.
Sub-product LIMIT.REFERENCE
For fuller analysis of limit struc-
tures, please the Limits user
guide.
Product LIMIT.REFERENCE
The choice of which limit ref-

erence is selected for a customer
is controlled from the criteria
established in LIMIT.P-
ARAMETER.
This screenshot shows how dif-

ferent limits can be set for Cur-
rency Futures, Bond Futures and
Currency Futures by testing values
from TRADE.TYPE and CON-
TRACT.CLASS fields in
DX.TRADE.
LIMIT.PARAMETER showing defaulting limits for DX.TRADE
Using one set of tests for both primary and secondary side customers can lead to problems where differences between sides need to be taken
into account. This would typically apply when applying tests on any fields identified with PRI. or SEC. from DX.TRADE.
The solution here is to create

another set of criteria in
LIMIT.PARAMETER with
APPLICATION defined as
“DX.TRADE-SEC”.
The application suffix “-SEC” will

relate tests solely to customers
on the secondary side of the
trade.
In this example, the field

PRI.HEDGE.TRADE equal to
“HEDGE” will default the limit
reference to 4554 for a customer
on the primary side of
DX.TRADE.
The field SEC.HEDGE.TRADE

not equal to blank will default
limit reference to 4555 for a cus-
tomer on the secondary side of
DX.TRADE.
Once the LIMIT has been estab-

lished for a particular customer,
the system is then able to use
this information to ensure that LIMIT.PARAMETER showing defaulting limits for secondary side customers
the limit is not exceeded.
If the transaction will cause

excess, the user must decide
whether the excess is to be
allowed.
Likewise if a credit line has not

already been set up, an override
is raised to allow a system gen-
erated limit to be created.
l Example Limit Setup
Example Limit Setup
The following is a basic example to show updating of a LIMIT input for customer 50027, Hewlett Packard, linked to LIMIT.REFERENCE
4552 for Bond Futures up to USD 3 Million:
Limit ID Description Limit Utilisation Remaining
050027.0004552.01 HP bond futures limit 3M
Trade 1 input: 50027 buys 5 lots CBOT US T-Bond @ 104.16.
Internal price = value of one lot = USD 325,500.00
Therefore amount to update limits = internal price x No. Of lots = USD 1,627,500.00.
050027.0004552.01 HP bond futures limit 3M 1,627,500 1,372,500
Trade 1 is amended to 4 lots. When the original version of the trade is removed from the position, the first limit updates are backed out and
replaced with the revised amount.
New limit status = internal price x No. Of lots = USD 1,302,500.00.
Trade 2 input: 50027 sells 5 lots CBOT US T-Bond @ 105.20.
Internal price = value of one lot = USD 328,750.00.
Amount to update limits = internal price x No. Of lots = USD 1,643,750.00.
N.B – sell trades have the same impact on utilisation as buy trades, i.e. sells are not ‘cancelled’ out against buys.
050027.0004552.01 HP bond futures limit 3M 2,945,750 54,250
Trade 1 is matured: limit utilisation is restored by the relevant amount for that trade,
i.e. USD 1,302,500.00.
Trade 2 is partially closed out against an opposing buy trade, where 2 out of the original 5 lots are closed.
Limit utilisation is restored on a “pro-rata” basis of actual lots closed
i.e. 2 / 5 * 1643750.00 = USD 657,500.00.
050027.0004552.01 HP bond futures limit 3M 985,750 2,014,250
If more than one LIMITof the same type exists the Derivatives module will default to the first LIMIT (i.e. the LIMIT with serial number 01),
unless the user specifically indicates otherwise by input of a LIMIT.REFERENCEnumber in the field LIMIT.REFERENCE.NO provided for this
purpose on the Trade record.
Occasionally the required LIMIT does not exist or is already fully utilized. If it does not exist the user must make a decision as to whether or
not to generate a default LIMIT.
At the maturity of a Derivatives transaction the module will provide notification of the event to the LIMIT System, which will then reset the
utilization figures.
Derivatives Limits
The inclusion of Derivatives within the T24 Limits module adds an extra element of risk control for clients trading in derivatives instruments.
The application of Limits within the Derivatives operation applies to all products handled by the module. The LIMIT module provides a control
mechanism for the DX.TRADEmodule and when called at the time of input will check the availability of an authorized credit line for the cus-
tomers involved with the trade. The LIMIT system is designed to monitor, in real-time, the availability and utilization of customer limits. Back
end reports are available to allow the monitoring of limits for commodities, countries, country group and currencies. The word limit describes a
facility or credit Line available to a customer or group of customers, while the term LIMIT.REFERENCE describes a type of LIMIT, e.g. Futures
and Options Limit.
As well as allowing for different products, Limits also allows fine-tuning of products into sub-products. Therefore limits can be set up for dif-
ferent classes of contracts, e.g. Bonds, Shares, Currencies or Commodities.
The Limit Reference conditions for DX.TRADE are defined using LIMIT.PARAMETER, for example Currency Futures can be set a different
limit reference to Currency Options. 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 a limit has been exceeded.
Choosing an option from

LIM.AMT.VAL.CONT on DX.P-
ARAMETER sets the amount
used to update limit utilisation.
l Contingent

on the amount specified
in CONTINGENT.VALUE
Selecting calculation type for updating Limits
on DX.CO-
NTRACT.MASTER
Number of lots x con-

tingent value
l Value

on the following prin-
ciples:
Future: Number
Option Buyer: Number

Option Seller: Number

of lots x internal strike
price.
DX.TRADE links a limit reference
to each customer on both ‘pri-
mary’ and ‘secondary’ sides of the
trade - PRI.LIMIT.REF and
SEC.LIMIT.REF respectively.
Before any derivatives trades can

be entered, all the proposed types
of limit (global, product and sub-
product) must first be defined in
LIMIT.REFERENCE.
The two screens on the right

show a basic limit structure for
Bond Futures linked under a more
general product definition of
Futures.
Sub-product LIMIT.REFERENCE
For fuller analysis of limit struc-
tures, please the Limits user
guide.
Product LIMIT.REFERENCE
The choice of which limit ref-

erence is selected for a customer
is controlled from the criteria
established in LIMIT.P-
ARAMETER.
This screenshot shows how dif-

ferent limits can be set for Cur-
rency Futures, Bond Futures and
Currency Futures by testing values
from TRADE.TYPE and CON-
TRACT.CLASS fields in
DX.TRADE.
LIMIT.PARAMETER showing defaulting limits for DX.TRADE
Using one set of tests for both primary and secondary side customers can lead to problems where differences between sides need to be taken
into account. This would typically apply when applying tests on any fields identified with PRI. or SEC. from DX.TRADE.
The solution here is to create

another set of criteria in
LIMIT.PARAMETER with
APPLICATION defined as
“DX.TRADE-SEC”.
The application suffix “-SEC” will

relate tests solely to customers
on the secondary side of the
trade.
In this example, the field

PRI.HEDGE.TRADE equal to
“HEDGE” will default the limit
reference to 4554 for a customer
on the primary side of
DX.TRADE.
The field SEC.HEDGE.TRADE

not equal to blank will default
limit reference to 4555 for a cus-
tomer on the secondary side of
DX.TRADE.
Once the LIMIT has been estab-

lished for a particular customer,
the system is then able to use
this information to ensure that LIMIT.PARAMETER showing defaulting limits for secondary side customers
the limit is not exceeded.
If the transaction will cause

excess, the user must decide
whether the excess is to be
allowed.
Likewise if a credit line has not

already been set up, an override
is raised to allow a system gen-
erated limit to be created.
l Example Limit Setup
Limits Overview
There is no specific information relating to Limits for this product
Derivatives Non Stop Processing
This section describes Non Stop Processing for Derivatives, part of the Treasury suite.
This functionality allows T24 users to input derivatives transactions during standard Close of Business Processing.
While running a Close of Business the user can input DX.ORDER and DX.TRADEdeals. Users will NOT be able to input these transactions
with back-value dated values neither will they be permitted to input/change prices (DX.MARKET.PRICE), closeout a position (DX.CLOS-
EOUT) or run corporate action (DX.DIARY) events.
Users are not able to reverse or amend pre-existing transactions during the close of business process. The user can only input new deals, which
can be reversed or amended. DX.REP.POSITION and DX.TRANSACTION will be updated accordingly.
New deals input during the critical Close of Business window will have TRADE.DATE of the next working day. These transactions will be val-
idated as usual but will be held in a FWD queue on the DX.REP.POSITION. Every position is now "Dated" (POS.DATE) which is the date on
which that position is valid. When a transaction is on the FWD queue the transaction is not included into the transaction until the forward
date (FWD.DATE) is equal to the position date. Once the critical part of the Derivatives Close of Business is complete a Synchronise job runs,
the position date is updated to the current system date and the transaction in the forward queue where the forward date and position date
match are included in the position.
New deals input during the Close of Business will be available for CLOSEOUT events immediately after completion of the Close of Business
process.
DEALER.BOOK transactions input during the Close of Business will update DX.REP.POSITION, DX.TRANSACTION and accounting entries
in CONSOL.ENT.TODAY, whereas existing transactions for the DEALER.BOOK will be moved to RE.CONSOL.SPEC.ENTRY after Close of
Business.
Derivatives Services
This section describes background services and Close of Business for Derivatives, part of the Treasury suite.
The Derivatives product has been designed so that the minimum amount of processing possible has to be carried out in the main T24 batch
run. Most business-related end-of-day functionality is contained in DX.COB.WORKFILEwhich may be run online as and when exchange busi-
ness days close.
l DX.COB.WORKFILE
l End of Exchange Day Processing
l Revaluation
DX.COB.WORKFILE
This is the controlling mechanism for the Close of Business routines. This application provides 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 is multi-threaded to the level of Customer/Exchange valuation.
Most of the processing work is passed to an online revaluation engine, designed to process both online and during the Close of Business.
This means that both the Close of Business and Online Valuations are Multi-Threaded by using services.
For example, a System with two exchanges and three customers would result in six discrete threads being processed, one for each Cus-
tomer/Exchange combination.
The possibility of one customer’s valuation failing and requiring a re-run of an entire exchange is removed, as only part of the customers posi-
tion would have to be re-visited online.
This increase in the number of threads is most noticeable on systems with large numbers of customers, thus has the effect of shortening the
time taken for any close of business processing.
End Of Exchange Day Processing
End of exchange forms part of the core functionality within the module, when a derivatives exchange closes, there is no reason why the deriv-
atives module cannot run its close of business routines that relate directly to that exchange. Therefore the derivatives module includes an End
of Exchange utility. This application provides the definition and trigger for processes directly relating to the closing of an exchange
The End of Exchange application is part of the revaluation suite and therefore uses the “black-box” design detailed in The Revaluation Black
Boxes section. This will allow flexible local and client-driven development of new routines without core development involvement.
The end of exchange application provides tags for processes to be run, before (pre) and after (post) the End of Exchange revaluation. These rou-
tines will initially be defaulted from the DX.PARAMETER SYSTEM record, but new/ad-hoc routines can be added prior to any end of exchange
run.
Revaluation
DX revaluation process whether On-line or COB is done at the Customer/Exchange level.
For each of these combinations, there exists a record on the DX.COB.WORKFILE file and any changes to this record can be traced in the
DX.COB.WORKFILE.HISTORY file. If a combination no longer holds a position, it stays on the file until the Countdown (set as per the DX.P-
ARAMETER field HLD.REVAL.DAYS) on the work file is negative, then it goes to history. Note this Countdown field is reduced by a value of 1
if it still has no position, during COB processing.
An On-line revaluation for one or more such combinations has to be requested while the COB revaluation is done automatically during the
close old business processing. In order for the revaluation to process, the tSA service manager must be running.
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.
Similarly, if a user chooses to enter a trade, close a position, or run a corporate action whilst the Close of Business is
running the system will report that Service is not running, and/or the following
”An ‘&’ valuation is being run by ‘&’ for customer ‘&’ on exchange ‘&’, please try again later”.
Requesting An On-line Revaluation

A Customer/Exchange revaluation can be requested by changing the Status field of its corresponding DX.COB.WORKFILE record to either
“Ready” or “Re-Run”.
The record needs to be Input first, and then “Verify” to trigger the request for the tSA service to launch the revaluation process, which will then
update the status to “Completed” when successful.
Any errors or messages generated during the processing are updated on the Dialog section of the work-file record e.g. “No Market Price Found
for 100324*/15/EUR/200309/CALL/130.0*".
After rectifying error, the revaluation can be re-run by requesting again.
Customer 110020 Revaluation on Exchange 4
COB Revaluation
This process does not require any request. Note if a new price change has occurred after an on-line revaluation, any Customer/Exchange
affected needs to be manually requested again.
The COB will check the status of the DX.COB.WORKFILE see diagram below, to decide which combination to revalue. In day-to-day proc-
essing the status should only ever be “Completed” or “Running". Any Combination of Customer/Exchange with the following status will be
revalued in the close of business – New, Ready, Re-Run, and Completed with next run date less or equal today.
Again the Dialog section of the work-file will contain any messages, errors or warnings generated during the process.
End Of Exchange Revaluation

As part of the end of exchange processing a revaluation takes place across all positions held on a particular exchange. The details of the reval-
uation are kept in the same files as the on-line ad-hoc revaluation, but are identified by their record id.
End of Exchange Revaluation Details
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 DX.PARAMETER EOE.PRICE.SET price set that revaluation accounting
postings take place.
Derivatives API
This section describes the extension points and API for Derivatives, which is part of the Treasury suite.
l Local Routine Insertion Points and API

l Revaluation Black Boxes
Local Routine Insertion Points And API
Insertion Points
Note: Wherever the RETURN.CODE argument is specified for these routines (apart from where specifically stated), it is used to return
information for debugging purposes only.
Errors should be set within routine via standard methodology
l Accounting Entries
l Accounting Entries for Tax on Closeout
l Alternate Index Validation
l Automatic Closeout matching
l Automatic Trade Assignment
l Calculation of Exposure
l Calculation of Initial Margin
l Calculation of Net Cost
l Calculation of Theoretical Prices
l Calculation of Variation Margin
l Exotic Option Closeout Processing
l Exotic Option User-Field Validation
l Order Lot Assignment
l Price conversion to internal format
l Valuation of Futures Position
Application Program Interfaces (API)
l DX.AI.CUSIP
l DX.BB.CREDIT.EXPOSURE
l DX.CALC.NET.COST
l DX.CO.AM.FIFO
l DX.CO.AM.FIFO.DAY
l DX.CO.AM.LIFO
l DX.CO.AM.LIFO.DAY
l DX.CO.AS.FCFS
l DX.CO.PGM.NOACTION
l DX.FUT.EST.METHOD.THREE
l DX.ORD.ASSIGN.FIFO
l DX.ORD.ASSIGN.PRO.RATA
l DX.PR.BINOMIAL
l DX.PR.BLACK.SCHOLES
l DX.PR.BUILD.BS
l DX.PR.BUILD.GK
l DX.PR.GARMAN.KOHLHAGEN
l DX.RV.CHREG.VM
l DX.RV.ENHANCED.IM
l DX.RV.EURONEXT
l DX.RV.FXOPT.VM
l DX.RV.NO.IM
l DX.RV.NO.VM
l DX.RV.OCC.TIMS
l DX.RV.STANDARD.IM
l DX.RV.STANDARD.VM
l DX.STAND.AS.RANDOM
l DX.XO.CREATE.EURO
l DX.XO.CREATE.FX
l DX.XO.CREATE.FX.KNOCKOUT
l DX.XO.CREATE.FX.REBATE
l DX.XO.CREATE.SEC
l DX.XO.CREATE.SEC.KNOCKOUT
l DX.XO.FWDCASHPAYOUT
l DX.XO.INSTANT.CASHPAYOUT
l DX.XO.KNOCKIN
l DX.XO.KNOCKOUT
Accounting Entries
Description
Creates any additional accounting entries required beyond those automatically generated by the system. Local routine attached at this point
should insert accounting entries required into the existing list, based on the DX.EVENT.TYPE passed in. Used whenever accounting entries
are posted by applications or COB processes in DX.
Insertion Point
Application Record Key Field
DX.PARAMETER SYSTEM ACCOUNTING.API
Arguments
Argument List Direction Description
PGM In T24 product code – always DX
TYPE In Type of entry - CHG, DEL, VAL, VALAUT, REV, SAO,
SNP, SSS, RSAO,
SNP, ADD, AUT or ADD.AUT
ENTRIES In / Out Dynamic array of accounting entries*
FORWARD In Dynamic array of Forward entries*
EVENT.TYPE In DX.EVENT.TYPE being processed.
* Entries passed in as per layout of STMT.ENTRY.
Accounting Entries For Tax On Closeout
Description
Creates any additional accounting entries required beyond those automatically generated by the system for raising Tax entries on authorisation
of a DX.CLOSEOUTrecord. A local routine attached at this point should set the fields TAX.CODE, TAX.TYPE, TAX.ACY and TAX.TCY fields
on the DX.CLOSEOUTrecord. Any changes to other fields on the DX.CLOSEOUTrecord by the API will be ignored by the core processing.
Insertion Point
DX.PARAMETER SYSTEM CLOSEOUT.API
Arguments
R.DX.CLOSEOUT In/Out Current DX.CLOSEOUT record being processed (as dynamic array).
Alternate Index Validation
Description
Performs validation or defaulting of alternate indices, e.g. CUSIP number. If the alternate index is present, it will set the rest of the option
series. If the option series is present, the alternate index will be defaulted or validated against it. Used in DX.CONTRACT.MASTER, DX.MA-
RKET.PRICE, DX.TRADE and DX.ORDER.
Insertion Point
DX.PARAMETER SYSTEM ALT.IND.VAL
Arguments
ALT.IND.ID In / Out Alternate index id to be validated (e.g. CUSIP.NO)
CONTRACT.CODE In / Out Contract Code – DX.CONTRACT.MASTER id
MATURITY.DATE In / Out Maturity Date as yyyymm{dd}
STRIKE.PRICE In / Out External Strike Price (options only)
CALL.PUT In / Out CALL or PUT (options only)
OTHER.DATA In / Out field<2> = Alternate Index name from DX.PARAMETER, ALT.IND.NAME
RETURN.CODE Out Returned error codes/warnings for debugging purposes
Routine also has access to the insert I_DX.COMMON.
Automatic Closeout Matching
Description
Set rules for matching deals against a position to be exercised, i.e. First In First Out, Last In First Out etc.
Multiple deals against the same positions are matched short against long and closed out.
The routine takes a list of transaction ids to be matched, along with the DX.TRANSACTION records held within a dimensioned array. The rou-
tine then returns a list of matched transaction ids along with the number of matched lots per DX.TRANSACTION record.
Used in closeout processing.
Insertion Point
DX.CUSTOMER Customer number AU.SETT.TYPE
DX.CLOSEOUT.METHOD (from AU.SETT.TYPE field) ROUTINE.NAME
Arguments
IN.LIST In List of DX.TRANSACTION @IDs for matching
IN.RECORDS In Dimensioned array of the DX.TRANSACTION records
OUT.LIST Out List of matched DX.TRANSACTION @IDs
NO.LOTS Out List of matched lots for each DX.TRANSACTION record
Automatic Trade Assignment
Description
Set rules for allocation of lots to transactions from multiple deals against that position.
The routine takes an array containing multi-valued list of transaction ids to be matched against the number of unassigned lots for each,
together with the total number of lots to be assigned. The routine returns an array containing a list of a subset of these transaction ids which
have been matched against the number of lots assigned for each.
Insertion Point
DX.CONTRACT.MASTER Contract code AUTO.ASSIGNMENT
Arguments
UNASSIGNED.LIST In field<1> Unassigned Transactions; field<2> Unassigned lots
TOT.ASSIGN.LOTS In Total number of lots to be assigned
ASSIGNED.LIST Out field<1> Assigned Transactions; field<2> Assigned lots
ASSIGNED.ERR Out Returned errors / warnings
Calculation Of Exposure
Description
Routine performs calculation of Credit Exposure for Derivatives. The routine takes the record for the transaction being evaluated along with ele-
ments of the option series, and returns delta, time period, REVAL.ADDON.PERCEN id, replacement cost, regulatory add-on percentage and cal-
culated regulatory credit exposure. The T24 infrastructure then populates this data into the portfolio valuation.
Insertion Point
DX.PARAMETER SYSTEM CR.EXP.CALC.API
Arguments
APPL In T24 product code (always DX)
R.DX.TRANSACTION In DX.TRANSACTION record
LOTS In Total number of lots
TRADE.TYPE In Future or Option
CALL.PUT In Call or Put (options only)
BUY.SELL In Buy or Sell
INST.STK.PRICE In Strike price in internal T24 format
DELTA Out Delta value from DX.MARKET.PRICE record
TIME.PERIOD Out Remaining period
ADDON.ID Out REVAL.ADDON.PERCEN id
REPLACEMENT.COST Out Calculated replacement cost
REG.PERCENT Out Regulatory add-on percentage
REG.CR.EXPOSURE Out Calculated regulatory credit exposure
INT.PERCENT Out Add-on percentage in internal T24 format
INT.CR.EXPOSURE Out Calculated credit exposure in internal T24 format
RETURN.CODE Out Returned errors – can set here or via standard methodology.
Calculation Of Initial Margin
Description
Routine to calculate the Initial Margin to post against the exchange, by taking for each position reported, and for each position, each transction
within that position. For each of these transactions, the relevant detail file (DX.REVAL.DET . calc_ methodwhere calc_ methodis the
DX.INT.PRICE.CALC id) will need to be updated with respect to CONTRACT, CONTRACT.factor, RATE.KEY, RATE.TYPE, FULL.RATE,
SPREAD.RATE, SPOT.RATE, STRADDLE.RATE, MINIMUM, FULL.LOTS, SPREAD.LOTS, STRADDLE.LOTS, SPOT.LOTS, SPREAD.PAIR,
SPREAD.MNTHS, EXCH.FACTOR, INITIAL.MARGIN, CONTRACT.IM, MAINT.MARGIN and MAINT.FACTOR. The outgoing array
DX$R.RVC.PROCESS will need to be updated with respect to MR.CURRENCY, MR.IM.FACTOR, MR.INIT.MAR, MR.MAINT.MAR,
MR.COLL.ALLOC, MR.COMB.CDY, MR.COMB.CDY.CONTRACTS, MR.CONTRACT, MR.CONTRACT.FACTOR, MR.CONTRACT.IM and
MR.CONTRACT.CCY (for each subvalue).
Insertion Point
DX.CONTRACT.MASTER Contract code INIT.MARGIN.CALC
DX.INT.PRICE.CALC (from INIT.MARGIN.CALC field) PROGRAM.NAME
Arguments
n/a n/a Routine must include common block I_DX.REVAL.COMMON
This insert also defines field equates for the arrays mentioned below.
[DX$R.RVC.SETUP] [in] Parameters passed in via common block
[DX$R.RVC.PROCESS] [in / out] Data to process
Routine also has access to the insert I_DX.COMMON.
Calculation Of Net Cost
Description
Calculation of the net cost of a future or option trade after deduction of commissions, charges and tax.
Insertion Point
DX.PARAMETER SYSTEM COST.CALC.API
Arguments
CONTRACT.CODE In Contract code
MATURITY In Maturity Date as yyyymm{dd}
CALL.PUT In CALL or PUT (options only)
STRIKE In External Strike Price (options only)
BUY.SELL In Buy or Sell
CCY.MARKET In Currency Market (defaults to 1 if not set)
NET.COST.CCY In Currency in which net cost is to be expressed (defaults to local currency if not set)
LOTS In Quantity (defaulted to zero)
PRICE In Price expressed as input into T24
INT.PRICE In Price expressed as internal T24 format
CUST.PORT.ID In Customer number or Portfolio number if appropriate
CUSTOMER.TYPE In CUSTOMER, COUNTERPARTY, BROKER, EXCHANGE or DEALER
COMM.CCY In Array of currency codes against commissions/charges
COMM.AMT In Array of commissions/charges – expressed in COMM.CCY
TAX.AMT In Tax payable
NET.COST Out Net cost expressed in local currency or NET.COST.CCY
RESERVED01 n/a Reserved for future use
Calculation Of Theoretical Prices
Description
Calculates theoretical prices based on pricing models such as Garman Kohlhagen or Black & Scholes.
The pre-load routine(s) will need to populate the C$DXPR.PRICE.RECORD array with respect to SEC.INT.RATE, INT.RATE, INTER-
EST.BASIS, VOLATILITY, UND.PRICE and UND.INT.PRICE.
The calculation routine will then need to populate the C$DXPR.PRICE.RECORD array with PRICE, DELTA, GAMMA, VEGA and RHO.
Insertion Point (Pre-load routine)
DX.CONTRACT.MASTER Contract code PRICE.SOURCE
DX.PRICE.SOURCE (from PRICE.SOURCE field) BUILD.PGM
Insertion Point (calculation routine)
DX.CONTRACT.MASTER Contract code PRICE.SOURCE
DX.PRICE.SOURCE (from PRICE.SOURCE field) PROGRAM
Arguments (Pre-load routine and calculation routine)
n/a n/a Routine must include common block I_DX.PRICE.COMMON
[C$DXPR.CONTRACT.CODE] [in] Contract code passed in via common block
[C$DXPR.MATURITY.DATE] [in] Maturity Date as yyyymm{dd}
[C$DXPR.STRIKE.PRICE] [in] Strike price (options only)
[C$DXPR.CALL.PUT] [in] CALL or PUT (options only)
[C$DXPR.R.DX.PRICE] [in] Current DX.MARKET.PRICE record if it exists
[C$DXPR.PRICE.RECORD] [in/out] Price record built for these routines – same format as DX.MARKET.PRICE but
contains additional data.
[C$DXPR.PRICE.SET] [in] Current DX.PRICE.SET id.
[C$DXPR.R.DX.PRICE.SOURCE] [in] Current DX.PRICE.SOURCE record
[C$DXPR.CONS.DATA.NAME] [in] List of variable names for user variables extracted from current
DX.PRICE.SOURCE record.
[C$DXPR.CONS.DATA.ITEM] [in] List of variable data for user variables extracted from current DX.PRICE.SOURCE
record.
Routine also has access to the insert I_dx.price.
Calculation Of Variation Margin
Description
Routine will need to calculate variation margin by taking each position reported, and for each position, each transaction within that position.
For each of these transactions, the relevant detail file (DX.REVAL.DET.calc_ method where calc_method is the DX.INT.PRICE.CALC id) will
need to be updated with respect to CONTRACT, CONTRACT.VM, CONTRACT.UNOPT, TRANSACTION, REVAL.TRANS, TRANS.VM,
TRANS.UNOPT, MKT.PRICE, TRD.PRICE and NO.LOTS. The outgoing array DX$R.RVC.PROCESS will need to be updated with respect to
MR.VAR.MAR, MR.UNOPT.PL, MR.UNOPT.PL.LONG, UNOPT.PL.SHORT and REVAL.TXN (for each subvalue).
Insertion Point
DX.CONTRACT.MASTER Contract code VAR.MARGIN.CALC
DX.INT.PRICE.CALC (from VAR.MARGIN.CALC field) PROGRAM.NAME
Arguments
n/a n/a Routine must include common block I_DX.REVAL.COMMON
This insert also defines field equates for the arrays mentioned below.
[DX$R.RVC.SETUP] [in] Parameters passed in via common block
[DX$R.RVC.PROCESS] [in / out] Data to process
Exotic Option Closeout Processing
Description
Routine performs processing of all events that occur on exercise of exotic option, performed instead of standard processing for vanilla options.
The routine is called in two modes:
• CONTROL.VAR has flag set to check down-date of lots. Routine should return DOWNDATE flag set to true if the number of lots are to
be reduced as part of the processing (i.e. if a closeout has truly taken place or not).
• CONTROL.VAR does not have down-date of lots flag set and does not have flag to indicate that this event has already been processed.
Depending on the EXOTIC.EVENT flag on the transaction passed in, any underlying instrument(s) are created by the routine, adding the exotic
option record key to the field LINK.REFERENCE.
Insertion Point
DX.TRADE / DX.ORDER Trade or Order id EXOTIC.TYPE
DX.OPTION.TYPE (from EXOTIC.TYPE field) CO.PGM
Arguments
PRI.TXN.ID In List of primary DX.TRANSACTION ids
SEC.TXN.ID In Secondary DX.TRANSACTION id
R.PRI.TXN In Primary transaction format record
R.SEC.TXN In Secondary transaction format record
R.TRADE Out DX.TRADE record generated
CONTROL.VAR In Check downdate of lots if field<1> = ‘D’ ; post accounting if field<2> = ‘A’
TRADE.ID Out ID(s) of record generated
DOWN.DATE Out Set to true (1) or false (0)
RESERVED01 Out Reserved for future use
RETURN.CODE Out Returned errors – can set here or via standard methodology.
Routine also has access to the inserts I_DX.COMMON and I_DX.co.COMMON.
Exotic Option User-Field Validation
Description
Validation of user fields added to DX.TRADE and DX.ORDER applications for exotic options. This insertion point is used to specify standard
T24 IN2 validation routines only.
Insertion Point
DX.TRADE / DX.ORDER Trade or order id USR.FLD.NAME
DX.USR.FLD.OPT (from USR.FLD.NAME field) USR.FLD.IN2
Order Lot Assignment
Description
Rules for assignment of lots to multiple customers on partial fill of a DX.ORDER record, e.g. first come first served, pro-rata assignment etc.
Routine takes in a list of candidates in the format customer . account_number together with a corresponding list of open lots against each
within the current DX.ORDER record, and the total number of lots being filled. The routine should then determine which candidates to fill and
decrement the open lots for each, at the same time reducing the total number of lots to fill by the same amount
Insertion Point
DX.PARAMETER SYSTEM ORD.ASSIGN.PGM
Arguments
CANDIDATE.LIST In / Out List of candidates for assignment
CANDIDATE.LOTS In / Out Number of lots per candidate
ASSIGN.LOTS In Number of lots to assign
Price Conversion To Internal Format
Description
Conversion of price (as input) to internal format used by T24. Overrides normal processing of price calculation
Insertion Point
DX.CONTRACT.MASTER Contract code int.price.calc
dx.int.price.calc (from INT.PRICE.CALC field) CALC.SUBROUTINE
Arguments
EXTERNAL.PRICE In Price as input to T24
EXTERNAL.STRIKE In Strike price as input to T24
R.DX.CONTRACT.MASTER In DX.CONTRACT.MASTER record as dimensioned array
R.DX.INT.PRICE.CALC In DX.INT.PRICE.CALC record as dimensioned array
PRICE.TYPE In Type of price input – F (futures price), C (Call Option Premium), P (Put Option Pre-
mium), S (Option Strike Price) PS (Put and Strike together) or CS (Call and Strike
together)
TICK.SIZE In Contract Tick Size
TICK.VALUE In Contract Tick Value
INT.PRICE Out Price in internal format for T24
INTERNAL.STRIKE Out Strike Price in internal format for T24
Valuation Of Futures Position
Description
If specified, this API is used when performing a valuation on a Futures position in T24 that will be reported in SC.POS.ASSET and associated
tables. If no API is specified, the standard calculation will be used for calculating the estimated value of the future.
Please note that this API will not be triggered during valuation of options positions.
ESTIMATION.VAL,MARKET.PRICE,INT.COST.PRICE, no Lots, R.DX.CONTRACT.MASTER
Insertion Point
DX.PARAMETER SYSTEM FUT.EST.API
Arguments
ESTIMATION.VAL Out Estimated value of this position in trade currency and T24 internal format as calculated
by the API
MARKET.PRICE In Market price of this position in trade currency and T24 internal format
INT.COST.PRICE In Cost of this position in trade currency and T24 internal format
NO.LOTS In Number of lots (net) held against this position
R.DX.CONTRACT.MASTER In DX.CONTRACT.MASTER record for the position being valued.
DX.AI.CUSIP
CUSIP No. Alternate Index
Description Defaulting and validation of CUSIP numbers held as alternate index for deal.
Used In Contract definition; Trade, Order and Price Entry.
Insertion Point Alternate Index Validation
DX.BB.CREDIT.EXPOSURE
Credit Exposure for Derivatives.
Description This routine will return the calculated Replacement.Cost, and Credit.Exposure values, based on the Add-On rates returned
from the core routine GET.REVAL.ADDON. These returned values has to be populated in SC.POS.ASSET file by the calling
program.
Used In Portfolio valuation
Insertion Calculation of Exposure

Point
DX.CALC.NET.COST
Calc Net Cost of the Trade/Order
Description Subroutine attached to DX.PARAMETER to calculate the COST of Order/Trade from which this routine will be invoked.
Used In
Insertion Point Calculation of Net Cost
DX.CO.AM.FIFO
First In First Out Processing
Description Auto matching of exercise closeouts – matches selected transactions against least recent opposite positions first.
Used In Closeout processing
Insertion Point Automatic Closeout Matching
DX.CO.AM.FIFO.DAY
Day Trade - First In First Out
Description Auto matching of exercise closeouts – matches selected transactions against today’s opposite positions first and then least
recent opposite positions.
Insertion Automatic Closeout Matching

Point
DX.CO.AM.LIFO
Last In First Out Processing
Description Auto matching of exercise closeouts – matches selected transactions against most recent opposite positions first.
Insertion Point Automatic Closeout Matching
DX.CO.AM.LIFO.DAY
Day Trade – Last In First Out
Description Auto matching of exercise closeouts – matches selected transactions against today’s opposite positions first and then most
recent opposite positions.
Insertion Automatic Closeout Matching

Point
DX.CO.AS.FCFS
First Come First Served
Description This black box takes transaction as passed and assigns the maximum number of lots possible to the transactions on a first
come first served basis.
Insertion Automatic Trade Assignment

Point
DX.CO.PGM.NOACTION
No action on option closeout
Description ‘Dummy’ routine to be called on option closeout/exercise, suppressing the generation of any underlying asset.
Used In Closeout Processing where EXOTIC.TYPE is set on DX.TRADE
Insertion Point Exotic Option Closeout Processing
DX.FUT.EST.METHOD.THREE
Future Contract alternate valuation

Description
Returns estimation of the value of a futures position above cost (i.e. the return on a future position).
Used In Valuation processing
Insertion Point Valuation of Futures Position
It is also possible to compute taxes at the time of closeout with the help of an API to populate tax details in DX.CLOSEOUT application.
DX.ORD.ASSIGN.FIFO
FIFO Order Assignment
Description Assigns partial fills to multiple customers on an order as first customer first then subsequent customers.
Used In Order entry (partial fill)
Insertion Point Order Lot Assignment
DX.ORD.ASSIGN.PRO.RATA
Pro-Rata Assignment of filled lots
Description Assigns partial fills to multiple customers on an order on a pro-rata basis.
Used In Order entry (partial fill)
Insertion Point Order Lot Assignment
DX.PR.BINOMIAL
Cox, Ross & Rubinstein Binomial Pricing Routine
Description Black box routine to return theoretical price based on previous closing price and the greeks.
Used In Revaluation of derivatives positions for theoretical price calculation.
Insertion Point Calculation of Theoretical Prices
DX.PR.BLACK.SCHOLES
Black Scholes Pricing Routine
DX.PR.BUILD.BS
Pre-build for Black Scholes
Description This routine is part of preload process for BLACK SCHOLES "black box" pricing routine. Values for currency rates, volatility
and underlying price are passed back in C$DXPR.PRICE.RECORD
Insertion Calculation of Theoretical Prices

Point
DX.PR.BUILD.GK
Pre-build for Garman Kohlhagen
Description This routine is part of preload process for GARMAN KOHLHAGEN "black box" pricing routine. Values for currency rates,
volatility and underlying price are passed back in C$DXPR.PRICE.RECORD
Insertion Calculation of Theoretical Prices

Point
DX.PR.GARMAN.KOHLHAGEN
Garman Kohlhagen pricing routine
DX.RV.CHREG.VM
Swiss Regulatory VM Calc
Description Black box routine to return Variation Margin calculation for Swiss Regulations.
Used In Revaluation of derivatives positions.
Insertion Point Calculation of Variation Margin
DX.RV.ENHANCED.IM
Enhanced Initial Margin Calculation
Description
Insertion Point Calculation of Initial Margin
DX.RV.EURONEXT
Euronext Margin Calculation
Description Black box routine to return Initial Margin calculation for Euronext.
DX.RV.FXOPT.VM
FX option Variation margin
Description Routine based on STANDARD.VM caters for alternative market price quotation for forex options, i.e. allows exchange rate to
be quoted as delivery ccy vs. contract ccy rather than the other way round (which is the default)
Insertion Calculation of Variation Margin

Point
DX.RV.NO.IM
No Initial Margin Calculated
Description Dummy routine to return zero Initial Margin
DX.RV.NO.VM
No Variation Margin Calculated
Description Dummy routine to return zero Variation Margin
Insertion Point Calculation of Variation Margin
DX.RV.OCC.TIMS
OCC/TIMS Margin Calculation
Description Black box routine to return Initial Margin calculation for OCC/TIMS.
DX.RV.STANDARD.IM
Standard Initial Margin Calculation
Description Black box routine to return standard Initial Margin calculation
DX.RV.STANDARD.VM
Standard Variation Margin Calc
Description This is the "black box" routine that calculates the variation margin for a given set of transactions. These transactions are
passed to the black box by the reval suite. No other logic or processing should be done here.
Insertion Calculation of Variation Margin

Point
DX.STAND.AS.RANDOM
Standard Random Assignment
Description This “black box” routine randomly allocates lots for Option Assignment against a given list of Trades (denoted by Trans-
action Id). The processing is based on EUREX random assignment method.
Insertion Automatic Trade Assignment

Point
DX.XO.CREATE.EURO
FX Option on exercise
Description Routine to create a FOREX trade on exercise of a Derivatives Exotic Option if the Exotic.Event flag is set
DX.XO.CREATE.FX
Create FX Option
Description Routine to create a FOREX trade on exercise of a Derivatives Exotic Option if the EXOTIC.EVENT flag is set
DX.XO.CREATE.FX.KNOCKOUT
Create FX deal on knockout.
Description Create FX deal for knockout if exotic event flag not set.
DX.XO.CREATE.FX.REBATE
Create FX deal or Post Rebate
Description Create underlying FX deal for knockout option with rebate. Create FX deal if exotic event flag not set, otherwise create
rebate cash payment.
Insertion Exotic Option Closeout Processing

Point
DX.XO.CREATE.SEC
Create Sec Trade
Description Create underlying Security deal on exercise of a derivatives exotic option if exotic event flag set.
DX.XO.CREATE.SEC.KNOCKOUT
Create sec trade on knockout
Description Create underlying Security deal for knockout option if exotic event flag not set.
DX.XO.FWDCASHPAYOUT
Forward Cashpayout
Description Create cash payout at settlement of a Derivatives exotic option if the exotic event flag is set - value date of payment offset
from the maturity date

Point
DX.XO.INSTANT.CASHPAYOUT
Instant Cashpayout
Description Create cash payout at settlement of a Derivatives exotic option if the exotic event flag is set - value date of payment offset
from the closeout date

Point
DX.XO.KNOCKIN
Knock in and create underlying
Description Prevent exercise of option before knockin event. Routine will kick off standard exercise of underlying if exotic event is set. If
exotic event is not set no exercise will take place, and lots won't be down-dated.

Point
DX.XO.KNOCKOUT
Knock out or create underlying
Description Prevent exercise of option after knockout event. Routine will kick off standard exercise of underlying if exotic event is not
set. If exotic event is set no exercise will take place, and lots won't be down-dated.

Point
Revaluation Black Boxes
This section is a technical guide to local or client development of new margining algorithms for use in the T24 Derivatives product. It is not
intended for non-technical staff.
When creating new margining routines it is important to note that you cannot create a new record until you have created a revaluation detail
file. See the revaluation details section (DX.REVAL.DET) and also a DX.RV.DET.HIST file. You should use the standard T24 live file tem-
plate, TEMPLATE.L.
For example:
In order to enter a record called SPAN.IM you will need an application called. DX.REVAL.DET.SPAN.IM and a history application of the same
file layout called DX.RV.DET.SPAN.IM.HIST. The existence of these files is vital for the correct function of the derivatives revaluation process,
without them the process cannot complete.
The revaluation suite has a “black-box” design, which allows new variation and initial margin calculations to be developed easily to a published
standard and added to the Derivatives module with the minimum of effort. This will allow flexible local and client-driven development of new
routines without core development involvement.
The suite has been designed to be triggered by “user” events
l Ad-hoc Online “What If…” revelations triggered by DX.REVALUE.
l End of Day, where End of Exchange has not been run for exchanges traded today, using the multi-threaded T24 end of day.
Once the trigger applications have been authorised or verified one of the Grey Box Control Process is called. These grey box processes act as
the main controlling mechanism for the revaluation.
The Grey Boxes ensure the integrity of data within the process and ensures that each black box receives the information it requires to complete
successfully. The Grey Boxes also deal with errors generated by the Black Boxes and act accordingly.
DX.RUN.EOE is a control process that is called exclusively by the end of exchange processes.
l Initially the box controls the processing of a set of pre-defined “pre” processes that are called before the closing revaluation is called.
l It then calls for a revaluation to be completed for all contracts traded on that exchange that is currently held within the system, by mak-
ing a revaluation request to DX.RUN.REVALUE.
l After this has completed, the pre-defined “post” processes are called by the control process and errors dealt with.
DX.RUN.REVALUE is the main control process for the revaluation, it does nothing else but process the data required for the Margin Routine
Black Boxes. Using the information it has collected about the Client, Trade, etc… then it chooses the relevant Black Box routine to process the
information and return either a Initial Margin figure of Variation margin figures for all the constituent transactions. After this has completed it
also produces diagnostic data for the revaluation. See DX.REVALUE.SUMMARYand DX.REVALUE.EXCHANGE
The following sections document the technical details of the Black Boxes:
l Black Box Templates

l Initial Margin Black Boxes
l Variation Margin Black Boxes
Black Box Templates
Initial Margin Black Boxes
This section details the information passed into the Black Box routines for initial margin, and the data that is required back from the box.
In order to access data passed to the common block, the black box routine must have the DX.REVAL.COMMON included. In order to access a
piece of data reference DX$R.RVC.PROCESS(???),for example, in order to access the current list of client positions, use DX$R.RVC.PROCESS
(DX.RVP.MR.CUST.GRP.PORT).
Field/Insert Name No. Level G/M Description
DX.RVP.MR.CUST.GRP.PORT 21 AM G The current customer or portfolio being revalued.
See. DX.RVP.MR.RVLVL.KEY
DX.RVP.MR.POSITION 22 MV G The Positions of the customer or portfolio currently being revalued
DX.RVP.MR.TRANSACTION 23 SM G The constituent transactions for each of the positions held by the current
customer.
DX.RVP.MR.TXN.CNTR.CCY 24 SM G The transactions contract currency
DX.RVP.MR.VAR.MAR 38 SM G Variation Margin Amount
Sub Valued By Transaction
DX.RVP.MR.UNOPT.PL 39 SM G Unrealised Option P&L Amount
DX.RVP.MR.UNOPT.PL.LONG 40 SM G Unrealised Option P&L on Long Transactions Amount
DX.RVP.MR.UNOPT.PL.SHORT 41 SM G Unrealised Option P&L on Short Transactions Amount.
Sub Valued By Transaction.
DX.RVP.MR.EXCHANGE 25 G The Exchange on which the current position is held.
DX.RVP.MR.STRATEGY 26 G The Strategy the current position is a part of.
DX.RVP.MR.NETT.GROSS 28 G Does this exchange NETT its trades or treat them as GROSS.
DX.RVP.MR.CUST.BASE.CCY 29 G The customers reference currency, the currency the customers margins
should be reported in.
DX.RVP.MR.MARGIN.CALC 30 G The name of the current margin calculation.
DX.RVP.MR.FN.MARGIN.CALC 31 G The T24 file name, of detail file to be used for this black box routine.
i.e. F.DX.REVAL.DET.STAND.IM
DX.RVP.MR.RVLVL.KEY 43 M This field represents the key value by which the customer/portfolio/group
should be referenced in a key.
It is important to use this not DX.RVP.MR.CUST.GRP.PORT
DX.RVP.MR.REVAL.TXN 68 M The id of the DX.REVALUE.TRANSACTION record created and returned by

T24 subroutine F.DX.TXN.READ
DX.RVP.MR.DETAIL.KEY 32 M The key generated but the black box as a reference to the record generated
in the Detail file for this black box routine.
DX.RVP.MR.DETAIL.FILE 33 M The T24 application name of the detail file that contains the detailed data.
i.e. DX.REVAL.DET.STAND.IM
DX.RVP.MR.CURRENCY 34 MV M The currency the initial margin is being calculated in, taken from the T24
CURRENCY table.
DX.RVP.MR.IM.FACTOR 35 MV M The “bump up” factor used on the Initial Margin Figure
Multi-valued by Currency
DX.RVP.MR.INIT.MAR 36 MV M This initial margin value calculated in that currency.
DX.RVP.MR.MAINT.MAR 37 MV M This maintenance margin value calculated in that currency.
DX.RVP.MR.COMB.CDY 45 SM M The Combined Commodity Code.
Sub-Valued by Contract.
DX.RVP.MR.COMB.CDY.CONTRACTS 46 SM M The DX.CONTRACT.MASTER Contract codes that make up a combine

commodity.
DX.RVP.MR.CONTRACT 49 SM M The DX.CONTRACT.MASTER contract code for which the initial margin
value has been calculated.
DX.RVP.MR.CONTRACT.FACTOR 50 SM M The “bump up” factor applied to the contracts initial margin figure for this
margin routine calculation.
See DX.MARGIN.CALC field MARGIN.FACTOR
DX.RVP.MR.CONTRACT.IM 51 SM M The initial margin calculated for that currency and contract.
DX.RVP.MR.CONTRACT.CCY 52 SM M This currency the initial margin was calculated in.
(Will normally be the same as the Currency Multi-value)
G = Data Passed From Grey Box Control Process.
M = Must be returned from Black Box Process.
Fields 100-200 can be used for user-defined variables in the common block.
Variation Margin Black Boxes
This section details the information passed into the Black Box routines for variation margin and the data that is required back from the box.
In order to access data passed to the common block the black box routine must have the DX.REVAL.COMMON included. In order to access a
piece of data reference DX$R.RVC.PROCESS (???), for example, in order to access the current list of client positions, use DX$R.RVC.P-
ROCESS (DX.RVP.MR.CUST.GRP.PORT).
Field/Insert Name No. Level G/M Description
DX.RVP.MR.CUST.GRP.PORT 21 AM G The current customer or portfolio being revalued.
See. DX.RVP.MR.RVLVL.KEY
DX.RVP.MR.POSITION 22 MV G The Positions of the customer or portfolio currently being revalued
DX.RVP.MR.TRANSACTION 23 SM G The constituent transactions for each of the positions held by the current cus-
tomer.
DX.RVP.MR.TXN.CNTR.CCY 24 SM G The transactions contract currency
DX.RVP.MR.EXCHANGE 25 G The Exchange on which the current position is held.
DX.RVP.MR.STRATEGY 26 G The Strategy the current position is a part of.
DX.RVP.MR.CUST.BASE.CCY 29 G The customers reference currency, the currency the customer’s margins should be
reported in.
DX.RVP.MR.MARGIN.CALC 30 G The name of the current margin calculation.
DX.RVP.MR.FN.MARGIN.CALC 31 G The name of the T24 detail files to be used for this black box routine.
i.e. F.DX.REVAL.DET.STAND.VM
DX.RVP.MR.RVLVL.KEY 43 G This field represents the key value by which the customer/portfolio/group should
be referenced in a key.
It is important to use this not DX.RVP.MR.CUST.GRP.PORTwhen forming a key.
DX.RVP.MR.REVAL.TXN 68 SM M Sub Valued By Transaction
The id of the DX.REVALUE.TRANSACTION record created and returned by T24

subroutine F.DX.TXN.READ
DX.RVP.MR.DETAIL.KEY 32 M The key generated but the black box as a reference to the record generated in the
Detail file for this black box routine.
DX.RVP.MR.DETAIL.FILE 33 M The T24 application name of the detail file that contains the detailed data.
i.e. DX.REVAL.DET.STAND.VM
DX.RVP.MR.VAR.MAR 38 SM M Variation Margin Amount
DX.RVP.MR.UNOPT.PL 39 SM M Unrealised Option P&L Amount
DX.RVP.MR.UNOPT.PL.LONG 40 SM M Unrealised Option P&L on Long Transactions Amount
DX.RVP.MR.UNOPT.PL.SHORT 41 SM M Unrealised Option P&L on Short Transactions Amount Sub Valued By Trans-
action.
G = Data Passed From Grey Box Control Process.
M = Must be returned from Black Box Process.
Note:
Fields 100-200 can be used for user-defined variables in the common block.
And:
F.DX.TXN.READ should be the only routine used to read transactions into the revaluation suite.

Derivatives Unlocked

Uploaded by

Copyright:

Available Formats

Derivatives Unlocked

Uploaded by

Document Information

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

Derivatives Unlocked

Uploaded by

Copyright:

Available Formats

Derivatives User Guide

Derivatives User Guide 1

Derivatives is part of the Treasury suite of products.

(c) Temenos Systems 2012

The following areas will need to be configured when implementing Derivatives:

(c) Temenos Systems 2012

ACCOUNT.CLASS ID Type Description

SUSPDXIMCR Account Suspense account for credit initial margin

SUSPDXIMDR Account Suspense account for debit initial margin

SUSPDXVMCR Account Suspense account for credit futures variation margin

SUSPDXVMDR Account Suspense account for debit futures variation margin

SUSPDXOMCR Account Suspense account for credit option variation margin

SUSPDXOMDR Account Suspense account for debit option variation margin.

SUSPDXCGCR Account Suspense account for credit derivatives charges

SUSPDXCGDR Account Suspense account for debit derivatives charges

SUSPDXPRCR Account Suspense account for credit option premium payments

SUSPDXPRDR Account Suspense account for debit option premium payments

SUSPDXRPCR Account Suspense account for credit realised P&L

SUSPDXRPDR Account Suspense account for debit realised P&L

DXCSNPAID P&L ‘Suspense’ P&L category for derivatives commission paid

DXCSNRCVD P&L ‘Suspense’ P&L category for derivatives commission received

ACCOUNT.CLASS records for Derivatives Accounting

CATEGORY codes needing to be set up are divided into three types.

CLO Derivatives contract closeout

UOV Derivatives unrealised option value

(c) Temenos Systems 2012

E.g. IBM March 95.00 Put Options @ 0.05 would be 4592009OS.

Maturity & Call Put Indicator

Strike Prices 55 60 65 70 75 80 85 90 95 100

97 ½ 102 ½ 107 ½ 112 ½ 117 ½ 122 ½

(c) Temenos Systems 2012

l ‘System’ level default for all conditions.

1. Customer and contract.

2. Customer and contract class.

4. Customer group and contract.

5. Customer group and contract class.

The commission codes may be entered in the following formats:

CU100018 Customer 100018 (CU = Customer

CGINT2 Customer Group INT2 (CG = Customer

CT100 Contract Code 100 CT = Contract Code)

CCGILTS Contract Class GILTS (CC = Contract

CU100018- Customer 100018, Contract 100

CU100018- Customer 100018, Contract Class

CGINT2-CT100 Customer Group INT2, Contract 100

SYSTEM System level defaults

This screenshot shows a

1. The trade cur-

DX.COMMISSION SYSTEM Record

The types of com-

More than one com-

The field CHARGE.PE-

A couple of examples are presented to show some simple commission scenarios.

(c) Temenos Systems 2012

A bank has set up a customer

On behalf of their internal

They are not trading members

This broker charges different

These have been created in

The bank charges the internal

Following standard exchange