External pricing

From Flametree Technologies
Jump to navigation Jump to search


FIA offers a core library of pricing functions that meet the majority of our user's needs. However, in some circumstances the user may wish to introduce additional security types. Reasons typically include:

  • Integration of proprietary pricing code
  • Integration of third-party pricing code
  • New types of security that are not covered by existing models

For complete transparency, the source code for our pricing models is available to all our users under the LGL Open Source licence.

We intend to extend our library of functions over time, and encourage our users to contribute.

Writing a custom pricing function

To write a new pricing function, it may be helpful to examine the source code and pricing convention for one of our existing functions.

At present pricing functions must be written in C or C++, and compiled as dynamic link libraries (DLLs). This is for reasons of speed (pricing functions are one of the main processing bottlenecks in FIA) and flexibility.

Each function must have the following function signature:

 double FT_BOND_PRICE ( long settle, PRICING_QUANTITIES security_data, YIELD_CURVE c, ... )


  • settle is the settlement date for the price being calculated, in Julian date format;
  • FT_BOND_PRICE is the name of the pricing function;
  • PRICING_QUANTITIES is a structure that holds static pricing information for the security, such as maturity date, coupon and coupon frequency;
  • YIELD_CURVE is a structure that holds information about the yield curve used to price the function. FIA typically reprices the same securities multiple times with different yield curves to measure the effects of changes in market conditions;
  • The ellipsis ('...') at the end of the function signature means that additional field can be passed to the pricing function.

The various structures are defined in the include file PricingAPI.h.

Additional pricing fields

Information provided in these fields is enough to price the majority of fixed income securities. However, in some cases additional information is required.

For instance, FIA may hold information about the annualised volatility of a security, and this data may be required to price the option component of a callable bond.

Additional pricing information is passed to pricing functions in the form of a time series. These are set up as follows:

  • The name of the additional data item is supplied in the time_series field in the security master.
  • The pricing signature is extended to include an extra field.

Requirements from the user

 'With great power comes great responsibility'
      Uncle Ben, 'Spiderman' (passim)

The ability to write pricing functions allows a great deal of flexibility to be added.

Writing custom pricing functions requires (at the least) access to a C or C++ compiler that can generate DLLs, and a good knowledge of C/C++.

In particular:

FIA makes no checks that the function signature of user-defined functions is consistent with the extra fields supplied in the TIME_SERIES field. If the two do not match, FIA will probably crash and will certainly give incorrect results. Results of a crash can vary from unexpected halts to destruction of the operating system, requiring a complete reinstall (we have seen this happen).

We are unable to provide assistance with user-written functions apart from provision of this documentation, examples and general advice. If you do not know what you are doing, find someone who does!

Helper functions

FIA's pricing functions include

  • a linear interpolation function
 double InterpolateYield ( double ttm, YIELD_CURVE yc )

that reads yield curve data and a tenor point, and returns a linearly interpolated yield for any point on the curve

  • conversion functions from Julian dates to day, month and year, and vice versa
 long ToJul ( int month, int day, int year )
 void FromJul ( long jul_date, int *month, int *day, int *year )

FIA uses Julian dates for all date calculations. The conversion algorithm is that published by H. Fliegl and T. Van Flanders, Communications of the ACM, Vol. 11, No. 10, October, 1968, page 657.