You are on page 1of 82

Dynamic Tables

32
2014-07-25
MUREX+INTEGRATION
Murex Integration DMM Team

All intellectual property rights and other proprietary rights in and associated with the whole and every part of this
document (including all text, logos, graphics and images) shall at all times remain vested in Murex S.A.S.. You shall do all
that is necessary to protect these rights, including but not limited to, taking all measures necessary to keep confidential
the information contained herein and/or notified by Murex S.A.S. and not, directly or indirectly, using or divulging, or
allowing to be used or divulged such information to or by any third party. In addition, you shall not reproduce, copy,
distribute, republish, download, display, post or transmit this document or any part thereof in any form or by any means
whatsoever. You may also not mirror any content contained herein on any other server. Nothing in this document or the
present notice shall be construed as conferring any license of any of Murex S.A.S.'s intellectual property rights, whether
by estoppel, implication or otherwise. Any unauthorised use of any content contained in this document may violate
copyright laws, trademark laws, the laws of privacy and publicity, and communications regulations and statutes. If you are
aware of any unauthorised use affecting our rights and interests in and associated with this document, you will
immediately notify Murex S.A.S..
Table of Contents
Dynamic Tables....................................................................................................................................................................1
1 - Introduction..........................................................................................................................................................1
1.1 - Document Purpose....................................................................................................................................1
1.2 - Datamart Overview....................................................................................................................................1
1.3 - Dynamic Table Definition..........................................................................................................................2
1.4 - Dynamic Table Description.......................................................................................................................4
2 - Access Menus.....................................................................................................................................................6
2.1 - From a Configurator Session....................................................................................................................6
2.2 - From an End-User Session.......................................................................................................................7
2.3 - Dynamic Tables Management...................................................................................................................9
3 - Configuration.......................................................................................................................................................9
3.1 - Creation.....................................................................................................................................................9
3.2 - Naming conventions................................................................................................................................10
3.3 - Dynamic Creation Structure....................................................................................................................11
3.3.1 - Class type.....................................................................................................................................11
3.3.1.1 - Transaction.........................................................................................................................11
3.3.1.2 - Accounting..........................................................................................................................12
3.3.1.3 - Accounting Inventory Balances...........................................................................................13
3.3.1.4 - Accounting Inventory Entries..............................................................................................13
3.3.1.5 - Audit of Workflow Decision Definition.................................................................................14
3.3.1.6 - Copy Creation.....................................................................................................................15
3.3.1.7 - External...............................................................................................................................15
3.3.1.8 - STP Rights..........................................................................................................................15
3.3.1.9 - STP Rights Audit.................................................................................................................16
3.3.1.10 - Trade Version Audit..........................................................................................................16
3.3.1.11 - Simulation.........................................................................................................................17
3.3.1.12 - PL variance and Theta Analysis.......................................................................................18
3.3.1.13 - Data dictionary service......................................................................................................18
3.3.1.14 - MLC..................................................................................................................................19
3.3.1.15 - PL entries generator (simulation) & PL entries generator (Pl variance)............................19
3.3.1.16 - Hedge...............................................................................................................................19
3.3.1.17 - Deliverable Cash...............................................................................................................20
3.3.1.18 - Classification trees............................................................................................................21
3.3.1.19 - Liquidation position statements.........................................................................................21
3.3.1.20 - Cash position statements..................................................................................................22
3.3.1.21 - Securities position statements..........................................................................................23
3.3.1.22 - Corporate actions static data............................................................................................24
3.3.1.23 - Order.................................................................................................................................25
3.3.1.24 - PostTrade Workflow Audit................................................................................................26
3.3.1.25 - LiveBook...........................................................................................................................26
3.3.1.26 - Collateral exchange..........................................................................................................29
3.3.2 - Table History, Table Alias (Display), DBF Label and Other..........................................................29
3.3.3 - Table Fields List............................................................................................................................31
3.3.4 - Horizontal Fields...........................................................................................................................32
3.3.4.1 - Default Horizontal Field.......................................................................................................33
3.3.4.2 - Alternate Id horizontal field.................................................................................................34
3.3.5 - Interactive Fields...........................................................................................................................35
3.3.5.1 - Configuration - general.......................................................................................................35
3.3.5.2 - Field input options...............................................................................................................36
3.3.5.3 - Retrieval..............................................................................................................................37
3.3.5.4 - Default interactive parameters............................................................................................38
3.4 - Dynamic Creation Flags..........................................................................................................................40

i
Table of Contents
Dynamic Tables
3.4.1 - Creation Code...............................................................................................................................40
3.4.2 - Consolidated View........................................................................................................................41
3.4.3 - Disable Compute...........................................................................................................................42
3.4.4 - Duplication....................................................................................................................................43
3.5 - Default Configuration...............................................................................................................................44
3.5.1 - Underlying Type, built on..............................................................................................................45
3.5.2 - Calculation Unit (for PL Variance class type)................................................................................46
3.5.3 - Load by portfolio / position flag.....................................................................................................46
3.5.4 - Classification type and Breakdown mode flags.............................................................................47
3.5.5 - Load by portfolio flag.....................................................................................................................47
3.5.6 - Date Selection...............................................................................................................................48
3.5.6.1 - Fixed Dates (manually entered by the user).......................................................................50
3.5.6.2 - Variable Dates....................................................................................................................51
3.5.7 - Pre-filter Selection.........................................................................................................................54
3.5.8 - Position statement selection.........................................................................................................57
3.5.9 - Post-filter Selection.......................................................................................................................58
4 - Tests..................................................................................................................................................................58
4.1 - Running a 'Test on screen'......................................................................................................................58
4.2 - Analyzing Results....................................................................................................................................60
4.3 - Running a 'Test & Save on Disk'.............................................................................................................63
5 - Conclusion.........................................................................................................................................................64

Appendix 1 - Best Practices...............................................................................................................................................65


1.1 - Category: Risk................................................................................................................................................65
1.2 - Category: Position keeping.............................................................................................................................65
1.3 - Category: Market Data...................................................................................................................................66
1.4 - Category: Audit and Control...........................................................................................................................66
1.5 - Category: Accounting.....................................................................................................................................67
1.6 - Category: Finance..........................................................................................................................................67
1.7 - Category: Static Data / Configuration.............................................................................................................67
1.8 - Category: Hedge............................................................................................................................................67
1.9 - Category: Order..............................................................................................................................................68

Appendix 2 - Transaction Class Type...............................................................................................................................69


2.1 - Introduction.....................................................................................................................................................69
2.2 - DYN_TRNRP_PL: Trades description + Profit & Loss (P&L).........................................................................69
2.3 - DYN_TRNRP_CS...........................................................................................................................................69
2.4 - DYN_TRNRP_DT: Deals Details....................................................................................................................71
2.5 - DYN_TRNRP_XG: Fixing...............................................................................................................................71
2.6 - DYN_TRNRP_SV: Sensitivities......................................................................................................................72
2.7 - DYN_TRNRP_MK: Market Operations...........................................................................................................72
2.8 - DYN_TRNRP_MV: Profit &Loss + Market Value...........................................................................................75
2.9 - DYN_TRNRP_CD: Call-Deposits...................................................................................................................75
2.10 - DYN_TRNRP_OK........................................................................................................................................76

Appendix 3 - Data Dictionary Service Class Type...........................................................................................................77

Appendix 4 - Flags..............................................................................................................................................................78

ii
Dynamic Tables

This document illustrates the first steps to configure dynamic tables to feed the Datamart.

1 - Introduction

1.1 - Document Purpose

Dynamic tables, which constitute the basis of each reporting table, are intensively described throughout this document:
first, a full description of dynamic tables is provided (section 3), covering the definition and use of each section
characterizing them and the procedure followed in designing a new table.

The next part of the document describes the Test on screen, a technique used to preview the results that are output to the
reporting tables (section 4). It can be used to check the consistency of the data in the system, or for intermediate results.

1.2 - Datamart Overview

The Datamart relies on the Datapublisher service (also called DAP) in order to compute its data. The Datapublisher is
used to access stored data from the Mx Financial database and computed data in order to store them into the Datamart.
These extractions can then be used for particular purposes by external systems or by some MX processes (like the
simulation viewer for example).

Figure 1 Datapublisher service

The computations performed by the DAP rely, in most cases, on a dynamic table definition, or on the definition of the
simulation view referenced by that dynamic table (if any). The reporting tables of the datamart are then populated
according to the datamart mapping definition, the tool which defines the relation between each reporting table and
dynamic table.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 1
Dynamic Tables, 2014-07-25

Figure 2 Datamart overview

The feeders and batches define the extractions to be made: they contain the list of tables to populate, the filters, etc. They
are launched by end-users from an Mx session, and batches of feeders can be scheduled to run in End Of Day (EOD)
processing scripts.

1.3 - Dynamic Table Definition

Dynamic tables, also known as dynamic tables or datamart views, define the data to be computed by the DAP in order to
feed the datamart tables. Note that each reporting table is linked to a certain mode of computation , such as dynamic table
for instance, which determines the way in which the content of the table is computed. When datamart tables are populated
using feeders, details of the computation mode are carried in each table definition, defined at the Datamart mapping level
(see paragraph Datamart Mapping in the Datamart Configuration (document ID 1739) documentation).

A dynamic table is actually a flat list of fields giving access to MX computed data with a denormalized access to the Mx
data model. The fields are derived from various tables for transaction storage, tables for accounting entries, payment
flows, simulation, etc.

In addition, dynamic tables allow access to computed data not available in the Mx data model, such as P&L, MV, cash
flow schedules, sensitivities, etc.

The dynamic table fields can be extended by user definable fields.

The output can be customized by modifying the computation context : computation date, market data set,
detailed/consolidated mode etc.

The mechanism used in dynamic tables to compute the calculations is shared by all other system applications, mainly
those used in the simulation and P&L notepads, making the results homogeneous throughout the system.

The different kind of data accessed by the dynamic tables are:

• Transaction related : access to the shared computation engine


• Simulation : access to user simulation views
• Accounting and payments modules
• Any static table of MxG production data model

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 2
Dynamic Tables, 2014-07-25

... and many others

Dynamic tables can be accessed from the menu Data extraction/Datamart/dynamic tables in a Configurator session, and
from MiddleOffice/Reporting/DynamicTablesConfiguration in an End-user session.

Figure 3 Dynamic table configuration

A dynamic table is mainly defined by a Class type which determines the kind of data accessed by the current dynamic
table (figure 3).

The table fields, which form the dynamic table set of fields, are inherited from the Class type and the subclass of that
class. The Horizontal fields are user definable fields, built using table fields and Mx parser functions. And the Interactive
fields are parameter-like fields, whose value is determined at run-time by end-users. They are used for filtering purposes
or for reorganization of data.

In addition, special flags allow the enhancement of the data display, such as the duplication of lines, consolidation
according to a certain grouping key, disabling some computations, etc.

Finally, a dynamic table may require some default configuration: setting the computing dates for revaluation of data,
pre-filters whose conditions are verified before the computations, and post-filters which filter the results.

Details on the configuration and use of dynamic tables is discussed in the following paragraphs.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 3
Dynamic Tables, 2014-07-25

1.4 - Dynamic Table Description

The Murex users have access to a functional documentation of MX.3 dynamic tables; this documentation concerns class
type, creation class, native dynamic field and creation flag sections. Each section is composed by a short description
which is a quick presentation and a long description to provide additional details.

