Sssyuy PDF

Derivatives - User Guide
Release: R17 AMR

May 2017
©2017 Temenos Headquarters SA - All rights reserved.

Warning: This document is protected by copyright law and international treaties. Unauthorised reproduction of this document, or any portion of it, may result in severe
and criminal penalties, and will be prosecuted to the maximum extent possible under law.
Table of Contents
Introduction 9
Purpose of this Guide 9
Intended Audience 9
Overview 10
Design Principles 11
Accounting 13
Taxes in Derivatives 14
Contingent Asset/Liability 18
Trade/Value Dated Accounting 19
Trade Dated GL Accounting 20
Commissions and Charges 22
Initial Margin 24
Closeouts 25
Enhanced Unrealised P&L (Variation Margin) Postings 26
SY Equity Options Pay-out 28
Configuration 29
Accounting 30
Alternate Indexes 33
Commissions 35
Scenario 1 39
Scenario 2 42
Contracts 43
DX.CONTRACT.CLASS 43
DX.CONTRACT.MASTER 43
Basic Contract Information 47
Pricing Data 48
Contract Size Information 49
Maturity Date Validation and Key Contract Dates 51
Other Contract Information 56
Exotic Options 58
Setting Up Exotic Options 60
Black Box Routines 61
Example Setups 64
Credit Default Swap 67
Knock in Option 74
Knock out with Rebate 76
Setup 76
Dealing 78
Multiple Exotic events 83
Replacement of Knock In option with a vanilla option 85
Derivatives - R17 AMR - Page 2 of 452

Calculation of Initial Margin 86
Calculation of Variation Margin 87
FX OTC Options for Contract Master and Contract Class 88
Option Settlement Methods 92
DX Trade 93
Customers 95
Events 97
Standard Event Types 98
Commissions and Charges Posting 100
Event Based Reporting 102
Full List of Event Types 104
Exchanges 106
Groups 109
Local Currency Conversion of DX Contracts 110
Margins 111
DX.MARGIN.CALC 111
DX.MARGIN.RATES 111
Parameters 114
Contingent Postings and Product Categories 117
Automatic Expiry or Exercise 118
Automatic Tidying of Cash Settlement Feeds 119
Average Price Positions 120
Back to Back Closeouts 121
Best Rate 122
Blocking of Securities Positions 123
Calculation of Credit Exposure 124
Customer Available Funds Checking 125
Revaluation P&L 126
Straight Through Processing 128
Variation Margin Reversal 130
Pricing 131
DX.PRICE.SET 131
DX.PRICE.SOURCE 131
Routing 133
Strategies 135
Trading Constraints 136
Deal Processing 138
Trade Capture 139
Trade Data Common to All Parties to a Trade 142
Upfront Profit Allocation for Options 143

Customer-Specific Trade Data 144
DX.TRADE for FX OTC options 145
Strategy Linking 148
Commissions and Charges 150
Automatic commission 150
Manual Commission 151
153
Trading in Centralised Company 154
Contract Balances 156
Suppression of Underlying Trades for Options 157
Trade linkages 159
Order Capture 160
Consolidation of partial fills 164
Order Workflow 166
FX OTC Option Order 171
Data Take-on 173
Price Capture 174
Futures and Stock Prices 177
Option Prices 178
Futures/Stock Contracts 179
Option Contracts 180
Automated Price Capture 182
FX OTC Options Price 186
Third party Valuation and MTM 188
SYDX.MARKET.VAL 189
Mark to Market Accounting 191
Price Calculation 197
Price/Premium Terminology 198
Variable Tick Size Calculations 202
Australian Treasury Bill SFE Futures and Options 203
10-Year Treasury Bond Options 205
SFE 10-Year Treasury Bond Futures 208
90-Day Bank Bill Futures Tick Value Calculations 210
Australian Commonwealth Treasury Bonds 211
90-Day Bank Bill Options 212
Australian Government Bond SFE Futures and Options 213
Australian Commonwealth Treasury Bonds 214
SFE 10-Year Treasury Bond Futures 215

10-Year Treasury Bond Futures Tick Value Calculations 217
10-Year Treasury Bond Options 218
Example Contract Key Date Calculation 221
Price Calculation Methods 222
Black and Scholes 223
Cox, Ross & Rubinstein (Binomial) 224
Australian Government Bond SFE Futures and Options 225
Garman-Kohlhagen 226
Closing Out Trades 232
Manual Closeout 237
Automatic Closeout 240
Maturity Closeout 242
Futures/Stock Cash/Maturity Closeouts 245
Option Maturity Closeout 246
Assignment, Expiry and Exercise 249
Manual Assignment 251
Manual Exercise 255
Manual Expiry 261
Automatic Processing 263
FX OTC Options 269
Trade Transfer 270
Internal Transfers 270
Corporate Actions 273
Strike Price Rounding and Creation of New Series 277
DX.TRADE and DX.ORDER 278
DX.DIARY 278
DX.ENTITLEMENT 279
Exotic Options 280
Customer Position Reporting 281
Position Reporting 283
Transaction Reporting 285
Transfer Type 288
Trading Transfers 288
New Clearer 288
Changing Portfolios 288
New platform 288
Transaction Status 291
Trading Commissions Diagnostics 294

Revaluation and Margins 297
Revaluation Summary 298
Revaluation for Exchange 300
Revaluation Details 302
DX.REVAL.DET.CHREG.VM 303
DX.REVAL.DET.STAND.IM 304
DX.REVAL.DET.STAND.VM 305
Exchange defined Initial margin Requirements 306
Adhoc Revaluation 307
Initial Margin Methods 309
AEX Euronext 310
OCC/TIMS Margining 316
Back Valuation of Derivatives 321
Securities Portfolio Valuation 322
Credit Default Swaps 324
Overview 324
DX.PREMIUM.DETS 329
Swaptions 330
Overview 330
DX.TRADE 333
Handling premiums in any currency for FX OTC Options trades 337
Basket Options 341
Setup 341
Trading 341
Delivery 347
Outward Delivery 348
EB.ACTIVITY 350
DE.MESSAGE 351
DE.MAPPING 352
EB.ADVICES 355
DE.FORMAT.PRINT 356
SWIFT MT305 357
SWIFT MT306 359
SWIFT MT601 360
Delivery 361

SWIFT (MT202) 361
Delivery 362
SWIFT (MT202) 362
Credit Default Swaps - Enquiries 363
CDS Net Position 363
OUTSTANDING PREMIUM 363
PREMIUM RECEIVED 363
Swaption - Enquiries 365
Net Swaption Position 365
SWAPTION IN/OUT OF MONEY 365
Common Link Reference 366
List of Back-to-Back Trades 366
List of Linked Trades 366
Limits 367
Example Limit Setup 371
Limits 373
Non Stop Processing 377
Services 378
DX.COB.WORKFILE 379
End of Exchange Day Processing 379
Revaluation 381
Requesting an on-line revaluation 381
End of Exchange Revaluation 383
API 384
Local Routine Insertion Points and API 385
Insertion Points 385
Application Program Interfaces (API) 385
Accounting Entries 388
Accounting Entries for Tax on Closeout 389
Alternate Index Validation 390
Automatic Closeout matching 391
Automatic Trade Assignment 392
Calculation of Exposure 393
Calculation of Initial Margin 395
Calculation of Net Cost 396
Calculation of Theoretical Prices 398
Calculation of Variation Margin 400

Exotic Option Closeout Processing 401
Exotic Option User-Field Validation 403
Order Lot Assignment 404
Price conversion to internal format 405
Valuation of Futures Position 406
DX.AI.CUSIP 407
DX.BB.CREDIT.EXPOSURE 408
DX.CALC.NET.COST 409
DX.CO.AM.FIFO 410
DX.CO.AM.FIFO.DAY 411
DX.CO.AM.LIFO 412
DX.CO.AM.LIFO.DAY 413
DX.CO.AS.FCFS 414
DX.CO.PGM.NOACTION 415
DX.FUT.EST.METHOD.THREE 416
DX.ORD.ASSIGN.FIFO 417
DX.ORD.ASSIGN.PRO.RATA 418
DX.PR.BINOMIAL 419
DX.PR.BLACK.SCHOLES 420
DX.PR.BUILD.BS 421
DX.PR.BUILD.GK 422
DX.PR.GARMAN.KOHLHAGEN 423
DX.RV.CHREG.VM 424
DX.RV.ENHANCED.IM 425
DX.RV.EURONEXT 426
DX.RV.FXOPT.VM 427
DX.RV.NO.IM 428
DX.RV.NO.VM 429
DX.RV.OCC.TIMS 430
DX.RV.STANDARD.IM 431
DX.RV.STANDARD.VM 432
DX.STAND.AS.RANDOM 433
DX.XO.CREATE.EURO 434
DX.XO.CREATE.FX 435
DX.XO.CREATE.FX.KNOCKOUT 436
DX.XO.CREATE.FX.REBATE 437
DX.XO.CREATE.SEC 438
DX.XO.CREATE.SEC.KNOCKOUT 439
DX.XO.FWDCASHPAYOUT 440
DX.XO.INSTANT.CASHPAYOUT 441
DX.XO.KNOCKIN 442
DX.XO.KNOCKOUT 443
Revaluation Black Boxes 444
Black Box Templates 447
Initial Margin Black Boxes 448
Variation Margin Black Boxes 451

Introduction
Purpose of this Guide
This document illustrates the various functions in T24 Derivatives module. It involves the configuration,
workflow description, how to generate report/enquires and the Services/API involved in Derivative-Wealth
Management.
Intended Audience
This User Guide is intended for the use of Internal Temenos users and Clients.

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 of one party default. They are relatively regulated.
The specifications for contracts traded ‘Over The Counter’ are agreed between the parties to the trade, giv-
ing considerably more flexibility. OTC trades are cheaper to execute since there are no exchange or clear-
ing fees to be paid, but is more risk 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 pur-
chasing the right to buy or sell the underlying 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 allow the option
to be expired (refer 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 (typ-
ically 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 contract, 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

Design Principles
The Derivatives product allows trading of futures and ‘vanilla’ options initially. The product supports trad-
ing, 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 is 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 enables the bank to tailor the
product to their needs and minimise the amount of manual intervention required to run the system day-to-
day. The Bank can input comprehensive data to define the products/exchanges and the banks or their cus-
tomers can trade.
Derivatives perform online real-time updates of derivatives trading positions and cost of positions. Full
revaluations are performed at any stage during the system day for reporting purposes. The End of
Exchange process may either run online or during the main T24 batch, it generates and posts to 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 associated with one or more ‘events’ in
the life of a contract that form the basis of the module’s event-driven accounting updates.

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 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 appropriate 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
Refer 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 applic-
ations. The tax fields accept manual input or usage of API (in case of DX CLOSEOUT), core raises an appro-
priate 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 applications are TAX.CODE,
TAX.TYPE, TAX.AMT.ACY and TAX.AMT.LCY.
The tax details are also registered in the DX.TRANSACTION 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 customer deals, four sets of entries are generated.

Customer account is debited with the tax amount and an internal account is credited, with the help of wash
though entries.
For a dealer-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.TYPE (TT) for tax payable and a cor-
responding entry is raised to credit the internal 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 carries those details.
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.
This API is specified in DX.PARAMETER in the CLOSEOUT.API field.
The tax entry or entries as passed back in the relevant fields on the DX.CLOSEOUT record is raised as
accounting entries in the DX.CLOSEOUT record is authorised.

.

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.
l Own Book portfolio buys contract – debit CRF type DXFUTBUY
l 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 affects the posting of
option premiums, commissions/fees or ‘settlement’ P&L when posting offsets are set in the
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.
For example: A customer of the bank buys an option versus a broker, the option in question has premium
and fees posted at trade time. When the PREM.POST.OFFSET on the DX.CONTRACT.MASTER for the instru-
ment is set to ‘2’ (i.e. a two-day offset between premium date and posting) T24 behaves as follows:
Trade Dated:
DR Customer a/c Option premium Value date ‘today’
That is; 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
That is, the premium is booked as a forward dated entry and does not appear on the customer’s statement
until ‘today + 2 working days’.
Note : 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 sum is not posted until a trade on that instrument is
closed out.

Trade Dated GL Accounting
TDGL is an accounting treatment wherein the customer's balance is updated on the value date. However,
the Balance sheet General Ledger is updated on the trade date but under Payable/Receivable heads. Thus
under ‘TDGL’ Trade dated GL accounting, future value dated entries are treated as follows:
l Account actual balances are not updated until the value date
l Movements do not appear on account statements until the value date
l Movements are reflected in the balance sheet but under “Payable and Receivable”.
TDGL for Derivatives can be set in ACCOUNT.PARAMETER application with the relevant categories. Deriv-
atives module, then, posts the premium/commission entries to payable /receivable accounts on trade date,
and on value date the client account is debited and settled against the payable/receivable accounts.
For example, Sell Option (to Client)
Premium Booking on Trade Date:
Dr Premium Receivable (in native currency)
Cr Unrealised Profit
Premium Settlement on Value Date:
Dr Client Account
Cr Premium Receivable (in native currency)

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, commissions 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 must 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 CALCULATE.CHARGE must be
used.
For Own Book portfolios, commissions 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 must 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 CALCULATE.CHARGE must 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 secondary sides of the transaction. Appro-
priate 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 applic-
ations. The tax fields accept manual input or usage of API (in case of DX CLOSEOUT), core raises appro-
priate 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. The customer/broker account for external
customers, and to an internal account specified by the category code in DX.EVENT.TYPE for Own Book port-
folios.
Refer 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 Cus-
tomer’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) is generated in the Customer’s SAM Company. For Online processing, the Closeout
record is generated in the Company where the Closeout is manually executed.
The Intercompany Accounting entries are 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) Post-
ings
Revaluation P&L postings may be completely suppressed by setting the new field SUPPRESS.VM.POST on
DX.PARAMETER to ‘YES’. The Derivatives revaluation still calculates the figures for reporting purposes but
they are not posted to the accounts.
Where P&L is calculated and is to be posted, the 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 VM Posting behaviour

style
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 ‘replace-
ment 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 does 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 is performed.
l No DELIVERY messages is produced.

Apart from these changes, the trade behaves as a normal derivatives trade, that is; a subject to revaluation
during DX.COB.WORKFILE processing, and any postings that are due when the trade is closed out or
matured is also be made.

SY Equity Options Pay-out
T24 is enhanced to pay-out when the final trigger is to exercise the option as the underlying Security or the
cash or as a different security.
Pay-out can be in terms of the alternate instrument and the same is supported only for equity options. Con-
tract size and price for pay-out can be defined during closeout process. If alternate underlying instrument is
not defined for equity options, the pay-out can be made by cash.
Pay-out terms will be supported if SETTLEMENT.METHOD is set to physical or cash respectively.

Configuration
This section describes the implementation and configuration of Derivatives, which is part of the Treasury
suite.
The following areas are 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
l Position Management DX entries
l SY Ability to support Kick-in and Kick-out

Accounting
In order for the application accounting to operate correctly some static data set-up is essential. This section
contains a list of tables to be updated with guidelines for what must 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, for example; 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 there-
fore 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 follows:
ACCOUNT.CLAS- Type Description

S ID
SUSPDXIMCR Accoun- Suspense account for credit initial margin
t
SUSPDXIMDR Accoun- Suspense account for debit initial margin
t
SUSPDXVMCR Accoun- Suspense account for credit futures variation margin
t
SUSPDXVMDR Accoun- Suspense account for debit futures variation margin
t
SUSPDXOMCR Accoun- Suspense account for credit option variation margin
t
SUSPDXOMDR Accoun- Suspense account for debit option variation margin.
t
SUSPDXCGCR Accoun- Suspense account for credit derivatives charges
t
SUSPDXCGDR Accoun- Suspense account for debit derivatives charges
t
SUSPDXPRCR Accoun- Suspense account for credit option premium payments
t
SUSPDXPRDR Accoun- Suspense account for debit option premium payments
t

SUSPDXRPCR Accoun- Suspense account for credit realised P&L
t
SUSPDXRPDR Accoun- Suspense account for debit realised P&L
t
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 cat-
egories are to be used. If different categories are used for the Debit and Credit ACCOUNT.CLASS
(s) then the two Internal Suspense accounts net to zero, however the balances on the individual
accounts continues to grow in a +ve or –ve direction. In many cases it is advisable to use the
same CATEGORY for the debit and the credit ACCOUNT.CLASS , so that the funds wash in and out
of the same suspense account.
CATEGORY
CATEGORY codes needing to be set up are divided into three types.
Internal Account Categories
Should be set up for all non-P&L ACCOUNT.CLASS records (refer 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 manu-
ally for each internal account category 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 specifically 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
Product Categories
A product category in the appropriate range should be set up for each DX.CONTRACT.CLASS defined by the
bank (refer the section on Contracts).
P&L Categories
This is set for the following DX.EVENT.TYPE RECORDS: CM – contract maturity (realised P&L), VM – vari-
ation margin, RP – realised P&L, OM – option variation margin, RO – realised option P&L.
Also must be set up for commission/fee posting event types if DX.EVENT.TYPE category codes to be used for
posting P&L rather than category codes generated by CALCULATE.CHARGE.
It is possible to setup a P&L category for the PP event type. This causes 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 must set aside a range of transaction codes for Deriv-
atives 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 generates 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 six digits of that CUSIP are then taken as the stem of the deriv-
atives extended CUSIP number.
For example; IBM has a CUSIP of 459200101 therefore the stem of any CUSIP number assigned to an option
in DX begins 459200
The extended CUSIP consists of a “stem” code (six characters) plus three 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.
For example; IBM March 95.00 Put Options @ 0.05 would be 4592009OS.
The seventh digit is always nine 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
Strike Price Codes

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 Equity Anticipation Securities (LEAPS) are option con-
tracts that expire more than nine months in advance, and can last as long as two 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 is ‘eight’ digit.
When a trade is assigned an extended CUSIP number, it keeps the same extended CUSIP number until the
trade expires.

Commissions
The Derivatives system allows trading commission to be calculated automatically dependent on certain cri-
teria 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 records 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
CT100 100
CU100018- Customer 100018, Contract
CCGILTS Class GILTS
CGINT2- Customer Group INT2, Con-
CT100 tract 100
CGINT2- Customer Group INT2, Con-
CCGILTS tract Class GILTS
SYSTEM System level
defaults
So that the system knows how to interpret the input, a two-character prefix is used to identify each ele-
ment, 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 contains 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
combined 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 customers, which appear on the
secondary side of the trade.
This screenshot shows a test, which requires two conditions to be satisfied. These are:
1. The trade currency 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 commissions specified in this test set will not be
used.

DX.COMMISSION SYSTEM record
Once the trade details have been matched, up to five different types of commission and charges can be cal-
culated.
Each type can contain a commission/charge code linked to either FT.COMMISSION.TYPE or
FT.CHARGE.TYPE.
The types of commission/charges and fields in which they are entered in are given on the right here.
More than one commission code can be entered for each commission type, but there is only one com-
mission currency per type. If a commission currency is specified then this overrides whatever currency is
defined on FT.COMMISSION.TYPE or FT.CHARGE.TYPE.
The field CHARGE.PERCENT contains a percentage multiplier to apply to the charge amounts calculated.
However this is performed on types commission, execution and clearing fees only.
Commission Type Field Name

Commissions COMM.CHARGE

Execution fees EXFEE.CHARGE
Clearing fees CLFEE.CHARGE
Regulatory fees RGFEE.CHARGE
Miscellaneous fees MISC.CHARGE
Below are example scenarios for simple commission.
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) cus-
tomers, 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 num-
ber 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 com-
mission amount, STDCUST.
The following standard exchange rules, commission are only actually charged when a position is closed out.
In examining the GROUPEXT client commission set-up, it can be seen that the PAY.RECEIVE field is set to
“PAY”, indicating that the customer is paying the commission to the bank.
DX.COMMISSION Input Record

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” picks up all exchanges (LIFFE and EUREX in this example).

The commission set-up for Broker “A”, 100115, has the PAY.RECEIVE field set to “RECEIVE”, indicating that
the bank is paying the commission 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 currencies, USD and GBP, for which it charges a percentage com-
mission, 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 Derivatives as standard contracts, that is, 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 allows the definition of a group of contracts. This name is entered in
the DX.CONTRACT.CLASS application and is 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. This application allows the
bank to set the portfolio to be the default secondary customer, on orders entered in a particular company,
for a particular group of products.
Within each record, there are slots, which allows the bank to set defaulting secondary customer.
DX.CONTRACT.MASTER
DX.CONTRACT.MASTER is the main application that defines the characteristics of future, stock or option con-
tracts 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
l FX OTC Options Contract Master and Contract Class

Basic Contract Information
The most basic contract information like name, mnemonic, exchange on which the contract is traded, type
of contract, are entered first. The CONTRACT.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 DELIVERY.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 Derivatives 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 contract, 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, for example;
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.CONTRACT.MASTER, but the ability to
handle anomalous pricing characteristics through creating specialised pricing routines are 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 mar-
ket price, an override is raised at trade entry.

