• Import, Create and Manage Risk Factor Definitions (i.e. EQUITIES, CURRENCIES,...),
• Store large quantities of TIME SERIES (i.e fast retrieval of large amounts of Snapped Prices, Levels)
• Store large quantities of Computed Stochastic Data (Volatilities, Correlations, etc)
• Store Time-Stamped Stochastic data to compute changes of Volatility and Correlations, Volatility of Volatility, Mean Reversion, etc

• Automatic Risk Factor Import from external source (Excel, Feeds, Flat Files).
• Automatic Creation and Normalization of new Risk Factors.
• Market Data Definition Management.
• Scrubbing and filtering policies applied to external data.
• Time Series Price Management (Reordering, Computing Missing Points.
• Export to external systems.
• Store computed stochastic variables such as volatilities, correlations, forward volatilities and Correlations, Mean-Reversions
• 
  
  Market Data Entities are separated into three sub-groups:
  
  
  
  
  1. The Risk Factor Import and Export Tables.
  2. The asset and Risk Factor Vertex Definition
  3. The Risk Factor Value Storage.

  

  Continue...

   

• ACCOUNTS
  The ACCOUNTS binds the Trade with the Paying and Receiving Parties Netting Agrreement and Colllateral, Credit Tags and dimensions can be attached to both position and account.
  • COUNTERPARTY (The Tag Hierarchy definition).
  • OBLIGOR (The Obligor for Credit Sensitive Assets).
  • TAG (Credit Tag Definitions.
  • DIMENSION (The Dimension Category).
  DEFAULT_PROBABILITY SURVIVAL MARGINAL-CONDITIONAL HAZARD TRANSITION OBLIGOR_CORRELATION
  • RATING_GROUP_NAME
  Defines the Rating System
• RATING
defines each individual Rating Characteristics
• RATING_WEIGHT defines each rating weight applicable to OCDE and non-OCDE corporations and banks.
• RECOVERY: RECOVERY_RANK RECOVERY_GROUP,RECOVERY_GROUP_NAME determine the Recovery Groups available to the user.
• COUNTRY, COUNTRY_VIEW, DEVALUATION
• The Credit Module leverages most of its power from Group definitions.
  
  Groups are not available to Guests as they only can access a single Group (i.e. the  Default Group) which is the DefaultGroupId.
  Active Users can define unlimited amounts of Groups that are activated through the Default Data Object. It is however the responsibility of each user to maintain these groups in a reasonable manner. System administrators and users can however always delete inactive groups and their data.
  
  Each Group of Data has an active Group Identifier. This identifier is bounds to the user's active session through the Default Data Schema. This configuration allows users to stored multiple copies of data for sequences simulations, scenario management, etc.
  
  
  

What you need to know about the Position Schema:

The Position Schema is an essential component of  PositionManager, Cash-Flow-Manager and Implied Volatility Manager.

The Position Schema unites two separate object oriented hierarchies:

The Contract Hierarchy.
The Instrument Hierarchy.


Every Trade is defined with a Common Header, also known as the trade envelope. This header or envelope is called the position definition, The position definition binds all the terms and conditions that are part of all trades:
As such, the position serves as the key between other trade entities. such as the trade's settlement flows, the exposures Legs, option or exchange traded future terms and conditions.

The Common Header or Trade Envelope,  contains all the terms and conditions that are relevant to the Trade as a whole. (The Trade Name, the Asset Type, The Trade Identifier, The Tags, The Account (the Paying/Receiving Party) the Settlement Schedule, etc.. This data is stored in the POSITION table.

As mentioned previously, the POSITION binds other instrument entities together through the Position identifier. The Position is always related to an Exposure based entity (usually the EXPOSURE table or the Option table (called OPT, since OPTION is a reserved ANSI keyword.),
The Exposure (also known as the Trade Exposure or Trade Leg) can have attached one or multiple events or flows, whereas the option (OPT) tables can have different contingent definitions attached (path dependency, barriers, exercises schedules)



Position / Trades Tables Organization:

• POSITION_TAG :Binding POSITION - TAG - DIMENSION
  The POSITION_TAG table binds positions, Tags and dimensions so multiple tags and dimensions can be attached to the same
  • trade
   
  • TAGS (The Tag Hierarchy definition). Associates a Tag hierarchy to it's dimension.
  • DIMENSION (The Dimension Hierarchy).
    
  Each Dimension holds a tagged tree definition. A tagged tree is the hierarchy of tgas associated to the same dimension. Every Dimension holds a Root tag, where alll other tags are attached. The root always accumulates the total of that dimensions. Risksvr™ accepts a maximum of 10'000 Dimensions. Which is more than sufficient even for the most far fetched analysis. Dimensions are often invoked by their Id rather than their name. Although both risksvr™ and Financial-Risk-Manager treat these two interchangeably. There are actually two kinds of Dimensions.
  1. Pre-Defined Engine Dimensions.
     • Position, Accounts, Counterparties, Trade Identifiers, Portfolio, Country, Rating, etc.
     • Yield curve Time Buckets.
     • Risk Factor Accumulator.
     • Dynamic Combined Return Slicer.
     • Benchmark Return Slicer.
• Event Slicer.
1. User Defined Dimensions
   • User defined Tags.

• SETTLEMENT_FLOWS
if the Trade includes one or multiple settlements.
• OPT Note: OPTION is a reserved ANSI SQL reserved keyword!
  The OPT can further specialize into:
  • OPT_AVERAGE (For Asian and Look-back Options).
  • OPT_BARRIER (For Barrier Options).
  • OPT_EXERCISE (For Bermudan, Callable, American Exercises).
• FUTURE not to be confused with FUTURES

Trade Exposure - Legs

• EXPOSURE
The Exposure Table defines each payable or receivable leg that is part of the Trade.
Each Exposures might additionally have:
• FIX_FLOWS (For Fixed and Bullet Cash-Flows).
• FLOAT_FLOWS (For Flows Dependant on Reset Index, Contingent Claims Equity Streams and Commodity Streams).
• BARRIER_FLOWS (For Barrier Related Floating Events
• PAYMENTS (For Fixed Notional Exchange, Optional Flow Attachable to each Exposure Leg)
• EXPOSURE "INHERITANCE" or "SPECIALISATION"
Depending on the Type of Trade involved EXposures might be replaced by the folllowing specialized Table. This approach is akin to "Specialisation" for Templates or "Inheritance" when dealing with the instantiated objects:
• CDO_TRANCH: Multiple Tranches define One side of the Collateralized Deal.
• ASSET_EXPOSURE (An Index or Benchmark Trade includes Multiple Equity in one single.