For class type and creation class section, click on the character '?' near the section's selection to access to the
description.

Figure 4: Dynamic table description for class type and creation class sections.

For native dynamic table fields section: click on the selection field button, then right click on the field and select "Help".

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 4
Dynamic Tables, 2014-07-25

Figure 5: Dynamic table description for field section

For creation flag section: click on the drop down list, then right click on the item and select "Help".

Figure 6: Dynamic table description for creation code section

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 5
Dynamic Tables, 2014-07-25

2 - Access Menus

The scripts used to populate the reporting tables can be defined from a Configurator session. In this case they are known
as Reporting (or Datamart) views. They can also be defined by end-users, in which case they are called Dynamic tables.

2.1 - From a Configurator Session

From a Configurator session, the Dynamic tables can be accessed from Data extraction/Datamart/Views . There are two
different sets of dynamic tables:

• Murex dynamic tables: The Murex set is used to populate Murex reporting tables. These tables are usually
business-oriented, thereby targeting specific needs, such as P&L computations or Cash Flow computations. The
Datamart tables delivered by Murex are associated with views of the Murex set. Access to Murex views is locked
by an access code.
• User dynamic tables: The Client set may contain custom dynamic tables, used to populate custom reporting
tables defined by the client, and not available in Murex tables.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 6
Dynamic Tables, 2014-07-25

Figure 7 Accessing dynamic tables from a configurator session

2.2 - From an End-User Session

From an End-user session, the Dynamic tables can be accessed from Middle Office/Reporting/Dynamic tables
configuration . In addition to the two previous sets accessible from a Configurator session, labelled here Murex report
Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 7
Dynamic Tables, 2014-07-25

dynamic tables and User report dynamic tables , two more sets of dynamic tables are present:

• Murex additional dynamic tables: only used in P&L notepads.


• User additional dynamic tables: only used in the Trade query.

Figure 8 Accessing dynamic tables from an end-user session

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 8
Dynamic Tables, 2014-07-25

2.3 - Dynamic Tables Management

By entering one of the menus leading to the Dynamic tables, the list of existing Murex or User dynamic tables are
accessed (figure 9). From this screen, using the menus or the keyboard, it is possible to:

• Create: Edit/Insert or Insert key.


• Delete: Edit/Delete or Delete key.
• Modify: Edit/Open or spacebar .
• Duplicate: Edit/Duplicate
• Import from one of the three other sets of dynamic tables: File/Import. Here, the name of the table cannot be
changed unlike the case of duplicate views.

Figure 9 Managing dynamic tables

By right clicking on one of the dynamic tables, it is possible to test the result of this view by doing a Test on screen
(section 4).

It is also possible to save the result in a DBF table in the production database by choosing Test and Save on Disk.

3 - Configuration

3.1 - Creation

To define a new dynamic table, go to Edit/Insert or press the Insert key (figure 10).

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 9
Dynamic Tables, 2014-07-25

Figure 10 : Dynamic Table Definition

The dynamic table should be identified using a unique Label . The naming conventions used by Mx to identify dynamic
tables are summarized in the next section. The Description should be brief but clear. It should indicate very concisely the
content of the table.

3.2 - Naming conventions

The naming convention that governs Mx dynamic table creation can be summarized as follows:

• The dynamic table should start with the prefix DYN_ followed by the name of the reporting table to populate:
DYN_<Table name prefix>.
• The table name should be entered as follows: CT[SS]_[C][0] [1] [2][_index], where:
♦ [] indicates an optional argument
♦ CT stands for the category (PL for Profits and losses, AU for audit, ...)
♦ SS indicates the subcategory
♦ C is used for consolidated results
♦ 0, 1, 2 reflects the reporting dates (relative to the view computation)
♦ index ( if necessary)

Examples: CS, PL_C012

This technique facilitates the visualization of the Datamart mapping, and helps in locating an error when it occurs. As
such, customers are advised to use a similar logic to name their views.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 10
Dynamic Tables, 2014-07-25

3.3 - Dynamic Creation Structure

3.3.1 - Class type

Different types of creation class types are available (figure 11). Depending on the creation class selected, the dynamic
creation table screen varies slightly.

Figure 11 : Class type selection

The main creation classes are described in the following paragraphs.

3.3.1.1 - Transaction

The Transaction class type offers a set of calculations based on the transaction database. The table produced can contain
results such as profit & loss, Greeks, cash flows, variance analysis, etc.

When selecting the transaction class type, a class has to be specified: for instance, DYN_TRNRP_PL displays one line
per transaction, DYN_TRNRP_CS outputs one line per cash flow and DYN_TRNRP_XG one line per fixing.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 11
Dynamic Tables, 2014-07-25

Figure 12 : Transaction Class type

3.3.1.2 - Accounting

The Accounting class type extracts data from the accounting journal.

Figure 13 : Accounting class type

This dynamic table returns the accounting entries generated between Date0 and Date1 where:

• Date0: refers to the lower boundary date. If there's no selection, it's set to Inception.
• Date1: refers to the upper boundary date.

• Date2 is the computing date's reference for datamart reports. It's only used as a key and doesn't affect the
dynamic table output.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 12
Dynamic Tables, 2014-07-25

Figure 14: Settings for retrieving accounting entries between origin monthly and yesterday.

3.3.1.3 - Accounting Inventory Balances

The Accounting inventory balances class allows to retrieve data from the Inventory accounting balances (accessible from
an End-user session under Accounting -> Query -> Inventory account balances).

The set of fields available are inherited from the view which is defined at the level of the dynamic table definition. The
dictionary and the view repository are shared with the end-user screen.

Figure 15: Accounting inventory balances class type

The execution parameters give access to:

• a filter on Balance date


• a filter on System date
• a generic HQL filter

Figure 16: Execution parameters

3.3.1.4 - Accounting Inventory Entries

The Accounting inventory entries class allows to retrieve data from the Inventory accounting journal (accessible from an
End-user session under Accounting -> Query -> Journal of inventory entries).

The set of fields available are inherited from the view which is defined at the level of the dynamic table definition. The
dictionary and the view repository are shared with the end-user screen.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 13
Dynamic Tables, 2014-07-25

Figure 17: Accounting inventory entries class type

The execution parameters give access to:

• a filter on Entry date


• a filter on System date
• a generic HQL filter

Figure 18: Execution parameters

3.3.1.5 - Audit of Workflow Decision Definition

The Audit of Workflow Decision Definition class type is used to generate reports on decision rule history. Workflow
decision rule feature provides a way to expose workflow business logic and configuration points to end users through a
dedicated GUI. Maintenance of this logic is simplified and open to non-technical users as it is not required anymore to
navigate through the MxML Exchange technical configuration GUI. Audit functionalities are available to ensure appropriate
tracking and control operational risk resulting from a rule modification. For instance, static data mapping implemented with
data dictionary best matching formulae can be exposed with a workflow decision rule.

Figure 19: Audit of Workflow Decision Definition class type

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 14
Dynamic Tables, 2014-07-25

3.3.1.6 - Copy Creation

The Copy creation class type is used mainly to filter data from an existing table of the system, and to store filtered results
in a temporary table to be read by the report. The production table to be copied has to be specified: for example
TRN_CPDF_DBF to access the counterparty table, and TRN_PFLD_DBF to get the portfolio table (figure 20).

Figure 20: Copy creation class type

To execute a dynamic table Copy creation, an union should be created in Mx for this table. For the previous example for
the union trn_cpdf.xdb should be available in Mx.

When used with the Datamart, copy creations can be replaced by tables based on SQL statements. SQL based tables
support filtering and parameters; however they cannot be used to call parser functions. SQL tables are described in detail
in the Datamart Configuration (document ID 1739) documentation.

3.3.1.7 - External

The External class type are specialized tables used in conjunction with the Mreport module (for example: market
parameters file for CURR trades). They are not used with the Datamart and therefore should not be used.

3.3.1.8 - STP Rights

This class gives access to end-user straight through processing (STP) rights template.

These rights gives the possibility to a certain group of users to perform actions on financial objects. They are given based
on different criteria:

• BO Type - Contract: contract component typologies


• BO Type - Package: Package Typologies
• Validation Statuses of Financial Contracts and Packages.
• Source Module
• Event

For more information on STP Rights, refer to STP Rights document (document ID 1776) .

The rights templates are defined in a SUPERVISOR session under STP Rights menu using a set of user definable views to
represent the configuration of the rights.

To retrieve a STP view configuration and export it to the Datamart, use a dynamic table of Class type set to STP Rights. A
view has to be selected from the drop-down list in the View field (figure 25). Open the view to check its definition in the
viewer and double click on it to select it. The table fields are then inherited from the selected View.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 15
Dynamic Tables, 2014-07-25

Figure 21: STP Rights Class

3.3.1.9 - STP Rights Audit

This Class type gives access to the modifications end-user had done on rights template of STP rights (section 3.3.1.8).

The audit on STP rights is available under the menu: MiddleOffice/Reporting/Audit Trail: STP Rights.

To retrieve information from a STP audit view, it is possible to use a dynamic table of Class type set to STP Rights Audit. A
view has to be selected from the drop-down list in the View field (figure 22). Open the view to check its definition in the
viewer and double click on it to select it. The table fields are then inherited from the selected View.

Figure 22: STP Rights Audit Class

Note that in order to add a new view to the drop down list, the user should add it in an end-user session under the
following menu: MiddleOffice/Reporting/Audit Trail: STP Rights.

3.3.1.10 - Trade Version Audit

This Class type gives access to the changes end-user has done on trades following any market operation. For more
information on how to activate the generation of the trade audit information, refer to XML Audit document (document ID
2315) .

The Trade Version Audit dynamic table is a view based dynamic table. These views can be added, edited or displayed in
the following menu:

MiddleOffice/Reporting/Audit Trail: Trade version diff or by right clicking on the trade in the trade query menu and choosing
History, then clicking on Audit (Figure 23).

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 16
Dynamic Tables, 2014-07-25

Figure 23: Access for Trade Version Audit User Defined View

To retrieve information from a Trade version audit view and extract them to the Datamart, a dynamic table of Class type
set to Trade version audit should be used. A view has to be selected from the drop-down list in the View field (figure Error:
Reference source not found). Open the view to check its definition in the viewer and double click on it to select it. The
table fields are then inherited from the selected View.

Figure 24: Trade Version Audit Class

3.3.1.11 - Simulation

This class gives access to end-user simulation views, predefined in the Viewer of the Simulation/Simulation/Portfolio
Simulation (detailed) menu.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 17
Dynamic Tables, 2014-07-25

Once the Class type is set to Simulation views , a view has to be selected from the drop-down list in the View field (figure
25). Open the view to check its definition in the viewer and double click on it to select it. The table fields are then inherited
from the selected View.

Figure 25 : Simulation Views Class

Note that a new view can be inserted at this stage, by pressing the Insert key in the list of User Defined Views.

3.3.1.12 - PL variance and Theta Analysis

PL Variance and Theta Analysis classes access the user defined scenarios previously created in
Simulation/Simulation/Portfolio Simulation (detailed) menu. The view of the layout configured in the scenario has to be
specified in the second parameter. The fields are inherited from the selected view.

Figure 26: PL Variance Class

3.3.1.13 - Data dictionary service

