Rate Request Logic

Building on the section Curve Definitions above, a curve is actually referenced with a combination of its CurveKey and a RateSource. This allows rates from multiple sources to be included in a single calculation.

A calculation is given a RateSource list, with each entry having a priority and CurveKey template (a CurveKey with wildcards that can match one or many curves). This gives complete flexibility for choosing which RateSources to favour for which curves.

Rates, Surfaces, CorporateEvents and ProcessParameters all reference a CurveKey and a RateSource. This means they indirectly reference a Curve. This makes it possible to gather a Curve from one RateSource and rates for that curve from another RateSource. Each rate request is an independent event. The system attempts to get rates as follows:

• Rates loaded with the analytic call, highest RateSource priority to lowest.
• Rates in the database, highest RateSource priority to lowest. Nb: Each curve has a CurveExpiry. If this value is greater than zero the system will look for older rates for the higher priority RateSource before looking for fresh rates from the lower priority rate source.
• To get ‘a rate’ the system will load the full term structure of rates (from one RateSource only) and apply the curve’s interpolation model to return the requested rate.

Loading Rates

An organisation can load curves, rates etc under its own rate source. Other organisations cannot access these rates. An organisation can use a mix of rates from different rate sources to generate parameters and correlations using their own assumptions (such as length of history and mean reversion settings). These parameters are then stored in the risk engine under the organisation’s RateSource (ie they are private to the organisation).    

An organisation can subscribe to independent rate sets supplied by partners of Vector Risk. The available rate sets are listed in the section Rate Sources in the User Guide.

Reversible Curves

Some curves, notably FX rates are reversible in that the last two fields in the curve key can appear in any order (you can describe an FX spot rate as FX.PRICE.JPY.USD or FX.PRICE.USD.JPY). The convention in the risk engine is that the value should be the number of units of the first currency required for 1 unit of the 2nd currency. So the rates loaded against the above two curves would be approximately 100 or 0.01 respectively.

So what happens if both curve keys exist in the system?

The key thing to remember is that a Curve is attached to a CurveKey which has a direction. So the curve expects rates to be supplied in one direction only. Process parameters and correlations must be generated for this curve (not its twin). In other words the two CurveKeys do not share rates or any other information.

Now, what happens when the risk engine requests a rate the ‘wrong way around’?

So we’ve loaded rates for FX.PRICE.JPY.USD and a pricing function requests a rate for FX.PRICE.USD.JPY. The system knows that ‘PRICE’ curves are reversible (this is a property of the CurveType) so it will find the rates. It achieves this by searching for the rate in the direction requested first, and if not found it searches in the opposite direction. It also knows that ‘PRICE’ curves are invertible, so it will invert the rate before passing it back to the pricing function that requested it. Importantly the Curve is searched for on the hightest priority RateSource in the requested and reverse direction before moving to the next RateSource. This ensures that a CurveKey and its twin cannot both end up in the rate cache for a single calculation (even though both may exist in the database).

The pricing functions in the system are designed to request spot exchange rates against the basc currency. So if the base currency is USD and you have a FX Forward trade that is EUR/GBP the spot rates that will be requested to price the trade are the EUR/USD spot and the GBP/USD spot. This mechanism ensures that all requests will be in the same direction (with Base currency the second of the pair) and all curve evolution in the simulation will be consistent because the curve has only been loaded in one direction in the simulation.

Note: PRICEVOL curves are reversible but not invertible, so a wrong way request for an FX volatility will be successful . The rate from the ‘reverse’ curve will be found and given to the pricing function (as the original rate – not inverted).

So the logic for reversing and inverting the rates only occurs in the GetRate code. The rates are actually held in the ‘rate cache’ in their natural direction (as dictated by the CurveKey they belong to).

The system will look for the curve and its reverse in the primary rate source before moving to the next rate source. This, coupled with the error checking above ensures full control for the customer over which rates are actually used.