DX Derivatives overview

Posted by
Print Friendly, PDF & Email

This document consists in a quick overview of the Globus Derivatives module (DX).

Executive Summary

The GLOBUS Derivatives product has been developed to allow trading of futures and options. The product supports orders, trading, position keeping, valuation and closing out of both exchange-traded and OTC contracts.

The Derivatives product may be used by banks trading on their own behalf, by banks trading on behalf of their customers (including ‘bulk’ trading) or by banks offering their customers brokerage services.

The module includes orders workflows (STP) from either internal traders or external clients; the orders are entered either manually or by an interface from a front office system (See annex 2).

Check order validity immediately, input and executed (checks the client ‘s availability of funds / limits / constraints). Orders can be amended, deleted or executed, either manually or automatically. Once fully or partially executed the order becomes a trade (one order may create multiple trades).

GLOBUS Derivatives has been designed to cope with the rapid changes and developments experienced in the derivatives market by adopting a ‘black box’ architecture for certain key elements of the system such as margin and profit and loss calculations. The module is then including standard calculations routines, opened for local calculations developments and finally opened to external trading systems as well as external margining/revaluation systems. See annex 1 for a concept diagram.

The philosophy of the Derivatives product is that a detailed static data set up will enable the bank to tailor the product to their own needs and minimize the amount of manual intervention required to run the system day-to-day. The Bank can input comprehensive data to define the products and exchanges they or their customers may trade.

GLOBUS Derivatives performs on-line real-time updates of derivatives trading positions and cost of positions. Full revaluations may be performed at any stage during the system day for reporting purposes, and the End of Exchange process may either be run online or during the main GLOBUS batch run to generate and post to the accounts the ‘official’ margin figures.

All operations carried out in Derivatives raise a record in the main derivatives transaction file. This file provides a comprehensive record of a customer’s activities within the Derivatives module and is the basis for most clients reporting/statementing etc. Each transaction is also associated with one or more ‘events’ in the life of a contract that form the basis of the module’s event-driven accounting updates. Exotic option can also be defined, though the prices have to be handled and maintained manually. The derivatives module is fully integrated in the Globus core system, e.g. trades are online impacting:

  • LIMITS (at input step)
  • DELIVERY (printed advices, SWIFT/SIC confirmations and payments)
  • CUSTOMER POSITIONS (portfolio valuation reports, performances reports,…)
  • OWN BOOK POSITIONS
  • ACCOUNTING: DX accounting is event-based – all significant events that may occur in the life of a contract are assigned an event code (see annex 3). Accounting DX system is compliant with IAS 32, 39 and IFRS 7.

1. Facilities already covered since G13:

1.1.1 Trading

DX.TRADE Main trade capture application, designed to allow the maximum flexibility possible for trading on- and off-exchange futures and options. Trade entry is double sided, allows ‘bulk’ trading; many clients trading with one broker on a single trade. – Examples:

  • Bank’s customer trades with Bank’s own book
  • Bank’s own book trades with broker
  • Bank’s customer trades direct with broker
  • Broker ‘transfers’ trade to another broker
  • Other scenarios…

ORDER CAPTURE Record individual orders from either internal traders or external clients; the orders are entered either manually or by an interface from a front office system (See annex 2)

Check order validity immediately, and record the time and date when the order is given, input and executed (checks the client ‘s availability of funds / limits / constraints).

Orders can be amended, deleted or executed, either manually or automatically. Once fully or partially executed the order becomes a trade (one order may create multiple trades).

1.1.2 Back-office facilities

AUTOMATED PRICE CAPTURE Request prices from one of any number of price sources without user intervention. A price source such as Black and Scholes Garman Kohlhagen FX option prices can be update automatically at the end of exchange.

MANUAL PRICE CAPTURE\\  Allow the correct valuation of open positions (trades) using the revaluation group. (Market or Fair Value price).

FUTURES, OPTIONS AND STOCK PRICES Historical records of the current market price for a Future, an option or a Stock. Records the current price for contracts (+ interest rates, volatility, strike prices, Call and Put Prices, delta, gamma and vega)

CLOSING OUT TRADES: Can be performed manually, automatically or by the system.

ASSIGN/EXPIRE/EXERCISE A CONTRACT Can either be a manual or an automatic process Underlying Vs Effect in Globus: Future: A DX trade for the future automatically created Cash: A FX transaction automatically created Bond or Stock: A Sec-Trade automatically created

REVALUATION AND MARGINING Valuation, accounting and reporting of futures/stock and options. Re-valuation process maybe (End of Day batch re-valuation/processing, End of Exchange/Centre re-valuation/processing, On-line ad-hod re-valuations).