Data dictionary service Class type is used to transfer market data from production database to datamart. The parameter
specified is a data dictionary engine, composed by two elements : a loader which executes a request defined thanks to
SQL editor, and a formatter which organises the output of the request in a view.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 18
Dynamic Tables, 2014-07-25

Figure 27: Data dictionary service Class

3.3.1.14 - MLC

MLC Class type enables the mapping of predefined MLC requests. MLC Class type can be used to execute LRB requests
per specific engine pattern (MLC framework) through the standard datamart framework.

3.3.1.15 - PL entries generator (simulation) & PL entries generator (Pl variance)

These class types are used in the specific context of the module 'ACCOUNTING_PL', which requires a dedicated license.

These class type enable the generation of the accounting P&L entries business object from the simulation engine or from
the Pl variance engine. These class types are only used in the context of the module 'ACCOUNTING_PL', which is kept in
MX.3 for backward compatibility reasons and does not correspond to any standard business usage.

By default it is not recommended to use these class types.

3.3.1.16 - Hedge

The hedge class type provides a number of extractions related to the hedge accounting module.

The following creation class types are available:

• Hedge audit - extraction of the hedge modification audit


• Hedge effectiveness method audit - extraction of the audit of the effectiveness method audit
• Hedge strategy audit - extraction of the hedge strategy audit
• Hedge config - extract the detail of the hedge, the related strategy and effectiveness methods
• Hedge trade - extract the detail of the hedge, the related strategy, effectiveness methods and underlying hedged
items, hedging instruments and hypothetical derivatives
• Hedge effectiveness - extract the details of the hedge and retrospective and prospective effectiveness results
• Hedge measurement - extract the fair value variations for a given hedge

The different creation class types can be configured by selecting the class type Hedge and selecting the desired creation
class. A view must be selected from the drop-down list entitled "view". The view can be chosen, a new view can be
configured or an existing view can be consulted from this screen. The dynamic table fields are then inherited from the

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 19
Dynamic Tables, 2014-07-25

selected view.

Figure 28: Hedge class type (example creation class “Hedge audit”)

Figure 29: View definition

3.3.1.17 - Deliverable Cash

This dynamic table provides information about the payments. It retrieves one record per deliverable cash flow and each
flow will be returned in the last version available at computing Date2.

The computing dates Date0 and Date1 are not used. Only Date2 is used as a computing date and also as a filter on the
actual date, it means that the dynamic table will retrieve all payments that have been accepted before Date2 and that have
been generated in the payfix window.

In order to filter on the payments with a start date and an end date; it is possible to use the two provided interactive
variables DLV_DATE1 and DLV_DATE2. Those dates will apply a filter on the value date of the deliverable cash flow.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 20
Dynamic Tables, 2014-07-25

Figure 30: Deliverable Cash dynamic table

3.3.1.18 - Classification trees

In MX.3, some objects that are defined as trees such as:

• Funds for asset management


• Sectors for credit derivatives
• Typologies for all asset classes
• Securities for equity derivatives
• Contract classifications
• Portfolio tree

This dynamic table will provide a easy access to the information from the tree thanks to a flat table with fields like the
parent node(s) of a given leaf, as well as the full path.

For instance for the typology tree if the typology leaf 'IR-Callable' is under the tree: Typologies/IRS/Exotic/IR-Callable,
then a first dynamic field should display IRS, another one Exotic, and the last one the full path IRS/Exotic/IR-Callable.

The different type of trees are accessible via different creation codes. In case of multiple trees, it is necessary to choose
the tree name.

Here is the list of some fields provided by the table:

Field Description
PATH Full tree path for each leaf using a slash between each level

DEPTH Height of the tree, m ax level

ROOT Contains the Level 0

LEVEL1, ... LEVEL8 One column by levels

LEAF_ID Leaf id

LEAF_LBL Leaf display label

3.3.1.19 - Liquidation position statements

This dynamic table allows exporting positions from the liquidation. It retrieves one line per position including position
breakdowns and position data such as average price, total cost, realized P&L ...

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 21
Dynamic Tables, 2014-07-25

The projection and balance type have to be selected under the section Dynamic creation flags respectively in the fields
Projections and Balance type. The list of available projections corresponds to the projections that have been activated in
the environment. The flag Balance type allows exporting real-time balances, theoretical balances or official balances
when respectively set to Realtime, Theoretical or Official.

For further details on the projections and balance types, refer to the corresponding documentation.
Once the projection and balance type have been selected, a view has to be selected from the drop-down list in the View
field to list the fields to be extracted. Open the view to check its definition in the viewer and double click on it to select it.
The table fields are then inherited from the selected View.

Figure 31: Liquidation position statements dynamic table

3.3.1.20 - Cash position statements

This dynamic table allows exporting balances from the nostro cash including contributing movements. It retrieves one line
per opening balances including balance breakdowns and balance data such as currency, amount, one line per closing
balances including the same details and one line per contributing movements including balance breakdown data and
movement details such as currency, amount, movement reference ...

The projection has to be selected under the section Dynamic creation flags in the field Projections . The list of
available projections correspondents to the projections that have been activated in the the environment. For the
projections by trade date, ie. when the first field Projections is set to NostroCashTradeDate , it is possible to choose
exporting real-time balances or historical balances by setting the second field Projections respectively to Current results
or Historical results .

For further details on the projections and balance types, refer to the corresponding documentation.
Once the projection has been selected, a view has to be selected from the drop-down list in the View field to list the fields
to be extracted. Open the view to check its definition in the viewer and double click on it to select it. The table fields are
then inherited from the selected View.

The view should include the field Type to distinguish opening and closing balances from contributing movements that are
exported by this dynamic table.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 22
Dynamic Tables, 2014-07-25

Figure 32: Cash position statements dynamic table

3.3.1.21 - Securities position statements

This dynamic table allows exporting balances from the nostro securities including contributing movements. It retrieves one
line per opening balances including balance breakdowns and balance data such as instrument, quantity, one line per
closing balances including the same details and one line per contributing movements including balance breakdown data
and movement details such as instrument, quantity, movement reference ...

The projection has to be selected under the section Dynamic creation flags in the field Projections . The list of
available projections correspondents to the projections that have been activated in the the environment. For the
projections by trade date, ie. when the first field Projections is set to NostroSecurityTradeDate , it is possible to choose
exporting real-time balances or historical balances by setting the second field Projections respectively to Current results
or Historical results .

For further details on the projections and balance types, refer to the corresponding documentation.
Once the projection has been selected, a view has to be selected from the drop-down list in the View field to list the fields
to be extracted. Open the view to check its definition in the viewer and double click on it to select it. The table fields are
then inherited from the selected View.

The view should include the field Type to distinguish opening and closing balances from contributing movements that are
exported by this dynamic table.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 23
Dynamic Tables, 2014-07-25

Figure 33: Securities position statements dynamic table

3.3.1.22 - Corporate actions static data

These dynamic tables allow exporting static data related to corporate actions. Two class sub types are available:

3.3.1.22.1 - Withholding tax matrix

This table extracts the withholding tax matrix.The available data is equivalent to the ones within the tax settings menu,
except the customization matrices which are not extracted. A view has to be defined to choose the fields to be extracted.

3.3.1.22.2 - Corporate actions journal

The data extracted by this table is equivalent to the corporate actions journal in the OSP. A view has to be selected: it is
common with corporate actions journal views in the OSP.

The CA static data filter (under Default configuration ) gives access to the Predefined queries configured under
Supervisor for the class "Security object event".

For further details on Corporate Actions, refer to the corresponding documentation.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 24
Dynamic Tables, 2014-07-25

Figure 34: Corporate actions static data dynamic tables

3.3.1.23 - Order

This dynamic table allows exporting order details. It retrieves one record per order master ID and order component ID per
version. Note that this table doesn't contain trade information, only the trade ID is available.

Figure 35: Order reporting view

Once the class type is set to order, a view has to be selected from the drop-down list in the View field by a double click.
The table fields will be then inherited from the selected view.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 25
Dynamic Tables, 2014-07-25

Figure 36: Order dynamic table

This view can be defined under the following menu: [End-User session] Processing/Trades/Order query for reporting; for
additional information please consult the documentation of the Order Management System module.

Note that a new view can be inserted at this stage, by pressing the insert key in the list of "User Defined View" screen.

3.3.1.24 - PostTrade Workflow Audit

This dynamic table allows access to workflow task grouping changes and workflow decision rule history. It retrieves one
line per task grouping/decision rule modification.

Figure 37: PostTrade Workflow Audit dynamic table

3.3.1.25 - LiveBook

This dynamic table class type gives access to results published by a LiveBook instance via LiveBook views.

There are two types of LiveBook views :

• Sever views : views published by the LiveBook server instance


• Client views : user defined views configured in the LiveBook client screen

To configure this class type, a configured LiveBook instance has to be selected. Then the user has the choice between
Server and Client views before selecting the views from the pop-up screen. Once a view is selected, the table fields are
then inherited from the view.

For more details about LiveBook configuration, and Server/Client views definition, please refer to the LiveBook (document
ID 11284) (document ID 11284) documentation (docid:11284).

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 26
Dynamic Tables, 2014-07-25

Figure 38: LiveBook Class Type

Figure 39: Instance selection

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 27
Dynamic Tables, 2014-07-25

Figure 40: Server view selection

Figure 41: Client view selection

Remark : No computation date can be defined in the "Default Configuration" menu : the computation date is always
"Contextual today" for this Class Type.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 28
Dynamic Tables, 2014-07-25

3.3.1.26 - Collateral exchange

This dynamic table allows exporting collateral exchanges objects (Margin Call, Substitution), functionally accessible from
back-office menu Processing/ Margin call/collateral exchange query . This dynamic table retrieves one line per collateral
exchange, per margin requirement or per Allocation item according to the chosen creation class, representing 3 levels of
details. Each sub-level inherits from its upper levels properties: Allocation item >> Margin Requirement >> Collateral
exchange:

Figure 42 : Collateral exchange

It is possible to set prefilters on these fields:

• Start date - by default: contextual yesterday date


• End date - by default: contextual today date
• Portfolio
• Counterpart

Figure 43 : Collateral exchange prefilters

3.3.2 - Table History, Table Alias (Display), DBF Label and Other

The Table History is not used in the Datamart. However, it has to be unique, and the character size should not exceed 8
characters (no special characters or spaces allowed).

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 29
Dynamic Tables, 2014-07-25

The Table Alias is automatically filled by the system with the name of the dynamic table. This label is no longer in use in
the Datamart. It was used in Mreports as a reference to generate the report layout (or for multi-table links), regardless of
the Table History input. It was also useful to refer to a dynamic table in a multi-table relation : the system would then find
the corresponding physical table.

The DBF Label is only available for class types Copy Creation or External :

• For the External type, the name of the file to be created should be entered (figure 44).

Figure 44 : DBF Label in External class type

• For the Copy Creation type , the name of the table to be copied should be entered (figure 45 ).

Figure 45 : DBF Label in Copy Creation Class Type

The directory of the DBF table should also be specified in the DBF directory box. The options available are (figure 46 ):

Figure 46 : File directory selection for Copy Creation Class

Default The location of the file to be copied is the same as the main directory.

Used to indicate the exact location of the file to be copied, if different from the main directory( Default ) (figure
By Path
47 ).

Market Used when market parameters are stored in sub-directories whose names depend on the date and the desk of
Parameter the user (only in older versions of Mx) (figure 48 ).

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 30
Dynamic Tables, 2014-07-25