Contract Size Information
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 appropriate.
The lot size for CME Frozen Pork Bellies futures, for example, is 40,000lb of frozen pork bellies of a stand-
ardised 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 deliv-
ery 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 matures. These are known as MONTHLY
maturity contracts. Some other contracts specify a single day for maturity – DAILY maturity contracts, for
example FLEX options. A few contracts specify a single day up until a certain forward date, and switch to a
monthly maturity after this time, for example LME copper futures. The MATURITY.TYPE field allows input
of MONTHLY, DAILY or OTHER.
The MATURITY.TYPE/AVAIL.MONTHS fields and the multi-value set MONTHS.FWD to MAT.DAYS allows the
user to define valid maturity months for the contract using information supplied by the exchange.
Contract specifications from exchanges quote monthly maturity date rules in one of two ways: either spe-
cifying which months are valid up until a certain number of months forward, or specifying a total number of
valid months. Either method may be combined with a ‘cycle’ of valid months within year, for example
March, June, September and December).
Setting MONTHS.FWD and any cycle required in the sub multi-valued MAT.MONTHS fields handles the first
case, whilst setting AVAIL.MONTHS and any cycle required handles the second case. Examples of set ups for
actual contracts are shown in the section "Example Contract Maturity Rules".
For a monthly maturity contract, certain dates related to the maturity month are significant; chief among
these is the ‘last trading date’, that is; the last date for which contracts maturing in that month may be
traded. The exchange publishes the rules to determine this and other key contract dates, which can be set
up in the fields LAST.TRADE.DATE to AMORT.DATE.
T24 Derivatives uses a range of keywords, codes and modifiers to represent the exchange rules when
determining the dates.
Note: These operators are only valid in the final input field of the date formula string and only
one of them is allowed.
Operators and multipliers can then be applied to any of the “keywords”, subject to the rules shown in the
table. For example, +3BD indicates add three business days.
Some keywords are only valid in the presence of operators or multipliers. It makes no sense to put the
keyword ‘BD’ into a field since it is only useful when describing a date offset, that is, +3BD or –2BD.
Conversely, keywords such as FBD and LCD describe fixed points in a month and are meaningless when com-
bined with operators or multipliers.

Note: The scenario “the first business day in the month 2 months forward” is represented by
“+2M,FBD” and not “+2FBD”.
The ‘days of the week’ keywords are admissible with or without multipliers/operators, because in certain
circumstances it is necessary to say that a date is valid, if it falls on any Monday in a given month. This is
represented by the keyword ‘MO’ without any modifiers.
Brief examples of the use of the keywords follow:
Description Formula
Last business day of the delivery month LBD
Third Wednesday of the month prior to the delivery month -1M, +3WE
The Saturday following the third Friday of the delivery month +3FR, +1SA
Ninth business day prior to the twentieth of the delivery month +20CD, -9BD
Key- Meaning Comments

word
MO Monday
TU Tuesday
WE Wednesday
TH Thursday
FR Friday
SA Saturday
SU Sunday
M Month Only valid with multiplier/operator in same field
W Week Only valid with multiplier/operator in same field
CD Calendar days Only valid with multiplier/operator in same field
BD Business days Only valid with multiplier/operator in same field
LBD Last business day of Not valid with multiplier/operator in same field
the month
LCD Last calendar day of Not valid with multiplier/operator in same field
the month

Key- Meaning Comments
word
FBD First business day of Not valid with multiplier/operator in same field
the month
FCD First calendar day of Not valid with multiplier/operator in same field
the month
MF* Move forward. If the date obtained is not a business day, the move forward until a
business date is found.
MB* Move backward If the date obtained is not a business day, then move backwards until
a business date is found.
CAL* Calendar Date Return the date obtained, even if it is not a business date.
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 continues to use the main rules.
DX.CONTRACT.MASTER
Where Clients do not want to set the Complex maturity date rules, then they can use the
DX.CONTRACT.MASTER table.
The field MATURITY.DATE in DX.CONTRACT.MASTER determines if the system must calculate the Maturity
date and other dates using the range of keywords, codes and modifiers or if system should directly read the
dates from a table called DX.CONTRACT.DATES
The field MATURITY.DATE in DX.CONTRACT.MASTER accepts the values CALC.ONLY, TABLE.CALC.UPDATE,
TABLE.ONLY and NONE. NONE is the default.

l Null & CALC.ONLY – Always calculates the Maturity date from the definition provided in contract mas-
ter. If this option is selected then the table must be empty and no input is allowed. The system works
the way it currently does.
l TABLE.CALC.UPDATE – Calculates the maturity date based on the definition available in contract mas-
ter and update the DX.CONTRACT.DATES table. No manual update is allowed to the table with this
option. Basically this is used just to store the system calculated values in a table.
l TABLE.ONLY – Always refers to the table to determine the maturity date. If a record is not found, it
raises an error.
Based on this field, during the Maturity process, the system either picks the date from the table or cal-
culate as currently done.
Three COB job are run and it updates the DX.CONTRACT.DATES table where required. These jobs (to be run
daily) calculates the valid Maturity Months for each Contract and creates the DX.CONTRACT.DATES records
and update the various fields therein
DX.CONTRACT.DATES

The ID is the Contract Master ID “/” Maturity month
The LAST.TRADE.DATE, FIRST.NOTICE, LAST.NOTICE, FIRST.DELIVERY, LAST.DELIVERY, SPOT.DATE,
DEC.DATE and AMORT.DATE fields accepts Dates. For Contracts set as TABLE.CALC.UPDATE, the system dur-
ing COB creates the records. It also calculates and updates these fields based on the set-up in
DX.CONTRACT.MASTER
For Contracts set as TABLE.ONLY, the users have to create the required records and also update these fields
manually.
The system the purge the records in the DX.CONTRACT.DATES table that are prior to the months specified
in HLD.CONTRACT.DATE field in DX.PARAMETER application.

Other Contract Information
The remaining fields on DX.CONTRACT.MASTER perform various functions. VAR.MARGIN.CALC and
INIT.MARGIN.CALC are defaulted from DX.EXCHANGE.MASTER but can be overridden to apply special mar-
gin 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 declares to. For a future it represents the actual asset the
contract is based on, for example; a stock. It may also represent the underlying Security No. in the
SECURITY.MASTER
The SETT.ALLOWED flag overrides the main flag at DX.EXCHANGE.MASTER level to say whether or not an
eligible open position in the contract must be automatically closed out in the End of Exchange processing.
CONTINGENT.VALUE can be set to represent 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 uses the contract 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 the handling of exotic
options. These have additional rules governing 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 expiration.
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 barrier. 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 out-
comes 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 sur-
passes 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 expiration, 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 pay-
out. 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 (regardless 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 is triggered when the field EXOTIC.EVENT in DX.TRADEor DX.ORDER is set. Any fur-
ther automation required, needs to be locally implemented, and it is therefore recommended to construct
enquiries that display 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 cre-
ated 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 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 EXOTIC.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 record keys for options of this type in T24.
l Black Box Routines

l Example Setups

Black Box Routines
The following Black Box routines downstream the processing of Exotic Options. These routines must be
attached to the field CO.PGM of DX.OPTION.TYPE.
l DX.XO.CREATE.FX - To create the underlying FX deal; no user fields required.
l DX.XO.CREATE.SEC - To create the underlying SEC.TRADE; no user fields required.
l DX.XO.CREATE.FX.KNOCKOUT - To create underlying FX deal in case of knockout options; no user
fields required
l DX.XO.CREATE.SEC.KNOCKOUT - To create underlying SEC.TRADE in case of knockout options; no user
fields required
l 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.
l 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.
l DX.XO.CREATE.FX.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
l 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.
l 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. For example,
maximum price barrier, rate level (a minimum interest rate barrier) and narrative (weather option cri-
teria).
DX.USR.FLD.OPT settings for Price Level, Rate Level and Narrative fields

.

Example Setups
The setup of DX.OPTION.TYPE and DX.EVENT.TYPE for some example exotic option types are explained
below. 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 Digital 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 must 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.
Note: The routine DX.XO.INSTANT.CASHPAYOUT is to be called when this transaction is exer-

cised or assigned.
CRED.DEFAULT Option Type

The DX.EVENT.TYPE record must also be created.

XO-CRED.DEFAULT Event Type
The contract master for the Credit Default Swap must be set up with the option type CRED.DEFAULT asso-
ciated to it, before the user 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 con-
tract is ready to be traded. The screen shot below displays 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 validation.
In order to trigger this Exotic option, the EXOTIC.EVENT field on DX.TRADE record must be set to yes. Then
the transaction is either exercised or assigned using the enquiries DX.CO.MANUAL.EXERCISE or
DX.CO.MANUAL.ASSIGN

DX.CLOSEOUT of a manual exercise
The cash payout is then posted (in this case USD $99,000) is then be posted as shown below.
Entries posted for the transaction

Knock in Option
It is normally expected to input DX.TRADE records into the system, if they have not yet kicked in/knocked
in. Using a version of DX.ORDER the kick-in or knock-in deal is input. An enquiry created to compare the
kick-in price with the underlying market price and display records as appropriate*, with a drill down 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 delivery 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.
The DX.OPTION.TYPE for KNOCK.OUT.REBATE must be set up, specifying that a currency other than the
local currency and an amount are to be prompted when this DX.OPTION.TYPE on the DX.TRADE is validated.
Note: The routine DX.XO.CREATE.FX.REBATE is to be called when this transaction is exercised or

assigned.
Finally the DX.EVENT.TYPE record needs to be set up.

The below screen shot displays 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 transaction is exercised manually.
The closeout is created.

The closeout then posts the accounting entries as shown below.

Statement entries

Multiple Exotic events
Multiple exotic types can be combined at trade level to construct options with multiple events. For
example, in KIKO (Knock In Knock Out) option, Knock In would be an exotic option type & Knock Out would
be another exotic option type, these two option types can be combined to construct a KIKO option.
The exotic type field in DX.TRADE can be multivalued to combine more than one option types.
The field EXOTIC.EVENT in DX.TRADE can be multivalued to record the occurrence of each event sep-
arately.
The fields EXOTIC.DATE and EXOTIC.TIME can be used the record the date and time of the event occur-
rence.
Exotic events can be activation type of events, i.e, the occurrence of the event will activate an option or in
case of digital options, triggers a payments. Examples of ‘Activation’ type of events include, Knock In and
Touch Barrier.
Exotic events could also be termination type of events, i.e, the occurrence of the event will terminate the
option. Examples include, ‘Knock Out’ and ‘No Touch’ Options.
This can be recorded in DX.OPTION.TYPE application and the same would be validated at the time of clos-
eout processing.
The field EXERCISE.EXPIRE is used for this purpose. Activation type of events should be set to ‘Exercise’
while, termination type of events should be set to ‘Expire’. A sample set for a ‘Knock In’ event is shown
below.

.

Replacement of Knock In option with a vanilla option
A bank might choose to replace an ‘ Knock In’ option with an plain vanilla option when the ‘Knock In’ event
occurs. This can be achieved by setting the KICKIN.EXPIRE field to yes. When the exotic event is triggered
(EXOTIC.EVENT is set to ‘Yes), then on authorization of the DX.TRADE, the trade will be marked as ‘Closed’.
The user can then key in the vanilla option manually. The KICKIN.EXPIRE field is available in DX.PARAMETER
,DX.CONTRACT.MASTER and DX.TRADE. The trade will default from the contract master which would in
turn default from the parameter, however it is possible to amend the value at contract and trade level.

Calculation of Initial Margin
The initial margin (or deposit) is required by counter parties, in order to ensure their financial stability if
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/options, each clearing-house or exchange pub-
lishes its initial margin calculation method. These various methods are implemented by using the revalu-
ation “black box” technology and by using a parameter in the contract master file DX.CONTRACT.MASTER.
Associated with each method it is 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) and are included in all initial
margin calculations. This allows the user to easily check all the margin figures including SPAN, spreads and
hedges.
Calculations performed by the system are based one of the following methods;
1. 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)
2. Enhanced IM
l As above except it does not include bought positions in the Naked calculation.
3. 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 para-
meter held in the contract master file. Initially, only the regular contract method (unit price * price dif-
ferential) are used, but alternatives can easily be added by using the “black box” technology.
In the case of options, separate figures are produced depending on when the premium for each contract is
paid. If the premium is paid at settlement time, then Option variation margin is calculated using the market
price or a fair value price. If the premium on the contract is already paid, then the figure is classed as
unrealised option profit/loss. This unrealised profit/loss are reported separately and can often be used in
the initial margin calculations, for example "SPAN" to reduce the initial margin requirements. Therefore
the variation/unrealised option value calculations must be performed before the initial margin calculations.
Based on the following methods, the system performs the calculation :
1. Standard VM
l For transactions with premium paid (Options)
VM = No Lots * Market Price
Otherwise
VM = (Market Price – Transaction Price) * No. Lots
2. Ch Reg
l VM = (Market Price – Transaction Price) * No. Lots
3. NO VM
l VM = 0

FX OTC Options for Contract Master and Contract
Class
Single DX.CONTRACT.MASTER for FX OTC CCY option is maintained. The actual Currency pair and other con-
tract details are set at the Trade Level.
The fields CONTRACT.TYPE and CONTRACT.CLASS in the applications DX.CONTRACT.CLASS and
DX.CONTRACT.MASTER are used.
DX.CONTRACT.CLASS
The field CONTRACT.TYPE defines the type of contract such as FUTURE, OPTION, FX-OPTION and NONE.
The FUTURE and OPTION are for information purpose only.
The user needs to select FX-OPTION if FX OTC functionality is needed.
Any DX.CONTRACT.MASTER with an FX-OPTION enabled Contract Class and exchange as OTC, will be
treated as an FX OTC option. For these kind of Contract Masters, the Trade and Delivery currencies can be
left open at the Contract level and users can set up different Currency pairs at Trade level by using this
single Contract Master.
Defaults to NONE when no values provided.
DX.CONTRACT.MASTER
The field CONTRACT.CLASSdefines the type of instruments being traded on the relative exchange. e.g.
Bond, Interest Rate, Metals, Softs, Stock Index and so on.
If the Contract Class selected has a Contract Type as FX-OPTION, currency fields and price definition fields
will become NOINPUT.

Introduced in DX.CONTRACT.MASTER to specify the settlement method and also the alternate instrument
to settle instead of Underlying. If the delivery method is Cash, it is also possible to specify the
FX.PAYOUT.CCY.

DX.CONTRACT.MASTER

Option Settlement Methods
T24 supports different Settlement methods for Options. The Option can be Cash Settled or Physically
settled. For Options with Security Underlying, it is also possible to settle the Option through an alternate
instrument. For example, an Option on Taiwanese Shares. In certain markets, the Underlying Taiwanese
Share is Non-Deliverable (as a result of a regulatory constraint), in such cases the Option is settled through
a participatory note issued by the Option Writer.
The user can input the value to determine the Pay-Out (Spot Price of the Underlying for Cash Settlement or
the quantity and price for Settlement through an alternate instrument) in the Closeout the suite of applic-
ations. The same is used when the Closeout is processed.
The calculation method for Cash Payout on Equity Options is as follows:
When CALL/BUY,
Cash_Payout_Amount = (Current_Market_Price – Strike_Price) * Contract_size * Lots
When PUT/BUY,
Cash_Payout_Amount = (Strike_Price - Current_Market_Price) * Contract_size * Lots
When Cash Payout is for FX Options, then the input for QUOTE.CCY (for normal FX Option, it is delivery cur-
rency; whereas for generic FX OTC Option, it is strike quote currency), SPOT.EXCHANGE.RATE (is the
Exchange Rate between Contract and QUOTE.CCY), FX.PAYOUT.CCY and SPOT.PAYOUT.RATE (is the
Exchange Rate between FX.PAYOUT.CCY and QUOTE.CCY) fields are required.
Cash_Payout_Amount = (Lots * (Strike_Rate – Spot_Exchange_Rate))
1. CALL/BUY with delivery currency as weaker currency and trade currency as stronger cur-
rency with quote currency as stronger currency.
2. CALL/BUY with delivery currency as stronger currency and trade currency as weaker cur-
rency with quote currency as weaker currency.
3. PUT/BUY with delivery currency as weaker currency and trade currency as stronger cur-
4. PUT/BUY with delivery currency as stronger currency and trade currency as weaker cur-
Cash_Payout_Amount = (Lots * (Spot_Exchange_Rate – Strike_Rate))
1. CALL/BUY with delivery currency as weaker currency and trade currency as stronger cur-
2. CALL/BUY with delivery currency as stronger currency and trade currency as weaker cur-
3. PUT/BUY with delivery currency as weaker currency and trade currency as stronger cur-

4. PUT/BUY with delivery currency as stronger currency and trade currency as weaker cur-
DX.CONTRACT.MASTER
The Settlement Method field in the DX.CONTRACT.MASTER allows the user to specify the settlement
method and also the alternate instrument to settle instead of Underlying.
If the delivery method is Cash, then the user can use the Fx Payout Ccy field to specify this value.
DX.CONTRACT.MASTER
DX Trade
The DX Trade application holds the settlement details and also the pay-out currency details.
FX.PAYOUT.CCY should be set if the pay-out should be made in a different currency other than Trade and
Delivery Currencies.

l FX.PAYOUT.CCY - Payout Currency if the settlement method is cash
l PRI.SETTLEMENT.ACC – Account (Primary side) to which the cash entries are posted when the payout
is in cash.
l SEC.SETTLEMENT.ACC – Account (Secondary side) to which the cash entries are posted when the pay-
out is in cash.
l PRI.TRADE.CCY.LOTS - This field holds the LOTS/amount in terms of trade currency and calculated
based on STRIKE.PRICE
l SEC.TRADE.CCY.LOTS - This field holds the LOTS/amount in terms of trade currency and calculated
based on STRIKE.PRICE

Customers
Specific information required for trading derivatives information must be entered for each customer that
are 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 for reporting purposes.
However, these three customer types have significance for margining purposes. As the DX module is double
sided for every buy or sell by a customer/dealer, the equal and opposite position is held for with a broker,
dealer or exchange. Therefore; when initial margins are calculated by the system, all positions held by
brokers, counterparties and exchanges are reversed, therefore ensuring the margin results are calculated
correctly and are reconciled. Brokers and exchange customer types are not expected to have portfolios
when trading. The Customer and Dealer types represent the majority of the Bank’s clients and own-book
trading, and must have SEC.ACC.MASTER portfolios set up before trading. Finally, the Exchange type cus-
tomer 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.
DX.CUSTOMER record
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 EXCHANGE to MARG.WEIGHTING fields allows the definition of the interaction of the
customer with one, several or all exchanges defined in the Derivatives product. This allows the Bank to
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 is 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 is typically used if the

Bank considers a particular customer to be a greater than normal 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 must be set to AUTO, if auto-
matic close out is to be allowed. Refer the Helptext for more details on 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 calculation, margin calculation and reporting purposes.
Note: The MARGIN.ACC.CCY field through to TRADING.STATUS is populated at this release but
are available for information only. They are used for 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 cus-
tomer in the Derivatives revaluation. 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 cur-
rency.
The RENEWAL.FREQUENCY field allows a standard T24 frequency code to be entered. It defines when the
document must 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 derivatives contract are selected from a predefined list and are associated
with information that is used in accounting for the Bank’s own book portfolios. The module 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, generates two DX.TRANSACTION records.
One for the broker and another for the own book portfolio. Each transaction are then tested and has the fol-
lowing events assigned:
l CI – Contract Initiation : Triggers posting of contingent liability posting for own-book portfolio.
l FC – Clearing Fee : Posts clearing fee calculated to broker account vs P&L category for own book port-
folio.
l FE – Execution Fee : Posts execution fee calculated to broker account vs P&L category for own book
portfolio.
Derivatives Event Type Record
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 are defined in the DX.EVENT.TYPE application are as follows:
Even- Name Description

t
code
CI Contract incep- Initial entry of trade
tion
CC Contract can- Cancellation of an authorised contract i.e. contract reversal not part of an
cellation amendment – contract completely cancelled
CD Contract dele- Deletion of an unauthorised contract
tion
CU Contract Amendment of an unauthorised contract.
unauth amend-
ment
CR Contract Reversal of authorised trade details before amended details entered
amendment
reversal
CA Contract Amendment of authorised trade – new details
amendment
CM Contract matur- Trade maturity
ity
CS Contract set- Settlement of trade (close-out)
tlement
PS Partial Set- Partial settlement of lots
tlement
SR Settlement Reversal of settlement (close-out)
reversal
PP Premium post- Posting of option premium
ing
FC Commission Posting of ‘normal’ trading commission
posting
FE Execution fee Posting of Execution fee
posting

Even- Name Description
t
code
FR Regulatory fee Posting of any regulatory fees
posting
FL Clearing fee Posting of clearing fees
posting
FM Miscellaneous Posting of any other miscellaneous charges entered manually
fee 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” conventions (e.g. LIFFE settlement and reopen process)
UO Unrealised Unrealised option value generated by revaluation (not variation margin since not
option value product of mark-to-market or similar)
OA Order amend- Amendment of authorised order – new details
ment
OC Order can- Cancellation of an authorised order
cellation
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
OM Option margin Margin at Market Value
(Market 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 Mar- Variation margin (unrealised P&L) generated and posted by revaluation for
gin 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 trans-
actions only, for certain types the CATEGORY code are mandatory.
The records PP (premium posting) and UO (unrealised option value) in DX.EVENT.TYPE can be assigned cat-
egories as:-
l PP – A PL-category (50000-59999) or an internal account category (10000-19999)
l 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, the system raises 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, the system raises a RE.CONSOL.SPEC.ENTRY
If a PL category is defined in the DX.EVENT.TYPE for PP & UO, the system raises a CATEG.ENTRY
For example, if a PL-category assigned, then on entering a DX.TRADE for option contract, the system books
the premium amount in PL by raising appropriate CATEG.ENTRY. It raises debit or credit entry in
CATEG.ENTRY for long and short positions respectively and corresponding entry are raised in STMT.ENTRY
for broker’s account.
Similarly, the UO amount generated on account of revaluation (for own-book trades) are posted to PL by
raising debit or credit entry (depending upon the position - long or short) in CATEG.ENTRY and cor-
responding entry are raised for internal account in STMT.ENTRY.

For an example, if an own-book trade is entered for buying a call option by paying a premium of 15 for 10
lots (lot size =1000). After authorizing the trade, the system raises a debit entry in CATEG.ENTRY for the
premium paid.

The corresponding entry is generated 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), the system calculates the UO amount
and posts it to CATEG.ENTRY.
The corresponding debit entry is generated in STMT.ENTRY for an internal account.
Similarly, the UO amount generated on account of revaluation (for own-book trades) is posted to PL by rais-
ing debit or credit entry (depending upon the position - long or short) in CATEG.ENTRY and corresponding
entry are 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 the events against positions and DX.TXN.ACTIVITY records the events against
transactions.
Event Based Reporting is enabled through the REP.UPDATES field in the DX.PARAMETER application.
In the DX.EVENT.TYPE record, the field TX.ACT.UPD controls the decision as to whether a given
DX.EVENT.TYPE must 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.
The user may require all or some of these depending on which products 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 are traded.
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, that is regulators.
Each exchange is uniquely associated with a REGION, since the module uses regions to represent exchanges
for the purpose of defining trading calendars in the HOLIDAYapplication.
The EXCHANGE.TYPE field allows an exchange to be set up as Normal, that is, 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 field allows the payment of option premiums and charges/-
commissions, to default to a trade or settlement (close-out) time for all contracts on the exchange. In both
cases the corresponding OFFSET field allows the postings to be delayed by the number of days set in the
fields.
Basic default margining parameters can be set for all contracts on the exchange. VAR.MARGIN.CALC and
INT.MARGIN.CALC define the default variation and initial margin calculation records in DX.MARGIN.CALC,
whilst NETT.GROSS is a parameter required by the margining algorithms on certain exchanges.

