FinancialInstrument-package: Construct, manage and store contract specifications for...

FinancialInstrument-packageR Documentation

Construct, manage and store contract specifications for trading

Description

Transaction-oriented infrastructure for defining tradable instruments based on their contract specifications. Construct and manage the definition of any asset class, including derivatives, exotics and currencies. Potentially useful for portfolio accounting, backtesting, pre-trade pricing and other financial research. Still in active development.

Details

The FinancialInstrument package provides a construct for defining and storing meta-data for tradable contracts (referred to as instruments, e.g., stocks, futures, options, etc.). It can be used to create any asset class and derivatives, across multiple currencies.

FinancialInstrument was originally part of a companion package, blotter, that provides portfolio accounting functionality. Blotter accumulates transactions into positions, then into portfolios and an account. FinancialInstrument is used to contain the meta-data about an instrument, which blotter uses to calculate the notional value of positions and the resulting P&L. FinancialInstrument, however, has plenty of utility beyond portfolio accounting, and was carved out so that others might take advantage of its functionality.

As used here, 'instruments' are S3 objects of type 'instrument' or a subclass thereof that define contract specifications for price series for a tradable contract, such as corn futures or IBM common stock. When defined as instruments, these objects are extended to include descriptive information and contract specifications that help identify and value the contract.

A simple example of an instrument is a common stock. An instrument can be defined in brief terms with an identifier (e.g., "IBM"). Beyond the primary identifier, additional identifiers may be added as well and will work as 'aliases'. Any identifier will do – Bloomberg, Reuters-RIC, CUSIP, etc. – as long as it's unique to the workspace. In addition, a stock price will be denominated in a currency (e.g., "USD") and will have a specific tick size which is the minimum amount that the price can be quoted and transacted in (e.g., $0.01). We also define a 'multiplier' that is used when calculating the notional value of a position or transaction using a quantity and price (sometimes called a contract multiplier). For a stock it's usually '1'.

More care is needed when dealing with complex instruments, like futures. First, we have to define a future as a root contract. This root is not tradable unto itself, but is used to generate a series of futures which are tradable and expire through time. The root contract will provide an identifier (e.g., 'C' for the CME's corn contract), a denomination currency, a multiplier (one futures contract will cover multiple items) and a minimum tick size. From that definition, a series of expiring contracts can be generated ("C_H08", "C_Z08", etc.) by specifying a suffix to be associated with the series, usually something like 'Z9' or 'Mar10' denoting expiration and year. As you might expect, options are treated similarly. The package also includes constructors for certain synthetic instruments, such as spreads.

FinancialInstrument doesn't try to exhaust the possibilities of attributes, so it instead allows for flexibility. If you wanted to add an attribute to tag the exchange the instrument is listed on, just add it when defining the instrument (e.g., future('CL', multiplier=1000, currency="USD", tick_size=.01, exchange="CME", description="Crude Light futures")). Or, as you can see, we've found it useful to add a field with more slightly more detail, such as description='IBM Common Stock'. You can also add attribute after the instrument has been created using instrument_attr as shown in the examples section below.

Defining instruments can be tedious, so we've also included a CSV loader, load.instruments, in the package, as well as some functions that will update instruments with data downloaded from the internet. See, e.g., update_instruments.yahoo, update_instruments.TTR, update_instruments.morningstar, update_instruments.iShares. You can also update an instrument using the details of another one with update_instruments.instrument which can be useful for creating a new future_series from an expiring one.

Once you've defined all these instruments (we keep hundreds or thousands of them in our environments), you can save the instrument environment using saveInstruments. When you start a fresh R session, you can load your instrument definitions using loadInstruments. We maintain an instrument.RData file that contains definitions for all instruments for which we have market data on disk.

You may want to use setSymbolLookup.FI to define where and how your market data are stored so that getSymbols will work for you.

FinancialInstrument stores instrument definitions in an internal package-level environment named '.instrument', rather than in '.GlobalEnv'. Users should access instrument definitions through exported functions such as 'getInstrument()', 'ls_instruments()', 'saveInstruments()', and 'loadInstruments()'.

We store instruments in their own environment for two reasons. First, it keeps the user's workspace less cluttered and lowers the probability of clobbering something. Second, it allows the user to save and re-use the .instrument environment in other workspaces. Objects created with FinancialInstrument may be directly manipulated as any other object, but in our use so far we've found that it's relatively rare to do so. Use the getInstrument function to query the contract specs of a particular instrument from the environment.

Author(s)

Maintainer: Justin M. Shea jshea01@uic.edu [contributor]

Authors:

  • Peter Carl

  • Brian G. Peterson

  • Garrett See

  • Ross Bennett

See Also

Useful links:


FinancialInstrument documentation built on Aug. 4, 2026, 5:10 p.m.