Figure 47 : File directory by path for copy creation class

Figure 48 : File directory by Market Parameters for Copy Creation Class

The Merge button is used to merge data from two tables; when the main table used for the report is missing, some
records necessary for the report construction can be retrieved from a second table and inserted into the first due to the
existence of a common field.

Figure 49 : Merge specification used in Copy Creation Class

3.3.3 - Table Fields List

The Table fields list depends on the class selected. Some classes propose a predefined list of fields (i.e. Transaction,
Accounting, Payment class types). Some fields are common to several creation classes : fields prefixed by TP_* can be
found in all transaction type dynamic tables. For copy creation, the proposed fields depend on the selected table to copy.
When a view is related to the class type (i.e. Simulation, PL Variance, Theta Analysis, Data dictionary service class types), the
fields list returns the columns computed by the view. In addition to those fields, the list contains the defined horizontal
fields, and some specific flag fields explained below.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 31
Dynamic Tables, 2014-07-25

Figure 50 : Accessing the Table fields list

Click on Selection to display available fields (figure 50). Note that the screen is a regular view such that standard
functions Tools / View , Find and Filter are available. These functions can be useful to identify a sub-group of fields in
order to shorten search time.

To select a field, click on the check box next to it, or use the spacebar to select it. Press Control + Enter to save the
selection.

Figure 51 : Selecting a field

3.3.4 - Horizontal Fields

Horizontal fields are user definable fields. Their definition can be based on previous fields, and/or on hard coded parser
functions.

To add a Horizontal field, tick the box next to the Horizontal fields flag and click on Selection .

Figure 52 : Accessing horizontal fields menu

In the list that appears, press the Insert key to add a new horizontal field.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 32
Dynamic Tables, 2014-07-25

If the dynamic table has Transaction as its Class type then It is possible to choose between two types of horizontal fields:
"Default horizontal field" and "Alternate Id horizontal field".

Otherwise, only the Default horizontal field will appear.

3.3.4.1 - Default Horizontal Field

Figure 53 : Default horizontal field definition

Name The Name of the field determines the title of the column

The Type can be Character, Date, Number or American. Note that when consolidating, horizontal fields have the
same behaviour as table fields: fields of type Character, Date, Number will contain the value of the first record
Type
consolidated; whereas fields of type American will contain the sum of all records consolidated according to the
criteria selected in the field list.

The Format determines the size of the field. In the special case of Number type, two boxes appear for the
Format
format: one for the size of the number and the other for the decimal.

Description Should be brief and concise in a way to shortly illustrate the use of the field.

Formula Determines the value of the field. When clicking on this button, a prompt window appears (figure 54).

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 33
Dynamic Tables, 2014-07-25

Figure 54 : Formula window

The Formula is made of previously selected table fields (press F9 to get the list), horizontal fields, logical operators (on the
left pane of the screen) and hardcoded parser functions (press Shift+F9 to get them). For example:
IIF(TP_SMAMT<>0,TP_SMAMT,TP_SPFAMT)

For additional guidance on Parser Functions consult the document Query language (document ID 280) .

The return type formula should be the same as the one defined as the type of the horizontal field (Numeric for type
Number, string for type Character ...)

Important : once the horizontal fields have been created, they must be selected from TableFields/Selection . Otherwise,
they will not be taken into account.

3.3.4.2 - Alternate Id horizontal field

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 34
Dynamic Tables, 2014-07-25

Figure 55 : Alternate Id horizontal fields definition

Name The Name of the field determines the title of the column

Should be brief and concise in a way to shortly illustrate the use of the field.
Description
If this field is left empty, It will be filled automatically "Alternate Id field"

Dynamic Field The scope of fields for which it is possible to extract the alternate Id.

Alternate
The system for which the chosen field has an alternate Id.
System

This option is only available for Transaction dynamic tables (Class type = Transaction)

This Alternate Id horizontal field purposes to extract the stored alternate Ids of different objects in the system. For now,
only alternate Ids for securities, counterparts and Contracts can be extracted. To define the alternate Id field, choose from
the selection of fields representing those objects in Dynamic Field drop down list. Then fill the field Alternate System for
which the object has an alternate Id.

This Alternate Id field will be added to the list of fields like a default horizontal field, therefore it needs to be selected from
TableFields/Selection. Otherwise it will not be taken into account

3.3.5 - Interactive Fields

Interactive fields provide another control tool given to users, in addition to filter formulas and date selections. The value of
the Interactive fields can be specified by the user at run time.

Interactive fields can be used for reports set-up (example: run the report in EURO mode), for reports layout (example:
select if results should be grouped by PFOLIO or INSTRUMENT), or for any other purpose that calls for an arbitrary
selection by the user.

3.3.5.1 - Configuration - general

To define a new Interactive field, click on the Selection button next to Interactive Fields and press Insert.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 35
Dynamic Tables, 2014-07-25

Figure 56 : Inserting an Interactive Field

Name Interactive fields are defined by a name.

Description Additional information.

Can be :

• Character
Type
• Numeric
• Date.

Determines how the Interactive field will be retrieved and interpreted. Three general cases are present:

• Direct: The Interactive field appears at run time, and the user can directly type the value to be
passed for that field.
• Predefined: At run time, the user is offered a list of values retrieved from the existing system table:
Field input the list of available currencies for instance.
• Domain: At run time, the user is offered a list of values defined previously by the user in the
definition of the Interactive field.

For more details on Field Input , see below section 3.3.5.2.

The Format , which determines the size of the field, must be set only for Direct Field Input. The size of the
Format
field is equivalent to the total number of characters, in addition to the number of decimals for numerical fields.

The Dummy attribute is a flag used when the interactive field is not directly accessible to the user; instead, the
field value will be calculated through a formula, eventually using another interactive field value. Or, in much
Dummy
simpler cases, the Dummy flag can be used to force the Interactive field to be set to the default value. In both
cases, the interactive field is not visible at run time.

Default Formula field is used, as in other cases, to compute the value of the Interactive field through a calculation,
using other fields, logical operators and parser functions. It holds, in much simpler cases, the default value of
formula
the interactive field.

3.3.5.2 - Field input options

• If the Field Input is set to Predefined , an additional attribute, under the name Set , must be specified (figure 57).
It is a drop-down list containing the possible categories of system tables for the Interactive field .

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 36
Dynamic Tables, 2014-07-25

Figure 57 : List of predefined field inputs

They are respectively:

Currency the Interactive field points, at run time, to the list of available Currencies in the system.

Counterpart the Interactive field points, at run time, to the list of available Counterpartie in the system.

Instrument the Interactive field points, at run time, to the list of available Instruments in the system

Portfolio the Interactive field points, at run time, to the list of available Portfolios in the system.

gives access to a set of reporting flags such as selection of the EURO mode. In this case the field name is
Config
preselected by the system

gives the choice of printing market parameters at the end of an Mreport (in conjunction with DYN_TRNRP_).
MP Print

• If the Field Input is set to Domain , an additional attribute, under the name of Values , must be specified (figure
58 ). These values must be entered by the user and appear in a list to choose from at run time.

Figure 58 : Inserting values for the Domain Field Input

3.3.5.3 - Retrieval

The value of the interactive field is read through a Horizontal field using specialized hard coded parser functions:

Format Function

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 37
Dynamic Tables, 2014-07-25

CINTFIELD ( <Field name> ) for character type fields

NINTFIELD ( <Field name> ) for numeric type fields

DINTFIELD ( <Field Name> ) or date type fields

3.3.5.4 - Default interactive parameters

Two default interactive parameters are automatically created by the system and will have impact on the dynamic tables
results:

• SU_CONFIG

This interactive parameter is configured for the dynamic tables defined with class type=Simulation views. By default this
parameter is set to <SIMULAT._VAR>, which refers to the Simulation settings defined from an end user session from the
menu Configuration/Settings/Simulation settings. As a consequence, we ensure that the data output by the dynamic table
are match ing with the figures displayed in the simulation viewer because the computation is achieved using the same
settings in both cases .

Figure 59 : SU_CONFIG interactive parameter definition

The SU_CONFIG can take the predefined value <DEFAULT._VAR>, which refers to the reporting settings defined from an
end user session from the menu Middle office/Reporting/Reporting setup.

The user can also define a specific configuration to compute data and assign this to the SU_CONFIG parameter during
the test on screen:

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 38
Dynamic Tables, 2014-07-25

Figure 60 : Definition of a new configuration to assign to SU_CONFIG

• CMM_EXEC

This interactive parameter is only available in the Mx environments deployed with a client license. It is configured for the
dynamic tables defined with class type=Transaction. It has been created to anticipate the EUR currency introduction in the
2000. This parameter refers to a Basket configuration where the user maps the old currency with the new one. Setting a
value to this parameter at run time enables the fields having labels starting with CMM (CMM_CUR, CMM_DTE etc) to be
computed and to evaluate the deals in Basket mode (new currency). Baskets can be configured from an end user session
from the menu Configuration/CMM/Basket definition

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 39
Dynamic Tables, 2014-07-25

Figure 61 : CMM_EXEC interactive parameter definition

3.4 - Dynamic Creation Flags

Additional flags can be set in the Dynamic Table definition. They are mainly used to control the output display and are
described in the following sections.

Figure 62 : Adding dynamic creation flags

3.4.1 - Creation Code

Creation code flag is available only if the Class Type is set to Transaction (for more information on class types, see
section 3.3.1). It is used to enhance the output display (split by leg for instance).

A description of these flags is detailed in dyn_fields.xls.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 40
Dynamic Tables, 2014-07-25

Figure 63 : Adding a Creation Code

3.4.2 - Consolidated View

This flag is used to force the dynamic table to display summarized results, grouped according to a consolidation key
determined by the XFLD_FSORT column in the tables fields list.

To determine the grouping key, go to TableFields/Selection . Place the cursor on the required field, and go to Edit /
Set/UnsetSortField (figure 64 ). Check the value of the XFLD_FSORT column for that field; it should now be set to 1,
indicating that rows will be summed according to that grouping key. Then, select the Consolidatied view flag, otherwise
the XFLD_FSORT flag is not taken into account.

Figure 64 : Setting the grouping key for the Consolidation view

In a consolidated view, a filter can be defined (using the table fields) to select a sub-set of records to be aggregated
leaving the others detailed (figure 65). If the filter is verified, the current record is involved in the consolidation, otherwise it
is detailed.

The Consolidation filter is applied after the Post-Filter , after the Duplication and after the Horizontal fields are
calculated (figure 65).

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 41
Dynamic Tables, 2014-07-25

Figure 65 : Adding a filter to a consolidation view

The consolidation filter needs to be based on a field of type Character.

The Detailed for today flag can be used if for reporting purposes the user needs a detailed display of the current day's
activity and a consolidated view for all past deals:

Figure 66 Detailed for today

3.4.3 - Disable Compute

By default, all the computations are enabled, even those involved in the different sensitivities (figure 67).

Figure 67 : Default Settings for the Disable Compute flag

In some special cases, where the dynamic table is used for Audit reports for example, and only description fields may be
required, computations of unnecessary data may slow down the system. The Disable compute flag is useful in this case,
since it deactivates all calculations fields, mainly the P&L computations and all its derivatives. Note that this flag exists
only with transaction class type.