DX.EXCHANGE.MASTER record
The valid days available for trading are read from the holiday record associated with the exchange region,
but unusual trading day rules (that is, Monday to Thursday rather than Friday) are defined in
DX.EXCHANGE.MASTER record in TRADING.DAYS field. The exchange’s specific trading opening and closing
times can be recorded in TRADING.OPEN and TRADING.CLOSE. These are multi-value fields, certain ‘ses-
sions’ during the exchange day are available for trading certain products. If these sessions have particular
titles, then they are 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 contract may be traded.
The fields MUTUAL.OFFSET to GEN.DATA.LIMIT details about the exchange’s trading arrangements with
other exchanges, electronic trading tools and any regulatory reporting schemes if 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 this field is set to "No", open positions in contracts on the exchange that are oth-
erwise eligible for automatic close out during the End of Exchange processing are kept open.
If the Bank is a member of any exchanges, then it may wish to record 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 depending on local regulatory requirements.

DX.EXCHANGE.MASTER record

Groups
DX.GROUPING is a simple application that allows Derivative customers to be grouped, for commission cal-
culation and margining/reporting purposes. The group is simply defined in DX.GROUPING and the Group
ID added to the DX.CUSTOMER record must be a valid ID in DX.GROUPING
DX Grouping record

In later stages of the Derivatives product development, the revaluation suite supports the revaluation of
hierarchical DX.GROUPING structure, that is, performing a revalue on group AA also revalues the 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 it is not used at present.

Local Currency Conversion of DX Contracts
Enables Euro conversion of local currency commitments where by commitments are cash settled.
Cash settlement for the purpose of this functionality are defined as follows :
l For futures contracts the effective realisation of any profit & loss due to involved parties
l For options contracts the payment of any outstanding option premium.
Refer to the Euro User Guide for more information.

Margins
DX.MARGIN.CALC
The DX.MARGIN.CALC application allows an entry/amendment of margin calculation routines into the T24
Derivatives module.
The Derivatives module is designed to use ‘black boxes’ to return information that may be obtained in sev-
eral different ways. In this way, the main applications calls one ‘shell’ routine, which selects 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 module calls a single ‘grey box’ routine that
determines the correct margin calculation to apply by examining the exchange and, if necessary, the con-
tract 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.
DX Margin Calc record

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” Initial Margin routines that are controlled by the application
DX.MARGIN.CALC. However some of these routines require rates to be entered depending on which cal-
culations being performed.
The DX.MARGIN.RATES application allows the entry of initial margin rates for various types of trades. These
rates are used, as required, by various initial margin calculation routines. Further applications are
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. That is; -19- -
100163-20010615, this margin rate becomes 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, the system knows how to interpret the input, a 2-character prefix is used to identity each element, the
application also recognises mnemonics used by the source applications.

Parameters
DX.PARAMETER is the main parameter control file for the Derivatives module. It contains the single record
named SYSTEM, which is read by other applications in Derivatives and their behaviour are controlled by the
contents.

DX.PARAMETER Record
Note: The details of the effect of the data in DX.PARAMETER can be found in the help-text for
this application.
Particular facilities that can be set up in DX.PARAMETER and other Derivative product tables are outlined in
the following sections:
l Contingent Postings and Product Categories
l Automatic Expiry or Exercise
l Automatic Off-set and Closeout from Orders
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
l Variation Margin Reversal

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
CONT.ULYING.VA- (DX.CONTRACT.MASTER
L Description DELIVERY.METHOD = ‘CASH’) Other Derivatives
NO Existing style CR or DB CRF asset type CR or DB CRF asset
type
Only for futures and options Amount – cost of position or
with premium un-posted contingent value Amount – cost of pos-
ition or contingent
Currency – contract currency
value
Currency – contract cur-
rency
YES New style CR CRF asset type CR and DB CRF asset
type
All trades Amount – underlying receiv-
able ccy amount Amount – cost of pos-
ition
Currency – receivable cur-
rency Currency – contract cur-
rency
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 instrument 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 con-
sideration.

Automatic Expiry or Exercise
The automatic expire/exercise functionality is activated at the DX.CONTRACT.MASTER level. The fields
SYSTEM.EXERCISE and SYSTEM.EXPIRY are 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 explain earlier causes the system to write a
record to the appropriate underlying file:
l DX.CO.MATURITY.INPUT
l DX.CO.ASSIGN.MANUAL
l DX.CO.EXERCISE.MANUAL
l DX.CO.EXPIRE.MANUAL
l DX.CO.MANUAL.INPUT
These files may in the passage of time become overly large and may not be required by the user. If the
user does not wishes to retain these records it is possible to set these files to be automatically cleared dur-
ing 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 in the BATCH record DX.END.OF.DAY, runs this process and can 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, are avail-
able in the application DX.CONTRACT.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 is 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, by setting the field SC.ASSET.UPD in
DX.PARAMETER to BUY.SELL.POS. This allows 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 is filled. By keeping the CREATE.TRADE flag on the DX.ORDER set to “NO” until the
final fill, then set it to 'Yes'. This must create one deal with the price set as the average of all the fills for
the order.
The FILLED.LOTS, FILLED.PRICE, FILLED.IPRICE and CREATE.TRADES fields are also available in the
DX.ORDER application.
The CREATE.TRADE field in DX.ORDER defaults its value from DX.PARAMETER, which however must be set
to YES for authorisation of DX.ORDER record.
Every input to unauthorised DX.ORDER record on execution, creates a new multi-value set of the above
mentioned fields. This averages 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 automatically, 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 does not result in a back to back closeout for the corresponding primary cus-
tomer.
For this purpose, the B2B.ACTIVE field in DX.PARAMETER is used. While the B2B.CO.OK field in
DX.CONTRACT.MASTER is used to activate the back to back closeout process.

Best Rate
As a standard, any debit or credit to the customer account is computed by applying the middle exchange
rate, if the derivative currency is different 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 premium, charges and commission involved in DX trades, besides retaining the cur-
rent functionality of applying mid rates.
However, following are the highlights of this functionality :
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 com-
mission type for the said trade
l The system defaults the best exchange rate from Globus bank perspective, for conversion of com-
mission/charges, based on the definition 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 available based on the class of the customers: Customers, Brokers, Dealers,
Counter Party and Exchange.
DX.PARAMETER
The SPECIAL.RATE field in DX.PARAMETER defines the class of customer to have special rates applied. If
this is left blank, it defaults 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.PARAMETER. 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 cer-
tain percentage of the nominal or underlying contract amount. For Derivative trades, this percentage
depends on the sub asset type and remaining time to maturity of the contract. However in case of interest
rate derivatives alone, original life of the underlying applies.
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 calculating 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
When the new flag CHECK.CUST.FUNDS on DX.PARAMETER is set to ‘YES’, the module calculates a ‘best
estimate’ initial margin figure for each transaction input (order or trade). This figure generated is used 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). Also makes 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) are posted to the account input for that cus-
tomer on DX.TRADE
For Own Book portfolios unrealised, P&L calculated by the Derivatives revaluation process are 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 MARGIN.DIFFERENCE parameter in
DX.PARAMETER.
If this field is set to YES then when a new margin figure is calculated, the difference between the previous
margin amount and the new amount is posted.
If this field is set to NO then the previous margin amount is reversed and the new margin amount is posted.
When the field VM.REVERSAL.STYLE set to "New" and the MARGIN.DIFFERENCE set to "Yes", the Reversal of
Variation margin for foreign currency contracts during closeouts are posted at the exchange rate at which
it was booked.
If the field is set to "Old", it reverses the VM amount with prevailing exchange rate.

The variation margin are reversed on reversal of the DX.TRADE. The details on how the reversal are be
handled can be viewed here.

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 possible to set these trades to be created with their status set to
INAU. This functionality can be activated through the STP.ENABLED.APP field in DX.PARAMETER
DX.PARAMETER Record with STP enabled
The USER designates the DX.ORDER application as a value in the field to activate the straight through pro-
cessing 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.SERVICE manager TSM should be running, and cor-
responding OFS.MESSAGE.SERVICE and OFS.RESPONSE.QUEUE set to AUTO
In case of any problem, the enquiry, DX.MONITOR.STP.PROCESS, monitors the state of DX.ORDER and
DX.CLOSEOUT generated OFS transaction messages. It reports any transactions that require operator inter-
vention and if a timeout period is specified, it also reports on any transactions that were not handled within
that time.
The enquiry reports the DX.TRADE ID, the error message, the date/time of the generated transaction, the
length of time since the transaction was generated and if it is a timeout related issue.

Example DX.MONITOR.STP.PROCESS enquiry
The STP.TIMEOUT field 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 it is left blank, no
timeout checking is done in the DX.MONITOR.STP.PROCESS enquiry.

Variation Margin Reversal
Two options are possible while posting Variation Margin entries. Either system is parameterised to post
only the difference between the current date and the previous date or otherwise reverse the full amount
collected on the previous date and re-post the current variation margin in full. Refer Revaluation P&L for
further details
When a DX.TRADE is reversed, only the last variation margin posting is reversed. This leaves the balance in
the Customer's account as correct on the date of reversal. However, the previous days balances since the
inception of the trade is not adjusted and this may affect the Interest charged on the account balances.
The VM.REV.INDIVIDUAL field in DX.PARAMETER needs to be set as YES, If all Variation Margin entries are
to be reversed with effective date.
If this field is set to YES, then the system updates a Live file called DX.VARIATION.MARGIN.DETS
Note: This is a no-change field and needs to be decided upfront.
The ID of the file is DX.TRADE id "." Portfolio ID.

Every time a Variation Margin entry is posted for a Trade, the system updates all the details including the
exchange rate, Amount, Account to which posted into this table.
When a Trade is reversed, the system uses the values in this table and it reverses each entry individually
with the correct value date.
This ensures that the Balance in the Account is adjusted for each day.

