Introduction to Derivatives

The Cont Ulying Val field in DX.PARAMETER allows the off-balance sheet postings made on entry of an own-book deal to be based solely on the underlying value of the trade. This is particularly useful for own-book over the counter (OTC) forex options, as the receivable and payable cash amounts are calculated and posted as assets or liabilities in the appropriate currencies. The Cont Ulying Val field can be set to:

Product categories can be used to differentiate different classes of derivatives and it is a useful tool from a reporting perspective. Different product categories can be assigned to long and short positions for both futures and options. The DX.CONTRACT.CLASS application is used to define product categories and each derivative instrument can be linked to a DX.CONTRACT.CLASS using the Contract Class field in DX.CONTRACT.MASTER. Product category is part of the consol key of the contingent entries and thus they are used to differentiate derivatives classes in the balance sheet.

This functionality is activated at the DX.CONTRACT.MASTER level. The System Exercise and System Expiry fields are set to Yes, and a tolerance level is defined using the Exer Pri Mem, Exer Pri Non and Expiry Pri fields.

Whenever the manual settlement functionality is used, the system writes a record to the appropriate underlying application as mentioned below:

• DX.CO.MATURITY.INPUT
• DX.CO.ASSIGN.MANUAL
• DX.CO.EXERCISE.MANUAL
• DX.CO.EXPIRE.MANUAL
• DX.CO.MANUAL.INPUT

These applications may become huge and the user may not require it in the future. When the user does not want to retain these records, it can be set to clear automatically these applications during the COB process. The multi-value field Feed To Clear in the DX.PARAMETER application allows feed files to be selected and cleared along with their related unauthorised and history files when the COB runs. The DX.COB.CLEAR.FEEDS job in the DX.END.OF.DAY record in BATCH application runs the process daily to maintain these records.

The DX module has five methods of average price calculations:

• Normal
• Opening
• Purchase
• Unweighted
• None

These methods are defined at the contract level in the Average Price field in DX.CONTRACT.MASTER along with the number of decimal places required for average price. The Average Price and Average DPS fields in the DX.CONTRACT.MASTER application controls the average prices at the contract level. These fields are used for calculating the average price and to update Trade Price and Average I Price fields in DX.REP.POSITION. The five methods of average price calculations are explained as follows: 

Normal

When the method is set to Normal, the average price is calculated using a standard average.

Opening

When the method is set to Opening, the average price is the average of buy prices of opening trades weighted by the number of lots traded.

Only the lots with the Tx Open Close field in DX.REP.POSITION set to Open and the Tx Buy Sell field in DX.REP.POSITION set to buy are considered.

Purchase

When the method is set to Purchase, the average price is the average price trades weighted by the number of lots traded.

Only the lots where the Tx Buy Sell field in DX.REP.POSITION is buy are considered.

Unweighted

When the method is set to Unweighted, the average price is the average of buy prices of opening trades weighted by the number of lots traded.

None

Average price is not calculated. 

Whenever a primary customer’s position is closed out, the corresponding opposite position of the secondary customer is also closed out automatically. The closeout does not require any separate authorisation by the user. Whenever an automatic secondary closeout cannot be performed for various reasons, there is a warning message to that effect. However, a secondary closeout does not result in a back-to-back closeout for the corresponding primary customer. For this purpose, the B2b Active field in DX.PARAMETER is used. The B2b Co Ok field in DX.CONTRACT.MASTER is used to activate the back-to-back closeout process.

As a standard, any debit or credit to the customer account is computed by applying the middle exchange rate, if the DX currency is different from the customer account currency. Banks can apply the user-defined exchange rates or the ones most beneficial for them, on the premium, charges and commission involved in DX trades (besides retaining the current functionality of applying mid rates). The following are the highlights of applying best rate:

• The best rate facility is designed only for the primary side of a DX.TRADE.
• When the primary customer chooses the manual commission type for the trade, the user-defined rates can be applied to commission.
• The system defaults the exchange rate from the CURRENCYapplication (for conversion of commission or charges) based on the definition in the Pay Receive Flag field (as to Pay or Receive) in the relevant record in DX.COMMISSION.
• This functionality is designed only for a scenario where a record in DX.COMMISSION does not have more than one multi-value set.
• This best rate facility is available based on the class of the customers such as customers, brokers, dealers, counter party and exchange.

The rate is defined in Temenos Transact using the following applications:

This is an automated mechanism for equity options. When the underlying asset (shares or possible bonds) is used to cover one or more option contracts, that asset cannot be sold through the Securities (SC) module while the option contract is still active.