Please note that, if this Disable compute flag is checked, then all the figures needing a "compute" to be calculated (e.g.:

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 42
Dynamic Tables, 2014-07-25

interest flows of a loan/deposit) will be disabled and the archived trades are not taken into account.
If the Disable compute flag is unchecked, an additional choice is offered for disabling sensitivities calculations,
independently from one another, mainly the computation of Delta, Gamma and Theta sensitivities.

Figure 68 : Disabling Sensitivities computations separately

If the Disable compute flag is checked, then the computation of the previous sensitivities is automatically disabled.

Figure 69 : Automatic Disabling of sensitivities when Disable Compute checked

3.4.4 - Duplication

By default, the records involved in each transaction appear only once in the output.

Figure 70 : Default settings for the Duplication Flag

The Duplication flag offers the possibility to duplicate, up to four copies, each initial record of the dynamic table created.
This technique was used in Mreports, when a report construction required the same deal to appear in two (or more)
different groups. It is no longer in use with the Datamart because other techniques that perform the same tasks while
avoiding the duplication of data are now available at the report level.

To duplicate a line, check the Duplication flag, and after clicking the Details box, determine:

• the Number of lines: between 1 and 4 for each record.


• the Line # 1-4 Filter: which determines the Filter formula applied to each copy (up to four) of the records. If the
filter is verified, the current record is duplicated.

For example, it is possible to display the P&L by Portfolio and by Instrument, by setting a group on PORTFOLIO followed
by a group on INSTRUMENT.

Without the use of the Duplication mode, the output will display subtotals by Instruments within a same Portfolio. This will
only give totals by Portfolio.

However, using the Duplication mode, select 2 lines per record (figure 71 )

Figure 71 : Insertion of lines in Duplication mode

then, under Horizontal Field List , define the field shown in figure 72.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 43
Dynamic Tables, 2014-07-25

Figure 72 : Horizontal field definition in Duplication

In the output, the column D_PFL_INS now contains a number of records with the value of the portfolios, and the same
records with the field set to the instruments values. Any grouping can then be done consequently.

3.5 - Default Configuration

Figure 73 : Default configuration

The filters and dates to be stored with the calculation definition, and therefore applied by default each time the report is
run, are set up in the Default configuration.

It mainly contains the setups for the computing or revaluation dates of the calculations, the prefilter selections (that
depend on the transaction type, portfolios, instruments, counterparties and other filtering expressions), and some
post-filter selections. Each of these will be discussed in detail in the upcoming paragraphs.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 44
Dynamic Tables, 2014-07-25

Figure 74 : Default Configuration screen (for transaction type only)

3.5.1 - Underlying Type, built on

Figure 75 : Built on types

There are mainly three underlying types:

Trn. Detailed The dynamic table seeks information from detailed transaction files. The Pre-filter Selection can be applied
DBF on all description fields of the deals.

• The dynamic table results are consolidated by TRN_FMLY + TRN_GRP + TRN_TYPE +


INSTRUMENT + RSKSECTION + PORTFOLIO.
• The dynamic table can be loaded by portfolio reference or by position reference (stored in
warehouse tables). See 3.5.3
Trn. • When results are printed as of current working day (between inception and today), calculation is
Consolidated very fast since data is loaded in the same way as in the simulation screen. Indeed, the dynamic
DBF table uses data already consolidated from a dedicated table computed by the warehouse module.
• When printed as of a past date, calculation time is comparable to the Trn. Detailed DBF mode.
• This mode is very useful for sensitivity reports, or global P&L as of current working day where the
results only show the sum according to one of the above criteria rather than deal by deal. A set of
simple or combined portfolios can be selected; otherwise all portfolios will be included.

Trn. Stored Deprecated and option is removed in future versions.


results Is used to extract the P&L of consolidated positions stored daily in the TRN_PL_DBF table via the STORED PL
module. The TRN_PL_DBF has been transferred to a datamart table REF_PL_REP to store the daily P&L (see
details in the section Profit and loss storage of the document End of day cycle migration (document ID 3620) ).
To build a report based on the stored P&L, a datamart extraction can be built directly on the REF_PL_REP
table instead of having to configure a dynamic table.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 45
Dynamic Tables, 2014-07-25

3.5.2 - Calculation Unit (for PL Variance class type)

The Calculation Unit is an option available for the PL Variance dynamic tables in detailed mode to allow the calculation to
be done by portfolio (default mode) or by trade.

When the calculation is done by trade, it gives the possibility to have prefilters based on trade attributes thanks to the filter
expression and to be able to run datamart feeders in parallel mode with the granularity by trade to ease the
troubleshooting in case of potential errors, because by default the PL Variance dynamic tables load the trades by portfolio
(as in the consolidated mode).

Figure 76: Calculation unit in PL Variance dynamic tables

When Calculation Unit=Portfolio, you can only filter the PLVar based dynamic table on portfolios. The computation is then
done on the whole portfolio.

Selecting Calculation Unit = Trade enables the pre-filter: Expression.

Thanks to this filter, it is possible to pre-filter the PLVar based dynamic table by a formula based on any trade description
field present in the Header file (TRN_HDR) (For example: Trade Number, Family, Group, Type...). This restricts the
computation of the PLVar on these filtered deals.

3.5.3 - Load by portfolio / position flag

The Load by portfolio / position flag is only available in consolidated mode for Transaction, Simulation view or PL Variance
dynamic tables to allow the load of data to be done by portfolio (default load mode) or position reference.

Figure 77: Load by portfolio / position flag

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 46
Dynamic Tables, 2014-07-25

3.5.4 - Classification type and Breakdown mode flags

The Classification type and Breakdown mode flags are only available in consolidated mode. These flags determine which
simulation by position will be used by the dynamic table.

Figure 78: Classification type and Breakdown mode flags

The following table summarizes all the different situations:

Classification type Breakdown mode Simulation by position used


Portfolio simulation by position: Results
P&L mode By position
are consolidated.

Portfolio simulation by position (with


breakdown by trade): Results are read
P&L mode By trade from the warehouse non aggregated
tables (providing access to trade
number).

Portfolio simulation aggregated positions


(Accrual): Results are consolidated, but
Accrual outputs By position Money Market trades are loaded with a
lower level of aggregation to compute
accrual P&L figures.

Portfolio simulation aggregated


positions, trade by trade (Accrual):
Results are read from the warehouse
Accrual outputs By trade non aggregated tables, and Money
Market trades are loaded with a lower
level of aggregation to compute accrual
P&L figures.

3.5.5 - Load by portfolio flag

The Load by portfolio flag is an option that is only available for the Simulation Views dynamic tables.

When this flag is ticked, data are aggregated with the same aggregation level than in the storage view (the view on which
the simulation view dynamic table is based) : you will have the same number of records output by the dynamic table than
in the storage view.

In the same time, this flag allows you to have the portfolio hierarchies retrieved by the dynamic table when it is executed
on a portfolio node if hierarchies portfolio are configured in the storage view.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 47
Dynamic Tables, 2014-07-25

Figure 52 : Load by Portfolio Flag

3.5.6 - Date Selection

Each dynamic table could require one, two or even three dates for the calculations (example: P&L variation between two
dates), or for filter criteria (example: audit of trades entered between two dates).

Figure 53 : Date selection

Referring to figure Error: Reference source not found , the table below highlights all revaluation dates used for each class
of dynamic database:

Date 0 Date 1 Date 2 Comments


DYN_TRNRP_PL Yes Yes Yes P&L as of three different dates

DYN_TRN_PL ... ... Yes P&L as of one date

DYN_TRNRP_CS
... ... Yes Cash and security flows as of a given date

DYN_TRNRP_DT ... ... Yes Deals Detail

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 48
Dynamic Tables, 2014-07-25

DYN_TRNRP_XG ... Yes Yes Fixing Rates between two dates

DYN_TRNRP_SV ... ... Yes Trade sensitivities on a given date

DYN_TRNRP_HB ... ... Yes Hedging Baskets on a given date

DYN_TRNRP_MK ... Yes Yes Market Operations done between two dates

DYN_TRNRP_MV Yes Yes Yes P&L as of three dates

DYN_TRNRP_CD Call deposit and Security Finance detail by


... Yes
event date

Simulation Yes Simulation as of one date

P&L Variance is always computed between


P&L Variance Optional Yes today and yesterday. Yesterday can be
specified using a particular calendar.

Theta Analysis is always computed between


Theta Analysis Yes
today and tomorrow.

Liquidation
Real-time positions are always available as of
position
today. Date 2 should always be set to Contextual
statements /
today.
Real-time

Liquidation
Theoretical positions are exported between
position
... Date 2 plus the shifter specified in the position
statements /
statement definition and Date 2.
Theoretical

Liquidation
Official positions are exported between Date 2
position
... plus the shifter specified in the position
statements /
statement definition and Date 2.
Official

Cash position
Real-time positions are always available as of
statements /
today. Date 2 should always be set to Contextual
Trade date /
today.
Real-time

Cash position
Historical trade date positions are exported
statements /
... between Date 2 plus the shifter specified in the
Trade date /
position statement definition and Date 2.
Historical

Cash position Value date positions are exported between Date


statements / ... 2 and Date 2 plus the shifter specified in the
Value date position statement definition.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 49
Dynamic Tables, 2014-07-25

Securities position
Real-time positions are always available as of
statements /
today. Date 2 should always be set to Contextual
Trade date /
today.
Real-time

Securities position
Historical trade date positions are exported
statements /
... between Date 2 plus the shifter specified in the
Trade date /
position statement definition and Date 2.
Historical

Securities position Value date positions are exported between Date


statements / ... 2 and Date 2 plus the shifter specified in the
Value date position statement definition.

• Yes : date used for dynamic file calculations


• ... : date can be used for filter criteria but is not used in the dynamic database calculations.

To refer to these dates in the filter or in horizontal fields formulas, use the following field names :

Report layout Dynamic database date syntax


First date DATE_REP0 CRT_BND10; CRT_BND20

Second date DATE_REP1 CRT_BND11; CRT_BND21

Third date DATE_REP2 CRT_BND12; CRT_BND22

The Description line next to each Date should indicate its purpose, for example, first P&L revaluation date. This will be
displayed when the user runs an Mreport only.

The selection made for each date can be modified by the users when running a report. The list of available date definitions
is the following:

3.5.6.1 - Fixed Dates (manually entered by the user)

No date is taken into account. This item should not be selected when the corresponding date field is used for
No selection
calculation.

Enables the user to manually type a date (with no restrictions: past or future date, open day or holiday). If the
date selected is used for calculations (P&L or Market Risk), and no set of closing rates is found, an error
User defined
message will be displayed when running the calculation indicating that current set of parameters will be loaded.
See figure Error: Reference source not found.

Enables the user to select a past date on which a back office end of day was performed. The closing rates
Historical date should be available for any of these dates, unless they have been purged (in which case the system loads
current market parameters by default and displays an error message).

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 50
Dynamic Tables, 2014-07-25

Figure 54 : Setting a user defined computing date

3.5.6.2 - Variable Dates

Variables dates are automatically computed by the system.

Figure 55 :S electing Contextual Today and Yesterday as Computing Dates

Refers to the current/previous Trading date or P&L reference dates depending on the type of the user (figure
Error: Reference source not found). If he is a Front Office user, then the Contextual Today refers to the Trading
Date, whereas the Contextual Today points to the P&L reference date for a Back Office user (the date selection
refers to the user group). The Trading dates and the P&L reference dates have also been added separately.