Pricing
DX.PRICE.SET
The function allows the user to enter/amend the 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 are 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 must 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 (for example; Reuters, Telerate, Telekurs).
l Batch based price downloads (for example; SPAN risk parameter files).
l Ability to call a price model routine and store the returned price (for example; 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 produce STP workflow, the derivatives module provides the ability for orders and the sub-
sequent trades to be routed between T24 companies
Order routing
The application DX.ACC.MASTER allows the user to set up inter-company routing information for a portfolio
in Derivatives. The fields RT.PORT.ID and RT.COMP.ID allows the trades/orders to be replicated to specific
portfolios in different T24 companies.
Set up order routing

The fields PRI.RT.COMPANY, PRI.RT.PORT.ID, PRI.RT.WHEN and PRI.RT.LINK on DX.TRADE and DX.ORDER
(also present on the secondary side of the deal) holds the routing information for a deal.
Derivatives Trade Record (partial extracts from application shown)

If an order in "Company A" is automatically routed to "Company B" for filling, fills made in "Company B"
are auto-routed back to "Company A".
This function is typically used, where one bank entity was taking customer orders, but for regulatory reas-
ons only a separate bank entity is allowed for trading the instrument in question with an exchange/broker.

Strategies
When trading derivatives, it is common to link individual transactions for forming a strategy and 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 are constrained as required.
Individual banks may define their own “combination” products, for example; 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 is 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 cus-
tomers 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 com-
bination to determine whether the customer or portfolio is not allowed to trade based on the details
entered.
More than one constraint is defined for a particular portfolio, as the ID of DX.TRADING.CONSTRAINT con-
tains a reference number that differentiates between multiple constraints for the same portfolio.
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 cus-
tomers with constraints that normally would preclude the customer. To do this the trading constraint fields,
PRI.CONSTRAINT and SEC.CONTRAINT on each side of the trade in DX.TRADE must be manually entered
rather than relying on the default of constraint 01 or SYSTEM being used.
DX.TRADING.CONSTRAINT Records
The System Record

If the SYSTEM record in the DX.TRADING.CONSTRAINT application exists, then this is applied to all sides of
the trade in the system, unless alternative trading constraints are 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. The user can also set up constraints which allows the 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 the user, 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:
l If the CONTRACT.TYPE on the DX.CONTRACT.MASTER record is equal to “FUTURE”, then produce an
“ERROR” with NARRATIVE “ONLY ALLOWED TO TRADE OPTIONS”
“or”
l If the CONTRACT.CODE on the DX.CONTRACT.MASTER record is equal to “1” (CBOT), then produce an
“ERROR” with NARRATIVE “NOT ALLOWED TO TRADE CBOT OPTIONS”
This shows that single constraints can be linked together using AND/OR to produce a complex constraint.
There is no limit to the number of constraints that can be held this way within the record.
The constraint 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.
Setting up a DX.TRADING.CONSTRAINT record

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 Transfer Type
l Transaction Status
l Trading Commissions Diagnostics
l Revaluation and Margins
l Back Valuation of Derivatives in Wealth Management
l Securities Portfolio Valuation
l Credit Default Swaps
l Swaption
l Handling premiums in any currency for FX OTC Options trades
l SY Equity Options Pay-out
l Valuation Capture

Trade Capture
DX.TRADE is the main trade capture application for the Derivatives product. It is designed to allow the max-
imum flexibility possible for trading on and off-exchange futures/options. Trade entry in DX.TRADE is
double sided and allows ‘bulk’ trading, where many clients trade with one broker on a single trade.
Derivatives trading may occur in many different circumstances:
l Bank’s customer trades with Bank’s own book.
l Bank’s own book trades with broker.
l Bank’s customer trades direct with broker.
l Broker ‘transfers’ trade to another broker.
l 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 customer 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 VERSION 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 CONTRACT.CODE is entered, DX.TRADE defaults in all relevant information from the
DX.CONTRACT.MASTER record including the exchange traded, type of contract (future, option or stock) and
contract currency.
The TRADE.DATE defaults to the Bank system date, but can be backdated if required. Forward trade dates
are not allowed.
There are two basic types of maturity date entry, daily or monthly corresponding to MATURITY.TYPE on the
contract record. For a daily prompt the date is in the format "dd/mm/yy" or "mm/dd/yy" depending on the
user setting for the date format. For a monthly period the date is in the format "NNNYY" or "MM-YY",
where NNN in the mnemonic for a month, for example; MAR and MM is the numeric month.
Note: To avoid confusion if a numeric month is entered there must be a separator between the
month and the year.
DX.TRADE Record
The MATURITY.DATE field accepts the input in any of these styles. It preserves the exact input date in
MAT.DATE.INPUT for input checking purposes. The actual date stored in MATURITY.DATE is always dis-
played in the format "yyyymm" for monthly contracts and "yyyymmdd" for daily maturity contracts. The
date entered are subject to validation against the parameters set for the contract on
DX.CONTRACT.MASTER
The EXECUTING.BROKER for a trade can be entered if applicable, later used in commission set-ups and
reporting purposes.

Additionally input fields are enabled for option trades. The STRIKE.PRICE or exercise price is entered and
the format is checked, thus an internal strike price is calculated according to the rules in Appendix “Price
Calculation Overview”.
The user must input the option type in the OPTION.TYPE field.
DX.TRADE Record
Upfront Profit Allocation for Options

In order to provide treasury rate functionality the Customer (Primary) and Broker (Secondary) prices/-
premiums on the derivatives trading application can be decoupled. This allows the user to enter a Customer
rate and an internal rate for the trade.
The TREASURY.CUSTOMER field controls the decoupling of the rates, if set as “NO” to denote that Cus-
tomer Price (usually PRI.PRICE) and the Bank/Broker Price (usually SEC.PRICE) are different. Thus allowing
the SEC.PRICE to be entered, 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 are posted to an internal account. This is
defined by the category on a new derivatives accounting event type (DX.EVENT.TYPE, BP Broker/Exchange
Profit).
This is used in conjunction with the Account Officer defined on the trading application.

Customer-Specific Trade Data
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 (CUSTOMER.TYPE in DX.CUSTOMER), the system requires the
input of a SEC.ACC.MASTER portfolio number. Else defaults the first valid portfolio for the customer if no
input is given. This is not required for Broker type customers.
The customer account is defaulted using standard utilities for customers and brokers, but is displayed as an
internal account taking the category from SEC.ACC.MASTER ASSET.CAT for Own Book accounts. This is indic-
ative, rather than the actual account/category code that is used to make own-book postings.
Trades are flagged as opening or closing a position (OPEN.CLOSE) or as speculative or hedge trades for
each customer. If a trade is designated as a hedge for a customer, the user is obliged to enter a description
or reference of the hedged product or instrument in the LINK field.
The ALLOW.SETT field allows the user to remove the particular trade from consideration for automatic clos-
eout of that customer’s position. The trade can be closed out manually also.
The STRATEGY field allows a groups of trades to be linked for reporting or margining purposes and links to
the DX.STRATEGY application.
Derivatives Trade Input

DX.TRADE for FX OTC options
T24 allows the set-up of a Generic contract master for FX OTC Options. A generic contract master will not
have a Trade currency or delivery currency. The Trade and delivery currencies are filled directly in the
DX.TRADE, thereby allowing flexibility to create different FX options using the same contract master.
Details on how to set-up a generic FX OTC Contract master are available here.
A sample screen shot of DX.TRADE is given below.
DX.TRADE

The field TRADE.CCY holds the details of Trade currency.
Input may be one of the following:
l user-defined alpha currency code
l user-defined numeric currency code
Alpha format - This code comprises three alpha characters as defined in the currency table. It is recom-
mended to use the standard SWIFT currency code.
The following are examples of ISO/SWIFT codes:

l USD = US Dollars
l GBP = Pounds Sterling
l DEM = Deutsche Marks
l FRF = French Francs
Numeric format - In most Treasury operations, certain currencies are traded more often that others. It is
time consuming to repeat the three alpha character code each time. Therefore, a numeric ranking
between 1 and 999 is given to the currencies on the "Currency" table. If USD is the most frequently traded
currency, it has the numeric code as "1". The user can enter "1" to access the details of US dollars from the
Currency table.
The currency code entered must appear on the Currency table. Dealing between LU'X' and BE'X' currency
codes is prohibited.
The OPTION.STYLE field populates the rule of settlement of an option according to the type.
Allowed values are AMERICAN/EUROPEAN/CARRIBEAN.
l AMERICAN: An option exercised at any time prior to its expiry date
l EUROPEAN: An option exercised only on its expiry date.
The STRIKE.QUOTE.CCY field, defines the currency in which the strike is be quoted. This must be either
TRADE.CCY or DLV.CCY
The STRIKE.QUOTEfield, defines the Strike in terms of STRIKE.QUOTE.CCY
The STRIKE.PRICE field, defines the price at which an option holder has the right to buy (Call Options) or
sell (Put Options) the underlying instrument, or to cash-settle the option if appropriate, to exercise the
option.
It is a NOINPUT field unless Trade Type is 'OPTION'. For ‘FX-OTC’ options this is again a NOINPUT and the
system calculates the Strike in terms of Trade Currency. Based on the values input in the fields
STRIKE.QUOTE and STRIKE.QUOTE.CCY
The DLV.CCY field holds the delivery currency.
The CCY.BOUGHT field, defaults the currency bought in terms of the own-book (bank side) in an FX-OTC
option trade.
The AMT.BOUGHT field, displays the Amount Bought by own-book (bank side) in an FX OTC Option.
The CCY.SOLD field , defaults the currency sold in terms of the own-book (bank side) in an FX-OTC option
trade.
The AMT.SOLD field, displays the Amount Sold by own-book (bank side) in an FX OTC Option.
If configured, an MT305 SWIFT message will be generated for FX OTC Trades.

Strategy Linking
In order to allow the linking of complex trading strategies, T24 can stamp trades with an automatically gen-
erated Strategy Link number. The PRI/SEC.LINK field on DX.TRADE generates a unique sequence number if
it is 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 has their transaction ID’s held
in a record BUTTERFLY001 in DX.STRATEGY.LINK application.
This functionality can be used for multiple reasons, one of which is the initial margin calculation.
Refer the DX.TRADE application helptext for the field level detailed information.
Strategy Linking

DX.TRADE Record

Commissions and Charges
The commission fields in DX.TRADE displays a summarised form of the commission data. Once a trade is
committed, more detailed analysis of trading commission can be viewed in DX.COMMISSION.DIAGS
There are two main methods of entering trading commission for a customer. They are:
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 the com-
mission collection method.
Automatic commission
The commission fields are updated without intervention from the user when this option is selected. All the
defaulting values are driven by information set-up within DX.COMMISSION
In the example below, the commission system has matched a DX.COMMISSION record to this transaction
and applied both execution and clearing commission. Commission amounts are held in PRI.COMM.AMT
and are calculated at $250 and $375. The ACCOUNT to post the commissions are established in
PRI.COMM.ACC. If the account currency is different from the commission currency, then the exchange rate
used to calculate PRI.CACC.AMT is displayed in PRI.COMM.EXC. The PRI.COMM.TAX field displays the
information of no tax duty levied on this commission.
If the customer for whom commission and charges are being calculated is a broker and another broker is
marked in EXECUTING.BROKER as the executing broker for the trade, then if any execution fees are to be
paid, the account or category for posting the execution fee only is changed to the executing broker’s
account.
Because the values of the trade can ultimately affect the automatic 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.

DX.TRADE Record
Manual Commission
For manual input of customer commission, one of the four different commission types are selected.
Each commission type can be input only once per customer.
The PRI.COMM.CDE (or SEC.COMM.CDE) field allows either of the following:
l A commission code from FT.COMMISSION.TYPE or FT.CHARGE.TYPE
l Or the text “OVERRIDE”
If “OVERRIDE” is entered instead of a commission code, then it is possible to enter the commission cur-
rency, the amount and the posting account.

It is also possible to specify commission as a percentage of contract value/trade cost. In such cases, the
commission is calculated based on the percentage keyed in and the amount is updated in the commission
amount field. The commission amount can be amended as per user requirement.
The following example displays the method being used for customer number 100163, who is on the sec-
ondary side of the trade.

DX.TRADE record
The DX.TRADE application allows the banks to collect commission from customers for exchange traded
futures and options, who have entered into the trade by Exchange Type (Floor or Electronic) or Mode of
transaction (Electronic or Telephone).
A set of multi-valued fields EXCHANGE.TYPE and CHANNEL in DX.TRADE and DX.ORDERare used for this
purpose.

DX.TRADE
l The EXCHANGE.TYPE field holds the types of exchange that are used to enter into the trade.
l The CHANNEL field holds the modes of transaction that are used to enter into the trade.
DX.ORDER
l The EXCHANGE.TYPE field holds the types of exchange that are used to enter into the order.
l The CHANNEL field holds the modes of transaction that are used to enter into the order.
Trading in Centralised Company

The user can have a set-up where all Securities and Derivative Trades take place in a Centralised HUB, for
Portfolios belonging to different Companies (Locations). The PORT.COMP.ID field in SEC.ACC.MASTER holds
the HUB company and the Derivative Trades and Transactions take place only in this HUB Company. The
Portfolio's Own Company is updated in the OWN.COMPANY field in SEC.ACC.MASTER

Based on settings in INTERCO.PARAMETER, the P&L on account of Commissions and Charges is directly
booked to the Portfolio's Own Company. Also, P&L on account of Broker side charges is re-invoiced to the
Portfolio's own company through inter-co accounting entries.
.

Contract Balances
For each DX.TRADE contract of Dealer type, a unique EB.CONTRACT.BALANCES record is updated. This holds
details of the contract currency, balances by asset types, daily movements for each asset types and Consol
key. This file is updated by core accounting process at authorization level.
The workflow is as follows :
l For each DX.TRADE contract, EB.CONTRACT.BALANCES is generated online upon authorization.
However accrual of interest, scheduled 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 A link file RE.CONSOL.CONTRACT is also updated during close of business.

Suppression of Underlying Trades for Options
The SUPPRESS.UNDERLYING field is input in DX Trade to suppress the underlying Trades. This field is defaul-
ted from the DX.CONTRACT.MASTER used in the Trade. If the value is defaulted from
DX.CONTRACT.MASTER or DX.PARAMETER, the user can override and prompt, then the system generates
the underlying trades and vice versa.
Whenever an Option Trade is exercised or assigned, the system validates, if suppress underlying field in
Trade is set to 'YES' or 'NO'. If underlying trade generation is suppressed, then the system does not gen-
erate underlying trades. All other processes remain the same as before. The Option Trade is marked as
'CLOSED'. All Commission and Charges to be collected at settlement are posted. 'DX.TRANSACTION' and
'DX.REP.POSITION' are also updated.

Trade linkages
DX.TRADE captures the Unique Common Reference in the SY.DX.REFERENCE field. Similarly, the user can
input the Common Reference in all Underlying Trades provided from an external system to T24.
The SY.DX.LINK.FILE link file is maintained in T24, with 'SY' or 'DX' reference as ID. It holds all the Trade ref-
erences with the same Unique Common Reference updated in T24.
Similarly, B2B.REFERENCE is entered in the Customers Trades and Counterparty Trade to maintain the link
between the Trades. The Back-to-Back Counterparty Trade can be identified by setting the
COUNTERPARTY.TRADE field to 'YES' in the DX.TRADE application.
Field Name Description

SY.DX.REFERENCE Holds the Common Reference between Option Trade and underlying trades.
B2B.REFERENCE Holds the Back-to-Bank reference that links the Customer Trades and B2B
Trade.
COUNTERPARTY.TRADE Identifies the counterparty B2B Trade.

Order Capture
The Order entry system records 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 date/time when the order is given, inputted and executed. It checks the user's availability of
funds/limits, therefore enabling a trader/credit officer to determine. As a result of the order being
executed, any limits are breached. It alerts the user, if there are constraints applying to that particular cli-
ent/portfolio.
After an order is entered, it can be amended, deleted or executed either manually or automatically. Once
executed fully or partially, 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 are checked for their validity. All orders are reported and the expired orders are
deleted.
The below examples displays 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 through DX.ORDER, with only 20 lots allotted to the second primary cus-
tomer.
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 IHLD.
The Trade is created in LIVE status, if the AUTO.AUTHORISE field in DX.ORDER is set to YES. This is useful
when Orders are executed outside T24 and then fed into the system. Here, Trades can be created in LIVE
without user intervention and to preserve the sanctity of the record.

DX.TRADE Record in HOLD status
Note : The remaining lots can be filled either partially or fully later on.

In the above illustrated flow the presumption is that all filled orders are 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, refer Straight Through Processing section within the Derivatives Configuration guide.
Consolidation of partial fills

Core Banking product can be parameterised to consolidate multiple partial executions, within the exchange
cut-off time, into a single trade for the aggregated lots at the average execution price. The exchange cut-
off time can be specified in the DX.EXCHANGE.MASTER application. This functionality is turned on by setting
the DAY.TRADE field as ‘Yes’. If it is set to ‘No’, each partial execution results in an individual trade.
If the order is fully executed within the exchange cut-off time, the consolidated trade is created at the time
of the last fill. On the other hand if the order is only partial executed, then on the exchange cut-off time the
consolidated trade is created for the filled lots. Any fills happening after the exchange cut-off time would
be part of the subsequent consolidation. The below examples illustrate the consolidation process.
Example 1
1. A GTW order is placed for 100 lots in the SIN exchange. The exchange cut-off time for SIN exchange
is 16:30 hrs. The order gets partially filled as below.
Day Lots Time Price

Day 1 20 11:30 a.m. 10
Day 1 10 11:45 a.m. 11
Day 1 30 12:30 p.m. 12.5
Day 2 40 11:30 a.m. 14
Day 1: At 16:30 hrs, system should generate a Trade for 60 lots.

Price:
Day Lots Price Total Nominal Amount

Day 1 20 10 200
Day 1 10 11 110
Day 1 30 12.5 375
Total 60 685
Average price = 685/60

= 11.416666667
= 11.42 (Rounding to Contract decimal points)

Day 2: At 11:30 a.m., system should generate a Trade for remaining 40 lots as the order is com-
pletely filled. For fully executed orders, Trade generation need not wait till exchange cut-off time
and trade should be generated upon full execution.
Price: - Price on the trade is 14, as it is a single fill after the exchange cut-off time.
Example 2
A GTW order is placed for 100 lots in the NYSE exchange. The exchange cut-off time for NYSE
exchange is 04:30 hrs. The order gets partially filled as below:
Day Lots Time

Day 1 20 20:00
Day 1 10 22:00
Day 1 30 00:30
Day 2 40 05:00
The COB is run at 00:00 hrs.

On Day 2 at 04:30 (exchange cut off time) system should generate a Trade for 60 lots as this is the
cut-off time defined for NYSE Stock Exchange. On Day 2 at 05:00 it should generate the second trade
for 40 lots as this is the full and final fill.
Example 3
A GTD Order is placed for 100 lots in the NYSE exchange. The exchange cut-off time for NYSE
exchange is 04:30 hrs. The order gets partially filled as below:
Day Lots Time

Day 1 20 20:00 p.m.
Day 1 10 22:00 p.m.
Day 1 30 00:30 a.m.
Day 2 40 04:00 a.m.
The COB is run at 00:00 hrs.

On Day 2 at 04:00 system should generate a Trade for 100 lots as this is within the cut-off time.
Note: The exchange cut-off time should be specified in the server time zone and not based
on the time zone of the individual exchanges. Refer to the help text for further details.

Note: If manual commission is specified as a flat amount in the DX.ORDER, each con-
solidated trade will have the same commission amount as the initial order.
Order Workflow
The status of an order undergoes numerous changes during the lifecycle of the order. These statuses are
explained in the below table.
S.No Status Description

1. Open Initial capture of the order in the system.
2. Transmitted The order has been placed with the exchange and the acknowledged by the
exchange.
3. Partial Order has been partially filled, that is, Partial execution.
4. Filled Order is fully executed.
5. Cancellation Request to cancel the pending lots placed with the market.
Request
6. Cancelled Cancellation request accepted by the exchange.
7. Modification Modification of pending lots placed with the exchange.
Request
8. Expired Order is expired.
The possible order workflows are depicted below.
New Order
Order Acknowledgement
Order Rejected

Order Execution
Partially Executed
Fully Executed
Order Cancellation Request
Order Cancellation Acknowledged
Order Cancellation Rejected (Order Status will be reset)

Order Modification
Order Modification Acknowledged
Order Modification Rejected
Note: The order status can be amended manually. (The status will be updated automatically for
a fill order.) The ORDER.AMEND field should be set to ‘Yes’, when there is a change in the order
status. For cancellation and modification, the order lots needs to be updated manually. If the
cancellation/modification request is rejected by the exchange, then the status and order lots
must be set to the earlier value. This would be a manual update.

Order status: Open
Order Status: Partial

Order Status: Rejected
Order Status: Cancelled

Order Status : Modification Request
Order Status : Modification Request
FX OTC Option Order

Orders can be created for an FX OTC Option. A generic Contract Master can be created to handle any Cur-
rency Pair by setting the CONTRACT.CLASS field in DX.CONTRACT.MASTER to one that is defined as FX OTC.
A contract class is set as FX OTC in the DX.CONTRACT.CLASS application.

When a generic FX OTC Contract is created, system does not insist in the Trade and Delivery currency fields
in the DX.CONTRACT.MASTER. These fields can be blank.
The Trade and Delivery Currencies can be given at the time of creating a DX.ORDER or DX.TRADE for such
contracts. Further, the Strike can also be quoted either in terms of Trade Currency or Delivery Currency.
FX OTC Option Order

.

Data Take-on
Using the TRANSFER.TYPE field, the DX.TRADE application allows three types of data take-on, 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 is 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 are used
to capture data about the transfer/legacy system).

Price Capture
This application allows 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 values all the portfolios during the revaluation process using a closing or “fair value” price. For
exchange-based contracts all the exchanges provide an official settlement price also called EDSP (Exchange
Delivery Settlement Price). For OTC options the prices are often manually input, calculated or received
from an external source. Throughout the day, when the contracts are being traded, current (or last) prices
might be received which, if stored, allows 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:
l Manual price input.
l Automatic price feeds (for example, Reuters, Telerate, Telekurs).
l Batch based price downloads (for example, SPAN risk parameter files).
l Ability to call a price model routine and store the returned price (for example, Black & Scholes).
l User created speculative or “What If” prices.
The sources of the prices are set-up using the DX.PRICE.SOURCEapplication, initially only MANUAL prices
are 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 deriv-
atives 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/200406/CALL/97.5//:
CLOSING:/20/GBP/200406/CALL/97.5/USD/E:

Where USD is the Delivery Currency and E is the Option Style
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.
In view of the Complex ID, a Front End application called DX.CREATE.PRICE is available to enable a user to
Manually create new DX.MARKET.PRICE records or to update prices manually in an existing record.
User selects the Price Set, Contract Code, Maturity Date and other details and sets the Quote ccy and Price.
On authorising the record, System automatically creates a DX.MARKET.PRICE record in "LIVE" status. If a
record already exists, then the price is updated in the existing record.
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
l FX OTC Options Price

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 record, 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 under-
lying 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 current market price for a Future or Stock contract the system requires simply that the price
be entered into the contract record, again with the optional update of the INTEREST.RATE and VOLATILITY
of the contact.
Therefore the current price of 94.50 for a December 2004 3MTH EURIBOR Future (12), the
CONTRACT.CODE and PRICE.SET should be entered; the application will then display the price for that con-
tract and price set etc.
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).
Futures/Stock Contracts
.

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 INTEREST.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.MARKET.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 records.
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.

DX.PRICE.SOURCE
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.
DX.PRICE.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.
When are Prices Updated
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.
.

FX OTC Options Price
The fields DELIVERY.CCY and OPTION.STYLE are defined in the DX.MARKET.PRICE application.
DX.MARKET.PRICE
The field DELIVERY.CCY defaults the delivery currency updated by DX.TRADE. It is a user-defined alpha cur-
rency code.
The field OPTION.STYLE holds the first character of option style value in DX.TRADE. Holds the values either
‘A’ for American, ‘E’ for European or ‘C’ for Carribean options.
Below is the sample screen shot of DX.MARKET.PRICE

Third party Valuation and MTM
Third party valuation in T24 is captured in the valuation table named ‘SYDX.MARKET.VAL’, which accepts
the valuation amount for individual deals. The valuation amount is then used to update the ESTIMATION
field in SC.POS.ASSET record, which is the key valuation file in the securities module.
DX.CONTRACT.MASTER
Set the PRICE.SOURCE field in DX.CONTRACT.MASTER as ‘Interfaced’, this indicates that the valuation is
keyed in or interfaced.
For OTC Contracts, bank’s own book is one of the parties to any Derivatives contract. The client side trans-
action are hedged by the bank through a street side transaction with an external counterparty. The booking
model are:

l Client Vs Dealer Book
l Dealer Book Vs Counterparty
The hedge can be a one-to-one Transaction, that is; for each client leg, there can be a street side trans-
action. Or it is also possible to have a many-to-one hedge, that is, many client leg Transactions are hedged
by a single street leg Transaction.
Thus, bank has a position against the client and an opposite position with the counterparty.
Mark To Market (MTM) Accounting entries must be posted to record the unrealised Profit and Loss for the
bank. While unrealised P&L are posted to the P&L Category, the other side is posted to the Balance Sheet
(either to a suspense account or a SPEC entry).
MTM amount, that is, unrealised P&L is derived from the valuation and stored in the MTM.AMOUNT field
in the SYDX.MARKET.VAL application (this MTM.AMOUNT is from the bank’s perspective).
SYDX.MARKET.VAL
The SYDX.MARKET.VAL application is used to record the valuation for a Structured Product deal or a Deriv-
atives contract.
l Record ID - The unique reference and date. Each contract holds a unique reference at the time of con-
tract inception. This unique reference then becomes the key to the valuation table.
l Deal Reference - Holds the SY deal number or DX.TRADE ID.
l Valuation Currency - Specifies the currency associated with the valuation amount.
l Valuation - Specifies the valuation amount in the associated valuation currency.
l Valoren No. - For Equity underlying Structures, VALOREN number is a unique number assigned to the
structure (for example, by Telekurs) which is used subsequently for pricing data.
l Price - For Equity Underlying Structures and Options, if price per unit is available then the valuation is
derived from the price and quantity or lot size.

l Trade date - Date of the trade .
l B2B reference - Back-to-back deal number.
l MTM Amount - Holds the MTM Amount for DX component.
The date in the record ID is the valuation date, therefore for each SY Deal or DX Trade, there is a record for
each day where valuation is received. This facilitates maintenance of valuation and price history.
Records are created in this table, when the SY Deal or the DX Trade is committed with the ID, Unique Refer-
ence Trade date.
The valuation amount entered by the user is used to update the ESTIMATION field in SC.POS.ASSET record.
When a record does not exist for a particular day, then the valuation from the last available record is used
to update the SC.POS.ASSET record.
Note:
l Those DX.TRADEs which are components of a structured product are not valued separately, rather
the composite structure would be valued as a whole.
l In case of direct DX.TRADEs, the DX Trade ID is stored in the deal reference.
l Price per unit or valuation can be a negative value for the some products.
l A derivatives contract is bilateral in nature. That is, the contract is between two parties. The valu-
ation amount updated in this table is interpreted to be from the buyer’s perspective. Therefore the
seller will have the inverse valuation.
l For example, if the DX.TRADE is input between the customer and the dealer book, then the valuation
amount entered (for example, 10 USD) in this application is from the buyer's perspective. That is, the
buyer of the contract is having an unrealised profit of 10 USD and the seller of the contract which is
having an opposing position has an unrealised loss of 10 USD.
This enquiry lists the valuation details. The user can amend the valuation details using this enquiry.

Mark to Market Accounting
The MTM related fields are available in DX.PARAMETER and DX.CONTRACT.MASTER applications.

DX.PARAMETER,INPUT

DX.CONTRACT.MASTER,OPT
The fields in DX.CONTRACT.MASTER defaults from the values in DX.PARAMTER, but it can be amended at
the DX.CONTRACT.MASTER level.
l MTM.REQUIRED - When set to YES alone Mark-to-Market (MTM) entry is posted.
l MTM.METHOD - The allowed values are PROFIT.LOSS and OPTION.VALUE. When set to PROFIT.LOSS,
the difference between trade and market cost is posted. When set to OPTION.VALUE, the entire mar-
ket value is posted.
l MTM.DIFFERENCE - The allowed values are ADJUST and REBOOK. When set to ADJUST, the dif-
ference between previous day and today’s MTM amount is posted as entry. Whereas when set to
REBOOK the previously posted MTM is reversed and the new MTM amount is posted.

l MTM.SPEC - When MTM.SPEC is set to null, Accounting entry are posted to the unrealised profit and
loss category defined in DX.EVENT.TYPE record called 'MT' and to the suspense category (balance
sheet) set in ACCOUNT.CLASS>SUSPDXMTCR or ACCOUNT.CLASS>SUSPDXMTDR.
When MTM.SPEC is set to Yes, balance sheet side entry would be posted as a SPEC entry.

