Professional Documents
Culture Documents
Sssyuy PDF
Sssyuy PDF
Intended Audience
This User Guide is intended for the use of Internal Temenos users and Clients.
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
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.
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.
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.
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.
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.
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:
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
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
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.
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
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 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.
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:
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:
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:
If either condition proves to be false for the trade, then the commissions specified in this test set will not be
used.
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.
l Scenario 1
l Scenario 2
.
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.
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
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.
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.
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.
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
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.
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.
DX.USR.FLD.OPT settings for Price Level, Rate Level and Narrative fields
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.
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.
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.
2. Enhanced IM
l As above except it does not include bought positions in the Naked calculation.
3. NO IM
l IM = 0
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
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.
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.
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
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.
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.
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.
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.
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.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.RATES
DX.MARGIN.RATES record
Margin rates are entered on a contract and client basis.
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- - -
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.
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
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.
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.
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 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.
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.
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).
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.
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.
DX.TRADING.CONSTRAINT Records
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.
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.
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.
DX.TRADE Record
DX.TRADE
Strategy Linking
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.
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.
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.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.
Note : The remaining lots can be filled either partially or fully later on.
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.
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:
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:
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.
Order Workflow
The status of an order undergoes numerous changes during the lifecycle of the order. These statuses are
explained in the below table.
New Order
Order Acknowledgement
Order Rejected
Fully Executed
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.
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).
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:
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
Therefore the closing price of 95.60 for a December 03, Three Month EURIBOR Future (12) 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
.
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
.
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
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.
DX.PRICE.SET
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.
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
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:
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 Price/Premium Terminology
l Variable Tick Size Calculations
l Example Contract Key Date Calculation
l Price Calculation Methods
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
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
Examples:
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:
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).
2. Futures contract value at 93.990 = $99,925.6470014 (rounded to eight decimal places).
3. Difference (value 0.01% of premium) = $74.3529986.Since there is 14 points of premium, the final
premium in dollars is calculated as: $74.3529986 x 14 = $1,040.9420 which when rounded to the nearest
cent gives $1040.94.Example Contract Maturity Rules
DX.CONTRACT.MASTER allows the Bank to set up maturity validation rules for trading using specifications
distributed by exchanges. This appendix contains some ‘real-world’ examples of how this is done.
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 10
1 MONTHS.FORWARD OPEN
MATURITY.MONTHS MARCH
MAY
JULY
SEPTEMBER
DECEMBER
MATURITY.DAYS
The value calculated is used as the internal price in the TEMENOS T24™ Derivatives module.
.
The value calculated is used as the internal price in the TEMENOS T24™ Derivatives module.
.
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:
1. Futures contract value at 94.000 = $100,000.0000 (rounded to eight decimal places).
2. Futures contract value at 93.990 = $99,925.6470014 (rounded to eight decimal places).
3. Difference (value 0.01% of premium) = $74.3529986.Since there is 14 points of premium, the final
premium in dollars is calculated as: $74.3529986 x 14 = $1,040.9420 which when rounded to the
nearest cent gives $1040.94.Example Contract Maturity Rules
DX.CONTRACT.MASTER allows the Bank to set up maturity validation rules for trading using specifications
distributed by exchanges. This appendix contains some ‘real-world’ examples of how this is done.
Example 1: SIMEX Euroyen TIBOR Futures
March, June, September, December contracts on a 5-year cycle.
MV Field Contents
Number
AVAIL.MONTHS
1 MONTHS.FORWARD 60
MATURITY.MONTHS MARCH
JUNE
SEPTEMBER
DECEMBER
MATURITY.DAYS
Six consecutive months, plus two quarterly months on a March, June, September, December rotation
MV Field Contents
Number
AVAIL.MONTHS 10
1 MONTHS.FORWARD OPEN
MATURITY.MONTHS MARCH
MAY
JULY
SEPTEMBER
DECEMBER
MATURITY.DAYS
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 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.
The routine that has been designed to fill in the Data in DX.MARKET.PRICE if required
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.
DX.MARKET.PRICE record
PERIODIC.INTEREST
The fields CONS.DATA.NAME “INTSEQ” and CONS.DATA.ITEM, in PRICE.SOURCE look at PERIODIC.INTEREST
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
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
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.
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.
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.
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.
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.
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-
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
Note: These postings include premiums for contracts with posting at settlement time.
Note: The postings include premiums for contracts with posting at settlement time.
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-
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
be a valid currency in CURRENCY table and it is a mandatory field for FX-OTC options.
DX.CO.EXPIRE.AUTO
l The field CONTRACT.CCY specifies the contract 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.
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.
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
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.
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
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.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
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.
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
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
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.
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).
Transactions are stored using the key of the parent trade or other entity, a portfolio/customer number to
identify the ‘side’ of the parent transaction it is associated with and a version number to keep track of
changes to the transaction.Old versions are retained.
DX.TRANSACTION record
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.
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.
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.
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.
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
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).
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)
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.
l Revaluation Summary
l Revaluation for Exchange
l Revaluation Details
l Adhoc Revaluation
l Initial Margin Methods
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.
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.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.
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 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.
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
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.REVALUE
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
Note: Input values for Gen Data Code = STOCK, STOCKINDEX, FOREX, or INTEREST
Stock Contract
STOCK INDEX CONTRACT - Define by “band”, that is, broadband 20 (percent) narrow-band 15 (per-
cent).
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
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
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
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
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.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.
DX.TRADE
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.
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.
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
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.TRADE
When the contract being traded is a “Basket”, DX.TRADE will allow multiple underlying to be defined.
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
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.
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.
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
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.
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
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:
DE.FORMAT.PRINT Record
Example DE.FORMAT.PRINT records are available in the system.
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.
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.
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.
Note: If the user configures Exotic and Precious Metal option for a contract, then MT601 SWIFT
message is generated by default.
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.
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.
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.
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.
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.
Note: Sell trades have the same impact on utilisation as buy trades, that is, sells are not ‘can-
celled’ out against buys.
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.
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.
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.
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.
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.
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.
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”.
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.
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
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
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
Arguments
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
Arguments
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
Arguments
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
Arguments
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
Arguments
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
Arguments
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
Arguments
Description
Calculation of the net cost of a future or option trade after deduction of commissions, charges and tax.
Insertion Point
Arguments
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.
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
Arguments
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
Arguments
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
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
Arguments
Description
Conversion of price (as input) to internal format used by T24. Overrides normal processing of price cal-
culation.
Insertion Point
Arguments
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.
Arguments
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.
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.
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:
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).
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.