• Contextual today =
♦ Trading date for FO user
♦ PL date for BO user
Contextual • Contextual yesterday =
♦ Trading date - 1 open day for FO user
Today /
♦ P&L date - 1 open day for BO user
Contextual
Yesterday These dates are stored in the following global environment variables:

• Trading date : DATE_TRADING, DATE_FO, DATE_SYS


• P&L date : DATE_PL, DATE_BO
• Contextual date : DATE_CONTEXT
• Consolidation date: DATE_CNS

They can be recovered through horizontal fields with the DENV parser function.

Equals the very first trading date in the system. In other words, no trades have been inserted before this date.
Inception
The P&L is zero at the Inception date (figure Error: Reference source not found).

Figure 56 : Selecting inception date as computing date

is the date stored in the Accounting module (Note that the Front Office, Back Office and Accounting dates can have three
Accounting date different values, FO>BO>AC ) .
This date is stored under the global environment variable labeled DATE_ACC

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 51
Dynamic Tables, 2014-07-25

Origin
(Monthly) /
Refers respectively to the Origin date defined from an End-user session in the MiddleOffice / P&L related
Origin (Simul) /
Procedures / Set P&L Origin Date menu. Different selections can be made for FO and BO group of users.
Origin (Daily) /
Origin (Yearly)

(Figure Error: Reference source not found ).Equals current system date minus/plus N open days, where N is
Date minus N / an integer manually defined (0 is the default value). The system refers to the Global Calendar to check the
Date plus N open days. This same calendar is also used for the calculation of the next open day in the End of Day
procedure. It is defined from a Configurator session in the ProcessingData /CommonSettings /Settings screen

Figure 57 : Selecting Date plus N as a computing date

similar to the Date minus N/ Date plus N, except that the system does not refer to the global calendar, but to
Date shifter
another pre-existing calendar, or a calendar inserted by the user (figure Error: Reference source not found).

Figure 58 : Selecting a Date shifter as a computing date

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 52
Dynamic Tables, 2014-07-25

Relative Prev. / The date depends on one of the three dates in Date Selection. The references used should therefore be 0, 1
or 2 (figure Error: Reference source not found). The resulting date is either one open day prior to, or one open
Relative Next
day following the reference date. This possibility is used in some of the Murex Standard Accounting Reports.

Figure 59 : Selecting Relative Previous as a computing date

It is equivalent to the Reporting date, and the reporting date shifted by a certain amount of days respectively.
The Reporting Date Shifter refers to a specific shifter, which can be selected in the same screen. The
Reporting Date is set from a Configurator session from DataExtraction/Datamart/Maintenance
/InitializeReportingDate.

This is a date specific to reporting that can be moved independently to any other date in the system. It can be
Reporting
easily changed to a past or future date, and is applied across the whole system.
Date/Reporting
Date Shifter The reporting date can also be rolled automatically during EoD, by using the processing script
REPORT-MVDATE.
Note that reporting date shifting depends uniquely on the calendar defined in the Processing center's EOD
settings. This calendar is accessible in a configurator session, from the menu : Infrastructure / Organization /
Processing center / EOD Settings.

Figure 60 : Selecting Reporting and Reporting Date Shifter as computing dates

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 53
Dynamic Tables, 2014-07-25

3.5.7 - Pre-filter Selection

The filter conditions defined at this level represent the first step in the dynamic database execution. It is crucial to set an
effective pre-filter formula, since it is a strong tool to optimize dynamic database creation (the calculations are performed
on the pre-filtered data only). The choices available in this screen section vary according to previous flag selections:

• When Class Type = Transaction and Built on Trn. Detailed DBF: Calculation will be performed only on
pre-filtered deals.

The filters available in this section are the following (figure Error: Reference source not found):

Figure 61 : The Pre-filter selection for transaction type and detailed DBF

Transaction See figure Error: Reference source not found. Selection of deals to be included. Very fast pre-filter, since only
type the associated body files associated with the transaction types selected will be scanned.

See figure Error: Reference source not found. Gives access to a list of portfolios from which the user can
Portfolio select the portfolios on which to perform the extraction. If nothing is selected, the extraction is done on all the
available portfolios.

See figure Error: Reference source not found. Gives access to the list of instruments from which the user can
Instrument select a set of instruments on which to perform the extraction. If nothing is selected, the extraction is done on
all the available instruments.

Tables See figure Error: Reference source not found. Select if data should be retrieved from current list of trades only,
Scanned or from purged results and P&L adjustment files.

Formula based on Trn family, group or type, Instrument or Portfolio name. Applying a filter at this level ensures
Expression
that data from purged deals and P&L adjustment files are included in the report.

Counterpart Easy selection of counterparty labels. Same concept as Portfolios and Instruments.

Expression Formula based on ANY trade description field as stored in the Header file (TRN_HDR).
Applying a filter formula at this level means that specific trade information is requested (ex: TRN_DATE = ...),
(2)
therefore data from purged deals and P&L adjustment are automatically excluded.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 54
Dynamic Tables, 2014-07-25

Figure 62 : List of transaction types to filter

Figure 63 : List of portfolios to filter

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 55
Dynamic Tables, 2014-07-25

Figure 64 : List of Instruments to filter

Figure 65 : List of trading tables

Although the Trn.Type selection optimizes considerably the output of the dynamic calculation, since only the selected
type of deals will be scanned (much faster than typing a filter expressing such as TRN_GRP== 'BOND' ), it is not

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 56
Dynamic Tables, 2014-07-25

recommended for reports which may be expanded to include a broad range of trades. For example if a report should
include all OTC products, it is preferable to exclude all Futures and Listed options in a filter expression, to make sure if at
any point a new type of OTC product is traded it is automatically included in the report.

• When Class Type = Transaction and Built on = Trn. Consolidated DBF: Calculations are performed on prefiltered
portfolios
• When Class Type = Copy Creation: Data is filtered from the existing table in the Expression box.
• When Class Type = Accounting: Journal detailed entries selected are included in the generated table.
• When Class Type = External: Calculation are performed only on prefiltered elements.

3.5.8 - Position statement selection

A position statement selection is available when Class Type = Liquidation position statements or Class Type = Cash position
statements or Class Type = Securities position statements. It allows filtering on the positions to be exported.

The same position statement selection can be shared by several dynamic tables. Nevertheless, the fields Projections and
Balance type defined in the position statement selection should always be identical to the fields Projection and Balance
type defined under the section Dynamic creation flags.

The filtering criteria necessary to configure the extractions have to be made available via the definition of a predefined
query in a SUPERVISOR session under Preference list / Query filters. One predefined query has to be defined per class
type and projection type as on the screen shot below (figure 79) and each predefined query should include all the
necessary filtering criteria. The figure 80 is an example of predefined query for cash position statements at trade date
dynamic table.

Figure 79: List of predefined queries required to run position statement dynamic tables

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 57
Dynamic Tables, 2014-07-25

Figure 80: Example of predefined query configured for the cash position statement at trade date including the portfolio, the currency, the account and the
settlement status as available filtering criteria

3.5.9 - Post-filter Selection

A post-filter condition can be applied on the calculations just performed. For example, after creating a table based on
DYN_TRNRP_PL the user can exclude records with positive P&L; of course such a filter is impossible to set on the source
transaction tables used in the pre-filter since P&L is not stored in the system on a deal by deal basis (see document
Sybase restrictions (document ID 294) on this area).

Figure 66 : Post-filter selection

The filter expression can be built on fields which have been selected in the table fields list. Avoid selecting unnecessary
fields, when running the report the user has access to Post-filter extra fields where they can select supplementary fields
(to those in the configuration of the report) to be used in a second post-filter formula.

4 - Tests

Once the dynamic table is created, it needs to be tested in order to make sure that the related reporting table is properly
populated.

The test on screen is a powerful and reliable tool since it projects the exact computations and data values with which the
reporting table will be filled.

The results shown in a test on screen reflect data computed and stored in a temporary table. They reproduce exactly the
expected generated data.

It is always recommended to run a test on screen before running the feeder to avoid inconsistencies and undesirable
results, and after the generation of data to validate the data populating the reporting tables.

4.1 - Running a 'Test on screen'

To run a test on screen, from an end-user session only, right click on the dynamic table in the dynamic tables list, and
choose Test on Screen.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 58
Dynamic Tables, 2014-07-25

Figure 67 : Running a test in screen

At this stage, a DAP filter list appears. It contains the list of filters previously defined by the user, and at the top of the list,
the default filter for that dynamic table. This default filter corresponds to the default configuration settings specified in the
dynamic table definition.

Figure 68 : DAP list

By selecting one of these filters and clicking Proceed, the filter definition screen opens (figure Error: Reference source not
found). The user can thus perform some modifications before continuing the procedure. A new filter can even be added
and defined at this stage (press Insert in the filter list).

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 59
Dynamic Tables, 2014-07-25

Figure 69 : Inserting a new filter

Note that the execution parameters that are set in the filter to run override the default configuration settings of the dynamic
table. More specifically, the date selected in that filter replaces the ones defined in the default configuration, the portfolios
selected at this stage are added to the ones selected in the default settings, and the expressions also. The d- label next to
one of the filters indicates that a default setting was set for that pre or post filter in the Default Configuration Settings.

Click on Proceed to run the test on screen and wait for the results.

4.2 - Analyzing Results

The screen that appears after running a test on screen contains the tabulated data (figure Error: Reference source not
found).

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 60
Dynamic Tables, 2014-07-25

Figure 70 : Results of tests on screen with default view

The appearance of the columns depends on a View selected by default. To personalize a view, go to Tools/View and
press Insert.

Figure 81 : Views list

In the View definition, a field list appears on the left, on the top of which appear the fields selected in the dynamic table
definition. The remaining fields are those of the union related to that table and should be omitted for the rest of the test.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 61
Dynamic Tables, 2014-07-25

Figure 82 : Defining a new view

To include a column in your view, double click on it or select it and the press on the right arrow to add it to the current view
list. Note that the sequence of the column can be reordered by dragging a field and moving it upwards or downwards in
this current list. Name the view and save it.

In the list of views, double click on the dynamic table just created in order to activate it. The screen now displays the data
in the manner described by the selected view (figure 83).

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 62
Dynamic Tables, 2014-07-25

Figure 83: Result of view

Note that if you have included, in your view, fields that have not been selected in the dynamic table definition (views
belonging to the union), then the data contained in these fields will appear as null. This indicates that although they exist,
they won't be computed and stored in the reporting table once you populate it with a Datamart feeder.

4.3 - Running a 'Test & Save on Disk'

To run a test on screen, from an end-user session only, right click on the dynamic table in the dynamic tables list, and
choose Test & save on disk.

Figure 84 Test and Save on Disk

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 63
Dynamic Tables, 2014-07-25

Then the behavior is similar to the command 'Test on screen', except that the result is also stored into the database.

In order to retrieve the name of the table which contains the result of the 'Test and Save on Disk', you have 2 steps to
perform.

Step 1: Retrieve the value of the field 'Table history' of the dynamic table.

Figure 85 Table history of the dynamic table

Step 2: In a SQL editor, run the following request (replace His0_42 by the value of the field 'Table history' of your dynamic
table):

Request for Sybase:

select name from sysobjects where type='U' and name like '%His0_42%'