Price Calculation
There are various factors used in the calculation of prices/premiums, given the quoted prices of a contract;
the correct cash value is generated. These factors are usually published by exchanges on a contract-by-con-
tract basis. They are stored in the DX.CONTRACT.MASTER application in T24
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 one tick. A tick used to be the minimum move-
ment in the price of a contract. This is no longer the case as half tick (and other) contracts are modified or
introduced.
Tick Value
This is the resultant change in the value of a contract by a movement of one 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/options contracts
this is 100 that is, decimal. Certain contracts trade in other units such as 32nd that is, a price of 118.20
means 118 and 20/32 units. As a decimal this is 118.625. To distinguish the difference, the decimal point
normally referred to as “spot”, that is, “One hundred and eighteen spot six two five”.
Multiplication Factor
Also known as an “adjustment” factor. This accounts for the 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 40,000 lbs 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 is the total amount that is payable for a futures contract. However, as futures con-
tracts are market-to-market, the price varies daily some of the contract amount are paid or
received throughout the life of the contract. These payments are known as variation margin.
LOT- The number of contracts bought or sold in a transaction. For calculation purposes this is signed,
S 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 is paid at trade time.
PA Premium Amount 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
called "Premium".
QP Quoted price is used internally as the price to calculate the internal price. Refer next section for
more details.
TP Trade Price is the price agreed with the counter party when a transaction is performed.
TS Tick Size
TV Tick Value
VM Variation Margin is the profit or loss on the contract, due to the change in the value price. This is
calculated (normally daily) for futures/options where the premium is not paid at trade time.
VP Value Price is the price at which a position is valued. For exchange traded contracts, it is normally
the market price. For other contracts, it is calculated by the Black and Scholes theoretical option
value model formula.
Calculations
Following are the basic calculations done by the system :
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”. IP is calculated as :
IP = QP / TS * MF * TV
This greatly simplifies and speeds up the calculations of the other figures. Quoted Price (QP) 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
LIFFE - Three 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
BOT - Five 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 113.00
Price
Example Price 116.23 Override generated price difference >
2%
CBOT - Five 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.
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 are simply inserted into the formula where
appropriate.
This is achieved by having different records with different parameters calling the same basic algorithm in
the new ‘internal price calc’ application.
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.

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 single 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. Accordingly, 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 calculated as follows:
1. Futures contract value at 94.000 = $100,000.0000 (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
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
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

SFE 10-Year Treasury Bond Futures
For SFE Treasury Bond futures, the pricing formula can be simplified because there is always an exact num-
ber 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 formula, 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 Clearing-house makes the cal-
culation 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.
.

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 underlying interest rate.
Accordingly, to establish what the dollar value of a futures tick will be at a given price, the following cal-
culations are made:
1. Use the contract valuation formula (as described above) to calculate the underlying value of the con-
tract at the nominated futures price.
2. Apply the same formula to that same futures price minus 0.01 (increase the yield by 0.01%).
3. The difference between the two contract values represents the dollar value of the tick at the nom-
inated 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 are returned as 0.01 and the tick value as whatever the above
calculation yields.

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 Com-
monwealth 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 consists of a capital price of $131.26073690 and accrued interest of
$4.78021978.

90-Day Bank Bill Options
Premiums for options on 90-Day Bank Bill futures are quoted in terms of annual percentage yield (for
example - 0.60% pa or 1.05% pa) with the value of a single point of premium (0.01% pa) calculated by com-
paring 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 is val-
ued 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, there are 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 are both 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 dif-
ferent 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 Com-
monwealth 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 are as follows:
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 has a value of A$136.04095670 per $100 face value (inclusive of accrued
interest). This figure consists 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 num-
ber 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 formula, 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 Clearing-house makes the cal-
culation 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 Cal-
culations
The methodology used to calculate tick values for the 10-Year Treasury Bond Futures is identical to that out-
lined 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 (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 (for example;
0.410% or 0.525%), with the value of a single point of premium (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. Accordingly, 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% are calculated as follows:
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
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
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
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
l Today’s date – 22/06/00.
l Last trading date is the second business day preceding the third Wednesday in the maturity month.
(DX.CONTRACT.MASTER LAST.TRADE = “FCD,+3WE,-2BD”).
l Delivery date is the third Wednesday in the maturity month. If not a business day, step forward until a
business day is found. (DX.CONTRACT.MASTER DELIVERY.DATE = “FCD,+3WE,MF”).
Step 1 – calculate all valid trading months.
Use information stored on DX.CONTRACT.MASTER (refer the previous section dealing with Price/Premium
Terminology).
l Is reference date in a valid maturity month? If so, then…
l 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 for-
mula given) is the 19th. Take reference 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 par-
ticular 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 20th 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 rel-
evant 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 1st 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.

Australian Government Bond SFE Futures and
Options
Although the algorithm and parameters required to produce the internal price for this contract are dif-
ferent 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
.

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 routine is run (as part of the end of exchange processing). Note that a
build routine has been included to automatically populate this data (see section 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/sell positions within the same contract to effect-
ively close the open positions and realise any profit or loss due. Once the settlement is occurred the pos-
ition is closed-out and profit/loss is realised. Commission and charges also due to be paid at settlement
time are also posted.
Within the derivatives module there are two methods of closing out trades:
l The first involves matching opposing buy/sell positions within the same contract to effectively close
the open positions and realise any profit/loss due.
l The second form of closeout occurs when a position is held until maturity. This also results in a pos-
ition 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 effectively settled against a pseudo trade.
For futures, this trade is performed at the Exchange Delivery Settlement Price (EDSP). For options, no
pseudo trades are created. For trades, where premium was not paid at Trade Date, the trades/trans-
actions are closed out against each other on the same way as a manual closeout. Where the
premium is already paid, these are cash settled against the Original Premium Price.
Closeouts are manually, automatically or performed by the system. In the case of manual closeouts, the
user selects a customer and a unique contract. For futures, this involves the specification of a contract code
and a delivery period. For options, this involves the selection of a contract code, a delivery period, a strike
price and the option type (call or put). Additionally, other fields are entered to further restrict the selection
of trades. All the open trades matching these criteria are displayed. The user may then select the trades
and the number lots from each trade which are to be settled. As long as the total numbers of buy lots are
same as the total numbers of sell lots, the close out is confirmed.
Off-set Orders and Close Out
Normally, Exchange Traded Derivative contracts are not held until maturity.
Instead a futures or options, Order is effected to off-set an existing trade or trades and there is no delivery
of the underlying product but a cash settlement of the profit/loss.
The details of the Trade or Trades to be off-set by the order is captured at the time of Order input. Upon
filling the Order in the Market, the system creates a Trade and simultaneously closes out this against the
existing Trade, thus off-setting the position.

l ORDER.CLOSEOUT - Mandatory field which accepts values.
OPEN – If set to "Open", no change to current processing. Default is "OPEN'.
CLOSE - If set to "Close", then a DX.TRADE of the Trade which is to be off-set (Closed Out) is filled in
the CLOSEOUT.TRADE field.
l CLOSEOUT.TRADE – A valid DX.TRADE ID. This is the ID of the Trade that needs to be off-set.
Note : The system does not validate at this stage, if the Trade matches the Order that is
being input. It is for the User to key in the correct ID. However, a context enquiry is
provided against the field to list trades that can be off-set by this order.
The version to be used for creating the Automatic Closeout record, needs to be specified in the
CLOSEOUT.VERSION field in DX.PARAMETER
DX.CLOSEOUT
The DX.CLOSEOUT application is the central application for the processing of closeouts within the T24 deriv-
atives module. Once a closeout is 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 external
source). Once a closeout is created in the DX.CLOSEOUT application, it can be authorised, deleted or

reversed in the same way as any normal T24 application function. Because of the nature of closeouts the
user cannot re-run a history record closeout; instead the user must run a new closeout.
From the closeout application, the user is able to access the information regarding that specific closeout. A
closeout marked as RUNNING in the STATUS field denotes that the closeout is created and processing is still
running. An ACTIVE is a closeout that has occurred, that is, the trades are matched and the closeout is now
waiting for authorisation. Closeout marked as DELETED in STATUS field can be reversed.
The closeout type denotes the style of closeout. SETTLEMENT closeouts are basic manual closeouts per-
formed by the system. MATURITY closeouts are cash maturity settlements. Exercise, Expiry and Assignment
are Option Actions, which are to be handled by the closeout suite.
The creation of the DX.CLOSEOUT record identifies how the closeout was created/requested. The user can
run a MANUAL CREATION. AUTO (Automatic) using the enquiry DX.CO.MANUAL.BRWSand
DX.CO.MATURITY.BRWS, when they want the system to automatically close out a position available in later
phases of implementation. The SYSTEM closeouts are closeouts generated by the system under a specific
set of circumstances.
The ACCOUNT identified on the record is the account where the profit and loss/option premium are posted
for this closeout.

A Typical Closeout record
Closeouts are performed against each leg of the closeout separately. T24 can also be configured to clos-
eout both sides of the deal automatically - refer the section on back to back closeouts in the Derivatives Con-
figuration 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
There are two DX.CO.MANUAL enquiries, one for options and the another for stocks and futures.
DX.CO.MANUAL.OPTION.BRWS and DX.CO.MANUAL.FUTURE.BRWS are in essence the same apart from val-
idation and field layout differences. Run the relevant enquiry to process a new manual closeout, for
example ENQ DX.CO.MANUAL.FUTURE.BRWS
The user selects a customer and a unique contract. For futures this involves the specification of a contract
code and a delivery period. For options this involves 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 further restrict the
selection of trades.
Futures Manual Closeout Enquiry

All the open trades matching this criterion are displayed. The user confirms if the trades selected are those
from which they want to process the closeout, and selects the number of lots from each trade 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 can be
committed. A screen is displayed with the total profit/loss on the trades being “closed out” and listing the
options to create an authorised or unauthorised DX.CLOSEOUT record.

If the user wants to create an unauthorised DX.CLOSEOUT record, then he needs to authorise the record so
that the system can generate the realised profit and loss entries. However, an authorized record auto-
matically generates these entries.
Once the settlement is confirmed the closeout engine reports the current closeout ID, profit/loss of this clos-
eout and any commission charged as part of this closeout.
Generated Manual Closeout

The closeout key reported is a key to the master closeout record held in DX.CLOSEOUT
The lots chosen for closing is processed through the DX.TRANSACTION application in the TRA.PND.SETT and
TRA.PND.LOTS field. These fields holds the closeout key and the number of lots pending to closeout.
Futures Manual Unauthorised Closeout record

During trade, the PRI.PND.SETT/SEC.PND.SETT and PRI.PND.LOTS/SEC.PND.LOTS fields are also updated to
display the number lots pending for settlement.
Futures Transaction with Settled Primary Lots
Note: The user cannot directly input into the DX.CLOSEOUT application using function I, the can
only Authorise, Delete, or Reverse a Closeout. After authorising the closeout the number of open
lots in the DX.TRADE and DX.TRANSACTION records are decremented and the closeout details
are moved to DX.TRANSACTION TRASETTNOS and DX.TRADE PRI.SETTNOS /SET.SETTNOS fields.
Any Commissions, Profit or loss for the closeout are 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
l The SETT.ALLOWED field is set to YES, to allow settlement or closeout on this exchange, or NO to dis-
able or Blank defaulting to YES.
DX.CUSTOMER
l The AU.CT.CLASS field is set to FUTURES, OPTIONS, BOTH OR NONE.
l The AU.SETT.TYPE field is set to FIFO (first in first out), LIFO (last in first out) or FIFO.DAY (today
trades take precedence).
l The AU.SETT.DELAY field is set to the no.of.days after trade when settlement/closeout can occur.
DX.CONTRACT.MASTER
l The SETT.ALLOWED field is set to YES, to allow settlement or closeout, NO not to allow or Blank to
default to the Exchange Master setting.
DX.TRADE
l The XXX.ALLOW.SETT field is set to YES, to allow settlement or closeout, NO to prohibit auto or sys-
tem 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 : If the user is done through an End of Exchange process, only trades for that exchange are
considered for settlement. The system selects 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 tries to match any trades following the rules specified for
auto closeout.

Maturity Closeout
There are two DX.CO.MATURITY enquiries, one for options and another for stocks and futures. The ENQ
DX.CO.MATURITY.OPTION.BRWS and ENQ DX.CO.MATURITY.FUTURE.BRWS are similar to the
DX.CO.MANUAL enquiries (apart from validation and field layout differences). Run the relevant enquiry to
process a new maturity/cash settlement closeout, for examples sample inputs for the enquiries
DX.CO.MATURITY.FUTURE.BRWS and DX.CO.MATURITY.OPTION.BRWS respectively are shown below.
Futures Maturity Closeout Enquiry
Option Maturity Closeout Enquiry

The user selects a customer, unique contract and maturity date. For options, he selects a strike price/option
type (Call/Put).
Additionally, other fields may be entered to further restrict the selection of trades. All the open trades
matching these criteria are displayed.
The closeout application is essentially the same as the one used for manual closeouts, however the number
of buy and sell lots need not match, and a maturity price field is present. The user then selects the trades
and the number of lots from each trade are to be settled before committing the record.
Futures Maturity input for Market price

Once a maturity price is entered, the settlement is confirmed as either to produce an Authorised or Unau-
thorised Closeout record.
Once the settlement is authorised the closeout engine reports back the current closeout ID, profit/loss of
this closeout 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 does 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, if the user wishes to close out a transaction of a Sell of 25 Lots of Dec00 (CME) GBP Cur-
rency 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 transaction is automatically created as a pseudo transaction; it does not phys-
ically 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:
l 25 Lots X Internal Price = USD 2,225,781.25
l 25 Lots X Internal Price = USD 2,250,000.00
l 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 section.

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.
Note : For options contracts there are no maturity price field available in the closeout applic-
ation. Unlike manual closeouts, the number of lots closed out for buys and sells need not be
equal.
Options Maturity Closeout Selection Application

The profit and loss figure for this closeout is in fact the amount of option premium for this contract remain-
ing outstanding to be paid at settlement.
Option Closeout Confirmations

This below screenshot displays the number of lots pending and the closeout for which they are pending. It
also displays the details of what the Charge Date was at Trade time, which means that for this transaction,
there is no profit and loss to post.
Transaction Record of a Transaction Being Used As Part of the Closeout

This displays the related DX.CLOSEOUT 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 section.

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. It can be an automatic process where the system does the selection. Regardless of
the method used to select the transactions, the underlying processing are identical. If the options are being
exercised or assigned, the appropriate underlying transaction are also created.
Note : Automatic assignment is not supported as T24 cannot intuitively understand how many
lots are assigned (this can only be done manually).
For details on setup, please see the Automatic Expiry or Exercise section within the Derivatives Con-
figuration 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 con-
tract 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 3 months Eurodollar Option has EXER.PRI.MEM set to a value of 1.0000
2. Customer buys 200309 3 months Eurodollar 95.00 Calls
3. No manual actions are performed against the DX.TRADE during its life and the DEC.DATE for the con-
tract 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 occurs in the next COB and the DX.TRADE remains ACTIVE.
If the underlying product is a futures contract, the appropriate derivatives trade is automatically created by
the system. If the underlying is a stock, a system call to the SECURITIES module is made to create the under-
lying stock transaction. If the option exercises to CASH, a system call to the FOREX module is made to cre-

ate a Spot FX transaction.
Manual Processing
The functionality is invoked as an enquiry selection under three enquiries DX.CO.MANUAL.EXPIRE.BRWS,
DX.CO.MANUAL.EXERCISE.BRWS and DX.CO.MANUAL.ASSIGN.BRWS.
This involves the selection of a Portfolio or Customer ID, a Contract Code, a Maturity Date, an Option type
(Call or Put) and a Strike Price. As this is a standard T24 enquiry, other fields may be added to restrict the
trades’ selection. All the open trades matching the selection criteria are displayed for the user to select the
trades and the number of lots from each which is to be processed.
Note : This process may take place at any time of the day with the restriction that only one ses-
sion is in progress.
l Manual Assignment
l Manual Exercise
l Manual Expiry

Manual Assignment
The DX.CO.ASSIGN.MANUAL application is used to manually assign an option. The DX.CO.ASSIGN.MANUAL
application supports pay-out in cash. It also supports settlement in the underlying security as well as set-
tlement in an alternate instrument. The inputs required for cash settlement of options and for settlement in
alternate instrument is keyed in the DX.CO.ASSIGN.MANUAL application
l SETTLEMENT.CCY - The currency of the cash pay-out will be updated in this field.
l SETTLEMENT.AMOUNT - For cash settled options, the cash pay-out calculated by the system (by com-
paring the spot price of the underlying against the strike price). This can be amended by the user.
Cash entry would be generated for this amount when the closeout is processed.
l MARKET.PRICE Holds the market price of the underlying security at the time of assignment
l CASH.SETTLE.CCY - Holds the delivery currency for the options with underlying as SECURITY.MASTER
when the SETTLEMENT.METHOD is CASH. The exchange rate between this currency and contract cur-
rency is defined in DLV.CCY.RATE field.
l DLV.CCY.RATE - Holds the exchange rate between contract and delivery currency.
l SETTLE.INSTRUMENT - The alternate settlement instrument which is settled on exercise.
l SETT.INSTR.CONT.SIZE - The contract size of the alternate settlement instrument which is mandatory
when settled using alternate underlying.
l SETT.INSTR.PRICE - The price of the alternate settlement instrument which is mandatory when
settled using alternate underlying.
l QUOTE.CCY - The currency in which the SPOT.EXCHANGE.RATE is quoted.
l SPOT.EXCHANGE.RATE - Holds the current exchange rate between the currency pairs of an FX option
quoted in the QUOTE.CCY.
l FX.PAYOUT.CCY - Currency in which the pay-out is to be made.
l SPOT.PAYOUT.RATE - Holds the exchange rate between QUOTE.CCY and FX.PAYOUT.CCY

The DX.CO.MANUAL.ASSIGN.BRWS enquiry allows the user to manually choose the options to assign.

DX.CO.MANUAL.ASSIGN.BRWS Enquiry
According to the selection criteria, the trades and the number of lots assigned before commitment are dis-
played.
Trades displayed from DX.CO.MANUAL.ASSIGN.BRWS Enquiry
Manual Assign record

The Closeout process on authorisation, removes these options from the open position and makes any neces-
sary postings.

Note : These postings include premiums for contracts with posting at settlement time.
Manual Option Assignment Closeout

Furthermore, depending on the nature of the underlying product, a corresponding transaction in HOLD
status is generated in its related module.
Underlying Product Trade

Future A DX trade for the future
Cash A FX transaction
Bond or Stock A SEC trade
Transaction types created on closeout

Manual Exercise
Options can be manually exercised using the DX.CO.EXERCISE.MANUAL application. This application sup-
ports cash settlement and physical settlement. Additionally it supports settlement in alternate instrument as
well. The inputs required for cash settlement of options and for settlement in alternate instrument is keyed
in the DX.CO.EXERCISE.MANUAL application.
l SETTLEMENT.CCY – The currency of the cash pay-out will be updated in this field.
l SETTLEMENT.AMOUNT – For cash settled options, the cash pay-out calculated by the system (by com-
paring the spot price of the underlying against the strike price). This can be amended by the user.
Cash entry would be generated for this amount when the closeout is processed.
l MARKET.PRICE - Holds the market price of the underlying security at the time of exercise
l SETT.INSTR.PRICE - The price of the alternate settlement instrument which is mandatory when settled
using alternate underlying.
l FX.PAYOUT.CCY - Currency in which the pay-out is to be made.
l SPOT.PAYOUT.RATE - Holds the exchange rate between QUOTE.CCY and FX.PAYOUT.CCY.

Using the DX.CO.MANUAL.EXERCISE.BRWS enquiry, the user can manually choose the options to exercise.

Manually choose and display trades
The trades are displayed, according to the selection criteria.
The user can select the transactions and the number of lots to be expired before committing the selection.
Displaying trades for selecting lots to exercise

Corresponding closeout record
The Closeout process, on authorisation, removes these options from the open position and make any neces-
sary 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 product, a corresponding transaction in HOLD
status is generated in its related module.
If a DX.CLOSEOUT record resulting from an exercise option with an underlying future is reversed, the child
record for the underlying future in IHLD is deleted, or if it is already been authorised it is set as RNAU.
Refer to the ENQUIRY DX.MONITOR.STP.PROCESS if there is any problem.
Underlying Product Trade

Future A DX trade for the future
Cash A FX transaction
Bond or Stock A SEC trade
Transaction type created on closeout

Manual Expiry
Using the enquiry DX.CO.MANUAL.EXPIRE.BRWS, the user can manually choose which options to expire.
Manually choose which options to expire

According to the selection criteria, 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 authorizing the manual expiry the close out (expiry) is done through the service
DX.CO.EXP.MANUAL.SERVICE, which removes these options from the open position and make any necessary
postings.
Note: The postings include premiums for contracts with posting 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. Pro-
cessing is similar to the equivalent manual application, except that the user may wish to automatically
authorise the closeout. Authorisation of DX.CLOSEOUT is needed for the processing to continue if Unau-
thorised 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

Automatic Exercise - DX.CO.EXERCISE.AUTO
This application is used to select and exercise a set of trades satisfying the selection criteria. Depending on
the settlement method defined in DX.CONTRACT.MASTER, it supports pay-out in cash or as an alternate set-
tlement instrument. The STRIKE.OPERAND field can be used to select a range of trades with different strike
prices.
l STRIKE.OPERAND - Allows the user to select the trades based on the strike quote provided.
l STRIKE.QUOTE - Holds the strike price in the quote currency which is STRIKE.QUOTE in trade.
l MARKET.PRICE - Holds the market price of the security at the time of exercise.
l FX.PAYOUT.CCY - Currency in which the payout is to be made.

l TRANS.ID - Holds DX.TRANSACTION reference which gets selected based on the conditions given in
selection fields. Value to the field gets defaulted only when SETTLEMENT.METHOD in contract mas-
ter is set to CASH.
l SETTLEMENT.CCY - Holds the delivery currency for equity options cash payout and FX.PAYOUT.CCY
for FX options cash payout.
l SETTLEMENT.AMOUNT - Holds the cash payout amount calculated in settlement account currency,
that is, in the SETTLEMENT.CCY field.

Automatic Option Exercise
Automatic Assignment - DX.CO.ASSIGN.AUTO

This differs from Exercise and Expiry in that, as well as specifying the unique contract the user has to indic-
ate the total number of lots to be allocated.
The system, using the assignment method stated on the contract master record, assigns the lots to the selec-
ted trades. The trades and lot details are then passed to the assignment process in the same way as the
manual process.
l STRIKE.OPERAND - Allows the user to select the trades based on the strike quote provided.
l STRIKE.QUOTE - Holds the strike price in the quote currency which is STRIKE.QUOTE in trade.
l MARKET.PRICE - Holds the market price of the security at the time of exercise.
l DLV.CCY.RATE - Holds the exchange rate between contract currency and delivery currency.
l SETTLE.INSTRUMENT - The alternate settlement instrument which is settled on assignment.
l FX.PAYOUT.CCY - Currency in which the payout is to be made.
l TRANS.ID - Holds DX.TRANSACTION reference which gets selected based on the conditions given in
selection fields. Value to the field gets defaulted only when SETTLEMENT.METHOD in contract mas-
ter is set to CASH.
l SETTLEMENT.CCY - Holds the delivery currency for equity options cash payout and FX.PAYOUT.CCY
for FX options cash payout.
l SETTLEMENT.AMOUNT - Holds the cash payout amount calculated in settlement account currency,
that is, in the SETTLEMENT.CCY field.

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, that is DEC.DATE = “TODAY”. It also checks that the client or trade is not set up to hold options
open for a certain number of days. Then based on the strike price, the underlying price and the price dif-

ferences defined in the DX.CONTRACT.MASTER, the system determines if each option trade must be exer-
cised, expired or “left alone”.
Note : System assignment of Options is not supported, as it cannot automatically determine

accurately the number of lots that the bank has been assigned.
FX OTC Options
The FX OTC Options are exercised and expired through the applications DX.CO.EXERCISE.AUTO and
DX.CO.EXPIRE.AUTO
DX.CO.EXERCISE.AUTO
l The field CONTRACT.CCY specifies the contract currency of option to be exercised. The currency must
be a valid currency in CURRENCY table and it is a mandatory field for FX-OTC options.
l The field DELIVERY.CCY specifies the delivery currency of option to be exercised. The currency must
DX.CO.EXPIRE.AUTO
l The field CONTRACT.CCY specifies the contract currency of option to be expired. The currency must
l The field DELIVERY.CCY specifies the delivery currency of option to be expired. The currency must be
a valid currency in CURRENCY table and it is a mandatory field for FX-OTC options.

Trade Transfer
Derivatives module allows the transfer of trades between portfolios and customers, both internally and
externally. These transfers can be performed 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 authorization of the DX.CO.XFER.MANUALor DX.CO.EXT.XFER.MANUAL records,
DX.CLOSEOUT record is created to reflect the trade transfers.
The following new DX.EVENT.TYPErecords are setup:
l CN – Internal Transfer (Transferor Side)
l II – Internal Transfer (Transferee Side)
l CO – External Transfer (Outgoing)
l 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 is 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 transfer a new DX.CLOSEOUT record is generated and when committed removes the pos-
ition on the Transferors side.
To action the transfer the DX.CLOSEOUT record generated must be authorised by another user.
The positions held is now between the Transferee 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 an internal transfer, including the creation of a new DX.CLOSEOUT
record which must be authorised.
On authorising the DX.CLOSEOUT record the system removes the internal position for the transferor and
generates an delivery message setup in DX.EVENT.TYPE CO and generates 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 transaction automatically generates between the transferor and the transferee for
the number of lots defined in the DX.CO.XFER.MANUAL record at the price defined in PRICE.TRADED field.
When committing the transfer, new DX.CLOSEOUT record is also generated and removes the position on
the Transferor’s side. Positions held is between the Transferee and the original counterparty.
For external transfers DX.CO.EXT.XFER.MANUAL application is used. On authorizing the DX.CLOSEOUT
record, the internal position for the transferor is removed and a delivery message is generated.
The user can use the DX.CO.EXT.XFER.MANUAL application to perform external transfers.
DX.CO.EXT.XFER.MANUAL Record

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 application. 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 application DX.ENTITLEMENT acts in the same way as the Securities
ENTITLEMENT application.
DX.ENTITLEMENT displays the Customer/portfolio entitlements per DX.DIARY event.
Each maturity and strike is shown with the new strike, contract size and number of lots.
Records are created through DX.DIARY. They are created as unauthorised.
The authorisation of these records is controlled by DX.ENT.ACTION

Derivatives Option Entitlements Record
Entitlement authorisation takes place using DX.ENT.ACTION, which runs an automated authorisation of
DX.ENTITLEMENTS as per DX. DIARY event.
If the EX.DATE is arrived or passed, then the DX.ENTITLEMENT records can be authorised.

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 (for
example, 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/down or no rounding is called if
required.
When the contract size changes as a result of the Corporate Action, then a new contract for the new option
series must be created to trade in the future (as the contract size is likely to be different for the original
option series).
The problem of not being able to do closeout because of the two different contract sizes, is eliminated by
keeping the original series and creating a new one.
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.
DX.CONTRACT.MASTER
The following fields are used for this process ROUNDING, RND.FACTOR, LINK.CONT.ID and
LAST.VALID.DATE
l Values allowed in the ROUNDING field are STANDARD, ROUND and UP
l When STANDARD is specified RND.FACTOR field is not required, as this is validated by the system
l When UP or DOWN is specified, the value stored in RND.FACTOR field is the value the STRIKE.PRICE is
be rounded to
l The LINK.CONT.ID field specifies the new option series that the system creates and LAST.VALID.DATE
field indicates the last trading date. This option series can be trade.

DX.CONTRACT.MASTER Rounding Factor
DX.TRADE and DX.ORDER

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
DX.DIARY
When processing Corporate Actions in the Derivatives Module, the user creates one record in DX.DIARY per
Corporate Action, in which the parameters defining the Corporate Action are set. This includes ratios
describing changes in Contract Size, Strike Price and Number of Lots.
The option to create a new contract is also chosen here.
The fields include ROUNDING, RND.FACTOR, CREATE.CONT.Y.N, NEW.CONT.MNE and NEW.EXCH.CODE
DX.DIARY rounding factor
The ROUNDING and RND.FACTOR fields take defaults from DX.CONTRACT.MASTER record.
The CREATE.CONT.Y.N field 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 depends 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 the user needs to
l Ensure using the ratios input, that if the amended contract size is not an exact multiple of the original
one, a warning is displayed to tell the user to create a new contract.
l The processing of the NEW.CONT.CODE and NEW.CONT.SIZE fields stays unchanged.
If this field in set to YES, then
l If a NEW.CONT.MNE is 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, cal-
culating 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.
DX.ENTITLEMENT
On Authorisation of these records created from the DX.DIARY the individual DX.TRADEs and their under-
lying 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 is amended to include derivatives transactions, where the Derivatives
module is installed.
There are three types of entry into the CUSTOMER.POSITION file - DX, DXVM and DXIM. These being the
transaction values, the variation margin values for the transaction and the initial margin value for the cus-
tomer respectively.
l Plain DX items reports the contingent value of a transaction, the maturity date, the value date and
category along with many other data.
l The DXVM items reports the Variation Margin figure generated by the end of exchange revaluation
process, along with other data.
l The DXIM items reports the Initial margin figures for that user. There is only one of these items per
user, as Initial Margin cannot be broken down into transaction by transaction based figure as it relies
on a group of trades.
Note: That the DXVM items are only available after an end of exchange revaluation is taken place. The
DXIM figures does not take into account any transaction not included in the last end of exchange revalu-
ation.
Example CUSTOMER.POSITION Listing

Example CUSTOMER.POSITION record

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 format.
It holds details of the summary trading position for the customer/contract/date including net lots open and
separate buy/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 drill down fields to allow access to the underlying transactions and hence the original
trade record if required.
The average price of the position is also calculated and held on the DX.REP.POSITION record, using the cal-
culation specified in DX.PARAMETER AVE.PRICE.METHOD (refer 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 portfolio/customer number to
identify the ‘side’ of the parent transaction it is associated with and a version number to keep track of
changes to the transaction.Old versions are retained.
All transactions in the Derivatives module are recorded in DX.TRANSACTION

When recording trades, most of the customer dependant data in the trade record is reproduced in
DX.TRANSACTION for reporting purposes.
DX.TRANSACTION record

DX.TRANSACTION holds trade details on a customer-by-customer basis, that is, a simple trade between two
customers generate two DX.TRANSACTION records, whilst a bulk trade between ten customers and one
broker builds 11 DX.TRANSACTION records.
As a general example, the initial entry and validation of a derivative trade involving three customers and
one broker produces entries in DX.TRANSACTION as shown on the right.
If the trade were deleted before authorisation, all the DX.TRANSACTION records raised are also be deleted.
The transactions remain unaltered on authorisation of the trade.
Portfolio 100018-1: DXTRyydddnnnnn.100018-1.1

Broker 110010: DXTRyydddnnnnn.110010.1
If the trade is amended. Upon validation of the amendment a new set of transactions are created.
Note : New transactions are created for all participants in a trade with consistent sequence numbers, even
if the ‘side’ of the trade associated with a particular customer/portfolio is not changed.

Broker 110010: DXTRyydddnnnnn.110010.2
The ‘old’ set of transactions on the trade has REVERSAL.DATE field set to the current bank date and remains
in the file.
If the amendment were to add a further portfolio to the customer side of the trade, a new transaction is
created as follows:
Added portfolio 100060-5: DXTRyydddnnnnn.100060-5.2
That is, 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 deleted, only the new transactions
that are raised for the unauthorised amendment must be removed from the transaction files. The set of
transactions ‘belonging’ to the authorised (unchanged) version of the trade must be reinstated, that is,
REVERSAL.DATE and REVERSAL.TIME fields must be set to null.

In the case of the reversal of an authorised trade (or settlement), updating the transaction file and the asso-
ciated routines occurs only at authorisation of the reversal. When this happens, the current set of
DX.TRANSACTION records associated with the parent trade have their REVERSAL.DATE fields updated with
the current bank date and REVERSAL.TIME fields set to the current time, but they are NOT removed from
the DX.TRANSACTION file.
If a reversed record is restored from history (on verification of history restore, record goes into HNAU
status in unauthorised file ), the latest set of transactions belonging to the transaction must have
REVERSAL.DATE and REVERSAL.TIME fields set to null.
DX.TRANSACTION list showing history of the record

Transfer Type
Transfers generally occur either as a result of trading, open position moving to a new clearer, customer
preference to move positions within their portfolios or a bank moving to a new banking platform.
Trading Transfers
Trading Transfers occur when a customer uses different brokers for execution and clearing. That is, Broker
A executes the trade on exchange and then "gives-up" the trade to Broker B (the clearing member), for sub-
sequent processing.
l Broker A receives the execution commission/charges, but at the end of the day Broker A does not
have a position.
l Broker B receives the clearing commission charges and holds the open position at the end of the day.
Entering a trade with a different execution broker (BROKER A) to the secondary customer must generate
the correct charges and obviously the secondary customer (BROKER B) holds the open position.
New Clearer
Some customers wish to; or be forced to; move their open positions to a new clearing member. For
example, to get better deals or if the clearing member is closing down.
In this case, the open positions are moved in or out of T24, however there is generally no financial implic-
ations.
In the case of options with premiums paid up front, the premium must not be recharged, as it would be in a
new trade that was entered.
No P&L is generated when the position is "closed out", it is transferred and the P&L is generated later. P&L
generated in the existing life of the position (variation margin) is already posted in the cash account. These
are also known as TRANSFER-IN and TRANSFER-OUT types. An alternative type RVPDVP (Receipt Versus Pay-
ment, Delivery Versus Payment) supports stock options.
Changing Portfolios
A customer may hold a certain position in one portfolio and may wish to move them to another one of his
portfolios or move the position to a different customer. This scenario occurs if the user has different port-
folios for futures and options. When an option is exercised, a new underlying future is created in the
"option" portfolio. This can be moved into the "futures" portfolio. These transactions are supported by
TRANSFER.INC and TRANSFER.INC.PAY types.
New platform

If a bank goes live on T24, from their old version, it must load the open positions into T24. The New Clearer,
premiums and variation margin are posted earlier and formed a part of the account balance transfer. The
position being transferred must have a new P&L, that is, calculated at the transfer price (generally the pre-
vious day’s closing price). These types of transfers are TAKEON and TAKEON-CONT. The TAKEON-CONT
includes the contingent entries for a bank's own position
Using the TRANSFER.TYPE field, the DX.TRADE application, allows three types of data take-on, they are:
TAKEON (for legacy trade entry), TAKEON-CONT (for legacy own-book trade entry), and RVPDVP (for trans-
fers of trades into a position without affecting account postings etc.).
The TAKEON and RVPDVP fields are used during data migration for take-on of Customer Trades. No entries
and messages are posted and sent.
The TAKEON-CONT field is used for takeover of Own Book Trades. System generates only CRF entries and
no messages are sent.
Where TRANSFER.TYPE is 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
In addition to TAKE ON, the Transfer type fields are as follows:
l The TRANSFER field gets updated in TRANSFER.TYPE for the trades generated from internal trans-
fers.
l The TRANSFER.INC and TRANSFER.INC.PAY fields moves the trade/position from one portfolio to
another.
l The TRANSFER.INC field is used for informative / reporting purpose only. System does not generate
any entries or messages.
l The TRANSFER.INC.PAYfield generates entries and advices when the fields FEE and ADVICE are set to
YES.
l The EXECUTION, CLEARING, SWITCH and BOTH fields are used for informative / reporting purpose.
These fields behave as normal trade.
All other fields on the trade are entered as normal (though narrative and external reference fields may be
used to capture data about the transfer/legacy system).

.

Transaction Status
DX.ITEM.STATUS records the activity against derivative transactions and displays the current and previous
status of the transaction.
The ID for each record on this file corresponds to the underlying DX.TRADE that is being recorded, that is,
DXTRA060101234
Each activity that reports to DX.ITEM.STATUS creates a new multivalued data set on the record.
The activity corresponds to a defined DX.ITEM.STATUS.TYPE, where enrichments are added to describe the
status.
With each new status update (NEW, AUT, AMD), the application also records the DATE, TIME, USER and
APPLICATION (DX.TRADE, DX.ORDER or DX.CLOSEOUT) associated to the activity.
The CURR.STATUS is displayed in the first multivalued set . Previous activities displayed in chronological
order thereafter by STATUS.
DX.ITEM.STATUS.TYPE(s)

The above screenshot displays the DX.ITEM.STATUS record resulting from a NEW trade which is entered
and retained in INAU status.
When the trade is in INAU status, the following holds true:
Curr Status Denotes the last status of the application (NEW, AMD, AUT, REV, AUR)
Curr Date Denotes the date when the trade is punched
Curr Time Denotes the time of the trade
Curr User The user who input the trade
Curr Application Denotes which application has been used.
DX.ITEM.STATUS record
The user can amend the trade, commit and authorise the changes. The DX.ITEM.STATUS record is displayed
as shown below.

DX.ITEM.STATUS record

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 customers or brokers. The code to DX.COMMISSION.DIAGS is a combination of
the key to DX.TRADE suffixed with the customer number. The respective commission records are updated
every time a trade is input or amended by DX.TRADE. No history of individual changes is maintained, so
once a change to commission is saved on the trade, the new diagnostics overwrites the previous details for
that customer.
The live file holds commission irrespective of whether the commission was input manually into the trade or
generated automatically by matching criteria on DX.COMMISSION. In the latter case, the
COMMISSION.CODE field is updated with the key from DX.COMMISSION
Commission is displayed with different commission types to make reporting easier.
Each type displays the following information:

l Commission currency
l Account where commission is posted
l Currency of the posting account
l Exchange rate (if commission currency is different from the account currency)
l Commission or Charge code
l Any taxes associated with the commission
Commission types Diagnostic field descriptions

COMMISSION COMM…
EXECUTION EXFE…
CLEARING CLFE…
REGULATORY RGFE
MISC MISC…
Commission/Fee Diagnostic Information

This example displays the commission charges relating to customer number 110018 for trade
DXTRA0324100001
The field names beginning with “EXFE…”, indicates that EXECUTION is the commission type category.
The commission is automatically generated for this customer with charges taken from a customer group
DX.COMMISSION record, --DEALERS-

Derivatives Trading Commission
The other customer involved in the trade 100163, has three different types of commission charges entered
that is, EXECUTION, CLEARING and REGULATORY. These are inputted manually into the trade.

Derivatives Trading Commission

Revaluation and Margins
A part functionality of the derivatives module is to re-calculate the value of customer or portfolios after the
exchanges are closed. This can either be done as part of the overnight batch utility or as an on-line process.
Revaluation is invoked in different modes and produces different events. The base of this module forms
part of the end of exchange process and therefore is the part of the end of day processing for the module.
The revaluation module allows valuation, accounting and reporting of futures/stock and options held in the
T24 derivatives system. Following are the different reasons to undergo revaluation process :
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 calculation process is same. The differences are the products to be val-
ued, the prices they are valued against and the resultant accounting treatment of the figures produced.
Therefore along with the core revaluation process additional modules are written around it, which are
called as required.
The core revaluation process consists of two major functions: initial margin and variation margin alloc-
ation. Additional processes include retrieval/calculation or prices, retrieval of trades, posting of accounting
entries and reporting of results. These additional processes are added into close of business
(DX.COB.WORKFILE) as required.
Refer the Derivatives Configuration User Guide, for more details on how to configure Initial Margin cal-
culation and Variation Margin calculation
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 customer, portfolio or group. This
depends on the event which 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 revaluation level RE.VALUE.LEVEL set in DX.REVALUE
l For an end of exchange the key is structured using a customer ID.
The below screenshot defines the margins for all contracts held by the Customer "110018".
This record details the figures held in the currencies in which they were calculated, and the
BASE.CURRENCY for that customer held in DX.CUSTOMER REPORTING.CCY.
It also holds the exchange rates used to convert these amounts.
The details in the record is also a link down to the next level of reporting.
EXCHANGE.KEYS holds all the keys of the DX.REVALUE.EXCHANGE records, that combines to make the
DX.REVALUE.SUMMARY record.
DX Revaluation Summary Record

.

Revaluation for Exchange
The DX.REVALUE.EXCHANGE file details the total margin amounts for a customer, portfolio or group in a
currency on an exchange. This key is dependent on the event that triggers 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 revaluation 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. For example,
DXEOE003644*4*GBP*50030
The margins on USD contracts held on Exchange 2 for Customer 110018 are detailed below:
The exchange record details a number of group information.
l A link to the revaluation detail files, the keys of and the application names relating to those keys.
l The total margin figures for this currency and exchange.
l The combined commodities used and their constituent DX.CONTRACT.MASTER contracts.
l The margin totals on a contract-by-contract 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 exist-
ing 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 is 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 file holds the data required to calculate the standard initial margin on a group of transactions in the
derivatives system; these transactions are grouped by exchange, by strategy, by contract, and by cus-
tomer/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 file holds the data required to calculate the standard variation margin on a transaction in the deriv-
atives 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 displayed 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
Currently, there are two other initial margin routines available with the derivatives module: EURONEXT-
AEX and OCC.TIMS. Their detail filenames are DX.REVAL.DET.EURONEXT and DX.REVAL.DET.OCC
The details are 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 EURONEXT method as do a number of other exchanges throughout the world.
The example displays a list of EURONEXT margin calculation.
EURONEXT Margin Calculation

As with the previous methods the DX.REVAL.DET (NNN) application files, provides the user with details of
which values are used in the calculation of the margin. Therefore if there are any discrepancies the user
can do a manual check, 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 are input and authorised, the revaluation process passes control to the “Grey
Box” processes.
DX Revaluation record
The selection criteria has 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 Cus-
tomers, 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 the user 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.REVALUE.EXCHANGE is to be stored. This allows the system to
calculate the total margins for either; a PORTFOLIO, a CUSTOMER, or a CUSTOMER group.
The user must set-up a revaluation, to create a new DX.REVALUE record and then define which cus-
tomers/trades must be revalued. Revaluation records cannot be re-used. The processing begins 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, with a published standard and add it to the Derivatives module with the minimum effort.
Note: Also to simplify the Temenos development of future margining algorithms, this allows
flexible local and customer driven development of new routines without core development
involvement.
For all margining algorithms used, diagnostic information are created and stored so that it allows easy jus-
tification of the figures produced.
l AEX Euronext
l OCC/TIMS Margining

AEX Euronext
Margin requirements applies to investors who write uncovered options. No margin is required for the writ-
ing of covered call options or the purchase of options.
Amsterdam Exchanges option market (Euronext) prescribes minimum margin requirements for uncovered
writing of options. Margin requirements 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 exercise price is generally lower than the market price of the underlying
value. If the writer of the call option 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 is generally 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. Therefore monthly changes are
possible. However, Euronext may decide to change margin percentages at other times. In this event Eur-
onext will publish 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.EXCHANGE.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, SYNTHETIC.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.CONTRACT.MASTER in INIT.MARGIN.CALC - Input must be EURONEXT

DX.CONTRACT.MASTER in INIT.MARGIN.CALC input should be EURONEXT
6. DX.TRADE - The user must 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 - To 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 transactions. In order 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 must 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 cal-
culated 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 CONTRACT - Define by “band”, that is, 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 contracts respectively by percentage,
for example 0.35, 3 and 3.5 and minimum for example 0.05, 0.5 and 0.5

Interest Contract
LINKING OF TRANSACTIONS
This is done by noting the link number generated from the first transaction for the strategy being
used. Then for the other transaction that is being strategically linked to the first one, the same link and
strategy must be input. This is the way the system identifies the strategy linkage.
DX.TRADE (linking transactions)

Use DX.REVAL.DET.OCC.TIMS (List) to view the margin details.

Back Valuation of Derivatives
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.MARKET.PRICE.HISTORY file can be changed or created only if the price set is
defined in the DX.PARAMETER and date stamp is within the period defined in DX.PARAMETER to store his-
torical 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 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 hap-
pens, 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 include items relating to transaction-based deals within the Derivatives module.
Every trade relating to a portfolio requested is included and only portfolio trades are included.
Example SC.POS.ASSET listing

The data extracted from the DX module are the latest up-to-date data, all transactions are included once
they are authorised. Where it is possible to update on a Position/Transactional basis, it is anticipated that a
positional update is 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.

Credit Default Swaps
Overview
A Credit Default Swap (CDS) is a financial swap agreement, where the seller of the CDS compensates the
buyer in the event of a loan default or other credit event. The buyer of the CDS makes a series of payments
(the CDS "fee" or "spread" or “premium”) to the seller and in exchange receives a payoff if the loan
defaults. In the event of default the buyer of the CDS receives compensation (usually the face value of the
loan), and the seller of the CDS takes possession of the defaulted loan.
In T24, a CDS is captured using the Derivatives (DX) module.
Note: This user guide contains field names and field labels matched in a tabular column in the
respective sections.
DX.CONTRACT.CLASS
The Contract class application defines a contract class for Credit Default Swap (CDS) by setting the Con-
tract Type field to CDS.
DX.CONTRACT.CLASS
DX.CONTRACT.MASTER

This application holds the contract definitions of the contract types that are tradable in the DX module. A
CDS Contract Master can be created by setting the Underlying field to OTHER and Contract Class field to a
Contract Class that is defined as CDS.
The DELIVERY.METHOD field is mandatory and must only be set as PHYSICAL. It must be noted that on Exer-
cise of a CDS contract, system automatically raises entries to Debit or Credit the bank’s P&L and pay or
receive the amount of the Contract.
Physical delivery of the Underlying bond or instrument is not handled and is done manually, if required.
Price Details tab provides the information about pricing methods. The values of the fields Tick Size and Tick
Value must be 1.0000 and the field Min Price Mvmt must be 0.0001
Contract Dates tab provides the information about Maturity type.The Maturity Type is Daily or Monthly.
For more information refer DX.CONTRACT.MASTER

Calculation tab provides the information about premium posting. The Prem Post Time field determines the
type of payment. It is mandatory to input Prem Post Time as Trade, since initial premium is posted at the
time of trade.
The OPTION.TYPE field (Exotic Events allowed) must have a valid DX.OPTION.TYPE record. This is essential
because there is only one generic DX.CONTRACT.MASTER for all CDS contracts. Each CDS is uniquely iden-
tified only in the DX.TRADE application based on the underlying and other details. If the
DX.CONTRACT.MASTER is not set as EXOTIC, then only single DX.MARKET.PRICE record is created for all
CDS contracts and it is not possible to update the price and valuation details for different contracts.
By setting the Contract Master as an Exotic contract and by creating a DX.OPTION.TYPE that captures
some details to distinguish each type of Contract, it is possible to capture separate Price and Valuation.
Below is one Option type which updates the Trade ID, thereby creating a separate DX.MARKET.PRICE
record for each CDS TRADE.

Field Names Field Label
UNDERLYING SECURITY Underlying Bond
AS.CURRENCY Bond Currency
AS.PRINCIPAL Bond Value

Commission tab holds the commission details of the contract.

PREM.PAY.FUTURE Prem Pay Future
PREM.PAY.PERCENTAGE Percentage Premium
PREM.PERCENT Premium Percentage
PREM.PYMT.AMT Premium Amt
PREM.PYMT.DATE Premium date

When Prem Pay Future is set to YES and premium details are input, system will post the premium entries
on the respective dates. Once the first premium is received, then the Premium Frequency, Premium Date
and Premium Amt fields cannot be amended. The fields will be unavailable for user input.
When Prem Pay Future is set to NO, user can still input future premiums to be received. However, all
accounting entries will be posted immediately on trade date with forward VALUE.DATEs.
Note: Reversal of trade is disallowed once the first premium is paid.
When Percentage Premium is set to YES and Premium Frequency is input, the Premium date and
Premium Amt gets calculated automatically (based on the premium percentage and notional amount).
When Percentage Premium is set to NO, the Premium Percentage field will be unavailable for user input.
Future Premium date and Premium Amt will have to be manually input.
Exotics tab holds the Transaction id information of the contract. The Exotic Fld Val .1 holds the unique trans-
action id that gets defaulted in DX.MARKET.PRICE
DX.PREMIUM.DETS

Swaptions
Overview
Swaption (an option of the underlying SWAP), is one of the most traded Derivative Contracts. Though
options can be traded on variety of swaps, the term ‘Swaption’ typically refers to options on interest rate
swaps. Typically, a counterparty trading swaption can either be a buyer or seller of Swaption.
Two types of Swaption contracts are:
1. A payer Swaption gives the buyer of swaption the right to enter into a swap, where fixed leg is paid
and floating leg is received.
2. A receiver swaption gives the owner of Swaption the right to enter into a swap, where fixed leg is
received and floating leg is paid.
Buyer and Seller of Swaption agree on the following:
1. premium (price) of Swaption.
2. length of the option period.
3. the terms of the underlying swap, including: notional amount.
4. the fixed rate (which equals the strike of the Swaption).
5. the frequency of observation for the floating leg of swap.
In T24, a SWAPTION contract is captured through the DX - Derivatives module. The module supports the fol-
lowing:
1. Trade capture.
2. Multiple premium processing on specific value date.
3. Delivery confirmations.
Note: This user guide contains field names and field labels matched in a tabular column in the
respective sections.
DX.CONTRACT.CLASS
The Contract Class application defines a contract class for SWAPTION, by setting the Contract Type field to
Swaption.

DX.CONTRACT.CLASS
DX.CONTRACT.MASTER
The Contract Master application holds the contract definitions of the contract types that are tradable in the
derivatives module. The Contract Master application creates a Swaption contract by setting the Underlying
field to OTHER and Contract Class field to one that is set as SWAPTION.
The DELIVERY.METHOD field is mandatory and must only be set as PHYSICAL. It must be noted that on Exer-
cise of a Swaption contract, system will not automatically create a SWAP. If a physical SWAP is to be cre-
ated, the same has to be done manually and the ID of the SWAP can be updated in the DX.TRADE for future
tracking.

Exotics
DX.TRADE

PAY.TYPE Pay Rate Type
RECEIVE.TYPE Receive Rate Type
AS.CURRENCY Currency
AS.PRINCIPAL Notional Amt
AS.FIXED.RATE Fixed Rate
AS.FLOAT.KEY Float Key
LB.CURRENCY Currency
LB.PRINCIPAL Notional Amt
LB.FIXED.RATE Fixed Rate
LB.FLOAT.KEY Float Key
AS.INT.FREQUENCY Int Frequency
AS.RR.FREQ Rate.Reset.Freq

PREM.PAY.FUTURE Prem Pay Future
PREM.PAY.PERCENTAGE Percentage Premium
PREM.PERCENT Premium Percentage
PREM.PYMT.AMT Premium Amt
PREM.PYMT.DATE Premium date
When first premium is paid , then the Premium Frequency, Premium Date and Premium Amt fields are
unavailable for user input.
When Prem Pay Future is set to YES and when the trade is authorised, the premium amount gets updated
in DX.PREMIUM.DETS. The premium amount is then paid in the Start Of Day (SOD) process. When Prem
Pay Future is set to NO, the premium is posted on trade date with Premium Date as VALUE.DATE.
Note: Reversal of trade is disallowed once the first premium is paid.
When Percentage Premium is set to YES and Premium Frequency is input, the Premium Amt (based on
the premium percentage and notional amount) and Premium date gets calculated accordingly. When Per-
centage Premium is set to NO, the Premium Percentage field will be unavailable for user input.

The Premium Percentage field holds a valid percentage. The percentage is considered as percentage per
annum.
Premium
Exotics tab holds the Transaction id information of the contract. The Exotic Fld Val .1 holds the unique trans-
action id that gets defaulted in DX.MARKET.PRICE
Exotics

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 identifies that an order or a trade is a FX OTC Options based on the following:
l EXCHANGE.TYPE field of DX.EXCHANGE.MASTER is ‘OTC’
l UNDERLYING field in DX.CONTRACT.MASTER is set to CASH
l Value in fields, CONTRACT.CCY and DLV.CCY in DX.ORDER or DX.TRADE are currencies and not pre-
cious metals
The following fields cater to the requirement of collection of premium at Trade level:
l PRI.PRICE: Premium quoted in PIPS in contract currency
l PRI.TRADE.COST: Total premium amount in contract currency
l PRI.PREMIUM.CCY: Currency in which the premium is denominated. If not defined by User, the cur-
rency of the PRI.ACCOUNT is defaulted.
l PRI.PREM.PRICE: Premium quoted in PIPS in premium currency
l PRI.PREM.EXCH.RATE: Exchange rate between premium currency and contract currency. Defaulted
from the currency table if not defined by the User
l PRI.TOTAL.PREM: Total premium amount denominated in premium currency (Premium amount X
Contract size X No. of lots)
l PRI.ACCOUNT: Account used to pay/receive the total premium amount (can be in any currency). If
not defined by User, Account corresponding to the Premium Currency is defaulted. If no Account
exists in the premium currency, the first Account in SEC.ACC.MASTER is defaulted. The user can over-
ride 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 updates the other related fields. The fol-
lowing defaults/validations is done by the system:
l PRI.PREMIUM.CCY must be inputted by the user and if left blank, is defaulted with the currency of the
PRI.ACCOUNT

l When PRI.PREMIUM.CCY is input by the user, PRI.ACCOUNT is 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 is defaulted.
l Override is generated by the system, if the user inputs PRI.PREMIUM.CCY and PRI.ACCOUNT cur-
rency differs.
l PRI.PREM.EXCH.RATE is defaulted as “1”, when the PRI.PREMIUM.CCY and the CONTRACT.CCY are
same and is a no input field.
l PRI.TOTAL.PREM field accepts value in terms of amount denominated in PRI.PREMIUM.CCY. In this
case, system populates PRI.PREMIUM.PRICE and PRI.PRICE.
l When either PRI.PREMIUM.CCY or PRI.PREM.EXCH.RATE is amended, the price/premium related
fields are cleared by the system prompting the user to input the values again.
l Primary side of DX.TRADE or DX.ORDER does not accepts more than one customer ID and error is
thrown by the system if input by the user.
Depending on which side the CUSTOMER represents in the DX.TRADE, the above mentioned fields must be
related either to PRI or SEC.

For treasury customers, the premium related field values at the secondary side is defaulted from the
primary side. For non-treasury customers, the premium related fields at the secondary side must be input.

Basket Options
Basket Options would be traded through the DX module. Both Equity and Currency baskets are supported.
Functionality is available to book a trade with
l Single Notional in reference/base currency
l Multiptle Currency pairs/securities
l Multiple strike prices
Core Banking also supports processing of lifecycle events such as:
l Exercise
l Expiry
Setup
DX.CONTRACT.CLASS
The field CONTRACT.TYPE in the table DX.CONTRACT.CLASS will allow the value ‘Basket’, indicating that
this is a basket option class.
DX.CONTRACT.MASTER
It is required to create a Generic contract master with CONTRACT.CLASS set to one which is defined as a
basket.
When this is defined, the following fields in DX.CONTRACT.MASTER will work as under:
UNDERLYING: This field will be defaulted with the value ‘Basket’.
PRICE.SOURCE: Defaults to ‘Interface’.
TICK.VALUE: Defaults to ‘1’
TICK.SIZE: Defaults to ‘1’
CONTRACT.SIZE: Defaults to ‘1’
CURRENCY: Will be no-input
DELIVERY.CURRENCY: Will be no-input
SETTLEMENT.METHOD: Will be no-input
CONTRACT.SIZE: Will be no-inpu
EXCHANGE: Not mandatory
OPTION.STYLE: Not mandatory
Trading

DX.CONTRACT.TERMS
This application will allow creation of frequently traded baskets.
It will have the following fields. The Basket can be linked to the trade and values from the basket will
default to the trade. Note: If values are given here, they will default to the Trade. Else the values can be spe-
cified in the individual trades.
S.No Field Description
1. @ID Alphanumeric Text

2. MNEMONIC Alternate identifier for identifying the basket.
3. UNIQUE.INDENTIFER Unique identifier such as Ad Valoren number can be recorded here.
4. ULYING.ASSET.CLASS Mandatory. Accepts the following drop down values
l Equity
l Currency
5. BASKET.TYPE This field will take the following values

l NULL
l Equal-weighted
l Custom-weighted
l Best-of-the-basket
l Worst-of-the-basket
Default value would be NULL. NULL indicates that this is not a Basket
Option.
While currently 4 types of Baskets are envisaged, the list of BASKET.TYPE
should be scalable and hence the list should be defined as an EB.LOOKUP
field.
6. PRICE.SOURCE Interface: This will override PRICE.SOURCE set at DX.CONTRACT.MASTER
7. CALL.PUT Accepts the values

l CALL
l PUT
8. TRADE.CCY Trade currency.

9. MATURITY.DATE Maturity date of the option

S.No Field Description
10. SETTLEMENT.METHOD Accepts the following values.

l Physical
l Cash
11. STATIC.LEG Mandatory if it is a Currency Basket. It will accept values CALL.CCY or

PUT.CCY. This leg will then have to be the same in all the multi-values.
12. ULYING.SECURITY Mandatory if ULYING.ASSET.CLASS is Equity.Either underlying (equity bas-
ket) or CALL.CCY/PUT.CCY (currency basket) is mandatory. The fields
from UNDERLYING to STRIKE is part of an associate multi value set.
13. CALL.CCY Mandatory if ULYING.ASSET.CLASS is Currency This is the currency , the
customer(Primary side) will buy in the FX spot deal
14. PUT.CCY Mandatory if ULYING.ASSET.CLASS is Currency.This is the currency , the
customer(Primary side) will sell in the FX spot deal
15. WEIGHT Weight of the currency pair or the underlying in this basket.
16. STRIKE.PERCENTAGE Either STRIKE.PERCENTAGE or STRIKE is mandatory. Applicable when,
strike is expressed as a percentage of spot rate.
17. ULYING.STRIKE.CCY This is applicable for currency basket, this is the currency in which the
exchange rate is quoted.
18 ULYING.STRIKE.PRICE Strike price of the currency pair/underlying.
DX.TRADE
When the contract being traded is a “Basket”, DX.TRADE will allow multiple underlying to be defined.
CONTRACT.TERMS Yes Baskets, defined in DX.CONTRACT.TERMS, can be linked to the trade,

through this field. This is not mandatory. If Contract Terms is given, the
details will default from the DX.CONTRACT.TERMS and cannot be
changed. If DX.CONTRACT.TERMS is not given, then the basket details
can be input directly in the Trade.
SETTLEMENT.METHOD Existing field. Will Default from DX.CONTRACT.TERMS
BASKET.TYPE Yes Defaults from DX.CONTRACT.TERMS
ULYING.ASSET.CLASS Yes Accepts the following drop down values Equity Currency
STATIC.LEG Mandatory if it is a Currency Basket. It will accept values CALL.CCY or
PUT.CCY. This leg will then have to be the same in all the multi-values.

ULYING.SECURITY Yes Underlying would default from the DX.CONTRACT.TERMS. This would be
a no input field. The fields from ULYING.SECURITY to PUT.AMOUNT are
part of an associated multi value set. The number of multi value cor-
responds to the number of equites/currency pairs in the basket.
CALL.CCY Yes This is the currency, the customer will buy in the FX spot deal. Defaults
from DX.CONTRACT.TERMS.
PUT.CCY Yes This is the currency , the customer will sell in the FX spot deal. Defaults
from DX.CONTRACT.TERMS
WEIGHT Yes Weight of the currency pair or equity in the basket. Defaults from
DX.CONTRACT.TERMS.
SPOT.PRICE Yes Spot price of the underlying equity/ exchange rate of the associated cur-
rency pair.
STRIKE.PERCENTAGE Yes Strike denoted as a percentage of the spot price.
ULYING.STRIKE.CCY Yes This is applicable only for currency basket. This is the currency in which
the exchange rate is quoted.
ULYING.STRIKE.PRICE Yes Strike price of the associated currency pair/equity.
EXERCISE Yes. This field is used to trigger the settlement of physically settled basket.
For an equity basket, setting this field to yes would indicate a SEC.TRADE
to be created for the associated underlying on exercise of the basket
option. The price in SEC.TRADE would be the associated strike price and
Nominals in the SEC.TRADE would be the associated quantity. For a cur-
rency basket, setting this field to yes would indicate a FX deal needs to
be created for the associated currency pair.
QUANTITY Yes. Associated multi value set. In case of the physical delivery this field
would hold the number of shares to be delivered of this underlying.
Applicable only for physical delivery method. Mandatory for equity bas-
ket when field EXERCISE is set to ‘Yes.
CALL.AMOUNT Yes Associated multi value set. In case of the physical delivery this field
would hold amount the customer receives in the CALL.CCY. Applicable
only for physical delivery method. Mandatory for currency basket when
field EXERCISE is set to ‘Yes.
PUT.AMOUNT Yes Associated multi value set. In case of the physical delivery this field
would hold amount the customer pays in the PUT.CCY. Applicable only
for physical delivery method. Mandatory for currency basket when field
EXERCISE is set to ‘Yes.

CASH.EXERCISE Yes. This field is used for generating cash payouts If this field is set to yes at
the time of exercise, a cash pay-out will be triggered for the amount spe-
cified in the CASH.AMOUNT field and in the currency specified in
CASH.CCY field. Applicable only for cash settled baskets.
CASH.AMOUNT Yes This field holds the cash amount that needs to be paid out for a cash
settled option.
CASH.CCY Yes This field holds the currency corresponding to the CASH.AMOUNT field.
If the field CONTRACT.TERMS is updated, then the values from the corresponding DX.CONTRACT.TERMS
record will be populated and cannot be amended. Alternatively the terms can be directly keyed in the
DX.TRADE application.
Exotic fields will be disabled for Basket Options
PRICE and VALUATION

T24 will not calculate the price of Basket options.
Valuation/Market price will be per contract and keyed in to the SYDX.MARKET.VAL application.
MATURITY
At the time of maturity, the EXERCISE flag needs to be set for each underlying (in case of physical delivery)
or the CASH.EXERCISE flag needs to be set in case of cash payout. If the exercise flag is set, then SEC.TRADE
would be created for the associated underlying. For example, if a basket has 5 underlying securities and the
exercise flag is set for 3 underlying securities, 3 SEC.TRADEs will be created. If the CASH.EXERCISE flag is
set, then a cash pay-out will be generated. If neither the EXERCISE flag nor the CASH.EXERCISE flag is set at
the time of maturity processing, then this would be equivalent to an option expiry. A combination of Cash
payout and physical settlement will also be possible. (For Eg:-, For a physically settled basket, cash payout
can be used for fractional shares).
POSITION.UPDATES
DX.REP.POSITION will be updated for Basket options. The ID would contain the Trade ID as all baskets use
the same generic contract master.
Further, a new field is introduced in DX.REP.POSITION and will hold the DX.CONTRACT.TERMS relevant to
this position, if available.
Each position would be unique and will represent 1 basket
CORPORATE.ACTIONS
The DX.DIARY application would be enhanced to handle a corporate action on any of the underlying secur-
ities in an Equity Basket, which requires a change in the Strike Price of that underlying.
The existing CONTRACT.CODE field would also accept a DX.CONTRACT.TERMS record. If this is given, sys-
tem would identify all DX.TRADES based on these Contract Terms and correct the Strike price AND/OR Lots
of the Equity undergoing corporate action.

If due to a “conversion’ event, the underlying security changes, then this too can be updated in the
DX.DIARY and system would identify the DX.TRADES and correct the Underlying Security field.
ACCOUNTING
Contingent entries for Notional amount will be raised for Own Book Trades. Entries for Premium and
Charges will be raised as currently done in DX.TRADE.
LIMIT UPDATES
Limit can be updated for Basket Options. For the Option Buyer, the Limit outstanding will be adjusted to the
extent of the Premium amount. For an Option Seller, the Limit outstanding will be adjusted to the extent of
the Notional.

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 deliv-
ery messages (in SWIFT 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 processed, that is
DX.TRADE is entered, amended or reversed.
Delivery messages are also generated, when a DX.CLOSEOUT is performed. The content of all delivery mes-
sages are based on the DX.TRANSACTION file.
Messages can be produced for any action including corporate actions/option exercise/assignments etc.
Any new event added to the module is therefore automatically available as having a possible link into the
deliveries module.
Derivatives Event Type Record

Until the EB.ACTIVITY field in DX.EVENT.TYPE is populated with a delivery activity to perform, the system
does generate any delivery messages.
Once a selection of a DX.EVENT.TYPE is populated 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 inform-
ation, using the same basic defaulting as the FOREX application. This information is used as part of the deriv-
atives originated Swift Messages.
Note : 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 par-
ticular 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
l SWIFT MT305
l SWIFT MT306
l SWIFT MT601

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.
A basic setup is done to create the following EB.ACTIVITY records.
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.
They are assigned to the relevant DX.EVENT.TYPE records in EB.ACTIVITY field once they are created.
Every time the event is processed in the central DX transaction processing a message is 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 indicates whether the fields are mandatory or optional. Some basic example
DE.MESSAGE records are 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 4040.DX.1. These example records are released as shown below.
DE.MAPPING records Details

4000.DX.1 Trade Input
4010.DX.1 Trade Amendment
4020.DX.1 Trade Reversal
4040.DX.1 Closeout confirmation
Additionally, full 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

DE.MESSAGE record
DE.MESSAGE record
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 records 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.

SWIFT MT305
SWIFT MT305 messages are exchanged to confirm plain vanilla foreign currency option contracts
MT305 message is generated for the following events:
l Foreign Currency option contract (DX.TRADE) is Authorised.
l Foreign Currency option contract (DX.TRADE) is Amended.
l Foreign Currency option contract (DX.TRADE) is Reversed.
For exotic Foreign Currency Contracts, MT306 is generated. That is, the option either has exotic features
(EXOTIC.TYPE field in DX.TRADE is not null) or it is non-deliverable (Cash settled).
Note: SWIFT tag related information needs to be populated in the DX.TRADE application for the
message to be generated correctly. Refer to the help text for the SWIFT related fields.

SWIFT MT306
SWIFT MT306 messages are exchanged to confirm foreign currency option contracts, which are exotic in
nature. That is, the option either has exotic features (EXOTIC.TYPE field in DX.TRADE is not null) or it is non-
deliverable (Cash settled).
MT306 message is generated for the following events:
l Foreign Currency option contract (DX.TRADE) is Authorised.
l Foreign Currency option contract (DX.TRADE) is Amended.
l Foreign Currency option contract (DX.TRADE) is Reversed.
For plain vanilla Foreign Currency Contracts, MT305 is generated.

SWIFT MT601
SWIFT MT601 messages are exchanged to confirm commodity option contracts. That is, Currency option
contracts, where one of the currency is defined as a Precious Metal.
l Precious Metal option contract (DX.TRADE) is Authorised.
l Precious Metal option contract (DX.TRADE) is Amended.
l Precious Metal option contract (DX.TRADE) is Reversed.
Note: If the user configures Exotic and Precious Metal option for a contract, then MT601 SWIFT
message is generated by default.

Delivery
SWIFT (MT202)
In Swaption contract, a SWIFT confirmation message (MT202) is generated on each premium payment.

Delivery
SWIFT (MT202)
In CDS contract, a SWIFT confirmation message (MT202) is generated on each premium payment.

Credit Default Swaps - Enquiries
CDS Net Position
ENQ DX.CDS.NET.POSITION
DX.CDS.NET.POSITION enquiry lists the Net CDS Position with the following information: Portfolio valu-
ation, Client’s security position, Trade details and Bond details.
OUTSTANDING PREMIUM
ENQ DX.PREMIUM.PENDING
DX.PREMIUM.PENDING enquiry lists the premium outstanding amounts along with the dates. The user can
also view the Initial Premium Paid, Initial Premium Percentage and the Total Premium value.
PREMIUM RECEIVED
ENQ DX.PREMIUM.RECEIVED
DX.PREMIUM.RECEIVED enquiry lists the premium received along with the Trade Status. The user can also
view the Initial Premium and the Total Premium value.

Swaption - Enquiries
Net Swaption Position
ENQ DX.SWAPTION.POSITION
DX.SWAPTION.POSITION enquiry lists the Net Swaption Position with the following information: Rates and
Portfolio valuation along with the contract details.
SWAPTION IN/OUT OF MONEY

ENQ DX.OPTION.MONEY.SWAPTION
DX.OPTION.MONEY.SWAPTION enquiry lists the in and out money of Swaptions.

Common Link Reference
List of Back-to-Back Trades
This enquiry lists the Trades with similar B2B reference. The user can check the contracts that have a Back-
to-Back Trade reference and reconcile the differences if any.
List of Linked Trades

This enquiry lists the linked Trades with Common Unique Reference. If underlying trade is not traceable
due to the missing Common Reference or a wrong reference, the users can manually map and update the
same.

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 checks the availability of an authorized credit line for the customers involved with the trade. In real-
time, the LIMIT system is designed to monitor the availability and utilization of customer limits. Back end
reports are available to allow the monitoring of limits for commodities, countries, country group and cur-
rencies. 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, for example, Futures and Options Limit.
For different products, the Limits also allows fine-tuning of products into sub-products. Therefore limits can
be set up for different classes of contracts, for example, 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 occurs for a relevant
derivative product/portfolio, a limit check is done and generates an override if a limit is exceeded.
Choosing an option from LIM.AMT.VAL.CONT on DX.PARAMETER sets the amount used to update limit util-
isation.
l Contingent
Calculates a value based on the amount specified in CONTINGENT.VALUE on DX.CONTRACT.MASTER
Number of lots 'x' contingent value
l Value
Calculates a value based on the following principles:
Future : Number of lots x internal price.
Option Buyer : Number of lots x internal price.
Option Seller : Number of lots x internal strike price.
Selecting calculation type for updating Limits

DX.TRADE links a limit reference to each customer on both ‘primary’ 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 be defined in LIMIT.REFERENCE
The basic limit structure for Bond Futures linked under a more general product definition of Futures are
shown in the below screens.
Refer the Limits user guide, for more analysis of limit structures.
Sub-product LIMIT.REFERENCE
Product LIMIT.REFERENCE
The choice of which limit reference is selected for a customer is controlled from the criteria established in
LIMIT.PARAMETER.

The below screenshot explains how different limits can be set for Currency Futures, Bond Futures and Cur-
rency Futures by testing values from TRADE.TYPE and CONTRACT.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 dif-
ferences between sides need to be taken into account. This typically applies when processing 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” relates the tests solely to customers on the secondary side of the trade.
In this example, the PRI.HEDGE.TRADE field equal to “HEDGE” defaults the limit reference to 4554 for a cus-
tomer on the primary side of DX.TRADE
If SEC.HEDGE.TRADE field is not equal to blank, it defaults the limit reference to 4555 for a customer on the
secondary side of DX.TRADE
Once the LIMIT is established for a particular customer, the system is able to use this information to ensure
that the limit is not exceeded.
If the transaction causes excess, the user must decide whether the excess is to be allowed.
Likewise, if a credit line is not been set up already, an override is raised to create a system generated limit.

LIMIT.PARAMETER showing defaulting limits for secondary side customers
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.
Note: Sell trades have the same impact on utilisation as buy trades, that is, sells are not ‘can-
celled’ 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,
That is, 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
That is, 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 provides a notification of the event to the LIMIT sys-
tem, which resets the utilization figures.

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 checks the availability of an authorized credit line for the customers involved with the trade. In real-
time, the LIMIT system is designed to monitor the availability and utilization of customer limits. Back end
reports are available to allow the monitoring of limits for commodities, countries, country group and cur-
rencies. 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, for example, Futures and Options Limit.
For different products, the Limits also allows fine-tuning of products into sub-products. Therefore limits can
be set up for different classes of contracts, for example, 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 occurs for a relevant
derivative product/portfolio, a limit check is done and generates an override if a limit is exceeded.
Choosing an option from LIM.AMT.VAL.CONT on DX.PARAMETER sets the amount used to update limit util-
isation.
l Contingent
Calculates a value based on the amount specified in CONTINGENT.VALUE on DX.CONTRACT.MASTER
Number of lots 'x' contingent value
l Value
Calculates a value based on the following principles:
Future : Number of lots x internal price.
Option Buyer : Number of lots x internal price.
Option Seller : Number of lots x internal strike price.
Selecting calculation type for updating Limits

DX.TRADE links a limit reference to each customer on both ‘primary’ 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 be defined in LIMIT.REFERENCE
The basic limit structure for Bond Futures linked under a more general product definition of Futures are
shown in the below screens.
Refer the Limits user guide, for more analysis of limit structures.
Sub-product LIMIT.REFERENCE
Product LIMIT.REFERENCE
The choice of which limit reference is selected for a customer is controlled from the criteria established in
LIMIT.PARAMETER.

The below screenshot explains how different limits can be set for Currency Futures, Bond Futures and Cur-
rency Futures by testing values from TRADE.TYPE and CONTRACT.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 dif-
ferences between sides need to be taken into account. This typically applies when processing 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” relates the tests solely to customers on the secondary side of the trade.
In this example, the PRI.HEDGE.TRADE field equal to “HEDGE” defaults the limit reference to 4554 for a cus-
tomer on the primary side of DX.TRADE
If SEC.HEDGE.TRADE field is not equal to blank, it defaults the limit reference to 4555 for a customer on the
secondary side of DX.TRADE
Once the LIMIT is established for a particular customer, the system is able to use this information to ensure
that the limit is not exceeded.
If the transaction causes excess, the user must decide whether the excess is to be allowed.
Likewise, if a credit line is not been set up already, an override is raised to create a system generated limit.

LIMIT.PARAMETER showing defaulting limits for secondary side customers
l Example Limit Setup

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 Pro-
cessing.
While running a Close of Business the user can input DX.ORDER and DX.TRADEdeals. Users are not 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.CLOSEOUT) 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 validated 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 trans-
action 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 com-
plete 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 com-
pletion 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.

Services
This section describes background services and Close of Business for Derivatives, this is a part of the Treas-
ury suite.
The Derivatives product is 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 business 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 (COB) 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 results in six discrete threads being pro-
cessed, one for each Customer/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 position 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 derivatives 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 applic-
ation 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 allows the flexible local and client-driven devel-
opment 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 routines are initially 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.PARAMETER field HLD.REVAL.DAYS) on the work file
is negative, then it moves to "History".
Note : If no position is held during COB processing, the Countdown field is reduced by a value of
'1'.
An On-line revaluation for one or more such combinations is requested while the COB revaluation is done
automatically during the close old business processing. In order to process the revaluation, 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 reports that Service is not running, and/or the following error :
”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 user must first create the record and then “Verify” to trigger the request for the tSA service to launch
the revaluation process. This then updates 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, for example, “No Market Price Found for 100324*/15/EUR/200309/CALL/130.0*"
After rectifying error, the user can re-run the revaluation 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 verifies the status of the DX.COB.WORKFILE (refer the diagram below), to decide which com-
bination to revalue. In day-to-day processing the status must only be “Completed” or “Running". Any Com-
bination of Customer/Exchange with the following status is revalued in the COB
l New
l Ready
l Re-Run
l Completed (with next run date less or equal today)
The "Dialog" section of the work-file contains all messages, errors or warnings generated during the pro-
cess.

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 revaluation 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.

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 used to return information for debugging purposes only. Errors must be
set within routine through 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 must 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.CLOSEOUT record. A local routine attached at this point must
set the TAX.CODE, TAX.TYPE, TAX.ACY and TAX.TCY fields in the DX.CLOSEOUTrecord. Any changes to other
fields in the DX.CLOSEOUTrecord by the API is 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, for example; CUSIP number. If the alternate index is
present, it sets rest of the option series. If the option series is present, the alternate index is defaulted or val-
idated against it. This is used in DX.CONTRACT.MASTER, DX.MARKET.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 (for example; 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, that is, 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 routine then returns a list of matched transaction IDs along with the num-
ber 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 are 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
This routine performs the calculation of Credit Exposure for Derivatives. The routine takes the record for
the transaction being evaluated along with elements of the option series and returns delta, time period,
REVAL.ADDON.PERCEN ID, replacement cost, regulatory add-on percentage and calculated 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 through standard meth-
odology.

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 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) is 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 is 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
Argument List Dir- Description

ection
CONTRACT.COD- In Contract code
E
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) populates the C$DXPR.PRICE.RECORD array with respect to SEC.INT.RATE,
INT.RATE, INTEREST.BASIS, VOLATILITY, UND.PRICE and UND.INT.PRICE
The calculation routine, then populates 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)

ection
N/A N/A Routine must include common block I_
DX.PRICE.COMMON
[C$DXPR.CONTRACT.CODE] [in] Contract code passed in through 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.SOURC- [in] Current DX.PRICE.SOURCE record
E]
[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
The routine needs 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) is 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 is 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 through 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:
l CONTROL.VAR has flag set to check down-date of lots. Routine must return DOWNDATE flag set to
true, if the number of lots are to be reduced as part of the processing (that is, if a closeout has truly
taken place or not).
l 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 through 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, for example, first
come first served, pro-rata assignment etc.
Routine takes in a list of candidates in the format customer.account_number together with a cor-
responding list of open lots against each within the current DX.ORDER record and the total number of lots
being filled. The routine must 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 cal-
culation.
Insertion Point