CALCULATION OF INITIAL MARGIN The initial margin calculation methods vary from exchange to exchange and from broker to broker. For ETD futures and options, each clearinghouse or exchange published its initial margin calculation method. These various methods can be implemented, by using the revaluation “black box” technology, and by using a parameter in the contract master file, DX.CONTRACT.MASTER . Associated with each method will be related table maintenance or data extract modules to enable each method to be fully implemented. Full reporting functions, based on the exchanges own reports if applicable, will be included in all initial margin calculations. This will allow the user to easily check all the margin figures including SPAN, spreads and hedges. CALCULATION OF VARIATION MARGIN Variation margin calculation method (profit/loss) is determined from parameters held in the contract master file. Regular contract method (unit price * price differential) used, and alternatives can be easily added by using the “black box” technology.

REVALUATION PROCESSING Re-calculate the value of clients or portfolios after the exchanges have closed (overnight batch utility or on-line process), includes “what if” revaluations.

CORPORATE ACTION PROCESSING The function of the DX.DIARY application is essentially the same as the Securities DIARY application, but is tailored for Derivatives corporate actions. This includes options to alter the lots/strike price/contract size/contract number etc…

1.1.3 Interfaces to Other GLOBUS Modules

LIMITS (online controls at input step)

DELIVERY Uses ‘Soft Delivery’ which enables the user to define the output of the delivery messages (in S.W.I.F.T. or printed output) by calling a core routine (EB.HANDOFF) to initiate and pass information to the Delivery system. Delivery messages are generated whenever a derivatives DX.EVENT.TYPE event is processed i.e. DX.TRADES are entered, amended or reversed. Delivery messages are also generated when a DX.CLOSEOUT is performed. Messages can be produced for any action including corporate actions/option exercise/ assignments etc… Any new event added to the module will therefore be automatically available as having a possible link into the deliveries module.

CUSTOMER POSITIONS Now include derivatives transactions

SC.POS.ASSET\\  Now includes derivatives.

ACCOUNTING DX accounting is event-based – all significant events that may occur in the life of a contract are assigned an event code. Accounting details are associated with these event codes, allowing the Derivatives account entry routines to make the appropriate postings to the appropriate accounts, categories or CRF types at the appropriate times. Accounting DX system is compliant with IAS 32, 39 and IFRS 7.

