Software Development Case Study

The following provides an overview of the software development completed to enable the trading of Non Deliverable Forwards within an existing Foreign Exchange trading system (FXR) for the Treasury Team. Screen shots are from a test environment and the code changes were in Powerbuilder 10 for the front end and SQL Server and Sybase for the back-end. We were involved in writing the initial system in 1998 for Gartmore and have now added the new functionality to a copy of FXR now run by HSBC Middle Office Services on behalf of Gartmore.

Non-Deliverable Forwards

A Non-Deliverable Forward is an over the counter foreign exchange derivative product on a thinly traded or non-convertible currency (referred to as the Restricted Currency) that is cash settled based upon the difference between the agreed forward exchange rate and the subsequently realised fixing rate (spot rate) in a convertible currency (generally the USD).

Programming and Screen Modifications

Treasury Team Treasury will utilise the ‘Timed Pick-up’ screens to execute NDF trades and associated Second Leg FFX trades. NDFs and associated Second Leg FFX trades are highlighted in orange on the ‘Dealer Pool’ screen. In the following example an NDF has been proposed for 152,730,000 SEK (SEK/Swedish Krona being identified as a restricted currency within the test environment) and a second leg trade to cover the exposure to USD of 22,270,000.

The Treasury Dealer highlights the trade they wish to promote to ‘FX to Deal’. In the case of an NDF trade, any associated Second Leg FFX trade will automatically be promoted alongside the original NDF as they must be executed with the same counterparty.

The two trades selected for promotion are now available in the ‘FX to Deal’ screen. Detailed trade information, including fields to confirm the Counterparty and agreed Forward Rates are made available upon the dealer selecting the NDF trade.

As detailed, the NDF must be executed and sent to ‘Validate’ prior to the second leg being execution. The following example shows the Second Leg FFX trade post execution and being sent to ‘Validate’.

The NDF and Second Leg FFX have now been executed and are available in ‘Validate’. The Treasury Dealer must select the required trades for validation and select ‘Finalise’.

Upon validation by the Treasury Dealer the NDF is updated to a status of ‘Validated & Exported – Awaiting Fixing Date’ with the required Swift MT300 being sent via existing infrastructure to the counterparty. The Second Leg FFX is updated to the status of ‘Validated & Exported’ as per existing functionality.

The Cash processing Team will review and propose Close out NDF’s and New NDF’s for the next three month period. In addition Close Out and new Second Leg FFX trades will be proposed and as with the initial execution must be executed with the Counterparty. In the below example a Close out NDF of 3,190,007,747 KRW has been proposed and a New NDF for 6,425,000,000 KRW. In addition a Second Leg FFX Close Out has been proposed for 3,490,000 USD and new Second Leg FFX for 6,990,000.

Treasury The trades proposed by Cash Processing on the Roll date are available in the ‘Timed Pick-up’ screen. These trades are processed through ‘FX to Deal’ and ‘Validate’ as described within the initial execution process on Trade Date. The Close Out Trade does not actually close open NDF’s in FXR, i.e. update the status from ‘Validated & Exported – Awaiting Fixing Date’ to ‘Validated & Exported’, however reverses out the position in the valuation system and agrees the closing rate with the counterparty via an MT300.

Both the Market Convention Trades will be sent to ‘Validate’ to ensure an audit record of the process is maintained. The Treasury Dealer must select the trades requiring validation and select ‘Finalise’. The Market Convention trades will be updated to a status of ‘Validated & Exported’. There are numerous software development database changes associated with these fromt end modifications in 3 different databases.