DX.CONTRACT.MASTER Contract code int.price.calc
dx.int.price.calc (from INT.PRICE.CALC field) CALC.SUBROUTINE
Arguments

ection
EXTERNAL.PRICE In Price as input to T24
EXTERNAL.STRIKE In Strike price as input to T24
R.DX.CONTRACT.MASTE- In DX.CONTRACT.MASTER record as dimensioned array
R
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 Premium), 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 is reported in
SC.POS.ASSET and associated tables. If no API is specified, the standard calculation is used for calculating
the estimated value of the future.
Note: This API is not 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

ection
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.MASTE- In DX.CONTRACT.MASTER record for the position being val-
R ued.

DX.AI.CUSIP
Description CUSIP No. Alternate Index
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
Description Credit Exposure for Derivatives.
This routine returns 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 are populated in SC.POS.ASSET file by the calling program.
Used In Portfolio valuation
Insertion Calculation of Exposure
Point

DX.CALC.NET.COST
Description Calc Net Cost of the Trade/Order

Subroutine attached to DX.PARAMETER which calculates the COST of Order/Trade from
which this routine is invoked.
Used In N/A
Insertion Calculation of Net Cost
Point

DX.CO.AM.FIFO
Description First In First Out Processing

Auto matching of exercise closeouts – matches selected transactions against least recent
opposite positions first.
Used In Closeout processing
Insertion Automatic Closeout Matching
Point

