Product Coding Scheme in RiskLib.NET

Rules of RiskLib Product Coding Scheme

Why Product Coding Scheme

If your company participates many markets and investment instruments, it is very difficult to consolidate so many different sources of market and position data. For example, if you trade US stocks only, you might have IBM stored in a field in your closing price and position tables. But after your portfolio extended into European markets, which are using alphabet as stock code, you will find it is not a good idea to just store the US stock code as a unique key in the table. For many Asian stock markets, including Japan, Hong Kong, Korea, and Taiwan, they are using numbers as stock code.

For fixed-income instruments, that is a more complicated case. Although all issues of bonds have ISIN (International Securities Identification Number), there are still many indices or interests rates have no common coding. ISIN is a good choice for bonds, but we need more.

Global futures market has its own coding scheme, I prefer to use Reuters' codes.

Product Coding Scheme is for Assets or Indices only, not for OTC or derivatives trades

Please note only standard assets (securities or indices) need standardized coding. Over-the-Counter or derivatives trades are usually one of a kind for each trade and is not necessary to define in a coding scheme.

Product Coding Scheme Used in Current Systems

I will introduce coding scheme used in Reuters and Bloomberg later.

Objective of RiskLib Product Coding Scheme

Where is a perfect coding scheme? I don't know. I think a good coding scheme is a key of good risk management system, unless your portfolio is simple and local. I think a good coding scheme should have the following attributes:

• short
• product type can be recognized from the code itself
• connect to offical system