Request for Oracle

select table_name from all_tables where table_name like UPPER('%His0_42%')

Step 3: Run the following SQL request to get access to the result of the 'Test and Save on Disk' (replace
REPBATCH#PC_3#HIS0_42_DBF by the result of the step 2):

select * from REPBATCH#PC_3#HIS0_42_DBF

5 - Conclusion

Once the dynamic table is built and tested using the Test on screen, the next step in configuring the Datamart would be to
build a reporting table based on this dynamic table and a feeder to populate this table.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 64
Appendix 1 - Best Practices
This matrix serves as a guideline on which Dynamic Table to use in a given situation.

1.1 - Category: Risk

Data Type Dynamic Table Class Type


Risk (Credit Exposure, Yield Curve Risk, Basis Risk, FX Risk,
Simulation View
Greeks)

Risk Matrix
Risk Matrix

Theta Analysis Theta Analysis

MLC based reports (Collateral, Counterpart Credit Risk) MLC

1.2 - Category: Position keeping

Data Type Dynamic Table Class Type


P&L as of one date Simulation View

P&L Variation between two dates:

• No need to revaluate the P&L as of past date every Simulation View - Store one data set per day
day

• Need to revaluate the P&L as of past date every day


♦ Big Volumes of trades and aggressive • DYN_TRNRP_PL with two computation dates
SLAs for the report • Simulation View - Store one data set per day and
♦ No issue with trades volume and no recalculate the past date every day
aggressive SLAs for the report

Trades Position Simulation View

Security Position Simulation View

P&L Variance based on scenarios PL Variance

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 65
Dynamic Tables, 2014-07-25

• DYN_TRNRP_PL for all deals


• Simulation View for LIVE trades only (details of
Trade Details dead, purged and archived trades are not
computed by the simulation)

Cash and Security Flows DYN_TRNRP_CS

Market Value and P&L decomposition details - granularity by


DYN_TRNRP_MV
trade leg

Schedules periods + Flows Amortization details DYN_TRNRP_DT

1.3 - Category: Market Data

Data Type Dynamic Table Class Type


Market data used for the trade evaluation Simulation view

Market data independently from the trades Data Dictionary service (based on a market data loader)

1.4 - Category: Audit and Control

Data Type Dynamic Table Class Type


DYN_TRNRP_XG / DYN_TRNRP_DT for indexation
Details on Trades Fixings
rate/date

Trade life cycle history (listing of events with their details) DYN_TRNRP_MK

Call/Deposit and Security finance Trade life cycle history


DYN_TRNRP_CD
(listing of CD events)

Audit on Trade life cycle : modification of the trades induced


Trade Version Audit
by events

Listing of the navigation templates details Navigation Templates

Listing of STP rights details STP Rights

Audit of changes done in the STP rights STP Rights Audit

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 66
Dynamic Tables, 2014-07-25

1.5 - Category: Accounting

Data Type Dynamic Table Class Type


Accounting entries postings Accounting

Accounting Balances Accounting (reporting)

1.6 - Category: Finance

Data Type Dynamic Table Class Type


Settlement (Payment) Deliverable Cash

1.7 - Category: Static Data / Configuration

Data Type Dynamic Table Class Type


Static Data (UDF, Counterpart Details, audit on static data
amendments):

• Need to store computed formulas based on the static


fields, formulas that can not be reproduced within the • Copy Creation
SQL query • Datamart table based on SQL
• No Need to store computed formulas based on the
static fields (the computation can be done at report
level if needed)

Static Data stored as trees like Portfolio trees, Typologies,


• Classification tree
Contract Classifications, Sectors, Funds, Securities

1.8 - Category: Hedge

Data Type Dynamic Table Class Type

Hedge's configuration: Hedge strategy template, hedge


• Hedge config
effectiveness template, hedge query

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 67
Dynamic Tables, 2014-07-25

Hedge's components: quantity, Market Value variation per • Hedge trade


trade

Hedge effectiveness (retrospective/prospective) result • Hedge effectiveness

Hedge measurement: Market Value variation daily (same as


• Hedge measurement
menu Measurement Report in Hedge query)

Hedge (hedge insertion, modification and suppression) audit


• Hedge audit
summary and details of old / new values

Hedge strategy audit summary and details of old / new values • Hedge strategy audit

Hedge effectiveness method audit summary and details of old


• Hedge effectiveness method audit
/ new values

1.9 - Category: Order

Data Type Dynamic Table Class Type

Order log: general monitoring report • order

Order allocation matrix: List the allocation ratio, the live


• order
quantity and the portfolio for each component of a block order

Execution output: to report the transactions that are coming


from order, this is a draft report showing the link between order • order
execution and the generated transaction

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 68
Appendix 2 - Transaction Class Type

2.1 - Introduction

If the Class Type is set to Transaction, a choice of computation engine is given, each one offering different types of
results. A description of each dynamic table is provided in the document Dynamic Databases Specific Fields dyn_fields.xls
. A general description of these tables is provided below.

2.2 - DYN_TRNRP_PL: Trades description + Profit & Loss (P&L)

This selection, which gives a breakdown of Realized/Unrealized P&L, is adapted to reports displaying the Capital
Gain/Economic P&L but also to open positions. The contribution of purged deals as well as P&L transfers and adjustments
is included (records with the field NB equal to 0).

The output displays one line per transaction, and each record can show results as of 3 different revaluation dates.

The most common used fields are:

• P&L set:
♦ PL_CGR,PL_CGU
♦ PL_CGRA, PL_CGUA
♦ PL_RVR, PL_RVU
♦ PL_RVRA, PL_RVUA
♦ PL_CSFI
♦ PL_FTFI
• MP (market parameters) set:
♦ MP_UPRC, MP_SPOT, MP_
• S (sensitivities) set:
♦ S_Delta, S

This dynamic table contains specific flags that are described in the section 4

2.3 - DYN_TRNRP_CS

This table gives security and cash flow details, and displays one line per cash/security flow. It is primarily used for cash
management reports showing flows, cash balances, financing ...

The Cash/security flows are returned as of one date only (third computing date). The first two computing dates can be
used for filtering. To activate security flows, the "Include security flows" flag should be checked at dyn table configuration
level.

The most commonly used fields:

• F_AMOUNT (F_AMOUNTF)
Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 69
Dynamic Tables, 2014-07-25

• F_CURRENCY
• F_VALUE
• F_DTEEVENT
• F_TYPE(C,R,EXR,XIT), F_TYPELAB (5 fields)
• F_OBSCOM (post filter F_OBSCOM="N")

The associated Creation Codes and corresponding description are detailed below:

Field Definition
Past cash + Initial payments not yet paid (e.g. option
CASH_DETAIL_ALL
premium)

CASH_DETAIL_ALL_EVALFUT Past cash + Future cash proceeds from known fixed flows

Past cash + Initial payments not yet paid + Fut. cash from
CASH_DETAIL_ALL_ESTIMFUT
fixed flows + Fut. cash from estimated floating flows

CASH_DETAIL_FUTURE Initial payments not yet paid

CASH_DETAIL_FUTURE_EVALFUT Future cash from fixed flows

Initial payments not yet paid + Future cash from fixed flows
CASH_DETAIL_FUTURE_ESTIMFUT
+ Future cash from estimated floating flows

CASH_DETAIL_PAST Past cash

Only the flows having a value strictly greater than a certain tolerance will be displayed. The tolerance is set to 0.01 by
default but can be customized via the Tolerance box:

Figure 86 : Tolerance box

For instance, a flow having a value of 0.0001 is considered as a null flow and is not returned.

In order to cancel this behavior and return all flows, the "Include null flows" flag can be ticked. Details on this flag can be
found below 4

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 70
Dynamic Tables, 2014-07-25

2.4 - DYN_TRNRP_DT: Deals Details

It is specially designed for multi-period deals such as Interest rate swaps. It returns the specific details of each individual
period and leg, and covers swaps, FRAs, swaptions, bonds, bond forwards, bond repos, bond buy/sell backs, and
lending/borrowing deals.

Most of the fields appear twice: those indexed with 0 refer to the first leg and those indexed with 1 refer to the second leg.

The most frequently used fields are:

• DT_START / DT_END
• DT_CAPREM (Nominal), DT_PRMAM (interest)
• DT_PAYMNT (interest payment date)
• DT_FIXING (fixing rate)

The Creation codes associated with this class are the following:

Field Definition
Floating/fixed legs are displayed on the same line (suffixes 0
DATA_HORIZONTAL
& 1)

Floating/fixed legs are handled separately; number of lines


DATA_VERTICAL
generated = n fixed and m floating (suffix 0).

2.5 - DYN_TRNRP_XG: Fixing

It includes detailed information on the floating leg of interest rate instruments.

It displays one line per fixing period and the most commonly used fields are:

• XG_FIXRT1, XG_FIXRT2
• XG_FIXING (date)
• XG_FIXED (Y/N)
• XG_START, XG_END (period start/end date)
• XG_FIXAMT (interest)

The Creation codes associated with this class are:

Field Definition
Default One line generated for each floating fixing

INCLUDE_FIXED_FLOW Records for both floating & fixed rollovers are generated.

This dynamic table contains additional flag that is described in the section 4

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 71
Dynamic Tables, 2014-07-25

2.6 - DYN_TRNRP_SV: Sensitivities

This dynamic table gives the detailed sensitivities per deal according to the pillars of the rate curve for interest rate
products, and detailed sensitivities by basket component.

For Interest Rate products:

• Returns detailed sensitivities by maturity bucket and by rate curve. Includes ZC zero coupon sensitivity and
market rate sensitivity

For multi-instrument flex deals:

• Returns sensitivities by Deal and by Instrument.

Fields:

Field Definition
SV_AMOUNT sensitivity amount

SV_DATE1 sensitivity period start

SV_DATE2 sensitivity period end

SV_UNIT currency

SV_INS11 interest rate curve

SV_PARAM1

IRD: ZC / Market rate indicator

Flex Spot indicates Delta or Gamma; rate indicates Rho, RhoF

Murex recommends to use the Simulation Class type to output sensitivities.

2.7 - DYN_TRNRP_MK: Market Operations

This Dynamic Database provides a detailed description of all events performed in the system (one record per event and
per deal version) and their related information, plus a detailed description of the corresponding trades. It provides
transaction details, cash flows and events related information. It displays all the transactions versions and all the events
versions since the first insertion date of the first version of the transaction (trade insertion returns one single line with a
version equals to 1).

The revaluation dates could be used as follow:

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 72
Dynamic Tables, 2014-07-25

Date 0: 1st revaluation date

Date 1: 2nd revaluation date

Date 2: Event filter. All events prior to Date 2 will be displayed.

The field list provides trade details will all standard TP fields plus a specific list of fields with their name started with V_.
The TP fields are related to the trade whereas those fields are related to the trade version itself, more precisely V_* fields
are related to the action whereas V_EVT* fields are related to the event itself. Here is a description of the specific fields
provided by this dynamic table.

Field Name Description Field Name Description


V_ACTOR Version actor V_CNT_SRC Contract source

V_TST Version timestamp time (ms) V_CNT_DEST Contract destination

V_TSD
Version system date (timestamp) V_AVQTY Current available quantity
(SYSDATE)

V_TSH
Version system time (timestamp) V_IMPQTY Current impacted quantity
(SYSTIME)

V_TRD_REF Physical trade reference V_EVT_OREF Event origin reference

V_STP_STS STP validation level status V_EVT_VER Event version

V_STP_STS0 STP status 0 V_EVT_CLS Event class id

V_STP_STS1 STP status 1 V_EVT_REF Event reference

Version actual date.


Note that V_ACTDT is different from
MRPL_DATE: MRPL_DATE is only modified
V_STP_STS2 STP status 2 V_ACTDT when a new transaction is generated. For
example, it is updated for a C&R but not for an
Unwind. On the contrary, V_ACTDT is updated
for each new version.

V_STP_STS3 STP status 3 V_LAT Version acceptance flag

Number of event settlement flows (should be


V_STP_STS4 STP status 4 V_EVSTLNB used with the creation code
ACTIVATE_MULTIPLE_SETTLEMENTS )

Index of current event settlement flow (should


V_VERSION Current contract version V_EVSTLIND be used with the creation code
ACTIVATE_MULTIPLE_SETTLEMENTS )

Amount of current settlement flow (should be


V_UDF_REF Version component UDF reference V_EVSTLAMT used with the creation code
ACTIVATE_MULTIPLE_SETTLEMENTS )

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 73
Dynamic Tables, 2014-07-25

Date of current settlement flow (should be used


V_CMP_EXT Version component extension reference V_EVSTLDTE with the creation code
ACTIVATE_MULTIPLE_SETTLEMENTS )

Currency of current settlement flow (should be


V_ACTION Version action V_EVSTLCUR used with the creation code
ACTIVATE_MULTIPLE_SETTLEMENTS )

V_DATE Version date

Financed past cash proceeds (Capital)


Non-financed past cash proceeds (Capital)
(should be used with the creation code
PL_CSCF PL_CSCNF (should be used with the creation code
ACTIVATE_OUTSTANDING_QUANTITY
ACTIVATE_OUTSTANDING_QUANTITY)
)

Financed past cash proceeds (Revenue)


Non-financed past cash proceeds (Revenue)
(should be used with the creation code
PL_CSRF PL_CSRNF (should be used with the creation code
ACTIVATE_OUTSTANDING_QUANTITY
ACTIVATE_OUTSTANDING_QUANTITY)
)

Financed future cash proceeds (Capital)


Non-financed future cash proceeds (Capital)
(should be used with the creation code
PL_FPCF PL_FPCNF (should be used with the creation code
ACTIVATE_OUTSTANDING_QUANTITY
ACTIVATE_OUTSTANDING_QUANTITY)
)

Financed future cash proceeds (Revenue)


Non-financed future cash proceeds (Revenue)
(should be used with the creation code
PL_FPRF PL_FPRNF (should be used with the creation code
ACTIVATE_OUTSTANDING_QUANTITY
ACTIVATE_OUTSTANDING_QUANTITY)
)

Financed market Value (Capital)


Non-financed market Value (Capital)
(should be used with the creation code
PL_MVCF PL_MVCNF (should be used with the creation code
ACTIVATE_OUTSTANDING_QUANTITY
ACTIVATE_OUTSTANDING_QUANTITY )
)

Financed market Value (Revenue)


Non-financed market Value (Revenue)
(should be used with the creation code
PL_MVRF PL_MVRNF (should be used with the creation code
ACTIVATE_OUTSTANDING_QUANTITY
ACTIVATE_OUTSTANDING_QUANTITY )
)

Currency
Key1
(should be used with the creation code
PL_CUR PL_KEY1 (should be used with the creation code
ACTIVATE_OUTSTANDING_QUANTITY
ACTIVATE_OUTSTANDING_QUANTITY)
)

Event Settlement Price for UNWIND and


MK_STLPRC
EXERCISE

The creation code selection is optional:

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 74
Dynamic Tables, 2014-07-25

Creation Code Definition


None One record per trade per version.

ACTIVATE_MULTIPLE_SETTLEMENTS Allow to provide multiple settlement flows per version:


One record per trade per version per settlement flow

Used to replicate MxG2000 behavior:

• in addition to the lines created for each event, an additional line is


created at the end to represent the outstanding quantity if it is
ACTIVATE_OUTSTANDING_QUANTITY
non-null
• PL_xxxx fields are populated with the exact same behavior than in
MxG2000

Additional flag can be set on this kind of dynamic table and the details can be found in this section 4

2.8 - DYN_TRNRP_MV: Profit &Loss + Market Value

It is adapted to reports displaying the Cash and Market Value; it is used to split the contribution of P&L by flow currency.

It returns the P&L as of three dates, and displays in the outputs one line per Cash flow currency, per transaction. For
example, if one trade has cash flows in two different currencies, TRNRP_MV will display two lines (currency swaps,
spot/forward deals etc).

The most commonly used fields are:

• MV_CUR
• MV_FCS, MV_NFCS (past cash)
• MV_FFP, MV_NFFP (future proceeds)
• MV_FMV, MV_NFMV (market value)

The Creation code selection is mandatory. The ones associated with this class are:

Creation Code Definition


LEG_CNS Consolidation by currency of the deal legs

LEG_DETAIL Detail of the deal legs regardless of the currency

2.9 - DYN_TRNRP_CD: Call-Deposits

Displays the detailed events and interest calculation of Security Finance and Call Deposit trades; one line per event.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 75
Dynamic Tables, 2014-07-25

The most commonly used fields are:

• CD_CTRP, CD_CUR, CD_DEST, CD_GEN, CD_INDEX: Counterpart, Currency, Destination portfolio, Generator
and Index.
• CD_MARG, CD_MARG_F: event margin and event margin flag.
• CD_RATE, CD_RATE_F: event rate and event rate flag.
• EVT_BEGIN, EVT_END:First event and Last event.
• EVT_CANCEL: Event canceled.
• LB_NEW_M, LB_NEW_Q, LB_OLD_M, LB_OLD_Q: New margin, New quantity, Old margin and Old quantity.
• LB_PRICE: Event closing price.
• LB_RET_Q: Returned quantity (decrease/increase quantity for example).
• TP_IQTY, TP_LQTY2: Initial and Live quantity.
• TP_PRICE: Settlement price.
• TP_RTMNDD0, TP_RTMNDD1: Leg 1 and Leg 2 main displayed indexes.
• TP_FEE: Event fees.

The creation code selection is necessary :

Creation Code Definition


TRNRP_CD returns one line per event.
Call / Deposit events: deposit, withdrawal, etc...
Standard
Security Finance events: Shares modification, Early termination total return, Rate
amendment, SLA, Capital increase/decrease, Interest payments, etc...

In addition to the lines per events TRNRP_CD returns one line per day. This mode enables
Daily accrual
the user to see the daily calculation of interest.

Additional flag can be set on this kind of dynamic table and the details can be found in this section 4

2.10 - DYN_TRNRP_OK

This Dynamic Table is not used in the datamart context. When computed via the DAP API, it gives the user the possibility
to export the MxML tree of a deal in a table or in an XML tree.

This table should not be used anymore.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 76
Appendix 3 - Data Dictionary Service Class Type
Data dictionary service Class type is used to transfer market data from production database to datamart. The parameter
specified is a data dictionary engine, composed by two elements : a loader which executes a request defined thanks to
SQL editor, and a formatter which organises the output of the request in a view.

Dynamic table of class type Data dictionary service contains 3 computing dates :

Figure 87 : Data Dictionary Service computing date configuration

The first 2 dates are used to define a range of date and are only relevant for Data Dictionary Service based on a loader
defined with class value equals to Market data.Fixings.Rate indices. For such dynamic table, the top first date is the fixing
start date and the second date is the fixing end date. The last date is by default Contextual today and should stay
unchanged because it is not used. In the example above, the dynamic table is configured to retrieve historical index rates
for a range of dates beginning at 10th December 2002 to 15th December 2002 (included).

For dynamic table of class type Data Dictionary based on a loader defined with class value different than Market
data.Fixings.Rates indices, the two first dates are not relevant and only the last one should be configured : it defines the date
on which we want to get market data values.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 77
Appendix 4 - Flags
The flags are some settings that will impact the dynamic tables outputs. They are specific to class type and creation class
dynamic tables. They are available in the main screen of the dynamic table definition in the section Dynamic creation
flags.

The table below provides functional description of the different flags and displays on which kind of dynamic table there
apply . For instance the "Default is closing price" flag is available for all dynamic tables having class type=Transaction.

Figure 88 : Default is closing price

Dynamic Table Dynamic table


Flag Functional description
Class Type creation class
This flag enables the non-discounted closing price
to be displayed instead of the calculated
theoretical market value. This setting will impact
the fields PL_FMVCL (the discounted closing
market value), PL_NFMVCL (non discounted
Default is closing price closing market value) and PL_NFMV (non Transaction ALL
discounted market value).
As a prerequisite, the market value should have
been imported first from an end user session from
the menu Middle Office /Closing prices/set trade
market values

The "Include null brokerage fees details" flag


Include null brokerage
ensures that brokerage fees are taken/not taken Transaction ALL
fees details
into account if this flag is checked/unche c ked.

Extend selection It gives the possibility to handle the contract/ Transaction ALL
package not i on at the level of the dynamic table.
If this flag is checked, the user will be able to get
all the legs of a contract which has not expired yet.
The computation can then be done in three
modes:
- A 'trade' mode: (The flag is unchecked)
- A 'contract' mode: All the trades which belong to
a contract are returned. At least one of the trades
should be selected by the per-filter

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 78
Dynamic Tables, 2014-07-25

- A 'package' mode: All the trades which belong to


a package are returned. At least one of the trades
should be selected by the per-filter.

The "Include archived deals" flag enables the user


Include archived deals to include or not the logically purged deals in the Transaction DYN_TRNRP_PL
computation.

This flag allows the system to retrieve all flows


Include null flows Transaction DYN_TRNRP_CS
and in this case the tolerance setting is ignored.

When th is flag is ticked, a line is created for trade


insertions.
A filter based on event type is available to filter out
events which were not market operations in
MxG2000 (e.g. fixings).
Include trade insertion A maintenance step is available for migration Transaction DYN_TRNRP_MK
projects: "Transfer TRNRP_MK Dynamic Tables"
which automatically selects the
ACTIVATE_OUTSTANDING_QUANTITY creation
mode for TRNRP_MK tables and untick s "Include
trade insertion".

The "Include last revision flows" enables to


Include last revision flows retrieve records related to instruments' dividends, Transaction DYN_TRNRP_CD
interests and capitals.

This flag enables to retrieve flows related to the fix


Fixing details leg, not only fixing information related to the Transaction DYN_TRNRP_XG
floating leg.

The "Counterpart - side simulation" flag computes


the positions, sensitivities, P&L and cash flows
from the counterpart side. The figures retrieved by
Counterpart-side
the dynamic table are matching with a simulation Simulation view
simulation
executed from the menu Simulation/counterpart
side simulation. As a consequence, the figures will
have opposite values when this flag is ticked.

When activated, all STP templates configured in


Extract all templates the system, not only the template that is assigned STP Rights
to the group the user belongs to.

The "Disputed only" flag allows filtering on the


collateral exchange objects being disputed. A
Disputed only collateral exchange is set as disputed when a Collateral exchange
dispute event is applied on one margin call and
may impact one or many of its requirements.

Printed for MUREX+INTEGRATION Copyright 2014 Murex S.A.S. All rights reserved. 79