DX.CO.AM.FIFO.DAY
Descrip- Day Trade - First In First Out

tion
Auto matching of exercise closeouts – matches selected transactions against today’s oppos-
ite positions first and then least recent opposite positions.
Point

DX.CO.AM.LIFO
Description Last In First Out Processing

Auto matching of exercise closeouts – matches selected transactions against most recent
opposite positions first.
Point

DX.CO.AM.LIFO.DAY
Descrip- Day Trade – Last In First Out

tion
Auto matching of exercise closeouts – matches selected transactions against today’s oppos-
ite positions first and then most recent opposite positions.
Point

DX.CO.AS.FCFS
Descrip- First Come First Served
tion
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
Description No action on option closeout
‘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 Exotic Option Closeout Processing
Point

DX.FUT.EST.METHOD.THREE
Future Contract alternate valuation

Description
Returns estimation of the value of a futures position above cost (that is; the return on a
future position).
Used In Valuation processing
Insertion Valuation of Futures Position
Point
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
Description FIFO Order Assignment

Assigns partial fills to multiple customers on an order as first customer first then sub-
sequent customers.
Used In Order entry (partial fill)
Insertion Order Lot Assignment
Point

DX.ORD.ASSIGN.PRO.RATA
Description Pro-rata Assignment of filled lots

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
Description Cox, Ross & Rubinstein Binomial Pricing Routine
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 Calculation of Theoretical Prices
Point

