Trade Store Demo
JavaScript XQuery Other
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.



This file tells you all about the TradeStoreDemo application.

For setup details see setup.txt

The application is designed to acheive the following

1)	Create a realistic repository of trade documents, expressed using the FpML standard
2)	Create daily valuations and risk analyses of the above trades, again expressed using the FpML standard.

The purpose of the above is to allow us to develop a demonstration of a Trade Store using MarkLogic.

Design Decisions

It is not possible to accomplish the above for the full plethora of trade types and currencies that would be found on the books of a large banking institution.

The limitations are data availability and writing calculations for each trade type.

As such I have elected to build a repository of just one trade type - USD interest rate swaps.

The reason for this is that market data is freely available ( via the Federal Reserve Bank ( the Fed ) website ), the resulting risk calculations are sufficiently complex to be 
interesting, and interest rate swaps are a fundamental asset type, forming a significant part of any trading room's portfolio.

Application Description

On a daily basis, the application does the following :

1)	Queries the Fed website and pulls down the most recent deposit and swap rates that have not been previously captured. For any given date we will have deposit rates for 
maturities of 1M,3M and 6M and swap rates for 1Y,2Y,3Y,4Y,5Y,7Y,10Y,30Y.

2)	Calculates discount factors based on these - required for swap calculations. The resulting documents may be found in the 'discountfactors' collection. An example URI is
/rates/USD.DiscountFactors.2012-01-03.xml - the meaning should be clear.

3)  Generates a fixed number of trade documents, with maturities chosen at random from the maturities for which swap rate data is available (1Y,2Y,3Y,4Y,5Y,7Y,10Y,30Y). The application
assumes we act as MarkLogic Bank (MLBK). The side of the trade taken ( pay fixed / pay floating ) is chosen at random, and the 'counterparty' is chosen at random from the list of
counterparties in /config/counterparties.xml. These documents may be found in the 'trade' collection. The resulting document conforms to the FpML specification for a document 
for an interest rate swap. An example URI is /trades/swaps/MLBK-0e3f56-00559173. Note that the 0e3f56 part is part of the md5 hash of the date - so all trades commencing on a 
given date will differ only in the last 8 characters of the URI. MLBK-0e3f56-00559173 is the MarkLogic identifier for the trade and can be found in the tradeId field for MLBK.

4)  Values all current trades and stores the result in a document conforming to the FpML specification for a valuation. These documents can be found in the 'valuations' collection.
An example URI is /trades/swaps/valuations/2012-01-04/MLBK-0e3f56-00559173 - which contains the valuation date and trade id.
5)  Takes the original swap rates and 'bumps' each one independently by 0.01% and computes the resulting discount factors. This provides data that allows interest rate risk analysis
to be undertaken, which is the effect on a portfolio of a change in interest rates. The result is a document equivalent to the existing discount factor document ( see stage 2 ) 
except for the bumped rate, and the resulting changes in derived quantities. These documents can be found in the 'pv01' collection. An example URI is /pv01/USD/2012-01-03/7Y.01.xml - 
this document contains discount factors based on those calculated for 2012-01-03, where the 7Y swap rate only has been bumped.

6)  Values each trade using each 'bumped' set of discount factors and storing the change in value, for each bumping in a document. This document may be found in collection "trade-pv01". An example URI is /trades/swaps/pv01/2012-01-04/MLBK-0e3f56-00559173 comprising the date of the
original discount factors, and the trade id for the trade.

7)  A status mail is sent once per day showing the most recent date for which the above process took place, the start time, end time, no of new trades, total valuations to date, total pv01 calculations to date, total trade population, no of discount factors documents for date ( should always be = 1 ) and number of pv01 documents ( should always be 11 )

General comments :

All files relevant to date X are put in a collection with name X formatted as YYYY-MM-DD ( e.g. 2012-01-05 ). This makes for easy querying using collections.

Valuations and risk analysis are done using xdmp:spawn.

Application Resources

Some example queries can be seen in ad-hoc-query.xqy

Anything starting with insert* is a wrapper to allow an action to be executed in a separate transaction ( or on the task server ) using xdmp:invoke. e.g. insertDiscountFactors.xqy, insertPV01.xqy, insertPV01DiscountFactors.xqy, insertSwap.xqy, insertValuation.xqy

getRates.xqy is responsible for pulling down the rate files from the Fed, parsing them and calling insertDiscountFactors.xqy

doEverything.xqy executes the process outlined in 'Application Description' apart from the status email.
doEmailStatus.xqy sends an email as per the application description.               

showExposure.xqy - shows the different sorts of aggregate queries that can be run. All queries running in 3s or less on

The remaining files should be ignored ...

deleteValuationsForDate.xqy - allows valuations to be deleted for a given date, and allows this task to be spawned if executing for multiple dates

doPV01ForScheduling.xqy - if trade pv01 recalculation needs to take place, this spawns the calculations, but also makes sure enough space is available on the queue. Useful if wanting to recalculate for a number of dates         

doValuationsForScheduling.xqy - same idea as for doPV01ForScheduling.xqy

doSwapGeneration-Strategy1.xqy - in theory different swap generation strategies could be put in place e.g. biasing to a particular counterparty, biasing towards the side taken ( fixed vs floating ) or biasing the selected tenor. The functions that select counterparty / side / tenor are passed as pointers so other strategies could be put in place. Note also that the resulting trades may be stored in specific collections to allow different example portfolios to be shown