1.1.4 Static Data

 DERIVATIVES MASTER FILE (main characteristics of options and futures)
 EXCHANGE PLACES (all specifications of market places, last trading dates, maturity rules, …)
 DX.CUSTOMER (Customers classifications depending on roles -Customer, Counterparty, Broker or Exchange type customer). 
 DX.GROUPING (Derivative customers to be grouped together for commission calculation and margining/reporting purposes)
 DX.DOCUMENTS (Documents and agreements can be maintained, -definition -frequency for renewing,…).
 DX.MARGIN.CALC (Allow entry/amendment of margin calculation routines into the GLOBUS derivatives module). 
 DX.MARGIN.RATES (calculate initial margin figures)
 DX.PRICE.SOURCE  (Entry/amendment of price sources, -Manual -Automatic e.g. Reuters, Telerate, Telekurs, “Batch” (e.g. SPAN risk parameter files). Ability to call a price model routine and store the returned price (e.g. Black and Scholes).
 DX.STRATEGY (Link individual transactions to form a strategy, own valuation methods can then be applied)
 DX.TRADING.CONSTRAINT (options and futures business restrictions can be designed at several levels, controls are then on-line at input step)

 

2. Derivatives Module detailed functionalities

2.1 Static Data

Basic contract information: name, mnemonic, exchange on which the contract is traded, type of contract (may be FUTURE, OPTION or STOCK). The DELIVERY.METHOD of the contract may be CASH, PHYSICAL or NONE Pricing data: contains powerful functionality to describe the format and calculation of contract prices, and to validate them on that basis. Main pricing data such as the price basis (INTEREST for interest-rate based prices, NORMAL otherwise) are then same for all prices on a contract, but in some cases values like tick size and value may vary when the contract price falls within different bands. Examples of the use of the format codes:

CBOT 10-Year Treasury Note Futures: Points and 1/32 of a point; i.e., 84.16 equals 84 and 16/32.

LIFFE 3 Month Sterling Interest Rate Future: Quoted as 100 minus rate of interest, tick size 0.01. e.g. 94.25

Maturity Date Validation and Key Contract Dates

  • Can be specified as a maturity month, or as a single day for maturity (e.g. FLEX options) or as a single day up until a certain forward date, and switch to a monthly maturity after this time (e.g. LME copper futures).
  • Definition of 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 specifying 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 (e.g. March, June, September, December).
  • For a monthly maturity contract, certain dates related to the maturity month are significant; chief among these is the ‘last trading date’, i.e. the last date for which contracts maturing in that month may be traded. The exchange will publish rules to determine this and other key contract dates, which can be set up.

Other Contract Information *Variation margin and initial margin calculations are defaulted from DX.EXCHANGE.MASTER but can be overridden to apply special margin calculations to individual contracts. The UNDERLYING field (for an option contract) it specifies the ID of the DX.CONTRACT.MASTER record that the option will declare to. For a future it represents the actual asset the contract is based on, e.g. a stock.

  • Flag to say whether or not an eligible open position in the contract should 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 will use the contract value (no. of lots * internal price) to calculate the posting.

DX.EXCHANGE.MASTER – defines the characteristics of exchanges on which customers defined in the GLOBUS Derivatives module may trade. – contains the following types of information:

	Details of the exchange/market itself (description, address, etc).
	Default rules and methods for trading on the exchange (margin calculations, premium posting times etc).
	Links to customers/portfolios/accounts that represent the exchange in GLOBUS for the purposes of posting fees and other account entries.
	Basic details about any relationships between the exchange and other entities, i.e. regulators.

Each exchange is uniquely associated with a REGION , since the module uses regions to represent exchanges for the purpose of defining trading calendars in the HOLIDAY application.- The EXCHANGE.TYPE field allows an exchange to be set up as Normal – i.e. a ‘real’ exchange, or OTC – Fields allowing the payment of option premiums and charges or commissions to be defaulted to 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.- For the most part, the valid days available for trading are read from the holiday record associated with the exchange region, but unusual trading day rules (i.e. Monday to Thursday rather than Friday) may be defined. The exchange’s specific trading opening and closing times can also be recorded. These fields may be multivalued if certain ‘sessions’ during the exchange day are available for trading certain products – if these session have particular titles they can then be named in the EXCHANGE.SESSION field.- Field that constrains the set up of contracts on the exchange and sets the maximum number of months forward that any contract may be traded.- Field defaults the behaviour of all contracts on the exchange with regard to automated closeouts (settlements). If set to No, open positions in contracts on the exchange that would otherwise be eligible for automatic close-out during the End of Exchange processing will be kept open.- If the Bank is a member of any exchanges, it may wish to record trades directly between customers and the exchange. To allow this, customers may be associated with the exchange for the purpose of holding trading positions.

Exchange defined Initial margin Requirements. There are two other initial margin routines currently available with the derivatives module: EURONEXT-AEX and OCC.TIMS; their detail filenames are DX.REVAL.DET.EURONEXT and DX.REVAL.DET.OCC. The details will be grouped within the revaluation or the end of exchange run, in their respective strategies for the customer. The calculation’s used by these black box routines are defined by the exchanges that use them, for example the AEX exchange uses the EURONEXT method as do a number of other exchanges throughout the world.

DX.CUSTOMER – Specific information required for trading derivatives information must be entered for each customer that will be used in the Derivatives product (classed as Customer, Counterparty, Broker or Exchange type customer). The Exchange type customer used to hold the exchange’s positions when trading direct with the exchange.- allow the definition of the interaction of the customer with one, several or all exchanges defined in the Derivatives product. This lets the Bank define the customer as a speculative or hedge trader on each exchange, and also whether the customer is a member of the exchange. The exchange membership may be set to Trading, Clearing, Both or None.- Ability to force the Derivative product to apply a percentage weighting to any initial margin figure calculated for the customer on the relevant exchange(s). – Automatic close-out routines- A customer can be treated as a member of a group for commission calculation, margin calculation and reporting purposes.

DX.GROUPING DX.GROUPING is a simple application that allows Derivative customers to be grouped together for commission calculation and margining/reporting purposes. The group is simply defined in DX.GROUPING and the group id added to the DX.CUSTOMER record in question.

DX.DOCUMENTS – Documents and agreements that must be put in place and maintained to allow external customers to trade with the Bank can be maintained. (definition of required document types, frequency with which the documents must be renewed).

DX.EVENT.TYPE Events occurring during the life of a derivatives contract are selected from a predefined list and associated with information that is used in accounting for the Bank’s own book portfolios. The module then assigns one or more events to each activity performed on the system and logged in the DX.TRANSACTION file. See annex 3 fro full list of events.

DX.MARGIN.CALC To allow entry/amendment of margin calculation routines into the GLOBUS derivatives module.  The Derivatives module is designed to use ‘black boxes’ to return information that may be obtained in several different ways. In this way, the main applications need only worry about calling one ‘shell’ routine, which will select the correct algorithm, routine or interface to use to return the required data for that margin calculation. Margin calculations rely on this technique – the Derivatives module will call a single ‘grey box’ routine that will determine the correct margin calculation to apply by examining the exchange and (if necessary) the contract traded. The DX.MARGIN.CALC application holds descriptions of the calculations that may be used, and points to the PGM.FILE record defining the actual routine to be called as part of the revaluation process. Two default margining routines are provided. STAND.IM and STAND.VM these are the Standard Basic Initial Margin Calculation and the basic Variation Margin calculation routines. There are two other Initial Margin Calculation currently available, namely Euronext-AEX and OCC-TIMS and more may follow.

DX.MARGIN.RATES Part of the functionality of the Derivatives module is to calculate initial margin figures. The amounts are actually calculated by “Black Box” Initial Margin routines that are controlled by the application DX.MARGIN.CALC . However some of these routines require rates to be entered depending on which calculations being performed.  The DX.MARGIN.RATES application will allow the entry of initial margin rates for various types of trades. These rates will be used, as required, by various initial margin calculation routines. Further applications will be developed as required for specific initial margin calculation routines e.g. SPAN.  Margin rates are entered on a contract and client basis.

DX.PRICE.SET The function of this application is for the entering/amendment of price sets in the Derivatives module. These “Price Sets” are predominately used in the valuation of open positions (trades) using the revaluation process. Examples of commonly used price sets would be ” CLOSING” and ” CURRENT”. These price sets can be used to set-up “what if” price sets, allowing an ad-hoc revaluation to take prices from a notional price set. In this way the system can be used to answer the question, “What would happen if the prices …?”.The DX.PRICE.SET key is used to validate the key of the DX.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 this application is to allow entry/amendment of price sources into the GLOBUS Derivatives module. A price source should be considered as an identifier for the entry point of prices into the system. There are many different price sources:- Manual, a user physically entering prices into the system.- Automatic price feeds (e.g. Reuters, Telerate, Telekurs).- Batch based price downloads (e.g. SPAN risk parameter files).- Ability to call a price model routine and store the returned price (e.g. Black and Scholes). A basic DX.PRICE.SOURCE record MANUAL is provided with the system to allow the entry of prices using DX.MARKET.PRICE.

DX.STRATEGY When trading derivatives, it is common to link individual transactions to form a strategy to achieve a desired result. Examples are caps, collars and floors, where combinations of ‘simple’ derivatives trades together allow risk and profit and loss characteristics of a portfolio to be constrained as required. Individual banks may define their own “combination” products e.g. Structured Deposits. This application allows that strategy to be defined along with its own valuation methods. The strategies defined here are used in the DX.TRADE application, a different strategy can be used for each side of the trade, in the PRI.STRATEGY and SEC.STRATEGY fields.  When transactions with a strategy are found as part of the revaluation process, these trades are valued together using the margin routine, if specified, in the DX.STRATEGY record.

DX.TRADING.CONSTRAINT The Derivatives module includes a method of applying constraints to which contracts and/or exchanges customers or individual portfolios may trade in the module. This is accomplished through the application DX.TRADING.CONSTRAINT and associated. The application allows different data fields held on DX.CONTRACT.MASTER and DX.EXCHANGE.MASTER to be tested alone or in combination to determine whether the customer or portfolio is not allowed to trade based on the details entered. More than one constraint may be defined for a particular portfolio, as the ID of DX.TRADING.CONSTRAINT contains a reference number that differentiates between multiple constraints for the same portfolio. By setting up multiple constraints for a client or portfolio the system can apply special rules for alternative products, for example if the exchange is offering a new contract and this is being offered to the banks customers with constraints that normally would preclude the customer. To do this the trading constraint fields, PRI.CONSTRAINT and SEC.CONTRAINT, on each side of the trade in DX.TRADE will manually have to be entered, rather than relying on the default of constraint 01 or SYSTEM being used. Example: customer who is only allowed to trade options apart from options traded on CBOT. ”’ DX.TRADE”’ DX.TRADE is the main trade capture application for the Derivatives product. It is designed to allow the maximum flexibility possible for trading on- and off-exchange futures and options. Trade entry in DX.TRADE is double sided, and allows ‘bulk’ trading; many clients trading with one broker on a single trade.  Derivatives trading may occur in many different circumstances: Bank’s customer trades with Bank’s own book Bank’s own book trades with broker  Bank’s customer trades direct with broker  Broker ‘transfers’ trade to another broker Other scenarios…DX.TRADE is designed to handle all these cases and so unlike SEC.TRADE it allows the entry of customers or brokers on either ‘side’ of a trade rather than having a ‘customer’ and a ‘broker’ side per se. A Bank may of course choose to establish a convention that the secondary customer on the trade will always be, for example, a clearing broker. Order Capture The Order entry system will record individual orders from either internal traders or external clients; the orders are entered either manually or by an interface from a front office system. The derivatives module order entry allows the trader to check the validity of the order immediately, and record the time and date when the order is given, input and executed. It checks the client ‘s availability of funds / limits, therefore enabling a trader / credit officer to determine if, as a result of the order being executed, any limits would be breached. It will alert the user if there are constraints applying to that particular client / portfolio. After an order has been entered it can then be amended, deleted or executed, either manually or automatically. Once fully or partially executed the order becomes a trade. Therefore one order may create multiple trades. In some cases the order may never be executed or maybe only partially filled. At the end of exchange all orders remaining unfilled will be checked for their validity. All orders will be reported and those that have expired will be deleted. ”’ Manual Price Capture”’ The major function of this application group is to allow the correct valuation of open positions (trades) using the revaluation group. The actual method used to value a position can vary, however most methods rely on a Market or Fair Value price. The system will value all the portfolios during the revaluation process using a closing or “fair value” price. For exchange based contracts all the exchanges provide an official settlement price also called EDSP (Exchange Delivery Settlement Price). For OTC options the prices are often manually input, calculated or received from an external source. Throughout the day, when the contracts are being traded, current (or last) prices might be received which, if stored, will allow on-line real valuations to take place.  Additionally users may want to change prices based on what they think might occur in the market and then re-value a portfolio based on these speculative prices. The application is therefore required to accept and store prices in the following situations:• Manual price input• Automatic price feeds (e.g. Reuters, Telerate, Telekurs)• Batch based price downloads (e.g. SPAN risk parameter files)• Ability to call a price model routine and store the returned price (e.g. Black and Scholes)• User created speculative or “What If” prices The source of the prices are set-up using the application DX.PRICE.SOURCE . Initially only MANUAL prices will be entered, additional feeds can be added. The prices that need to be updated are known as price sets, and are defined using the application DX.PRICE.SET .

DX.MARKET.PRICE The function of this application is to store the current prices for Futures/Stocks and Options within the derivatives system. Each of these prices is related to a price set defined in DX.PRICE.SET. Prices within the derivatives module are identified by there price set, contract and the maturity date of that contract.  For example: The CLOSING price for a MAR01 LIFFE Short Sterling Future (FSS) would be identified as: CLOSING-FSS-MAR01 producing a key of CLOSING-19-200103 where contract 19 is the FSS contract code. The application details the previous source of the price data, the date on which it was update and the time of update.

Futures and Stock Prices To record the current market price for a Future or Stock contract the system requires simply that the price be entered into the contract record. With the optional update of the INTEREST.RATE and VOLATILITY of the contact. Therefore the closing price of 10.00 for a March 01 5 Year “T” Note Future( 1) would look as follows.

Option Prices To record the current price for an Option contract the system requires that Strike prices for that option be updated as well as the Call Price and Put Price. There is also the opportunity for that strike price to enter the DELTA, GAMMA and VEGA for the contract. Again there is the optional update of the INTEREST.RATE and VOLATILITY of the contact. So the a strike price of 13.00 on a March 2001 EuroBond Option ( 15) with a call of 12.59 and a put price of 13.01 would look as follows:

The DELTA of a contract represents the rate of change of the option price with respect to the underlying asset. The GAMMA of the contract represents the rate of change of the delta with respect to the underlying asset. The VEGA represents the rate of change of the value with respect to the volatility of the underlying asset.

Futures / Stock Contracts As with DX.PRICE to record the current market price for a Future or Stock contract the system requires simply that the price be entered into the contract record. Again with the optional update of the INTEREST.RATE and VOLATILITY of the contact. Therefore the closing price of 10.00 for a March 01 5 Year “T” Note Future( 1), the CONTRACT.CODE and PRICE.SET should be entered, the application will then select all of the prices for that contract and price set. In order to change the March 01 price search through the record for a maturity of 200103. If the maturity date does not exist then simply add a new multivalue set for the particular maturity date (MAT.DATE).

Option Contracts Again to record the current price for an Option contract the system requires that Strike prices for that option be updated as well as the Call Price and Put Price. There is also the opportunity for that STRIKE price to enter the DELTA, GAMMA and VEGA for the contract. Again there is the optional update of the INTEREST.RATE and VOLATILITY of the contact. So a strike price of 150 on a March 2001 5 Year “T” note Option ( 2) with a call of 151, and a put price of 149 would be updated as follows. The CONTRACT.CODE and PRICE.SET should be entered, the application will the select all of the prices for that contact and price set.  In order to change the March 01 price search through the record for a maturity of 200103. If the maturity date does not exist then simply add a new multivalue set for the particular maturity date (MAT.DATE). For each Maturity Date there is a list of strike prices. So search through the strike (OPT.STRIKE) prices for 150, if that strike does not exist then add a sub-valued set, adding the call (OPT.CALL) and put (OPT.PUT) prices.

Automated Price Capture The purpose of the automated price capture suite is to provide the system with a means to request prices from one of any number of price sources without user intervention. This means that where a price source such as Black and Scholes Garman Kohlhagen FX option prices can be update automatically at the end of exchange.

2.2 Closing Out Trades

Closeouts (or settlements) are used to match opposing buy and sell positions within the same contract to effectively close the open positions and realise any profit or loss due. Once the settlement has occurred the position will be closed-out and any profit/loss will be realised. Commission and charges also due to be paid at settlement time will also be posted. Within the derivatives module there are two methods of closing out trades:• The first involves matching opposing buy and sell positions within the same contract to effectively close the open positions and realise any profit or loss due.• The second form of closeout occurs when a position is held until maturity. This also results in a position being closed and subsequent cash or physical delivery taking place, this is also known as a “cash” or “maturity” settlement. In this case the open trades are in effect settled against a pseudo trade. For futures this trade would be performed at the EDSP (Exchange Delivery Settlement Price). For options no pseudo trades are created, for trades where premium was not paid a trade the trades/transactions are closed out against each other on the same way as a manual closeout, where the premium has already been paid these are Cash Settled against the Original Premium Price. Closeouts can be performed manually, automatically or by the system. In the case of manual closeouts the user selects a customer and a unique contract. For futures this would involve the specification of a contract code, a delivery period. For options this would involve the selection of a contract code, a delivery period, a strike price and the option type (call or put). Additionally, other fields maybe entered to further restrict the selection of trades. All the open trades matching these criteria will then be displayed. The user may then select which trades and how many lots from each trade are to be settled. As long as the total number of buy lots is the same as the total number of sell lots, the close out maybe confirmed.

2.3 Using the Closeout suite to Assign/Expire/Exercise a contract.

Option exercise, expiry, and assignment can either be a manual process, where the user selects the trades and lots to be processed, or an automatic process where the system do the selection. Regardless of the method used to select the transactions, the underlying processing will be identical. If the options are being exercised or assigned, the appropriate underlying transaction will also be created. If the underlying product is a futures contract, the appropriate derivatives trade will be automatically created by the system. If the underlying is a stock, a system call to the SECURITIES module will be made to create the underlying stock transaction. If the option exercises to CASH, the system calls to the FOREX module to create a Spot FX transaction.

Underlying ProductTradeFuture                 A DX trade for the future Cash                 A FX transaction Bond or Stock         A SEC trade

2.4 Revaluation and Margining

This forms part of the core functionality within the module and maybe invoked in many different modes and produce different events. The base of this module forms part of the end of exchange process and therefore will form the part of the end of day processing for the module. The re-valuation module has been developed to allow the valuation, accounting and reporting of futures/stock and options held in the GLOBUS derivatives system. The re-valuation process maybe called for three different reasons.• End of Day batch re-valuation/processing• End of Exchange/Centre re-valuation/processing• On-line ad-hod re-valuations In all three cases the re-valuation calculations performed are the same. The differences are the products to be valued, the prices they should be valued against, and the resultant accounting treatment of the figures produced. Therefore along with the core re-valuation process additional modules will be written around it which will be called as required.  The core re-valuation process consists of three major functions, initial margin, variation margin and collateral allocation. Additional processes include retrieval/calculation or prices, retrieval of trades, posting of accounting entries and reporting of results. These additional processes can be added into the end of exchange (DX.END.OF.EXCHANGE ) as required.

2.4.1 Calculation of Initial Margin

The initial margin (or deposit) is required by counterparties in order to ensure their financial stability in case the opposite party defaults. The initial margin calculation methods vary from exchange to exchange and from broker to broker. In the case of exchange-based futures and options, each clearinghouse or exchange published its initial margin calculation method. These various methods can be implemented, by using the revaluation “black box” technology, and by using a parameter in the contract master file, DX.CONTRACT.MASTER . Associated with each method will be related table maintenance or data extract modules to enable each method to be fully implemented. Full reporting functions, based on the exchanges own reports if applicable, will be included in all initial margin calculations. This will allow the user to easily check all the margin figures including SPAN, spreads and hedges.

2.4.2 Calculation of Variation Margin

The method used to calculate the variation margin (profit/loss) of a position is determined from parameter held in the contract master file. Initially, only the regular contract method (unit price * price differential) will used, but alternatives can be easily added by using the “black box” technology. In the case of options the separate figures will be produced depending when the premium for each contract is paid. If the premium is paid at settlement time then Option variation margin is calculated using the market price or a fair value price. If the premium on the contract has already been paid then the figure is classed as unrealised option profit/loss. This unrealised profit/loss will be reported separately and can often be used in the initial margin calculations e.g. SPAN to reduce the initial margin requirements. Therefore the variation/unrealised option value calculations must be performed before the initial margin calculations.

2.5 RE-VALUATION

Part of the functionality of the GLOBUS Derivatives module is to re-calculate the value of clients or portfolios after the exchanges have closed. This can either be done as part of the overnight batch utility or as an on-line process. This application allows the user to initiate an ad-hoc “what if” revaluation. The DX.REVALUE application allows the entry of the selection criteria defining the trades/positions to be re-valued. Once the entries have been input and authorised the revaluation process, passes control to the “Grey Box” processes.

2.6 Corporate Action Processing

As per the Securities module, new corporate actions are defined in the DIARY.TYPE application. If an event effects contracts defined in the derivatives module then it can be setup as an event in the DX.DIARY application, this is defined by setting the DERIVATIVES flag on the DIARY.TYPE record. The function of the DX.DIARY application is essentially the same as the Securities DIARY application, but is tailored for Derivatives corporate actions. This includes options to alter the lots/strike price/contract size/contract number etc…The derivatives entitlement application DX.ENTITLEMENT acts in much the same way as the Securities ENTITLEMENT application. DX.ENTITLEMENT shows Customer/portfolio entitlements per DX.DIARY event. Each maturity and strike is shown with the new strike, contract size and number of lots. Records are created via DX.DIARY. They will be created as unauthorised. The authorisation of these records is controlled by DX.ENT.ACTION . Entitlement authorisation takes place using DX.ENT.ACTION which runs automated authorisation of DX Entitlements per DX Diary event. Once the EX.DATE has arrived or passed then DX Entitlement records can be authorised.

2.7 Interfaces to Other GLOBUS Modules

2.7.1 Limits

The inclusion of Derivatives within the GLOBUS Limits module adds an extra element of risk control for clients trading in derivatives instruments. The application of Limits within the Derivatives operation applies to all products handled by the module. The LIMIT module provides a control mechanism for the DX.TRADE module and when called at the time of input will check the availability of an authorised credit line for the customers involved with the trade. The LIMIT system is designed to monitor, in real-time, the availability and utilisation of customer limits. Back end reports are available to allow the monitoring of limits for commodities, countries, country group and currencies. The word LIMIT describes a Facility or credit Line available to a customer or group of customers, while the term LIMIT.REFERENCE describes a type of LIMIT, e.g. Futures and Options Limit. As well as allowing for different products, Limits also allows fine-tuning of products into sub-products. Therefore limits can be set up for different classes of contracts, e.g. Bonds, Shares, Currencies or Commodities. The Limit Reference conditions for DX.TRADE are defined using LIMIT.PARAMETER , for example Currency Futures can be set a different limit reference to Currency Options. Whenever a trade takes place for a relevant derivative product and portfolio then a limit check will take place, which will generate an override if a limit has been exceeded. The amount used to update limit utilisation is set by choosing an option from LIM.AMT.VAL.CONT on DX.PARAMETER: This field dictates which value is associated to a trade to update the Limits system.

           1.	Contingent

Calculates a value for the trade using CONTINGENT.VALUE specified in DX.CONTRACT.MASTER number of lots * contingent value

           2.	Value

Calculates a value for the trade based on the following principles :-For futures: number of lots * internal price For options (buyer): number of lots * internal price For options (seller): number of lots * internal strike price

2.7.2 Delivery

The Derivatives module in GLOBUS uses ‘Soft Delivery’ which enables the user to define the output of the delivery messages (in S.W.I.F.T. or printed output) by calling a core routine (EB.HANDOFF) to initiate and pass information to the Delivery system. Delivery messages are generated when whenever a derivatives DX.EVENT.TYPE event is processed i.e. DX.TRADES are entered, amended or reversed. Delivery messages are also generated when a DX.CLOSEOUT is performed. The content of all delivery messages will be based on the DX.TRANSACTION file.  Messages can be produced for any action including corporate actions/option exercise/ assignments etc… Any new event added to the module will therefore be automatically available as having a possible link into the deliveries module. Until the DX.EVENT.TYPE field EB.ACTIVITY field is populated with a delivery activity to perform, the system will not generate any delivery messages. Once a selection of DX.EVENT.TYPE‘s have been populated with an EB.ACTIVITY then processing can take place for those events. As part of this enhancement the DX.TRADE and DX.ORDER applications have been enhanced to include delivery instructions fields used for FX options. These fields take the form of the field held on the GLOBUS FOREX application and are associated with each possible side of the trade. These fields include beneficiary information, counterparty information, inter-bank information, using the same basic defaulting as the FOREX application. This information is used as part of the derivatives originated Swift Messages. Note: this enhancement has been designed to allow the customization of which messages are sent and when they are sent locally. Any messages not currently provided can be added locally by setting up an activity on a particular event (DX.EVENT.TYPE ), whenever this event is raised a message will be passed to the GLOBUS delivery suite.

2.7.3 Customer Positions

The standard CUSTOMER.POSITION has been amended to now include derivatives transactions where the Derivatives module is installed. There are three types of entry into the CUSTOMER.POSITION file. DX, DXVM and DXIM, these being the transaction values, the variation margin values for the transaction and the initial margin value for the customer respectively. Plain DX items report the contingent value of a transaction, the maturity date, the value date, and category along with many other datum.  The DXVM items report the Variation Margin figure generated by the end of exchange revaluation process, along with other data.  The DXIM items report the Initial margin figures for that client, there will only be one of these items per client as Initial Margin cannot be broken down into transaction by transaction based figure as it relies on a group of trades.

2.8 Accounting

Concept GLOBUS Derivatives accounting is event-based – all significant events that may occur in the life of a contract are assigned an event code. Accounting details are associated with these event codes, allowing the Derivatives account entry routines to make the appropriate postings to the appropriate accounts, categories or CRF types at the appropriate times.

Accounting Events Contingent Asset/Liability Own Book portfolios only. On contract initiation (DX.EVENT.TYPE C1) a CRF posting is made representing an off-balance sheet asset/liability active during the contract’s life.  Own Book portfolio buys contract – debit CRF type DXFUTBUY Own Book portfolio sells contract – credit CRF type DXFUTSELL On reversal or complete close-out/maturity of the trade the postings are backed out. For partial closeouts, a pro-rata amount based on the ratio of lots closed to total lots on the trade is backed out.

Commissions and Charges Commissions and charges payable by customers or to brokers are simply posted to the customer account specified in the commission fields for that customer on DX.TRADE . For Own Book portfolios, commissions and charge postings are handled differently. The flag USE.FT.TXN.CODE on DX.EVENT.TYPE is crucial, since this decides whether the P&L should be posted using the category and transaction codes set on the commission posting event type, or whether the category and transaction codes assigned by the GLOBUS standard charge routine CALCULATE.CHARGE should be used.

Revaluation P&L For all external customers, revaluation P&L (variation margin) will be posted to the account input for that customer on DX.TRADE. For Own Book portfolios unrealised P&L calculated by the Derivatives revaluation process will be posted using the P&L category and transaction codes specified on the appropriate DX.EVENT.TYPE record. Posting of revaluation P&L for Own Book portfolios is controlled by the MARGIN.DIFFERENCE parameter in DX.PARAMETER . If this field is set to YES then when a new margin figure has been calculated, the difference between the previous margin amount and the new amount will be posted. If this field is set to NO then the previous margin amount will be reversed and the new margin amount will be posted.

Initial Margin Initial margin is posted in a similar fashion to revaluation P&L – to the customer/broker account for external customers, and to an internal account specified by the category code in DX.EVENT.TYPE for Own Book portfolios. Closeouts Closeouts are posted for Own Book portfolios using the category and transaction codes specified in DX.EVENT.TYPE. For customer or broker closeouts, a choice of account for posting must be confirmed at closeout time.

Accounting Enhancements (G13.1.00 onward) Contingent Postings and Product Categories Setting the new flag CONT.ULYING.VAL on DX.PARAMETER allow the off-balance sheet postings made on entry of an own-book deal to be based solely on the underlying value of the trade. This is particularly useful for own-book OTC Forex options, as the receivable and payable cash amounts are calculated and posted as assets or liabilities in the appropriate currencies.

CONT.ULYING.VAL Description Forex Derivatives (DX.CONTRACT.MASTER DELIVERY.METHOD = ‘CASH’) Other Derivatives NO Existing style Only for futures and options with premium unposted CR or DB CRF asset type Amount – cost of position or contingent value Currency – contract currency CR or DB CRF asset type Amount – cost of position or contingent value Currency – contract currency YES New style All trades CR CRF asset type Amount – underlying receivable ccy amount Currency – receivable currency DB CRF asset type Amount – underlying payable ccy amount Currency – payable currency CR and DB CRF asset type Amount – cost of position Currency – contract 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.

Enhanced Unrealised P&L (Variation Margin) Postings Reval P&L postings may be completely suppressed by setting the new field SUPPRESS.VM.POST on DX.PARAMETER to ‘YES’. The Derivatives revaluation will still calculate figures for reporting purposes but they will not be posted to the accounts. Where P&L is calculated and is to be posted, the new field VM.POST.STYLE allows the bank to select how they wish the posting to be made for the bank’s own book. The selections behave as follows: VM Posting style VM Posting behaviour PL (default) P&L calculated in contract currency. Posted to P&L Category in DX.EVENT.TYPE ‘VM’PLLCCY P&L calculated in contract currency, then converted to Local Currency Posted to P&L Category in DX.EVENT.TYPE ‘VM’PLRP P&L calculated in contract currency. Posted to P&L Category in DX.EVENT.TYPE ‘VM’Sign reversed, posted to Premium Payment account (maintains ‘replacement value’)PLLCCYRP P&L calculated in contract currency, then converted to Local Currency Posted to P&L Category in DX.EVENT.TYPE ‘VM’Sign reversed, posted to Premium Payment account in Premium ccy (maintains ‘replacement value’)

Customer Available Funds Checking If the new flag CHECK.CUST.FUNDS on DX.PARAMETER is set to ‘YES’, the module will calculate a ‘best estimate’ initial margin figure for each transaction input (order or trade) and use the figure generated to block customer funds until the next Initial Margin calculation run (when the funds are physically removed from the customer’s account in any case), and also to make an ‘unblocking’ posting forward dated to the notional maturity date of the deal.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.