DX.PR.BLACK.SCHOLES
Description Black Scholes Pricing Routine

greeks.
Point

DX.PR.BUILD.BS
Descrip- Pre-build for Black Scholes

tion
This routine is part of pre-load process for BLACK SCHOLES "black box" pricing routine. Val-
ues for currency rates, volatility and underlying price are passed back in
C$DXPR.PRICE.RECORD
Point

DX.PR.BUILD.GK
Descrip- Pre-build for Garman Kohlhagen

tion
This routine is part of pre-load process for GARMAN KOHLHAGEN "black box" pricing
routine. Values for currency rates, volatility and underlying price are passed back in
C$DXPR.PRICE.RECORD
Point

DX.PR.GARMAN.KOHLHAGEN
Description Garman Kohlhagen pricing routine
greeks.
Point

DX.RV.CHREG.VM
Description Swiss Regulatory VM Calc
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
Description Enhanced Initial Margin Calculation

Insertion Point Calculation of Initial Margin

DX.RV.EURONEXT
Description Euronext Margin Calculation

Black box routine to return Initial Margin calculation for Euronext.

DX.RV.FXOPT.VM
Descrip- FX option Variation margin

tion
Routine based on STANDARD.VM caters for alternative market price quotation for FOREX
options, that is, 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
Description No Initial Margin Calculated

Dummy routine to return zero Initial Margin

DX.RV.NO.VM
Description No Variation Margin Calculated

Dummy routine to return zero Variation Margin
Insertion Point Calculation of Variation Margin

DX.RV.OCC.TIMS
Description OCC/TIMS Margin Calculation

Black box routine to return Initial Margin calculation for OCC/TIMS

DX.RV.STANDARD.IM
Description Standard Initial Margin Calculation

Black box routine to return standard Initial Margin calculation.

DX.RV.STANDARD.VM
Descrip- Standard Variation Margin Calc

tion
This is the "black box" routine that calculates the variation margin for a given set of trans-
actions. These transactions are passed to the black box by the reval suite. No other logic or
processing is done here.
Insertion Calculation of Variation Margin
Point

DX.STAND.AS.RANDOM
Standard Random Assignment

Descrip- This “black box” routine randomly allocates lots for Option Assignment against a given list
tion of Trades (denoted by Transaction Id). The processing is based on EUREX random assign-
ment method.
Insertion Automatic Trade Assignment
Point

DX.XO.CREATE.EURO
Description FX Option on exercise

Routine to create a FOREX trade on exercise of a Derivatives Exotic Option, if the
EXOTIC.EVENT flag is set.
Point

DX.XO.CREATE.FX
Description Create FX Option

Routine to create a FOREX trade on exercise of a Derivatives Exotic Option if the
EXOTIC.EVENT flag is set
Point

DX.XO.CREATE.FX.KNOCKOUT
Description Create FX deal on knockout.
Create FX deal for knockout if exotic event flag not set.
Insertion Point Exotic Option Closeout Processing

DX.XO.CREATE.FX.REBATE
Descrip- Create FX deal or Post Rebate

tion
Create underlying FX deal for knockout option with rebate. Create FX deal, if exotic event
flag not set, otherwise create rebate cash payment.
Point

DX.XO.CREATE.SEC
Description Create Sec Trade

Create underlying Security deal on exercise of a derivatives exotic option, if exotic event
flag is set.
Point

DX.XO.CREATE.SEC.KNOCKOUT
Description Create sec trade on knockout

Create underlying Security deal for knockout option if exotic event flag not set.
Insertion Point Exotic Option Closeout Processing

DX.XO.FWDCASHPAYOUT
Descrip- Forward Cashpayout

tion
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
Descrip- Instant Cashpayout

tion
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
Descrip- Knock in and create underlying

tion
Prevent exercise of option before knockin event. Routine kick-off standard exercise of under-
lying, if exotic event is set. If exotic event is not set no exercise takes place and lots will not
be down-dated.
Point

DX.XO.KNOCKOUT
Descrip- Knock out or create underlying

tion
Prevent exercise of option after knockout event. Routine kicks-off standard exercise of
underlying, if exotic event is not set. If exotic event is set no exercise take place and lots will
not be down-dated.
Point

Revaluation Black Boxes
This section is a technical guide which deals with 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. Refer the revaluation details section (DX.REVAL.DET) and also a
DX.RV.DET.HIST file. You should use the standard T24 live file template, TEMPLATE.L.
For example:
In order to enter a record called SPAN.IM, an application called DX.REVAL.DET.SPAN.IM and a history
application of the same file layout called DX.RV.DET.SPAN.IM.HIST is required. The existence of these files
is vital for the correct function of the derivatives revaluation process, without them the process cannot com-
plete.
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 allows flexible local and client-driven development of new routines without core development
involvement.
The suite is 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 is not used for exchanges traded today,using the multi-threaded
T24 end of day.
Once the trigger applications are 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 cur-
rently held within the system, by making 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. Refer 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 N- Leve- G/- Description

o. l M
DX.RVP.MR.CUST.GRP.PORT 21 AM G The current customer or portfolio being reval-
ued.
See. DX.RVP.MR.RVLVL.KEY
DX.RVP.MR.POSITION 22 MV G The Positions of the customer or portfolio cur-
rently being revalued
DX.RVP.MR.TRANSACTION 23 SM G The constituent transactions for each of the pos-
itions 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 ref-
erence 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 cal-
culated 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 cur-
rency.
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.CONTRACT- 46 SM M The DX.CONTRACT.MASTER Contract codes that
S 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 cal-
culated.
DX.RVP.MR.CONTRACT.FACTOR 50 SM M The “bump up” factor applied to the contracts
initial margin figure for this margin routine cal-
culation.
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.PROCESS
(DX.RVP.MR.CUST.GRP.PORT).
Field/Insert Name N- Leve- G/- Description

o. l M
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.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.CAL- 31 G The name of the T24 detail files to be used for this
C 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 cus-
tomer/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 cre-
ated 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 con-
tains 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.SHOR- 41 SM M Unrealised Option P&L on Short Transactions Amount
T Sub Valued By Transaction.
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.

Sssyuy PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Sssyuy PDF

Caricato da

Copyright:

Formati disponibili

Derivatives - User Guide

Release: R17 AMR

©2017 Temenos Headquarters SA - All rights reserved.

Derivatives - R17 AMR - Page 2 of 452

Derivatives - R17 AMR - Page 3 of 452

Derivatives - R17 AMR - Page 4 of 452

Derivatives - R17 AMR - Page 5 of 452

Derivatives - R17 AMR - Page 6 of 452

Derivatives - R17 AMR - Page 7 of 452

Derivatives - R17 AMR - Page 8 of 452

Derivatives - R17 AMR - Page 9 of 452

Derivatives - R17 AMR - Page 10 of 452

Derivatives - R17 AMR - Page 11 of 452

Derivatives - R17 AMR - Page 12 of 452

Derivatives - R17 AMR - Page 13 of 452

Derivatives - R17 AMR - Page 14 of 452

Derivatives - R17 AMR - Page 15 of 452

Derivatives - R17 AMR - Page 16 of 452

Derivatives - R17 AMR - Page 17 of 452

Derivatives - R17 AMR - Page 18 of 452

Derivatives - R17 AMR - Page 19 of 452

Derivatives - R17 AMR - Page 20 of 452

DX Event Type Record

Derivatives - R17 AMR - Page 22 of 452

Derivatives - R17 AMR - Page 23 of 452

Derivatives - R17 AMR - Page 24 of 452

Customer (SAM, Account) Broker (Account) Comments

Lead Company Branch Company Interco entries for Broker

Derivatives - R17 AMR - Page 25 of 452

VM Posting VM Posting behaviour

Derivatives - R17 AMR - Page 26 of 452

Derivatives - R17 AMR - Page 27 of 452

Derivatives - R17 AMR - Page 28 of 452

Derivatives - R17 AMR - Page 29 of 452

ACCOUNT.CLAS- Type Description

Derivatives - R17 AMR - Page 30 of 452

ACCOUNT.CLASS records for Derivatives Accounting

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

Internal Account Categories

Derivatives - R17 AMR - Page 31 of 452

Derivatives - R17 AMR - Page 32 of 452

Maturity & Call Put Indicator

Strike Price Codes

Derivatives - R17 AMR - Page 33 of 452

Derivatives - R17 AMR - Page 34 of 452

l ‘System’ level default for all conditions.

1. Customer and contract.

CU100018 Customer 100018 (CU = Customer

Derivatives - R17 AMR - Page 35 of 452

1. The trade currency is equal to “USD”.

Derivatives - R17 AMR - Page 36 of 452

Commission Type Field Name

Derivatives - R17 AMR - Page 37 of 452

Below are example scenarios for simple commission.

Derivatives - R17 AMR - Page 38 of 452

DX.COMMISSION Input Record

Derivatives - R17 AMR - Page 39 of 452

DX.COMMISSION Input Record

DX.COMMISSION Input Record

Derivatives - R17 AMR - Page 40 of 452

Derivatives - R17 AMR - Page 41 of 452

DX.COMMISSION Input Record

Derivatives - R17 AMR - Page 42 of 452