Margin requirements for written (sold) option trades can be reduced, if the counter party selling the option is in possession of the underlying asset. The blocking of securities position is done using Open Financial Source (OFS) to drive the SC.BLOCK.SEC.POS application. A valid value is entered in the Ofs Source field in DX.PARAMETER to activate this facility. The Pri Hedge Trade field is set to Covered in DX.TRADE to block a securities position on short covered call position and for protective put. If the requirement cannot be met, the deal is set as Uncovered in the Hedge Trade field. The user is informed about this in the transaction screen through an override on committing the transaction.

The DX module enables the calculation of credit exposure on derivative trades as per the market method. Under this method, credit exposure is equal to replacement cost and an add-on factor. This is required for the purpose of regulatory reporting and credit monitoring.

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

The fields in SC.POS.ASSET reflects the credit exposure amount. This amount is calculated separately for regulatory reporting and credit monitoring. Whenever a record in SC.POS.ASSET record is built or rebuilt, the black box routine DX.BB.CREDIT.EXPOSURE is called and credit exposure amounts are updated in SC.POS.ASSET of the respective portfolio.

When the Check Cust Funds field is set Yes in DX.PARAMETER, the module calculates a best estimate initial margin figure for each transaction entered (order or trade). The value generated is used to block the customer funds until the next initial margin calculation is run (when the funds are physically removed from the customer’s account, in any case).

It also makes an unblocking posting forward dated to the notional maturity date of the deal. Defining a routine in Cost Calc Api field in DX.PARAMETER blocks the customer funds with respect to the premium cost of a transaction.

For all external customers, Revaluation P&L (variation margin) is posted to the account entered for that customer on DX.TRADE. For own book portfolios, unrealised - P&L calculated by the DX revaluation process are posted using the P&L category and transaction codes specified on the VM (Variation Margin) record in DX.EVENT.TYPE. Posting of revaluation, P&L for own book portfolios is controlled by the Margin Difference field 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 theVm Reversal Style field is 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. When Vm Reversal Style field is set to Old, it reverses the variation margin amount with prevailing exchange rate.

The variation margin are reversed on reversal of the DX.TRADE. Read Variation Margin Reversal for more information on how the reversal are handled.

The records in DX.TRADE are automatically generated to update the deal with respect to the order fill by filling orders through DX.ORDER. However, these trades can be created with their status set to INAU. This functionality is activated using the Stp Enabled Apps field in DX.PARAMETER.

The user designates the DX.ORDER application as a value in the field to activate the straight through processing of filled DX.ORDER records such that the corresponding DX.TRADE records are created with their status set to INAU. This activates the use of OFS, hence the TSA.SERVICE manager (TSM) should be running and the corresponding OFS.MESSAGE.SERVICE and OFS.RESPONSE.QUEUE is set to AUTO.

The DX.MONITOR.STP.PROCESS enquiry monitors the state of DX.ORDER and DX.CLOSEOUT generated OFS transaction messages, in case of any problem. It reports any transactions that require operator intervention, if a timeout period is specified, and it also reports on any transactions that were not handled within that time. The enquiry reports the following:

• DX.TRADE ID
• Error message
• Date and time of the generated transaction
• Length of time since the transaction is generated
• Timeout related issue

The Stp Timeout field in DX.PARAMETER 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 when left blank, timeout checking is not done in the DX.MONITOR.STP.PROCESS enquiry.

The two possible options while posting Variation Margin entries are:

• Either the system is configured to post only the difference between current and previous date or
• Otherwise, the system reverses the full amount collected on the previous date and re-posts the current VM in full (Read Revaluation Profit and Loss (P&L) for more information).

When a DX.TRADE is reversed, only the last VM posting is reversed. This leaves the balance in the customer's account as correct on the date of reversal. However, the previous day’s balances since the start of the trade is not adjusted and this affects the interest charged on the account balances. When Vm Rev Type field is set to INDIVIDUAL in DX.PARAMETER, all VM entries are reversed with effective date. When this field is set to Yes, the system updates the DX.VARIATION.MARGIN.DETS table (a live table).

The ID of this table is <DX.TRADE ID.Portfolio ID>. The system updates all the details (including the exchange rate, amount and the account to which VM was posted) every time a variation margin entry is posted for a trade. The system uses the values in this table and reverses each entry individually with the correct value date, when a trade is reversed. This ensures that the balance in the account is adjusted for each day.

The DX.PARAMETER application controls the DX modules and its functions. It contains a single record SYSTEM, that is read by other applications of the DX module and their behaviour is controlled by the various fields in this application.

The DX.CONTRACT.CLASS application allows to define a group of contracts such as equity options, equity futures and bond futures. Each contract class can be identified with a distinguished category code set in the Class Category field.

The DX.CONTRACT.TERMS application is more specific to basket options. The setup is done for each specific asset class like equity or currency.

The DX.OPTION.TYPE application is ideal for defining exotic deals. This parameter is used to input user-defined fields, which appear on orders and trades associated with the option type.