Compliance Reference Guide

5/21/2019 Compliance Reference Guide
You are here: Home > Front Office - PM > Front Office > Compliance Reference Guide
https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/Compliance Reference Guide.htm#_Toc528938570%3FTo… 1/61

Compliance Reference Guide
Introduc on
Front Office - Por olio Management (PM) is a comprehensive asset management package for UNIX-Windows NT networks. The package implements the latest client/server technology in conjunc on with the Sybase database. Front Office - PM
server-side modules use advanced analy cal and flow control features, including a financial server, report generator and database server to structure, access and administrate the database.
On the client side, Front Office - PM runs on Windows NT worksta ons. A variety of screens allows you to interact with the Sybase database. The data in the fields presented on the various screens is recorded directly in the appropriate tables in
the database when you validate it (usually by clicking OK in a data entry screen).
Front Office - PM makes extensive use of lists to display table data. For many opera ons, a selec on screen first displays a list so you can select an exis ng entry to view or modify. If the object is not in the list or the list is empty, a Create bu on
lets you create a new object of the list type. When you create and validate a new object, you are in fact entering a new record in the database. When you view or modify a list item, you are in fact reading records from the database and returning
modified records to the database if you validate your changes. A host of hidden features helps you manage this data and perform a wide range of financial calcula ons on it.
Front Office - PM also includes extensive, advanced script and interface languages that allow you to run the program in batch mode and customise it to meet your requirements. That way, Front Office - PM can manipulate large volumes of data.
Front Office - PM implements all the financial func ons used in today's markets and let you perform and record all the major financial opera ons currently prac sed. Advanced analysis and risk features help you make the right decisions on me.
About this document

This product guide describes the concepts and features of Front Office – PM that are related to investment compliance. Investment compliance treats regula ons such as the European Union’s Markets in Financial Instruments Direc ve (MiFID).
Banks have to ensure that order and investment proposals match with their client's objec ves, risk tolerance, financial knowledge, and experience.
The main features of Front Office - PM to support banks in these aspects are:
Different types of strategies to define investment objec ves.

Different types of constraints to define specific restric ons.
Strategy deriva on: Create a specialised strategy for a client from a standard one under considera on of client-specific constraints.
Pre-Trade Compliance Check: All orders are checked to be in line with the investment strategy, constraints, suitability, and appropriateness rules before they can be released for trading.
Case Management Component (CMC) to keep track of all viola ons.
Audience
This product guide is intended for Super Users and Implementa on Consultants.
Strategies
The Produc vity module of Front Office - PM lets you define investment guidelines that you can use for financial engineering, trading, and control ac vi es associated with Por olio Management.
Front Office - PM offers two dis nct ways of using this func onality:
A top-down approach that lets the Por olio Managers check that por olios are in line with predefined investment policies. Front Office - PM performs Actual/Target comparisons, recognises differences, and
provides the user with Sell and/or Buy proposals to align a por olio or mul ple por olios with associated strategies (these func ons are called Check Strategy and Strategy Reconcilia on in Front Office - PM).
A bo om-up approach that lets the Por olio Managers check that new orders/opera ons do not violate investment guidelines or restric ons (this func on is called Order Alloca on in Front Office - PM).
A strategy can have different origins and reflect different types of investment guidelines and restric ons:
Legal regula ons can impose investment compliance on the investment por olios of certain ins tu ons (e.g., pension funds, insurance companies) and control discre onary por olio management in some
countries (e.g., Switzerland).
Audit & Control Departments can define internal rules that must be respected by in-house Asset Managers (e.g., exposure limits, credit margins).
Investment Commi ees can regularly define Asset Alloca ons for the por olios in their care. In Private Banking, this can mean customer groups sorted by investor profile that are managed directly by the
por olio management department (e.g., CHF Balanced, USD Growth). As in ins tu onal asset management, the goal is to set guidelines for internal and external asset managers who are responsible for sub
por olios that focus on a special asset class (e.g., Yen Conver ble Bonds, Emerging Markets Equity).
Por olio Managers who specialise in a par cular asset class or market can consequently define specific Model Por olios based on their speciality (e.g., European Stocks, NASDAQ Blue Chips).
Financial Analysts can make buy and sell recommenda ons based on their research ac vity (e.g., buy Microso , hold Nestle, increase Bridgestone).
An addi onal type of strategy, the Surveyed Securi es List (SSL) can be used to provide analysts with a centralised repository of securi es. This repository can be used to store No onal Instruments (i.e., generic instruments used to set objec ves
for certain Market Segments in Model Por olios).
Front Office - PM can archive Strategy History records for each strategy nature because most strategies are not sta c and tend to change over me. You can, therefore, specify the Strategy Elements associated with a strategy for a given period of
me and perform accurate comparisons, even if the period has finished.
Before moving on, the following are a few important points to remember about strategies in general.
Before you create your strategies, it is advisable to first create the different grids that the Asset Alloca on, Model Por olio, or Recommenda on List is based on. Remember that the Market Segments are the
building blocks of the strategies. Always create the head grid of the hierarchy first, then its child grids, etc.
You can create hierarchies of strategies using alloca ons, sub-alloca ons, Model Por olios, and Recommenda on Lists:
You can build a hierarchy of Asset Alloca ons defining a top strategy for the whole por olio and sub-strategies for dis nct parts of the por olio.
You can also build a strategy hierarchy composed of Asset Alloca ons, Model Por olios, and Recommenda on Lists. To achieve this, do the following:
Make one Asset Alloca on the Parent Strategy. This strategy must contain a Market Segment that is defined in more detail in another strategy (such as an Asset Alloca on, Model Por olio, or
Recommenda on List).
Define the detailed Market Segment as the Parent Market Segment of the sub-strategy.
At the top of the hierarchy, specify if the strategies and associated sub-strategies are to be applied to a risk view (Risk Flag check box selected) or an accoun ng view of the por olio. In other words, specify if a
strategy is defined in terms of risk exposure or not. This informa on is used when Front Office - PM compares a por olio with a strategy.
If you choose the risk view, the risk exposure valua on of the por olio is taken into account in the comparison. The sub-strategies inherit the view
of the top strategy.
You can also define a currency at the strategy level (in the Create/Modify Strategy screen). The Currency data is not processed at this point. Typically, the currency is associated with the por olio base currency
in private banking or the specific Market Segment or Asset Class in ins tu onal asset management.
Do not try to modify the composi on of the grid once an alloca on is associated with it.
The strategies of nature Alloca on, Model Por olio, and Index can be linked to a quote valua on rule. This rule can be used to give preference to prices of certain types, markets, or providers. The main business
objec ve of this feature is to link the strategy to prices that have already been adapted for corporate ac ons. This prevents distor ons in dynamic weights due to price changes from splits, rights a ribu ons,
etc. When calling the Check Strategy func on or the Strategy Reconcilia on func on for a por olio against a strategy with a quote valua on rule, the strategy's rule will only be applied to the prices, which are
retrieved for the strategy. The por olio will be valuated with the prices according to its quote valua on rule, or the rule in the domain, respec vely.
The strategies men oned above are further detailed in the following sec ons:
Alloca on
Model Por olio
Recommenda on list
Index
Investment Profile
Benchmarks
Surveyed Securi es Lists
Risk strategy
Security access
Strategy administra on
Strategy Links

Alloca on
Alloca ons are targets set for various asset classes in a dis nct group of assets or instruments. Mul ple alloca ons can be linked hierarchically, which means that you can have a master (or primary) alloca on with associated sub-alloca ons.
The following is an example of an Alloca on called the CHF Balanced Investment Model:
Where:
Classifica ons used to build the Investment Grid above:

Category
Currency
Instrument lists used to build the Classifica ons above:
Category: Equity, Bonds, Liquidity, Others
Currency: CHF, EURO, USD, Others
Possible sub-strategies are:
Model Por olio or Recommenda on List
Asset Alloca on on US Stocks
Growth Stocks, Value Stocks, Others
Financial, Technology, Retail, Others
Concepts of alloca ons are explained in the following sec ons:
Asset classes
Investment targets and margins
Sub-alloca ons
Market Segment: Other
Asset classes
Asset classes (known as Market Segments in Front Office - PM) are defined using lists of instruments. These lists are grouped into classifica ons. The classifica ons are then used as the basis for building grids. Every alloca on strategy is based on
one or more matrices (i.e., a grid or a list of grids) showing the asset classes the por olio must invest in. To set up asset classes, you must create in the following order:
instrument lists
classifica ons
grid
The distribu on of the assets is user-defined and can be based on any list of instruments. The breakdown of the instruments can be based on their category, risk currency, sector a ribu on or other useful criteria. Instruments can also belong to
dynamic lists whose composi on changes over me (e.g., ‘bonds with a life of less than two years’).
Refer to the WealthSuite Front Office - Por olio Management - User Guide for more detailed informa on on lists, classifica ons, and grids.
Investment targets and margins

As the user, you define the associated investment targets in a Strategy Element. You can choose from the following investment targets:
percentage weight
minimum or maximum weight
dura on or the contribu on to the por olio dura on (Hicks)
beta or contribu on to the por olio beta
current yield or the contribu on to the por olio current yield
minimum ra ng rank
You can set mul ple targets for the same asset class.
Note that the Tracking Error investment target nature has not yet been implemented. The Tracking Error nature sets the devia on allowed between por olios and their benchmark returns and displays a warning message if the set devia on is
exceeded.
You can indicate a Fluctua on Margin for each target (if none is specified for a target with the nature ‘Weight’, Front Office - PM uses the margin defined at the strategy level). You cannot define this margin for the minimum/maximum weight and
the minimum ra ng.
You can define rela ve Fluctua on Margins for the different investment targets. The following is an example of the three different ways to compute Fluctua on Margins:
Example
Consider an Investment Profile (Asset Alloca on, with an objec ve weight = 10% on Chemicals, and a Model Por olio with two instruments: 50% Novar s and 50% Roche).
The Fluctua on Margin is defined as equal to 1% in the Model Por olio.
Stock/CHF
Chemicals Objec ve: 10%
Novar s 5%
Roche 5%
The computa on of the Fluctua on Margin is as follows:
Absolute: the Fluctua on Margin is weighted by the Market Segment objec ve weight:
1% * 10% = +/- 0.10%

Rela ve: the Fluctua on Margin is weighted by the instrument objec ve weight:
1% * 5% = +/- 0.05%.
Unweighted Absolute: there is no weigh ng on Fluctua on Margin: +/- 1%.
Sub-alloca ons
You can define sub-alloca ons for the different asset classes of an alloca on:
Equity Bonds Liquidity Other
CHF Weight = 15% Weight = 25% Weight = 6%
Beta = 1.2
Euro Weights = 5% Weight = 15%
Life > 2 years
USD Weight = 8% Weight = 8% Weight = 3%
Return > 15% Dura on = 8
Sub-strategy is
Asset Alloca on or
Model Por olio or
Recommenda on List
Other Weight = 3% Weight = 5% Weight = 7%
Minimum ra ng: AAA
The high-level Asset Alloca on is based on category classifica on (Equity/Bonds/Liquidity/Other) and currency classifica on (CHF/EURO/USD/Other).
You can subdivide the US Stocks asset class, say, into capitalisa on (Large Cap/Mid Cap/Small Cap/Others) and sector classifica ons (Finance/Technology/Retail/Others). To do that, you must define the sub-strategy and define the higher-level
asset class as its parent asset class (i.e., Parent Market Segment). Note that you must have already defined the head strategy.
The following example uses the USD equity from the example above:
Element Descrip on
Grid In the above example, the grid is based on a capitalisa on classifica on and a sector
classifica on. The grid must be based on specific lists in the Capitalisa on and Sector
classifica ons that must already exist or be created first.
Parent In the above example, this US Stocks (i.e., the 8% of USD Equity.
Market
Segment
Parent In the above example, the higher-level Asset Alloca on of the CHF Balanced
strategy Investment Model.
Example
Sub-alloca on called USD Stocks:
Equity Bonds Liquidity Other
CHF 15% 25% 6%
Euro 5% 15%
USD 8% 8% 3%
Other 3% 5% 7%
Small Caps Mid Caps Large Caps Other
Finance 5% 10% 20%
Technology 15% 10% 15%
Retail 5% 2% 10%
Other 3% 5%
Note also that the weight investment targets specified at the sub-alloca on level are stored as a percentage of the market value (8%) of the Parent Market Segment (i.e., objec ve weight). However, you can use the Edit Strategy Objec ves op on
to edit both the objec ve weight and the objec ve weight contribu on.
Basically, you are defining two strategies and making one the child of the other. The grids and the lists from which they are constructed that are used by alloca on strategies must already exist. The child must be an Asset Alloca on, Model
Por olio, or Recommenda on List. For sub-alloca on, the grid on which the sub-strategy is based can be a child of the parent strategy's grid.
You can edit the whole hierarchy of strategies in the same administra on screen, provided that they are linked together through the Parent Strategy parameter and contained in the same strategy list.
Market Segment: Other

We recommend that you include an instrument list with the nature ‘Other’ in the different instrument classifica ons that you use to build up grids. You should do this for the following reasons:

It avoids dispatching posi ons to the wrong Market Segment when por olios are compared with Asset Alloca ons. The Other instrument list acts as a posi ons bin.
The Market Segment ‘Other’ (that is, one based on instrument lists with ‘Other’ as their nature) is required if you run Produc vity func ons on a par cular Market Segment.
It is recommended not to define specific investment objec ves for the Market Segment ‘Other’.
Model Por olio

A Model Por olio is a series of instruments with an associated weight. It represents a percentage of the market value of the Parent Market Segment. Again, you can define a Fluctua on Margin at the strategy level that is applied by default to
each Strategy Element (i.e., each selected instrument). For display purposes, all instruments are assigned a Rank. The Rank defines the ranking order of an instrument in the Model Por olio history.
Besides the rank, the Model Por olio can use a priority set for individual instruments. This priority set allows users to priori se the purchasing of some instruments instead of others (for example, if there is not enough cash in the por olio). If
priority sets have the same value, the processing takes into account the degree of devia on from the objec ves (processing details are given later in this guide). The highest priority is 1.
A Model Por olio can represent an individual strategy. Therefore, it can be independent from any Asset Alloca ons. However, a Model Por olio cannot be the Parent Strategy of another strategy. On the other hand, it can be assigned to a Market
Segment of an Asset Alloca on like US stocks, as shown above. For example, take a Model Por olio for USD Stocks:
Stock Target Margin
Microso 28 % 7%
GE 20 % 5%
Boeing 15 % 3%
Chrysler 12% 3%
Philip Morris 8% 2%
Kodak 7% 2%
Coca Cola 5% 2%
Wal Mart 3% 1%
AT&T 2% 1%
Concepts of Model Por olio are explained in the following sec ons:
Model Por olio with grid

Constant weight Model Por olio
Real Model Por olios
Cash account objec ve weights
Model Por olio with grid

Model Por olio with grid means that for informa on purposes, the different instruments that make up the Model Por olio are grouped by asset classes. The following table provides an example of a Model Por olio with grid:
Total 100%
25%
Industrial sector
ABB 12.5%
Schindler bon 12.5%
25%
Financial sector
UBS nom. 12.5%
Zürich nom. 12.5%
50%
Other
Nestlé 12.5%
Roche 12.5%
Novar s 12.5%
Algroup nom. 12.5%
When entering the instruments into the Model Por olio, they have to be put into the correct Market Segment (i.e., the Market Segment to which they belong).
When Super Users define the main features of the Model Por olio, they can specify one or more matrixes (i.e., grids or grid lists) that contain the securi es. The objec ve weights are summed bo om-up. Note that the Market Segment sub-totals
are saved to the database to specify the margins.
Also, you can update these matrixes (i.e., grids or grid lists):
1. Select the strategy screen and then the Model Por olio you want to modify.
2. Choose Tools > Update Grid and modify the grid dimension and grid.
3. Click OK to save your changes.
Note that the default values are not re-executed.

Constant weight Model Por olio
You can specify the Model Por olio sub-nature Constant Weight. In this case, instead of storing the objec ve weight of an instrument, you save the objec ve weight contribu on of the instrument. Consequently, it makes sense to use this type of
Model Por olio if it is defined as a sub-strategy. If the Model Por olio is not defined as a sub-strategy, the objec ve weight is equal to the objec ve weight contribu on.
Real Model Por olios

You can compare por olios against a real Model Por olio in the same way as you can rebalance or check por olios against a Model Por olio strategy.
The relevant informa on to create a real Model Por olio is as follows:
Field Descrip on
Nature Model Por olio.
Por olio Enter the name of the dummy or real por olio used as a Model Por olio.
Sub-nature Dummy por olio.
Rela ve Absolute, Rela ve, or Unweighted Absolute.

Margin
Fluctua on Fluctua on margin value.

Margin
Grid You can specify a market structure and display the Model Por olio posi ons
Dimension according to the structure. The instruments are grouped by asset class and the
And Object corresponding weights are summed bo om-up.
Parent As with any strategy, you can specify a parent market. This allows you to link the
Market strategy to an asset class. Note that the posi ons held in the por olio that do not
Segment belong to this asset class are filtered (see below).
Parent As with any strategy you can specify a parent strategy.

strategy
No Strategy History or Strategy Element records are required for this type of Model Por olio. Finally, as with any strategy, you set up a Strategy Link between the real Model Por olio and the client por olios that you manage.
When you run a comparison (for example, Check Strategy, etc.) between your client por olios and the strategy, the system computes the different objec ve weights. This process is based mainly on a valua on of the real Model Por olio.
The valua on parameters are as follows:
STRAT_NET_AMOUNT_FLAG system parameter can only be set by the System Administrator on the Select Parameter screen, which can be accessed by choosing Administra on > Security > Parameter. This
parameter indicates whether the amounts used when checking strategies are net amounts or the market value (that is inclusive of Accrued Interest). To modify the parameter’s value, System Administrators can
select the parameter on the Select Parameter screen and click the Modify bu on.
Default Posi on Logical Id rule (Parameters tab of Valua on Domain screen)
Merged consolida on (Parameters tab)
All posi ons are loaded (i.e., all statuses, Min Cancelled, and Max Status 9 on the Loading Data tab)
The valua on date is the strategy date specified in the domain
All instruments are loaded
Zero quan ty posi ons are not loaded
Por olios are valued in their reference currency
No specific Fusion Date Rule
Posi ons with nega ve and posi ve amounts are merged (close_pos on_f = 1)
Risk view and delta exposure
No fund spli ng
This returns a series of instruments with an associated weight. You can define a Fluctua on Margin at the strategy level that is applied by default to each Strategy Element (i.e., each instrument).
Example (2% as absolute Fluctua on Margin):
Instrument Weight Margin
Total 100%
Alcatel 12% +/- 2%
Bri sh Telecom 10% +/- 2%
Daimler 13% +/- 2%
Volvo 13% +/- 2%
Unilever 24% +/- 2%
Paribas 24% +/- 2%
Euro 4% +/- 2%
If you specified a market structure at the strategy level (i.e., grid/grid list), the instruments are grouped by asset class.
Example (sector grid):

Sector Grid Weight Margin
Instrument
Sector Grid 100%
Finance 24% +/- 2%
Paribas 24% +/- 2%
Transports 26% +/- 4%
Daimler 13% +/- 2%
Volvo 13% +/- 2%
Food 24% +/- 2%
Unilever 24% +/- 2%
Telecom 22% +/- 4%
Alcatel 12% +/- 2%
Other 4% +/- 2%
Euro 4% +/- 2%
If you specified a Parent Market Segment, the process filters all instruments that do not belong to this asset class. Consequently, the sum of the different objec ve weights may not equal 100%. The Por olio Manager who is responsible for this
asset may prefer not to invest 100% at that par cular moment in securi es. The non-invested part is held in cash.
Example (Euro Equity as Parent Market Segment):
Instrument Weight Margin
Total 96%
Alcatel 12% +/- 2%
Daimler 13% +/- 2%
Volvo 13% +/- 2%
Unilever 24% +/- 2%
Paribas 24% +/- 2%
Cash account objec ve weights

You can include cash accounts in your Model Por olios. This means that you can assign objec ve weights to cash accounts.
Example:
Instrument Weight Margin Descrip on
Total 100%
Alcatel 23% +/- 2% All posi ons in Alcatel
Microso 23% +/- 2% All posi ons in Microso
Daimler 25% +/- 2% All posi ons in Daimler
IBM 25% +/- 2% All posi ons in IBM
Euro 2% +/- 2% (instrument with nature All posi ons in any cash account in
account = 4) Euro
Dollar 2% +/- 2% (instrument with nature All posi ons in any cash account in
account = 4) Dollar

When you run a comparison between your client por olios and a Model Por olio of this type, the cash posi ons are processed as follows: all por olio cash posi ons in Euro are grouped as a Euro account and all por olio cash posi ons in Dollars
are grouped as a Dollar account. Front Office - PM does not yet propose opera ons to rebalance these objec ves.
This means that you can only specify one cash account per currency in your Model Por olios. However, your client por olios can have different cash accounts for the same currency.
Note: This feature works with Model Por olios based on a real por olio.
Recommenda on list
Recommenda ons are Financial Analysts’ opinions to project future trends from fundamentals and financial models. Each company has its own terminology, but the most common ra ngs are Buy, Hold, and Sell.
Buy in case the security is regarded under its real value

Sell when it is above
Hold when it matches
Front Office - PM provides the following recommenda on natures:
Value Descrip on
Sell Posi ons are sold in every case, regardless of the Market Segment objec ve.
(Strong
sell)
Reduce Posi ons are sold if the Market Segment weight is s ll above its objec ve weight a er
(Sell) the Sell recommenda ons have been processed.
Keep Posi ons are never sold or bought through the reconcilia on process.
(Hold)
Buy Posi ons are always bought if the objec ve is not met and the Recommenda on List
(Strong is below the weight of the objec ve.
buy)
Increase Posi ons are only bought if an objec ve is not met (under-weighted), provided that
(Buy) there were already posi ons in this instrument before the reconcilia on.
Neutral Posi ons are bought or sold to meet the objec ve set for the Market Segment
Recommenda on List. Using this recommenda on allows banks to implement policies
that focus on a aining the Market Segment objec ves.
Note: Although many analysts do not differen ate Hold and Neutral recommenda ons, Front Office - PM manages the difference, mainly due to the fact that recommenda ons are translated into objec ves for rebalancing purposes.
The different supported nature of recommenda ons can be managed through what Front Office - PM calls the Recommenda on List (also known professionally as the Investment List). This list is a selec on of a set of securi es recommended for
investment. If you mainly use Recommenda on Lists to align your por olios, refer to the informa on about Recommenda on Lists in the WealthSuite Front Office - Por olio Management - Orders and Produc vity User Guide.
You can assign one or more matrices to a Recommenda on List for display purposes. In this case, the different instruments in the Recommenda on List are grouped by asset class in the Edit Strategy Objec ves func on only.
Index
Strategies of nature ‘Index’ can be used to maintain the composi on of market indices such as the Dow-Jones, EuroStoxx, SMI, etc. These strategies can only be used in the Performance Analysis func ons. For more details, refer to the
WealthSuite Front Office - Por olio Management - Performance Analysis Reference Guide.
Investment Profile
An Investment Profile is a combina on of strategies. You can group together all Model Por olio, Recommenda on List, Asset Alloca on, and Constraint strategies that you use to manage your por olios. This means that you only need to define
one Strategy Link between the por olio and the Investment Profile.
You can put instruments, strategies, or por olios into an Investment Profile but you cannot reconcile a por olio against a por olio or an instrument, for example.
Note: It is possible to include a Benchmark in the composi on of an Investment Profile but not the opposite. A Benchmark can only contain a non-composite strategy. Investment Profiles cannot contain other Investment Profiles.
The following image summarises the Investment Profile and Benchmark behaviour:
Core/Satellite Model approach within an Investment Profile
Business context
The Core/Satellite Model is an investment strategy approach that uses a ‘Core’ Model Por olio, which is largely comprised of compe vely-priced liquid assets (e.g., mutual funds, stocks, and bonds) and a ‘Satellite’ Model Por olio, which is built
with posi ons designed to exceed broad market averages.

The following illustrates how this strategy might be built through your managed clients’ por olios:
On the top, we should have an Investment Profile composed of the following strategies:
One Asset Alloca on per asset class: Equi es (Stock + Fund shares), Bonds, Conver bles Bonds, Op ons, and Cash.
Some standard Model Por olios placed under the Market Segments ‘Bonds’, ‘Conver ble Bonds’, and ‘Op ons’.
Directly placed under the Market Segment ‘Equi es’ are:
one Model Por olio that defines 80% of the segment. This is called the ‘Core’ side.
a second Model Por olio that defines 20 % of the segment. This is called the ‘Satellite’ side.
Weights are dynamic and therefore, follow the market price changes.
Defining Core/Satellite approach in an Investment Profile strategy

To be able to define and maintain the Core/Satellite approach, some relevant a ributes need to be available by assigning the applica on parameter USER_TYPE to specific users. This parameter can either be set by default (value 0) for users that
have exclusive access to Front Office - PM or by se ng it to value 1 for users that have access to Front Office - PM and Front Office - PM Web.
When alloca ng sub-strategies (such as Core/Satellite standard Model Por olio) to an Investment Profile strategy, you can define it by using the following fields:
Priority
Weight
Weight nature (None, Rela ve, Absolute, Computed by Difference)
Linking Model Por olios under the same Market Segment

Outside the Core/Satellite Model, it is s ll possible within an Investment Profile to link only one Model Por olio under the Market Segment by using the value None from the nature ‘Weight nature’. If, however, you want to link several Model
Por olios under the same Market Segment, you can use one of the following:
Rela ve Case
Absolute Case
The following are common business rules that apply:
The Investment Profile is mandatory to handle the Core/Satellite strategy.

All Model Por olios that form the Core/Satellite strategy must share the same Market Segment.
If an instrument does not appear in a Model Por olio, this means that its weight in the Model Por olio is 0%.
The models used in parallel must have the same priority in the strategy composi on.
The Asset Alloca on is mandatory in the Investment Profile. This means that you cannot merge several standard Model Por olios.
A minimum of two Model Por olios should compose the Core/Satellite strategy.
Several dummy Model Por olios under the same Market Segment are not supported.
The logical a ribute coresat_orig_strategy_id of en ty Extended Strategy Element keeps track and displays the ini al strategy iden fier when several models are merged into the Core strategy.
Rela ve Case
In the Rela ve Case, you give each Model Por olio a weight that represents the amount to invest in the Model Por olio rela ve to the Market Segment.
Specific business rules

The sum of the rela ve weights must be 100 %.
If you change the Market Segment weight in the Asset Alloca on, the weights to be invested in each Model Por olio changes accordingly.
Formula computa on
The resul ng objec ve weight for an instrument is calculated as follows:
Where:
= weight of the Parent Market Segment, to which the child strategies are a ached.
= weight of the instrument in the child strategy i (wi := 0 if the instrument is not contained in the strategy)
= rela ve weight of the child strategy i in the Investment Profile composi on (Σ li = 1)
= resul ng weight in the combined strategy for the instrument (with respect to the whole por olio’s market value)
Example
The following image illustrates one Investment Profile (IP1) composed of:
One Asset Alloca on (AA1)

One Standard Model Por olio (MP1) linked to Market Segment ‘Stock/CHF’
Two Standard Model Por olio represen ng the Core/Satellite linked to Market Segment ‘Stock/USD’:
The Core (MP3) set with a rela ve weight of 80%
The Satellite (MP2) set with a rela ve weight of 20%
Note: The "Weight nature" of MP1 must be specified with the default value None and the "Weight" must be le blank to let the system apply 100%.

The following illustrates case composi on of the Investment Profile (IP1):
The following illustrates case objec ve of the Investment Profile with the Asset Alloca on (AA1), the standard Model Por olios (MP1) and the Core/Satellite Model Por olios (MP2 and MP3):
The following illustrates the resul ng alloca on:
According to the formula described in sec on You are here: , the detail of the Rela ve weight computa on for MSFT is the following:
MSFT weight
= weight of Stock/USD * (rela ve weight of MP2 * MSFT weight in
MP2 + rela ve weight of MP3 * MSFT weight in MP3)
= 30% * (20% * 25% + 80% * 30%)
= 8.70%
Note: If the same instrument is defined in more than one sub-strategy, the system blends the objec ve weights.
Absolute Case
In the Absolute Case, all Model Por olios except one under the same Market Segment are given a fixed weight that represents the amount to be invested in the Model Por olio rela ve to the por olio market value.
For the last model, however, you do not specify a weight because it is computed by the difference between the Market Segment weight minus the sum of all Model Por olios weights.
https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/Compliance Reference Guide.htm#_Toc528938570%3FT… 10/61

The sum of the absolute weights must be less than the Market Segment weight. You must take care to keep this business rule when you change the Asset Alloca on.
If you change the Market Segment weight of the Asset Alloca on, then only the weight of the model “computed by difference” will change.
Formula computa on
The resul ng objec ve weight for an instrument is calculated as follows:
Where:
= weight of the Parent Market Segment to which the child strategies are a ached.
= weight of the instrument in the child strategy I, i = 1, …, n (wi := 0 in case the instrument is not contained in the strategy)
= absolute weight of the child strategy i in the Investment Profile composi on for the strategies with given weight, I = 1, … , n-1. The n-th strategy is the one with “weight computed by difference”.
= resul ng weight in the combined strategy for the instrument (with respect to the whole por olio’s market value)
Example

One Standard Model Por olio (MP1) linked to Market Segment ‘Stock/CHF’
Two Standard Model Por olio represen ng the Core/Satellite linked to Market Segment ‘Stock/USD’:
The Core (MP3) set with a weight computed by difference
The Satellite (MP2) set with an absolute weight of 6%
Note: The "Weight nature" of MP1 must be specified with the default value None and the "Weight" must be le blank to let the system apply 100%.
The following illustrates Case objec ve of the Investment Profile with the Asset Alloca on (AA1), the standard Model Por olios (MP1) and the Core/Satellite Model Por olios (MP2 and MP3):

According to the formula described in sec on Formula computa on, the detail of the Rela ve weight computa on for MSFT is as follows:
MSFT
weight = absolute weight of MP2 * weight of MSFT in MP2 + ((weight of Stock/USD - absolute
weight of MP2) * weight of MSFT in MP3)
= 6% * 25% + ((30% - 6%) * 30%)
=8.7%
Note: In this case, the first Model Por olio represents 20% (6% of 30%) of the Market Segment and the second 80% of the Market Segment is computed by the difference.
Handling Fluctua on Margins

Front Office - PM has applied rules to handle the Fluctua on Margins, through the Core/Satellite approach, when several Model Por olios containing the same instrument have to be blended. Details with illustrated examples are provided in this
sec on.
Note: Margins can be set globally at the Strategy level or more specifically to the instrument defined at the Edit Strategy Objec ves level, which always has a higher priority.
When more than one Model Por olio is linked to the same Parent Market Segment, the following priori es are applied over all instruments that are contained in at least one Model Por olio:
No. Rule
1 If the instrument is only contained in one of the Model Por olios, then the system applies
the margin rule of its Model Por olio.
2 If the instrument is contained in more than one Model Por olio, then the system applies
the margin rule, even if the margin is null, of the one that has the highest weight in the
Investment Profile composi on, which should be in theory the Core model.
Note: In the Absolute Case, the model with the weight ‘Calculated By Difference’ has to be
determined before.
3 If the instrument is contained in more than one Model Por olio and there is more than
one Model Por olio with the same highest weight, then the system applies the margin
rule, even if the margin is null, of the one in which the instrument has the highest
objec ve weight.
4 If the previous rules s ll do not lead to a unique result, then the system calculates the
absolute margins, based on the instrument objec ve weight, according to the margin rules
defined in the Model Por olios in ques on, and applies the smallest value (i.e., the most
restric ve margin).
Example 1

Fluctua on Margin: 9%
Rela ve Margin: Rela ve
Two Standard Model Por olios represen ng the Core/Satellite linked to Market Segment ‘Stock/USD’:
The Satellite (MP8) set with a rela ve weight of 20%
Rela ve Margin: Absolute
Note: Some specific Fluctua on Margins have been set for Segment Stock, Sub-Segment Stock/CHF, and some Instruments in the Model Por olios.

The following illustrates case objec ve of the Investment Profile with the Asset Alloca on (AA8) and the Core/Satellite Model Por olios (MP8 and MP9)
According to the business rules described in sec on Specific business rules, the following Fluctua on Margins, through the Core/Satellite approach, have been applied by the system.

Security Business Comment

Rule
MSFT Rule 2 2% Rela ve is applied because MP9 has a higher weight (80%) in the
strategy composi on
SUN Rule 1 5% Absolute is applied because the instrument is only contained in MP8
IBM Rule 1 3% Absolute is applied because the instrument is only contained in MP8
with a specific margin
JPM Rule 1 2% Rela ve is applied because the instrument is only contained in MP9
GM Rule 1 4% Rela ve is applied because the instrument is only contained in MP9

with a specific margin
Example 2
Four Standard Model Por olio represen ng the Core/Satellite linked to Market Segment ‘Stock/CHF’:
The following Satellites:
MP11 set with a rela ve weight of 40%
Fluctua on Margin: 0.015%

Note: Some specific Fluctua on Margins have been set for Segment Stock, Sub-Segment Stock/CHF, and some Instruments in the Model Por olios.
The following illustrates case objec ve of the Investment Profile with the Asset Alloca on (AA9) and the Core/Satellite Model Por olios (MP10, MP11, MP12 and MP13):

According to the previous business rules described in sec on Specific business rules, the following Fluctua on Margins, through the Core/Satellite approach, have been applied by the system.
Business
Security Comment
Rule
ABB Rule 1 2% Rela ve is applied because the instrument is only contained in MP11
Alusuisse Rule 3 5% Absolute is applied because among MP10 and MP11 with the highest
weight (40%) in strategy composi on, the instrument has the higher
objec ve weight in MP10
Bobst Rule 1 3% Rela ve is applied because the instrument is only contained in MP13
CS Rule 4 0.015% Absolute is applied because among MP12 and MP13 with the
highest weight (10%) in strategy composi on and the instrument with
the highest objec ve weight in both models, the stricter margin is in
MP12 (0.015% Absolute vs 0.6% Absolute in MP13)
Kudelski Rule 1 0.015% Absolute is applied because the instrument is only contained in
MP12
Logitech Rule 3 3% Absolute is applied because among MP12 and MP13 with the highest
objec ve weight in MP13
Novar s Rule 3 7% Absolute is applied because among MP10 and MP11 with the highest
objec ve weight in MP10 with a specific margin

Business
Security Comment
Rule
UBS Rule 3 1% Rela ve is applied because among MP10 and MP11 with the highest
objec ve weight in MP11 with a specific margin
Zurich Rule 4 2% Rela ve is applied because among MP10 and MP11 with the highest
weight (40%) in strategy composi on and the instrument with the
highest objec ve weight in both models, the stricter margin is in MP11
(0.4% Absolute vs 5% Absolute in MP10) with a specific margin
Handling excep ons

The following valida ons are applied by the Financial Server. For every excep on raised, an appropriate warning message is generated into the server log file.
If the user has defined only one Model Por olio either with Weight nature ‘Rela ve’, ‘Absolute’, or ‘Computed By Difference’, then the system processes it as a standard Model Por olio (Weight nature: None).
If a Core/Satellite strategy exists and one or several standard Model Por olios are set with the same Parent Market Segment, then the priority rule that governs them is applied. All other Model Por olios are
removed from the Check Strategy treatment.
If a Core/Satellite strategy exists and one or several standard Model Por olios are set with the same Parent Market Segment and the same priority, then the models associated with the Core/Satellite are applied
in priority. All other Model Por olios are removed from the Check Strategy treatment.
If the sum of the Rela ve weights or the sum of the Absolute and Computed By Difference weights, for a given Market Segment, is lower than 100%, then the system processes it anyway and evaluates it as an
under-allocated segment.
Benchmarks
Benchmarks allow combining strategies of nature Alloca on, Model Por olio, and Index in a top-down approach. These strategies can only be used in the Performance Analysis func ons. For more details, refer to the WealthSuite Front Office -
Por olio Management - Performance Analysis Reference Guide.
Surveyed Securi es Lists

Banks cannot analyse and offer all the securi es they define in the Front Office - PM instrument database. They can only effec vely see a subset of all exis ng securi es. Front Office - PM facilitates this task with Surveyed Securi es Lists (SSLs).
These lists allow you to include securi es in an investment universe. Organisa ons, for example, may decide to forbid Por olio Managers or Rela onship Managers to invest in securi es outside of the investment universe.
The SSL provides an entry gate (or filter) to all instruments that are candidates for No onal Instruments. The SSL also provides a centralised administra on tool for the different characteris cs of these instruments (e.g., recommenda ons,
maximum weight, etc.) that can be further used in the Check Strategy and Reconcilia on processes.
The SSL is a special strategy nature. It has prac cally the same characteris cs as the Recommenda on List except that it cannot be used directly to define objec ves. SSLs can be used to define the underlying of No onal Instruments and provide
vital informa on to the la er such as a recommenda on, maximum weight, etc.
The recommenda ons of instruments from the SSL are sent to the No onal Instrument’s components. As a recommenda on reflects an analyst's apprecia on of an instrument, it is independent from the context the instrument is used in.
Front Office - PM allows users to create mul ple SSLs. Therefore, for a given No onal Instrument, it is necessary to specify the SSL where the actual instruments are to be found. It is not obligatory to have mul ple SSLs; the system can work with
just one SSL.
From a technical point of view, a ributes such as grid, Market Segment, or currency are not used with the SSL.
Risk strategy
The Risk strategy is a strategy nature used to set the thresholds for the risk measures. This strategy can be included in an Investment Profile.
The Risk strategy is only used for storage purposes; there is no Risk Analysis treatment in Front Office - PM. This strategy can be interfaced with Risk Management so ware.
The Risk strategy includes the following dedicated a ributes:
A ribute Descrip on
Compliance Each Risk strategy requires a frequency update on the risk assessment (e.g., daily,
Frequency monthly, etc.). The Compliance Frequency is defined as number of frequency
units. For example, 1 day, 2 months, 1 week, etc.
Compliance
Frequency
Unit
Last This field is updated with the last risk assessment date. It allows for the detec on
Compliance of when to assess the risk of a por olio.
Update
The following columns are defined as objec ves and tolerance margins:
A ribute Descrip on
Min Compliance It is the limit that the investor should exceed to ensure the target return.
Max Compliance It is the limit that the investor should not exceed to respect the risk level
defined.
Compliance It defines the objec ve of the Risk measure.

Objec ve
Security access
You can also restrict the security access of par cular users to only allow them to update certain aspects of the overall strategy structure. The Strategy Administra on func on in the Func on Security Profile manages this. Strategy Administra on
lets you restrict the en es that individual users can access and also their type of access.
The En ty a ribute determines which Strategy Elements can be changed and the Create, Update, and Delete flags define the user's permissions (see sec on Detailed concept).
In addi on, the Data Profile assigned to strategies and the related administra on rights (e.g., View, Update) is taken into account.
Detailed concept
The Administra on rights defined for a specific en ty override the administra on rights defined for the en ty ‘All’.
For example, take the following Strategy Administra on Security Profile:
A ribute Value

Func on Strategy Administra on
En ty All
Create_f 0
Update_f 0
Delete_f 0
In the above example, users cannot modify the strategy data (e.g., strategy link, strategy history, etc.)
Now take the following Strategy Administra on Profile:
A ribute Value
En ty All
Create_f 0
Update_f 0
Delete_f 0
and
A ribute Value
En ty Strategy History
Create_f 1
Update_f 1
Delete_f 1
In this example, users cannot modify the strategy data (e.g., Strategy Link, Strategy Element, etc.) but can create, delete, and update Strategy History records.
The other important thing to remember is how to interpret the strategy administra on rights in the Edit Strategy Objec ves screen since you are manipula ng Extended Strategy Elements and not Strategy Elements:
Create, Delete, and Modify flags in the Strategy History:

Create_f = 1 enables the Save New History bu on
Create_f =0 disables the Save New History bu on
The Delete and Modify flags have no effect here. They do, of course, s ll ensure security in the Strategy History screen.
Create, Delete, and Modify flags in the Strategy Element:
Create_f = 1 enables Create/Insert of a new instrument (i.e., New ac on)
Create_f = 0 prevents users from inser ng a new instrument into a Recommenda on List, Surveyed Securi es List, or Model Por olio
Delete_f = 1 enables the dele on of instruments (i.e., Delete ac on)
Delete_f = 0 prevents users from dele ng an instrument from a Recommenda on List, Surveyed Securi es List, or Model Por olio
Update_f = 1 allows users to update the different editable cells in the Edit Strategy Objec ves screen
Update_f = 0 prevents users from upda ng the different editable cells in the Edit Strategy Objec ves screen
Strategy administra on
The basic tasks of crea ng and upda ng strategies are explained in the WealthSuite Front Office - Por olio Management - User Guide.
Concepts of strategy administra on are explained in the following sec ons:
Customising the Edit Strategy Objec ves screen

Mapping between the logical structure and the physical structure
Strategy administra on tools
Strategy administra on func ons for external API (TSL, OData)
Customising the Edit Strategy Objec ves screen

The Edit Strategy Objec ves screen is generated from a format. This means that you can customise it.
The main advantages are:
You can define an administra on screen per strategy nature.

You can add columns that display informa on about the instruments that compose a Model Por olio.
To customise the Edit Strategy Objec ves screen, you must set two system parameters that define which formats are used by the func on. One format is responsible for displaying the top part of the screen and the other for displaying the
workspace below (with the different columns, etc.).
Crea ng new formats

To define which formats are used in this func on, you must set the STRAT_ADMIN_DOM_FORMAT and STRAT_ADMIN_PAR_FORMAT system parameters.
To do this:

1. Choose Administra on > Security > Parameter.
2. Select the STRAT_ADMIN_DOM_FORMAT parameter from the list.
3. Click Modify bu on.
4. Enter the value you want and check that the data type is name_t. Do the same for STRAT_ADMIN_PAR_FORMAT. You can perform this step last, if you want, once you have created your formats.
The first parameter, STRAT_ADMIN_DOM_FORMAT, defines the domain format which controls the selec on data on the panel at the top of the screen. This format must have the following a ributes:
Nature – domain
Func on – Administra on
En ty – search_link
To set these a ributes:
1. Choose Administra on > Configura on > Format.

2. Select Domain and Administra on from the Nature and Func on drop-down lists.
3. Click Create bu on to open the Nature Selec on screen.
4. Choose ‘Domain’ from the list.
5. Click OK bu on to display the Create Format screen.
6. Set the Func on and En ty fields.
The second parameter, STRAT_ADMIN_PAR_FORMAT, defines the parent format of the individual child formats used in the func on to display details for the different strategy natures. These formats must have the following a ributes:
A ribute Value
Nature Dynamic List
Func on Administra on
En ty ext_strategy_element
7. Proceed as described above for the domain format.

8. Select ‘Dynamic List’ from the Nature Selec on screen.
9. Click OK bu on to display the Create Format screen.
10. Set the Func on and En ty fields.
Child formats
For the individual child formats (one for each different Strategy Nature), you must set a value for the Break Value a ribute. The Break Value a ribute defines which strategy nature the child format represents. Note that it is not necessary to
specify a Break Criteria value.
The possible values for the Break Value field are as follows:
Value Strategy Nature
0 Combina on of Asset Alloca on and Model Por olio
1 Asset Alloca on
2 Model Por olio
3 Recommenda on List
24 Surveyed Securi es List
You must also enter the Parent Format described above in the Parent Format field.
Establishing hierarchical links

When you use dynamic lists, you must include at least two format elements with their SQL names and defini ons in each child format. The two elements are ‘id’ and ‘disp_parent_ext_strat_elem_id’. To set these parameters, open the
Create/Modify Format screen and click the Format Element bu on. In the Select Format Element screen, click Create bu on to display the Create Format Element screen (assuming you are not modifying an exis ng format element):
For ‘id’ format element, set the following in the Create Format Element screen:
A ribute Value
SQL Name id
Datatype id_t
Hierarchy a ribute parent
Script Defini on id
For disp_parent_ext_strat_elem_id, set the following:
A ribute Value
SQL Name disp_parent_ext_strat_elem_id
Datatype id_t
Hierarchy a ribute child

Script Defini on disp_parent_ext_strat_elem_id
The above syntax must be strictly respected and the rank of the ‘id’ format element must be the lower of the two.
To set the Script Defini on, click the Defini on bu on at the bo om of the screen and enter the appropriate defini on.
If you want to use this func onality for editable instrument cells, some addi onal informa on is required in the Create/Modify Format Element screen. These details are:
A ribute Value
A ribute instr_id
Edit yes
Datatype code_t, name_t or info_t (to edit the code, name, or denomina on)
Fixed Column yes
Note: When you specify instr_id in the A ribute field, the Datatype automa cally defaults to id_t, which overrides the code_t, name_t, or info_t. It is therefore important that you complete the Datatype field a er the A ribute field and not
before.
You can also create input controls using the Front Office - PM script language to validate some of the criteria in the objec ves before they are saved to the database. If you do this, you must create the input controls based on the Strategy Element
en ty and not the Extended Strategy Element en ty.
Mapping between the logical structure and the physical structure

You manipulate the Extended Strategy Element records in the Edit Strategy Objec ves tool. When you confirm the data, you save Strategy Elements to the database. As a result, Front Office - PM turns Extended Strategy Element (i.e., the logical
table) into Strategy Elements (i.e., the physical table). The data mapping between these en es is presented below.
Model Por olio

Total and sub-total records
Extended Strategy Element Strategy Element
Strategy_hist_id Strategy_history_id
Market_segment_id Market_segment_id
Strat_nat_e Model Por olio

Nature_e=15* (Model)
Rank_n Rank_n
Obj_weight_n Value_n
Obj_weight_margin_n Fluct_margin_n
* nature_e = 16 (Contrib Model) if it refers to a ‘constant weight' Model Por olio

Instruments
Market_segment_id Market_segment_id
Instr_id Instr_id
Strat_nat_e Model Por olio

Nature_e = 12* (Model Item)
Priority_n Priority_n
Rank_n Rank_n
Obj_weight_n Value_n
Obj_weight_margin_n4 Fluct_margin_n
* nature_e = 17 (Contrib Model Item) if it refers to a ‘constant weight' Model Por olio
Recommenda on List
Market_segment_id NULL
Instr_id Instr_id

Strat_nat_e Recomm. List
Nature_e = Recommenda on (13)
Rank_n Rank_n
Priority_n Priority_n
Recom_nat_e Recom_nat_e
Max_weight_contrib_n Value_n
Asset Alloca on
Extended Strategy Elements (i.e., the logical table) can generate one or many Strategy Elements (i.e., the physical table). To do this, the func on checks the nature (nature_e = 1, Asset Alloca on) of the Asset Alloca on Extended Strategy
Elements. The following trigger mechanism determines the number of Strategy Elements to generate.
If any of the following a ributes is not Null, a Strategy Element is generated and stored:
max_weight_n
min_weight_n
min_ra ng_rank_e
obj_beta_n, obj_beta_margin_n
obj_beta_cont_n
obj_beta_cont_margin_n
obj_curr_yield_n
obj_curr_yield_marg_n
obj_curr_yield_cont_n
obj_curr_yield_cont_marg_n
obj_dura_n
obj_dura_marg_n
obj_dura_cont_n
obj_dura_cont_marg_n
obj_track_err_n
obj_track_err_marg_n
obj_weight_n (!!)
obj_weight_marg_n
bench_object_id
Strategy_hist_id = Strategy_history_id
Market_segment_id = Market_segement_id
Depending on what triggers the Strategy Element crea on
Nature_e = maximum weight (3)
= minimum weight (2)
= minimum ra ng rank (10)
= beta (6)
= beta contribu on (7)
= current return (8)
= current return contrib (9)
= dura on (4)
= dura on contribu on (5)
= tracking error (11)
= weight (1)
Depending on what triggers a record = Fluct_margin_n
Depending on what triggers a record = Value_n
bench_object_id = bench_object_id
bench_en ty_dict_id = bench_en ty_dict_id
In the case of Asset Alloca on, rank_n is not stored. In the Extended Strategy Element, it is based dynamically on the classif. compo rank.
Strategy administra on tools

The number of Model Por olios and Recommenda on Lists entered directly in the system may rise sharply. Consequently, Front Office - PM includes administra on tools for Super Users to help them maintain these objects on a large scale. These
tools take the form of the following stored procedures:
upd_instr_strat_elem: switching an instrument with another (see sec on Switching instruments).

sel_exd_strategy_by_instr: finds all strategies and strategy histories if a specific instrument is defined (see sec on Finding instruments).
Switching instruments

The stored procedure upd_instr_strat_elem helps replace one instrument with another in a Model Por olio or Recommenda on List.
Arguments
A ribute Datatype Value Meaning
@dim_strat_sqlname_c sysname_t "strategy", You can specify a specific strategy, a

"list" or null list of strategy, or all strategies.
@strat_object_code code_t "code" or null Code of the strategy or of the strategy

list.
@from_date_d date me_t "MM/DD/YYYY" Date at which you want to replace the
or null instrument; if null, the instrument is
replaced in all historical periods.
@old_instr_code code_t "code" cannot Code of the instrument that you want
be null to delete.
It is mandatory.
@new_instr_code code_t "code" cannot Code of the new instrument.

be null
It is mandatory.
@srv_name sysname_t "server name" SQL server.
It is op onal.
Example: exec upd_instr_strat_elem null, null, null , "213768", "224181"

Output
The stored procedure upd_instr_strat_elem executes the input controls assigned to the Strategy Element en ty and checks that there are no duplicate keys. If there are warnings or error messages from the system or the database, the instrument
is not replaced in the specific strategy or strategy history that caused the message. There is no complete rollback. The server.log and log files report these errors in detail.
Below is an example of a server log:
2000/07/07 10:59:26:AAASERVVERSION :aaa : 99(sub) : Start Strategy Switch Instrument (Novartis -> Roche)
2000/07/07 10:59:27:AAASERVVERSION :aaa : 99(sub) : Function Switch instrument : no update of instrument Novartis possible (strategy Swiss
Stocks, strategy history begin date 09/02/2000, strategy element rank 1)
2000/07/07 10:59:27:AAASERVVERSION :aaa : 99(sub) : Function Switch instrument : no update of instrument Novartis possible (strategy Swiss
Stocks, strategy history begin date 10/05/2000, strategy element rank 0)
2000/07/07 10:59:27:AAASERVVERSION :aaa : 99(sub) : Function Switch instrument : no update of instrument Novartis possible (strategy Stocks,
strategy history begin date 01/01/2000, strategy element rank 2)
2000/07/07 10:59:27:AAASERVVERSION :aaa : 99(sub) : Function Switch instrument : no update of instrument Novartis possible (strategy Stocks,
strategy history begin date 01/02/2000, strategy element rank 2)
2000/07/07 10:59:27:AAASERVVERSION :aaa : 99(sub) : Exit Strategy Switch Instrument (Novartis -> Roche) : 0 of 4 strategy elements updated
with new instrument.
Finding instruments
The stored procedure sel_exd_strategy_by_instr finds all strategies and strategy histories for a specific instrument.
Arguments
A ribute Datatype Value Meaning
@dim_strat_sqlname_c sysname_t "strategy", You can specify a specific strategy, a

"list", or null list of strategies*, or all strategies.
@strat_object_code code_t "code" or null Code of the strategy or of the strategy

list.
@from_d date me_t "MM/DD/YYYY" Date at which you want to find the
or null instrument; if null, the instrument is
searched in all historical periods.
@oinstr_code code_t "code", cannot Code of the instrument that you are
be null looking for.
Example: sel_exd_strategy_instr_by_cd null, null, null, "213768"

Output
Here is an example of the output when you run the procedure:
Strategy Code Strategy History Begin Date Rank Instrument Code
Swiss Stocks Jan 1 1998 12:00AM 1 213768
Stocks Jan 1 1999 12:00AM NULL 213768
Stocks Jun 2 1997 12:00AM NULL 213768
Strategy administra on func ons for external API (TSL, OData)

Dedicated func ons are available for external API but not in the GUI.
Edit Strategy Objec ve func on

Similar to the GUI func on, the Edit Strategy Objec ves func on mainly aims to build a market structure of an alloca on strategy, and to provide the results in the Extended Strategy Element structure.
During target weights edi on of an alloca on by a front-end, some market segments are hidden and need to be aligned. The Edit Strategy Objec ves func on aligns these market segments to ensure the consistency of the target weights edi on.
Domain
The Edit Strategy Objec ves func on uses the following fields:
Field Descrip on
Strategy Indicates which strategy is passed to the func on.

Dimension
Ini al Date Enter the date. It is used to select the valid strategy history at this date. Defaults to
current date.
Comp 0 - Online: To provide a market structure in extended strategy element

Date en ty.
27 - Sum and Save Strategy: Only for Alloca on strategy; sums the
target weight at the hierarchy levels and creates missing hierarchy
levels.
Select Grid Market Segment

The Select Grid Market Segment func on aims to build a market structure of a grid and to provide the results in the Extended Strategy Element structure.
Domain
The Select Grid Market Segment func on uses the following fields.
Field Descrip on
Grid Indicates which strategy is passed to the func on.
Strategy Links
Strategy Links associate strategies with por olios. In other words, Strategy Links connect the strategies you define to the por olios you manage.
As the strategies linked to a por olio can vary over me, Front Office - PM lets you archive links in a similar way to strategies. This means you can take changes in a client's risk profile into account, for example.
Concepts of Strategy Links are explained in the following sec ons:
Link natures
Physical and logical links
Priority and ranking
Link natures
A strategy can be linked to a Por olio or Por olio List for two purposes that are not mutually exclusive:
Por olio Management: the strategy is used in the Produc vity module of Front Office - PM. This means that you can compare one or more Por olios with a strategy, and Front Office - PM will propose
appropriate buy and/or sell opera ons.
Benchmark: the strategy is used in the Performance Analysis module of Front Office - PM. This means that you can compare the performance of one or more Por olios with that of a Benchmark Strategy.
The Link Nature a ribute dis nguishes between the purposes men oned above. The Link Natures are:
Strategy: creates a link for por olio management purposes

Benchmark: creates a link for performance benchmarking
Strat&Bench: creates a link for management and benchmarking purposes
Strategy (check only): creates a link for management purposes that is useful for, if limited to, checking (i.e., comparing por olios and strategies). For more details, refer to the sec on about the Strategy
Reconcilia on func on in the WealthSuite Front Office - Por olio Management - Orders and Produc vity User Guide. You can use the GET_STRATEGY script keyword to retrieve a strategy linked to a por olio.
For more details, refer to the WealthSuite Front Office - Por olio Management - Script Language Reference Guide.
If you set up links between por olios and a strategy hierarchy composed of Asset Alloca ons, Model Por olios, and Recommenda on Lists, check that you do not have two sub-strategies linked to the Parent Market Segment. In other words, an
asset class can have only one child strategy (i.e., Asset Alloca on, Model Por olio, or Recommenda on List).
Note that links must not be created between Surveyed Securi es Lists (SSLs) and por olios or lists of por olios. This strategy nature is only used as the underlying of No onal Instruments.
Physical and logical links

You can define links between strategies and por olios or between strategies and lists of por olios. This leads to the following types of links:
Physical links: links created directly between por olios and strategies.
Logical links: links between por olios and strategies created from physical links between por olio lists and strategies.
Strategies that are directly linked to a par cular por olio or are linked to a list containing the por olio are considered as associated with that por olio.
For example, if a Strategy Link is created between a strategy and a list of por olios, selec ng Physical Links returns that link but does not show a link between the strategy and the individual por olios that make up the list. Clear the Physical Links
check box to display Logical Links. Logical links also show all non-physical links between the strategy and the individual por olios in the list (see P . 1, P . 2, and P . 3 in the image below):
Example
This example shows the different links returned with All Links and Direct Links when Physical Links is set to Yes or No.
The por olio ABC belongs to the List 1 and List 2 por olio lists. List 1 has a link to Strat S1, List 2 has a link to Strat S2, and the por olio ABC has a link to Strat S3.
When the links of por olio ABC are requested, the links marked with an X are returned, depending on the parameters indicated in the column headers:

Direct Links. Direct Links.

All Links
Physical Links = No Physical Links = Yes
P ABC <-> Strat S3 X X X
List 2 <-> Strat S2 X
P ABC <-> Strat S2 X
When the links of List 2 are requested, the links marked with an X are returned, depending on the parameters indicated in the column headers:
Direct Links. Direct Links.

All Links
Physical Links = No Physical Links = Yes
List 2 <-> Strat S2 X X
P ABC <-> Strat S3 X X X
Priority and ranking

When you create a link, you can specify its priority in the Priority field. This is very useful when you select strategies in the different produc vity func ons.
The Expand strategy parameter displays the contents of the strategies with the Investment Profile or Benchmark nature. Each historical composi on inherits the valid links of the parent strategy, which is also displayed in the output results.
The indirect links (i.e., links associated with the por olio through the list) are returned with the historical list composi on.
For the func ons that are run on one date (principally the Orders and Produc vity func ons): The indirect links are returned with the list composi on found at the domain.calc_strat_d (begin_d for the Strategy
Link func on – with the Current Link op on). As for all the historical list contexts, if there is a list_compo valid at this date, it is used first. Otherwise, if the historical_list flag is set to Yes, the list is evaluated at
the calc_strat_d date. If it is set to No, the present list is used.
For func ons that are run on a period (principally PAA func ons, and Strategy Link on a period), the indirect links are retrieved with the historical list composi on retrieved at the beginning and end of the
period, plus:
at each date of modifica on if the list_compo are stored
at each end of month when the historical_list flag is set to Yes if the list_compo are not stored
Warning: This last process can be very heavy for long periods or when “all history” is asked; during the period where a list (of por olios) is linked to a strategy, an evalua on of the list will be done each month. Therefore we strongly recommend
the storage of the list composi on. But, the composi on of the list given in the domain (in port_object_id) is always the current list (it cannot be changed). Only Composite Manager works with historical lists.
The single period flag (not available in the GUI and can only be set with default values) splits the period of the different links into sub-periods that are available for all the links. For example, for por olios with 2 links to two overlapping periods,
31/12/1996 – 31/05/2000 and 31/12/1999 – today, the period will be divided into three: 31/12/96 – 31/12/99 for the first link, 31/12/1999 – 31/05/2000 for both links, and 31/05/2000 – today for the second link. This op on can only be used
with current links or links over a period. The output parameter rank_n defines the selec on order of the links.
Example
The following links (direct or indirect) are set for the por olio ABC:
Bench Link_nat Priority Begin End
Link1 Object1 Strategy 1 31/12/98 31/07/00
Link2 Object2 Strategy 2 31/12/98 Today
Link3 Object3 Strategy 1 31/07/00 31/10/00
Link4 Object4 Bench 1 31/07/00 Today
Link6 Object6 Bench 3 31/12/98 31/12/00
With the single period flag set to 1, the periods defined by the links are split into 5 sub-periods in which the links are classified as in the following table:
31/12/1998 31/07/2000 31/10/2000 31/12/2000 31/12/01

31/07/2000 31/10/2000 31/12/2000 31/12/2001 Today
1 Link1 Link3 Link2 Link2 Link2
2 Link2 Link2 Link4 Link4 Link4

3 Link6 Link4 Link6 Link5
4 Link6 Link7
Note: During the period under analysis, a link can modify its ranking (e.g., link2 is first number 2, then becomes number 1).
A en on: Cau on is necessary during the implementa on to maintain consistent links over the me period.
This kind of classifica on is used for por olio storage (link 1 is selected) and performance a ribu on and analysis (link 1 is selected for Return Analysis, and links 1 to 3 for Performance A ribu on).
No onal Instruments
Front Office - PM includes an instrument nature called No onal. A No onal Instrument is an abstract or virtual instrument.
You can define a No onal Instrument by:
Explicitly enumera ng the instruments that belong to it. The contents of the No onal Instrument is fixed:
‘IBM, Compaq or Dell shares'

Defining a set of criteria that must be later completed. Any instrument belonging to the scope of the No onal Instrument and observing the criteria can belong to the No onal Instrument at a given me. The
contents of such a generic instrument are automa cally adapted to either changes in the actual instrument characteris cs or updates to these characteris cs.
For a 'Bond denominated in EUR with redemp on between 3 and 5 years and a minimum ra ng of AA':
A bond that has 3 years and 1 day to maturity today belongs to the No onal Instrument but the day a er tomorrow it shall no longer belong to the same No onal Instrument. The evolu on of its
characteris cs determines, at a given moment, if the actual instrument belongs to the No onal Instrument or not.
A bond is rated AA today and belongs to the No onal Instrument. If its ra ng is downgraded (through an update in the Front Office - PM reference system), the bond is no longer part of the No onal
Instrument.
Among the other advantages for Order and Produc vity func ons are:
When used to define objec ves (i.e., Strategies - Model Por olios) in the Order and Produc vity func ons, No onal Instruments act like actual instruments.
For example:
Model Por olio on Stocks – Europe
Delhaize 15%
Swiss Banks (no onal) 20%
Air Liquide 25%
etc.
Model Por olio in Fixed Income – Europe
Belgian OLO, 3 years to redemp on (no onal) 15%
French bonds minimum A (S&P), 4 years to redemp on 25%
etc.
No onal Instruments combine the stability of the objec ves (characteris cs) with the changing character of the instrument's context.
As a conclusion to the reconcilia on process (por olio alignment), No onal Instruments leave a certain degree of freedom to Por olio Managers while s ll observing the bank's rules and guidelines.
The reconcilia on process can be extended to bonds as well as other instrument natures. It gains from the no on of ‘equivalent investment' and can be processed via No onal Instruments.
Global reconcilia on objec ves are set for No onal Instruments while results and orders are produced for actual instruments.
Cri cal mass problems can be avoided by using No onal Instruments. Rebalancing large numbers of por olios does not necessarily mean placing the same order in them all, hence there is less risk of sending a
large number of orders for a single instrument to the market at a given me.
The use of No onal Instruments allows a smoother modifica on of por olios under a centralised asset management system.
No onal Instruments are available in:
Order func ons (such as Strategy Reconcilia on)
For example, you can rebalance and generate orders for actual instruments using Model Por olios that contain No onal Instruments.
Compliance check func ons (such as Check Strategy, Pre-Trade Compliance Check, etc.)
A Surveyed Securi es List (SSL) is used as a central repository for the generic instruments and their characteris cs. This allows immediate online access to the appropriate (surveyed) securi es for the Rela onship Manager.
A No onal Instrument is an instrument and is also an iden fier of a class of instruments. At any moment in me, all instruments in the class are considered as equivalent investment opportuni es. Any subset of actual instruments belonging to
the No onal Instrument's underlying pool can be subs tuted for it. No onal Instruments are defined by either a set of characteris cs or a full enumera on of its members.
The main goal of crea ng No onal Instruments as a new instrument nature is to be able to set them as objec ves in Model Por olios and further use them for Check Strategy and Strategy Reconcilia on func ons.
No onal Instruments are much like Recommenda on Lists. However, use of No onal Instruments inside Recommenda on Lists is not allowed.
The following image shows No onal Instruments being used to set objec ves in Model Por olios in the Edit Strategy Objec ves screen:

The No onal Instruments appear in the model just like normal instruments.
The No onal Instruments men oned above are further detailed in the following sec ons:
Instruments of No onal Instruments

No onal Instruments and Market Segments
Use of lists for No onal Instruments
No onal Instruments versus actual instruments
Use of No onal Instruments to define objec ves
Checking and reconciling No onal Instruments
Impact of Trading Constraints on No onal Instrument split
No onal Instruments and group rebalancing
Instruments of No onal Instruments

The instruments that belong to the No onal Instrument at a given moment are actual instruments that:
Belong to the list (pool) of instruments a ached to the No onal Instrument.

The defini on of the list (pool) can be:
Enumerated (nature_e= 1)
Constrained (nature_e= 2)
Result of a search (nature_e= 5)
Belong to the Surveyed Securi es List (SSL). This is mandatory in order to provide them with characteris cs such as recommenda on or maximum weight. When the composi on of a No onal Instrument is
established, certain characteris cs of the instruments that fit the defini on are directly retrieved from the a ached SSL (recommenda on, margins, etc.). An instrument that does not belong to the SSL (see
matching context below) receives a default recommenda on that can be configured as Sell, Reduce, Hold, or Neutral.
Respect the criteria defined for the Market Segment to which the Model Por olio of Recommenda on Lists is a ached.
The set of instruments that fits the No onal Instrument depends on:
The defini on of the pool (list).

The context it is used in.
At a given moment in me, the same No onal Instrument used in two different contexts (Market Segments) can produce a different set of actual
instruments.
Time
The same No onal Instrument can involve, in the same context, different sets of actual instruments at different moments of me (e.g., No onal
Instruments defined on fixed income with criteria on maturity).
No onal Instruments and Market Segments

A No onal Instrument, whatever the defini on of its underlying list might be, belongs to any Market Segment of any alloca on grid. When a No onal Instrument is added as an objec ve, there is no need to perform a check at edit me.
When the No onal Instrument is actually used for comparison or reconcilia on purposes, only the instruments within its scope that belong to the Market Segment affected by the reconcilia on are taken into account.
The same No onal Instrument used for two different Market Segment objec ves and/or two different mes can include different actual instruments:
Use of lists for No onal Instruments

The set of instruments behind a No onal Instrument is defined as a Front Office - PM list. All lists defined or used in the No onal Instrument are interchangeable with other lists on instruments defined in Front Office - PM. This feature can make it
easy to create No onal Instruments based on the full defini on of a Market Segment that includes all possible instruments in the segment.
Available list types are:
Constrained: A defini on (script) on the instrument table

Search: A search on the instrument table
Enumerated: An exhaus ve enumera on of a set of instruments
The defini on criteria include all criteria directly available for the search lists (direct criteria on the instrument table) as well as the possibility to use script defini ons to their full extent.
The lists are defined from a limited subset of actual instrument natures, excluding the No onal Instrument itself as a nature: a No onal Instrument cannot contain another No onal Instrument.
No onal Instruments versus actual instruments

Actual instruments from the posi ons that respect a set of criteria and that belong to the scope of the No onal Instrument defined as an objec ve contribute to that objec ve.
If the objec ves are not respected, Front Office - PM proposes orders to correct the differences (ini ally based on the No onal Instruments). Before Front Office - PM actually displays the orders, it automa cally converts them into orders based
on actual instruments chosen from a list of candidates provided by the No onal Instrument.
The instruments that belong to the No onal Instrument list vary over me:

As Model Por olios can contain a mixture of actual and No onal Instruments, any instrument that explicitly belongs to the model (i.e., that is an actual instrument in the model) is no longer considered as part of the scope of the No onal
Instrument.
The following sec ons describe the processes associated with No onal Instruments:
Pricing
Matching
Spli ng
Pricing
As far as No onal Instruments are concerned, pricing informa on can be necessary, depending on the actual use you are making of them:
If used exclusively in standard Model Por olios without dynamic weights, the No onal Instruments do not need their prices. Valua on is performed through valua ng the actual instruments (belonging to the
no onal) that are held in a given context at a given moment.
If dynamic weights are used, this requires a valua on of all instruments in the Model Por olio.
Therefore, you must take the utmost care to indicate either some prices for these instruments or a method allowing such prices to be computed by Front Office - PM.
Matching
Matching is the process that matches actual instruments (from actual por olios) to a given No onal Instrument (from a Model Por olio) in a given context.
In certain circumstances, matching an actual instrument against one or more No onal Instruments may prove unsuccessful. An actual instrument cannot be matched against more than one actual or No onal Instrument in a given context.
In Order and Produc vity func ons (e.g., Check Strategy, Rebalancing, etc.), Front Office-PM starts with an actual por olio posi on and checks if the actual instrument is found in one of the No onal Instruments set as an objec ve in the Model
Por olio:
Finally, the weight of all actual instruments found in the No onal Instruments' scope is computed and compared to the objec ve set for the No onal Instrument in the model.
This comparison reveals the No onal Instrument as under/over weighted and a transac on is proposed. Once the transac on is set for the No onal Instrument, further automated processing splits it into actual instruments (see sec on Spli ng).
Spli ng
Spli ng is the process that breaks down the composi on of a No onal Instrument in a given context:
Spli ng a given No onal Instrument can provide a set of many actual instruments. The set can also be empty.

The spli ng process first analyses all instruments in the set that belong to the No onal Instrument (in a given context and at the specified moment in me). All instruments that appear explicitly (as actual instruments) in the global Model
Por olio are eliminated.
The resul ng set of instruments is in fact a Recommenda on List (set of instruments, recommenda ons, and margins) and is processed like any other current Recommenda on List.
The process of spli ng No onal Instruments iden fies the instruments that are common to:
No onal Instrument intrinsic pool of instruments

Surveyed Securi es List (SSL)
Market Segment
It adapts this set according to the Model Por olio objec ves, the actual por olio posi ons, and the nature of the order to be split (Buy or Sell).
Spli ng is performed automa cally. There are no No onal Instruments displayed in the proposed order screen. The set of proposals is pre-computed and the No onal Instruments are replaced with actual instruments.
This means iden fying the result of the split (composi on of the set of instruments) and processing the resul ng virtual Recommenda on List. The Recommenda on List is processed according to the current rules (e.g., maximum weights,
priori es, etc.). The results are enhanced and the maximum weights set in the SSL ensure that no single instrument is allowed to receive the en re difference (to the objec ve).
Several processes started in Orders and Produc vity func ons must classify the No onal Instruments themselves in some lists. A common example is the use of security constraints and the deriva on process.
To perform the classifica on, users must define appropriate characteris cs in the record of the No onal Instrument itself as the No onal Instrument cannot be split into its components. Front Office - PM interprets the list with No onal
Instruments in the same way as for any other Front Office - PM instruments (i.e., by using the data it finds in the reference records of the instrument).
Example: A security constraint on the BANKING economic sector. A No onal Instrument is said to belong to the BANKING sector if this field is completed in the instrument record (using the appropriate codifica on, of course).
Front Office - PM does not perform any checks on the coherence of the data entered at the No onal Instrument level and the data computed during the spli ng/matching process described above.
Use of No onal Instruments to define objec ves

No onal Instruments are like any other nature of actual instruments when they are used to set objec ves. However, the scope is limited to Model Por olios. They must not be used in Recommenda on Lists to avoid possible in-determina on (the
No onal Instrument is processed as a Recommenda on List when you use the Reconcile Strategy and Check Strategy func ons).
Checking and reconciling No onal Instruments

Checking takes into account No onal Instruments in Model Por olios and, depending on the matching process described above, displays the differences between the composi on of the actual por olio and its objec ves.
Reconcilia on (rebalancing) proposes orders that correct these differences according to currently available mechanisms and is enhanced by the matching process described above (automa c or manual).
Over/under-weigh ngs are processed in line with the instruments found in the Surveyed Securi es List (SSL).
The following image of the Strategy Reconcilia on screen shows the reconcilia on of a por olio that includes No onal Instruments in its objec ves:
Note: Instruments found in the actual por olio are grouped under the No onal Instrument objec ve. Also, the actual instrument orders are only proposed a er the No onal Instrument is split.
DEF_NOTIONAL_RECOM system parameter

When actual and Model Por olios (containing No onal Instruments) are reconciled, there might be some instruments held in the actual por olios that are not members of a Surveyed Securi es List (SSL). Front Office - PM can be set to either sell
or keep such instruments in the actual holdings.
The DEF_NOTIONAL_RECOM system parameter specifies if an instrument that is not in a Recommenda on List (or the SSL for No onal Instrument processing) is sold or kept. This parameter defines whether any holding that is not in the SSL is:
kept (recommenda on = keep/hold)

subject to a definite sell (recommenda on = sell)
sold if over-weighted compared to the objec ves (recommenda on = reduce).
This affects the rebalancing process and the No onal Instrument split.
Impact of Trading Constraints on No onal Instrument split

If Trading Constraints are linked to a por olio being rebalanced, they change the way in which an order in a No onal Instrument is split. The list of proposed actual orders must not contain any that violates constraint. Amounts that cannot be
traded due to constraints are re-allocated to other instruments belonging to the pool of instruments derived from the no onal.
Trading Constraints are taken into account in splits in the same way as for Recommenda on Lists.
Amounts in instruments rejected by the Trading Constraints are reallocated to the next instruments in the set resul ng from a split of the No onal Instrument. Under certain circumstances, the total amount proposed for the No onal Instrument
might not be completely split into individual orders.
The rejected orders can be viewed using the same formats as those used to display orders rejected by Trading Constraints.
No onal Instruments and group rebalancing

Rebalancing a group of por olios can be performed as a check on the consolidated posi ons of the por olios in the group. This leads to a series of order proposals (first for the group as a whole and then for the child por olio members of the
group).
No onal Instruments keep this mechanism intact:
Consolidate the posi ons of the por olios in the group.

Check the strategies linked (to the parent).
Generate orders correc ng the differences noted between the actual posi ons and the objec ves. These orders can be for actual or No onal Instruments. Take into account Trading Constraints linked to the
parent.
Split orders from No onal Instruments accordingly.
Allocate the orders for actual instruments to the child por olios. At this stage, Trading Constraints apply at child por olio level and affect the alloca on.
Constraints
This sec on describes the business view of constraints. You will learn about:
Constraint Sets (unstructured)

Trading Constraints
Constraint Wizard
Modelling Constraints
Constraint Sets
Constraints are unstructured targets that can be set by fund managers or is dependent on legisla on and clients. Examples are “No chemical stocks” or “No uncovered calls” or “The sum of all the bonds whose issuer represents more than 5% of
the por olio must not be greater than 40%”.
Technically, the Constraint Set is a strategy of this nature. The strategy can be linked to the por olios, to which they should apply, by the "Strategy Link" func onality.
Each Constraint Set contains constraint elements in history version, so that changes of the strategy can be considered by the business func ons (e.g., when execu ng the Check Strategy func on on a date in the past).
The condi ons of the constraint elements are defined by using the Front Office – PM script language. To define a constraint element, use the CHECK_SUM script language keyword to construct and validate the targets. You can use other script
language keywords in conjunc on with CHECK_SUM in the constraint defini on. For more details, refer to the WealthSuite Front Office - Por olio Management - Script Language Reference Guide.
Trading Constraints
In this sec on, you will learn about Trading Constraints that are computed ex-post. They are based on trading characteris cs, for example, “Do not buy IBM”.
Trading Constraints are ac ve constraints that act on individual orders (trades). The constraints are applied before the orders are displayed. Consequently, the automa c order genera on does not generate or propose non-compliant orders.
These constraints are based on the individual characteris cs of the orders.
Trading Constraints can be a ached to a single por olio or to a list of por olios. More than one Trading Constraint can be defined for the same por olio or list of por olios.
Each Trading Constraint contains a list of constraint elements. A Trading Constraint element is a single constraint (single script defini on) that:
acts as a restric on on proposed deals.

is based on certain directly iden fied instruments.
prohibits the buying and selling of a certain stock.
is based on certain instruments that are iden fied by their characteris cs.
prohibits the purchase of deep discount securi es.
prohibits the purchase of roll-up (automa c reinvestment) funds / buy-only funds with distribu on status.
is based on the characteris cs of held posi ons.
can apply minimum holding periods (e.g., hold each segregated equity for at least one year).
Trading Constraints are checked against all orders that are generated to realign the por olio hierarchy with its objec ves. The default constraints are always checked while Trading Constraints (user-defined constraints) are checked in accordance
with the por olios to which they are linked (see the link descrip on below):
Trading Constraints linked to the parent por olio are checked against the grouped order proposals (before alloca on).
Trading Constraints linked to child por olios are checked against the order proposals a er the applica on of the alloca on rules (default and user-defined).
As a general rule, Front Office - PM only proposes orders that do not contradict any of the applicable constraints. If the order fails to pass even a single constraint, it is discarded or gets a Case generated that must be eventually clarified regarding
its cri calness se ngs. For more informa on, see sec on Case Management Component and the WealthSuite Front Office - Por olio Management - Orders and Produc vity User Guide.
The constraints are processed before any orders are displayed in the final results. However, such constraints could distort pure strategy rebalancing and prevent the por olio (or por olio hierarchy) from replica ng the a ached models perfectly.
The following sec ons provide addi onal informa on about:
Script defini on
Default constraints
Script defini on
Trading Constraints have underlying script defini ons that use the extended opera on structure. You can use IF statements in the script language.
As a rule, Trading Constraint processing is similar to the processing of other constraints and is independent of the original func on call.
The script defini on is checked for each of the opera ons and, as a result, a compliance flag is set (complies/does not comply with the defini on). Front Office - PM con nues to process only the compliant orders.
Trading Constraints are generally defined for individual orders. This means that these constraints do not rely on posi ons already held in a por olio. There are two excep ons to this:
Constraints on acquisi on costs of already held posi ons. The goal of these constraints is to determine if you are selling at a loss or not. Por olio managers prefer to see the amount of gain or loss generated by
a sell order.
Constraints on the me a posi on is held. The goal is to avoid selling posi ons held less than a certain period (e.g. a month).
The above are especially useful in the context of specific tax-induced constraints. However, these constraints must be able to access data that is not currently found in the extended opera on table (the en ty chosen as the basis for applying
constraints). New data has been added to the extended opera ons table to enable the above-men oned features. This data makes it possible to check the profit and loss from a Sell opera on. The acquisi on costs of the posi ons held in the
por olio are computed if a sell order is set for a posi on instrument. Note the following points:
The financial server (Strategy Reconcilia on) automa cally performs the processing for the Orders and Produc vity func ons.
This processing is not performed for Buy orders.
The acquisi on costs computed are gross and net, and only in the por olio currency.
The resul ng values are inserted in the extended opera on table (logical a ributes). The informa on is not physically stored.
Por olio fusion rules are applied in the calcula on of the acquisi on costs. You must dis nguish the ORDER_ALLOCATION_RULE rule (split, etc., specifying where to buy or sell a posi on) from the por olio fusion rule (specifying which posi ons
are merged).
Default constraints
When Front Office - PM proposes orders, it always checks the validity of the following general constraints:
Cash balance check: no order proposal can lead to a por olio being over-invested (nega ve cumula ve cash balance is not allowed).
Short sell: no order proposals can be made for a quan ty larger than the quan ty held.
By default, Front Office - PM checks these two constraints against the grouped orders (before alloca on, for the en re hierarchy) and all the resul ng orders. It does this in the actual des na on por olios a er the alloca on rules have been
applied.
Constraint Wizard
Strategies with the Constraint Set nature and Trading Constraints are based on a script defini on. End users who do not use the script language cannot create Constraint Sets or Trading Constraints by themselves.
The Constraint Wizard is a feature that allows end users to define Constraint Sets and Trading Constraints directly in Front Office - PM without relying on skilled script language users. The main func on of the Constraint Wizard is to provide users
with a set of explicit pre-defined Constraint templates. In prac ce, users select a template and supply the required informa on (i.e., value, date, etc.). When they confirm their input, Front Office - PM automa cally generates the corresponding
script defini on. Users can modify the constraint parameters later. Front Office - PM automa cally overrides the previous defini on.
The Constraint Wizard cannot read exis ng constraints that are not based on a template.
You cannot define constraints with the Wizard that you were not able to do previously with script. The Wizard is simply an aid for wri ng scripts. Users are in fact wri ng script without being aware of it.
Front Office - PM is not supplied with templates. Customer sites must create their own templates on the basis of their own parameters (i.e., interface, etc.).
Examples
The specified set of instruments must not represent more than X% of the por olio market value.
Do not buy specific instruments.
These examples are used throughout this sec on for the purposes of illustra on.
A Constraint template is defined in the data model with the following a ributes:

A ribute Descrip on
Code This code is the Constraint template en ty business key.
Name The short name of the occurrence.
Denom. The long name of the occurrence. Try to provide an explicit descrip on of your
template. This informa on appears on the default selec on lists and is useful
later for iden fica on and descrip ve reasons.
Ac ve Describes the state of the Constraint template. A Constraint template must be

ac ve to appear on the default selec on lists. If a Constraint template is
inac ve, it is not displayed in the default selec on lists.
Parameter Specifies if the constraint holds specific parameters or not. If it is set to No, you
do not have access to the template elements.
Denomina on Logical a ribute of the en ty that corresponds to the long name of the
occurrence in a par cular language.
Template Logical a ribute of the en ty that corresponds to the descrip on of the

Element constraint parameters.
Script Generic script defini on of the Constraint template.

Defini on
Constraint template and Constraint Wizard concepts

The following sec ons describe the concept of the Constraint templates and the Constraint Wizard:
Iden fying new Constraint templates (i.e., constraint template en ty).

Iden fying the necessary parameters (i.e., describing the different open parameters that the users must enter such as template elements).
Crea ng generic Constraint template script defini ons, which refers to the previously described parameters (i.e., constraint template script defini on).
Subsequently, users can select templates and specify the correct parameters to define their constraints. Sec ons Using the Constraint Wizard and Constraint template view describes how the correct script
defini on are automa cally generated in line with the user's needs when they save their template.
Iden fying new Constraint templates

Constraint Wizard with templates is a very flexible tool. To create templates, you have to imagine the kinds of constraints your Rela onship/Por olio Managers would like to define in Front Office - PM.
Once you have defined a generic constraint, try to enter an occurrence in Front Office - PM in the usual way. This should tell you if your constraint fits or not and will help you in the following steps to create your template.
Example of an occurrence of the generic Holding Constraint: the specified set of instruments cannot represent more than x% of the por olio market value. Stocks in the banking sector can represent more than
5% of the por olio market value:
CHECK_SUM(pos_val.ref_mkt_val_m/por olio_id.mkt_val_m, LT, 0.05, , instr_id.nature_e=1 AND instr_id.SECTOR_ATTRIB["FT"].sector_id.code = "Banking")

Example of an occurrence of the generic Trading Constraint: do not buy specific instruments:
IF(nature_e= 1 AND instr_id.code = “alpha”, 0, 1)

You have to clearly define the parameters of your constraint. These parameters are the data that users must enter to generate an occurrence of the template.
Iden fying the necessary parameters

You must iden fy the necessary parameters. Front Office - PM dis nguishes between the following kinds of parameters:
Parameter Descrip on
Numerical value Corresponds to the Value nature.
Date Corresponds to the Date nature.
Logical operators such as "less than" Corresponds to the Operator nature.

(<)
Set of instruments such as "all fixed Corresponds to the Instrument Set nature. In fact, it
incomes" refers to the instrument lists defined in Front Office -
PM.
Query based up data defined in the Corresponds to the A ribute nature.

system such as "instrument code
alpha"
Examples
The specified set of instruments cannot represent more than x% of the por olio market value.
Using the following example shown in sec on Iden fying new Constraint templates:
CHECK_SUM(pos_val.ref_mkt_val_m/por olio_id.mkt_val_m, LT, 0.05, , instr_id.nature_e=1 AND instr_id.SECTOR_ATTRIB["FT"].sector_id.code = "Banking")
The “specified set of instrument” expression is an Instrument Set parameter, which corresponds to the “instr_id.nature_e=1 AND instr_id.SECTOR_ATTRIB["FT"].sector_id.code = "Banking" ” part of the
script.
“x%” is a Value parameter, which corresponds to the “5" in the script.
Do not buy specific instruments.
Using the following example shown in sec on Iden fying new Constraint templates:
IF(nature_e= 1 AND instr_id.code = “alpha”, 0, 1)
The “specific instruments” expression is an a ribute parameter, which corresponds to the "instr_id.code = "alpha" " part of the script.
You have to try and match your parameters with these different categories. If you cannot find the right match, it means that you cannot iden fy your parameter in the system.
The parameters are described in the Template Element en ty. In addi on to the nature a ribute, the following a ributes are relevant to defining an element:

Parameter Descrip on
Code This code is the business key of the template element en ty. This code is useful
when you write out the generic script defini on of the constraint template, as
described below.
Name Corresponds to the short name of the occurrence.
Denom Long name of the occurrence. Try to give an explicit descrip on of your
parameter. This informa on appears in the input parameter screen.
Sor ng Rank Used to sort the elements in the parameter input screen.
Display Describes the display format of the data in the parameter input screen as is the
format case with format elements. Only valid for the Value parameter. It can be
parameterised by the user using special script language keywords. The syntax is
described in the WealthSuite Front Office - Por olio Management - Script
Language Reference Guide.
En ty When you define an a ribute parameter, you must specify the a ribute used to
define your queries. The a ribute can only belong to the following en es:
Instrument, Por olio, Third Party, Currency, Geographical Area, and Extended
Opera ons (i.e., for Trading Constraints exclusively). An example of a query is:
instr_id.code IN (“alpha”, “beta”).
A ribute The a ribute used in your query. This a ribute is only valid for template
elements with the A ribute nature. Note that you can only define queries on
type, sub-type and all the a ributes with the data types: code, enum, and flag.
An example of a query is: instr_id.code IN (“alpha”, “beta”) or instr_id.nature =
1.
Denomina on Logical a ribute of the en ty that corresponds to the long name of the
occurrence in a par cular language.
Once you have defined your template elements, you can write the generic constraint template script defini on. This defini on is based on the different parameters described previously.
Crea ng generic Constraint template script defini ons

The Constraint template script defini on refers to the parameters described in the Template Elements using the PARAM() keyword. PARAM() refers to the elements of a Constraint template. The purpose is to describe the open parameters of a
template. Consequently, it is relevant only in Constraint template script defini ons.
The syntax of the keyword is PARAM(parameter, script):
Parameter corresponds to the code of one of the template elements. It is mandatory.

Script is relevant only for parameters with the A ribute and Instrument Set natures. More precisely, it must be used when the en ty specified in the A ribute parameters is not the Extended Opera on table. It
defines the en ty specified in the element. For example, if your query is based on the third party code, then you create an element with the A ribute nature in the third party en ty. Then, you have to define
how to get from the Extended Opera on or the Extended Posi on en ty to the Third Party en ty in script language. For example, instr_id.issuer_third_id. For Instrument Set parameters, you must systema cally
describe how to reach the iden fier of the instrument. For example, instr_id or instr_id.parent_instr_id.
Examples
CHECK_SUM(pos_val.ref_mkt_val_m/por olio_id.mkt_val_m, LT, PARAM(“value”), , PARAM(”instrument_set”, instr_id)) is an example of a holding Constraint template. The string value is the code of an
element with the Value nature. The instrument_set string is the code of an element with the Instrument Set nature.
IF(nature_e = 1 AND PARAM(“instr_code”, instr_id), 0, 1) is an example of a Trading Constraint template. The instr_code string is the code of an element with the A ribute nature. The en ty is instrument and
the a ribute code.
Note that Front Office - PM checks the syntax of your template script defini on and warns you about errors. This means that the system prevents you from genera ng the wrong script defini ons for the constraints entered by end users.
Consequently, all occurrences generated by the Constraint Wizard are syntac cally correct.
Using the Constraint Wizard

The Constraint Wizard is nothing other than the constraint parameter input screen. You access this screen by clicking the Constraint Parameter bu on in the Trading Constraint and Constraint Set Element data input screens. Of course, you must
have previously chosen a template since the Constraint Wizard creates the input screen with the necessary elements from it.
Note: All parameters are mandatory. This means that users cannot save their input if they have not entered all parameters.
When you save your input, the Constraint Wizard automa cally generates a script defini on and replaces the PARAM() expressions with the appropriate data. The new defini on is stored in the database and is usable immediately. Note that if
you later modify the Constraint template script defini on, the changes have no effect on the exis ng occurrences in the system. On the contrary, users can s ll modify their parameters and override the defini on.
When a parameter is a query based on a code, users can choose any classifica on to define their query. By default, the Constraint Wizard proposes the user default classifica on for the corresponding en ty. There is a shortcut for directly se ng
the internal classifica on. The default instrument codifica on is set in the Select Instrument screen (by choosing Tools> Op on>Codifica on from this screen's main menu). You can access all codifica ons from the Constraint Wizard, if necessary,
to select your instrument.
As the Constraint Parameter screen is very similar to a Search panel, this feature is similar to a Search Profile in that it allows you to define default values and filters.
Constraint template view
There are several logical a ributes for storing default values, filters, and the input control.

Note: If you see the Trading Constraint bu on, you are viewing the Constraint template of nature Trading Constraint (which is the opposite of nature Holding Constraint as illustrated above).
Default value, filter, and input control scripts

The Default Value, Filter, and Input Control scripts are based on a virtual en ty. This virtual en ty is generated each me it is needed:
Script recording
Script evalua on
Constraint Parameter screen use
Each a ribute of the virtual en ty references a template element. The sqlname_c of one of the a ributes is the code of the corresponding template_element.
Default value
You can define a default value for template elements of the following natures:
Operator
Date
Value
Instrument set
A ribute only for the following data types:
Flag field
Enumerated field
Foreign key displayed in a drop-down list such as Type
The script must adhere to the following forms of syntax:
Standard default value syntax for template elements of the operator, value, date, and instrument set natures as well as for template elements of the a ribute nature linked to a flag a ribute.
Standard filter syntax for enumerated field or foreign key.
The aim of these filter default values is to allow for the selec on of a set of values. With a default value, however, only one type of data is selected.
Note: The default value for template elements of nature must specify that the searched list is an instrument list. For example:
GET_BEST_OBJECT(GET_ENTITY("list"),&code = "LIST_Instr" AND &en ty_dict_id = 900).id
and
GET_BEST_OBJECT(GET_ENTITY("list"),&code = "LIST_Instr" AND &en ty_dict_id.sqlname_c="instrument",1).id

Filter
You can define default values on the following template elements:
Instrument set
A ribute only for the following data type:
Flag field
Enumerated field
Foreign key displayed in a drop-down list such as Type
If a filter is defined, then the user input must be selected from the filtered field.
Use
Scripts are evaluated at the opening of the search panel.
Default values are evaluated only if the search panel is open without a defini on. A default value overwrites the given defini on.
Filters are always evaluated.
Script nature
The Search default value with Default Value syntax is nature 28
The Search default value with Filter syntax is nature 30
The Search Filter is nature 29
The Search Input Control is nature 31
Example
Modelling Constraints
Modelling Constraints are structured constraints that can have the following different natures:
Alloca on Constraints (based on the market structure).

Security Constraints:
Security In Constraints (based on a specific instrument or on a list of instruments).
Security Out Constraints (based on a specific instrument).
These Modelling Constraints natures have the following proper es:
Alloca on Constraints only apply to Asset Alloca on objec ve weights. They do not apply to the objec ve weights assigned to the Market Segments defined in Model Por olios.
Security In Constraints apply to the instruments defined in Model Por olio instrument objec ve weights when the system parameter SECURITY_CONSTR_DERIV_METHOD is set to zero. Conversely, if this
parameter is set to one, you can define constraints on instruments that do not belong to a Model Por olio.

A mandatory, defined Security Out Constraint provokes the Uncovered Out Locking excep on, when the instrument held in the related por olio does not reach the constrained quan ty. You have the op on to
define this nature of constraint as op onal to allow the system to "Lock" only the exis ng quan ty.
These Modelling Constraints are always linked to a specific por olio. From a business point of view, this means that these constraints are specific to a par cular client.
They are expressed as maximum and/or minimum weights, quan es, or amounts. More precisely, this means that the following cases can apply:
Maximum weight, i.e. “<= x”
Minimum weight, i.e. “>= x”
Minimum and maximum weight, i.e. “x <= => y ”
Where x and y either express percentages or quan es. Percentages are numbers between 0 and 100 while quan es are expressed as posi ve or
zero values.
Note: In the third case, x=y means an equality constraint.
Percentages are always expressed as contribu on weights with regard to the total por olio market value.
Alloca on Constraints can only be expressed as percentages, while Security Out Constraints can only be expressed as quan es. Security In Constraints can be expressed as a percentage, a quan ty, or an
amount when based on a single instrument, and only as a percentage when based on a list of instruments.
You are not allowed to define No onal Instruments in a Model Por olio.
You are not allowed to define Security In Constraints in quan ty on No onal Instruments.
Modelling Constraints can lead to an op misa on of the strategy objec ves.
Alloca on Constraints
Alloca on constraints are based on the market structure of the por olio in ques on.
Business
From a business point of view, the Alloca on Constraints are minimum and/or maximum weights applied to a specific Market Segment. The Market Segment that can be constrained is the one that appears in the strategy hierarchy linked to the
constrained por olio. All the Market Segments except the global total in each grid can be constrained.
Typically, an Alloca on Constraint can be used if a client wants to add a constraint to the Asset Alloca on of their choice. Alloca on Constraints only apply to Asset Alloca on objec ve weights. They do not apply to the objec ve weights assigned
to the Market Segments defined in Model Por olios.
Note that since Alloca on Constraints are clearly dependant on the segment defini on on which the constraint is defined – and constraints are directly linked to por olios – any change performed manually or dynamically in the link established
between a por olio and a strategy (such as an Investment Profile or an Asset Alloca on) shall render the Alloca on Constraints inopera ve (i.e., those constraints become “floa ng”; such “floa ng constraints” must be manually closed from the
Modelling Constraint administra on menu in the GUI).
Data model
From the point of view of the data model, the constraints are stored in two tables, namely Modelling Constraint (MC) and Modelling Constraint Element.
Modelling Constraint en ty
The Modelling Constraint table contains the following constraint proper es:
Nature (Alloca on in this case)

Por olio to which the constraint is applied
Date at which the constraint starts
Op onally the date at which the constraint stops
Last construc on date (date at which the constraint was modified)
Composite flag (indicates if the presence of a constraint automa cally means that the por olio is part of a composite or not)
The nature is included because the security constraints are stored in the same table.
Modelling Constraint Element en ty
The Modelling Constraint Element table contains the descrip on of the constraint as defined by the client. For the Alloca on Constraint, each element of a constraint is defined by a Market Segment to which the constraint applies, a minimum
and/or a maximum weight, and the fixed cell flag informa on.
The fixed cell flag informa on indicates if the investment objec ve linked to the constrained Market Segment can change or not. The value of the fixed cell flag means:
Fixed cell flag = 0: The investment objec ve in the constraint Market Segment can change when new objec ves are computed to comply with all the constraints (see Chapter 3 for the compu ng process).
Fixed cell flag=1: In this case, the investment objec ves (a er the constraints have been taken into account) must be the same as the ini al investment objec ve (the one in the strategy). Typically, this case involves a constraint on an Asset
Alloca on based on a bi-dimensional grid, asset-class / currency, to maintain the asset-class alloca on.
A constraint element (for the Alloca on nature) then is:
Market Segment (the one that is constrained)

Minimum and/or maximum weight
Value of the fixed cell flag
Example of Modelling Constraints with Alloca on nature

This sec on describes how to create a Modelling Constraints with the Alloca on nature and its elements, step by step.
Take, for example, a por olio called P Balanced01. Assume that the following main Asset Alloca on is linked to the por olio:
Main Stock Bonds Cash Total
35%
WE 20% 5% 10%
30%
NA 15% 8% 7%
35%
CHF 10% 13% 12%
Total 45% 26% 29% 100%
Under the Market Segment ‘North America (NA) / Stock’, there is the following alloca on:
Na/St TECH CHIM BANK Total
9%
USD 3.75% 2.25% 3%
6%
CAD 1.50% 2.25% 2.25%
Total 5.25% 4.50% 5.25% 15%
Under the Market Segment ‘West Europe (WE) / Stock’, there is the following alloca on:

EUR 14%
GBP 6%
Total 20%
Assume that a client wants to add constraints to the por olio from the 01/09/2002 as follows:
Maximum 15 % on Stock/WE
Minimum 10 % on Bonds/NA
Minimum 10 % on Stock/CHF
Minimum 5 % on TECH/USD
Maximum 2 % on BANK/CAD
To create these constraints in Front Office - PM, you must perform two steps. The first step consists in crea ng and saving the constraint and the second in crea ng and saving the associated elements.
Crea ng constraints
Follow these steps to create the constraint:
1. Choose Constraint->Modelling Constraint from the Produc vity menu.

2. Click the Create bu on and in the Modify Modelling Constraint window, select ‘Alloca on Constraint’ from the Nature drop-down list.
3. Complete all fields except the End Date field. With no end date, this constraint will remain ac ve onwards from the date in the Begin Date field. Later, if you want to add an end date, then modify the constraint (for
example, add a new Alloca on Constraint to the por olio with a later Begin Date or input an End Date).
4. Click Save to save your work.
A er this informa on is entered, you can create the elements that compose the constraint (see sec on Crea ng constraint elements).
Crea ng constraint elements
To create the Constraint elements,
1. Click the Elements bu on in the Modify Modelling Constraint screen.
Front Office - PM retrieves the grid on which the strategy hierarchy is based and displays it in the constraint administra on formats
authorised in the user format profile. Two formats are required: one with the Domain nature and the other with the Dynamic List nature.
The default formats are:
PCK_PM_CNSTR_SELECT
PCK_PM_CNSTR_EDT_ALL
2. Enter the constraints.
3. Click the Save bu on to ac vate your constraint.
Security Constraints
Security In and Security Out Constraints are not based on the market structure of the por olio in ques on. They apply to a specific instrument or a specific list of instruments.
A Security In Constraint is op mised by taking into account the constrained assets, while a Security Out Constraint forces the deriva on process to first take the constrained assets out of the por olio market value and then derive from the
remaining por olio market value. Security Out Constraints are always processed before Security In Constraints.
The image below shows the differences between a Security In Constraint and a Security Out Modelling Constraint.
Business view
Security In Constraints
From a business point of view, the Security In Constraints are minimum and/or maximum percentages or quan es applied to a specific instrument or list of instruments.
Typically, you can use these constraints if a client wants to constrain a specific instrument to a certain percentage of the por olio market value.
The behaviour of Security In Constraints depends on the system parameter SECURITY_CONSTR_DERIV_METHOD, which lets you decide if you want to allow constraints to be defined constraints for instruments that do not belong to a Model
Por olio in your strategy.
The permi ed values for SECURITY_CONSTR_DERIV_METHOD are:
0 = The deriva on process fails when the constraint is not defined on an instrument that is part of a Model Por olio (old behaviour).
1 = When possible, the deriva on ar ficially adds the instruments to the related Model Por olio and propor onally impacts the already defined instrument weights for this Model Por olio.
Note that the system does not support minimum Security In Constraints that apply to a Market Segment that passes the Market Segment weight (defined in the ini al alloca on or by Alloca on Constraints). This limita on is also valid for the sum
or the constraints that apply to a Market Segment.
Moreover, a Model Por olio must impera vely be defined for the Market Segment (only the final or last one) to which the constraint applies.
Security Out Constraints
Security Out Constraints exclusively apply to single instruments, and can only be specified as a quan ty to be taken out of the por olio before the deriva on process. You can use the constraint processing parameter to decide if the constraint is
considered mandatory or op onal by the system. A mandatory constraint provokes an error in the deriva on process if the constrained quan ty is not held in the por olio in which the constraint has been defined while with an op onal constraint
the system takes out the held asset quan ty when the constraint quan ty is greater than the held quan ty.
Note that Security Out Constraints are exclusion constraints that are used to exclude instrument posi ons from the por olio during the Strategy Reconcilia on or Check Strategy process. When the deriva on is set to Yes, it excludes the
instrument quan ty specified in the Security Out Constraint, which results in por olio reconcilia on on a lesser por olio value. When the deriva on is set to No, the Security Out Constraint is ignored.
If the goal is to protect a part of the instrument posi on without excluding it from the por olio during the Strategy Reconcilia on or Check Strategy process, you must define the Min Value field during the crea on of the Security In Constraint.
The Min Value defines the minimum security posi on that should remain in the por olio a er reconcilia on.
Data model
As far as the data model is concerned, the constraints are stored in two tables:
Modelling Constraint (MC)

Modelling Constraint Element
Modelling Constraint en ty
The following constraint proper es are included in this table:
The nature, in this case, Security

The por olio to which the constraint applies
The date at which the constraint begins
Op onally the date when the constraints ceases to be valid
The last construc on date is the last date at which the constraint was modified
The composite flag that indicates if the presence of a constraint automa cally means that the por olio is in a composite or not
You can see that this is the same informa on for both natures (Alloca on and Security) except for the nature, which is obviously different.
Modelling Constraint Element en ty
The Modelling Constraint Element table describes the constraint defined by the client. In the case of a Security Constraint, each constraint element is composed of an instrument dimension (list or instrument), an instrument object (the list or
instrument to which the constraint applies) and a minimum and/or maximum weight.
A constraint element for the Security nature then is:
An instrument dimension (instrument or list of instruments)

An instrument object (the specific instrument or the list of instruments)
A minimum and/or maximum value
A constraint bound nature indica ng if the min and/or max value is specified as a percentage or a quan ty
Compu ng objec ves

In this sec on, you will learn about:
Dynamic weights
Op mising strategy objec ves
One-pass deriva on process (detailed)
Two-pass deriva on process (detailed)
Failed deriva ons
Propor onality
What is not supported by the deriva on process
Alterna ve financial func ons allowed by the deriva on process
Dynamic weights
The por olio management guidelines decided by the client and the bank take the form of a strategy. In this context, a strategy, then, is a management agreement between the client and the bank. The strategy is defined by percentage of
investment per asset class (or instrument) and index. Thus, each asset class or index has a certain weight in the por olio which is the percentage associated with it.
When the por olio is compared to the strategy at a date later than that of the strategy's defini on, the strategy weights are adjusted to take the rela ve performance of the indices into account.
Descrip on
Term Defini on
Strategy In this document, the term strategy represents an Asset Alloca on or a Model
Por olio.
Example:
At date 1, the strategy is composed of 50% of index A and 50% of index B. It can be
defined in Front Office - PM as an index instrument (simple or composite), an Asset
Alloca on strategy, or a Model Por olio.
Ini al The ini al weight calcula on or price adjusted weight is the weight defined to take
weight into account the rela ve performance of the indices that compose the benchmark
calcula on or strategy. In the context of Returns, the process is called "ini al weight
calcula on". In the Orders and Produc vity func ons (Check > Reconcile Strategy),
Price the same calcula on is called "price adjusted weight".
adjusted
weight Example:
Between date 1 and date 2 the return of index A is 10%, the return of index B -10%.
Due to these performances, the price-adjusted weights of the strategy are 55% for
index A and 45% for index B at date 2. If investments were made in a por olio in
line with the strategy at date 1, its composi on will be similar to the strategy at
date 2. These weights are also used as ini al weights to calculate the strategy's
return between date 2 and date 3. With index returns of +5% and +10% between
these dates, the strategy performance is 5% * 55% + 10% * 45%.
Formula
The weights of a benchmark/strategy composed of a percentage of instruments i at date t are wri en as wi,t , with (normally) .
If at date t1, the weights are: w1,t1,…, wn,t1, the price adjusted weights at t2 are:
If , the return from wdelta1 (where ) is 0%.
The formula then becomes:

Processing
For the processing of dynamic weights, there is a parameter in the domain called Dynamic Weight. If you set it to Yes, Front Office - PM adjusts the original objec ve weights.
This parameter is available in all func ons that allow you to check investment objec ves.
Op mising strategy objec ves

This sec on describes how Front Office - PM computes strategies for por olios with Modelling Constraints linked to them.
Briefly, the process (known as deriva on) is an op misa on of the strategy objec ves behind the Modelling Constraints. At the beginning of the process there is a hierarchy of strategies linked to a por olio and a set of Modelling Constraints on
the por olio. There could be a possible risk of conflict between the constraints and the strategy objec ves. To avoid such risks, Front Office - PM computes new strategy objec ves on the basis of the following principles:
The new strategy objec ves must not breach any constraints.
The new strategy objec ves must be as close as possible to the ini al objec ves.
This sec on also describes how Front Office - PM computes the new objec ves and provides some examples. Schema cally, this gives:
This sec on describes in detail the process used to compute op mised strategies (the results of the strategy deriva on). This informa on applies to both Asset Alloca ons and Model Por olios.
The deriva on process involves the following func ons:
Check Strategy
Strategy Reconcilia on
Allocate Order
View Por olio Objec ves
Strategy Deriva on
All of these func ons are run from a Domain screen.
Types of deriva on processes

The following devia on processes are available:
One-pass deriva on process (summary)

Two-pass deriva on process (summary)
One-pass deriva on process (summary)

This sec on briefly describes how the one-pass deriva on process works. For more detailed explana on, see sec on One-pass deriva on process (detailed).
Since Release 11, a one-pass deriva on process is available, which differs from the two-pass deriva on process that gives priority to the Market Segments. The one-pass method is more efficient because it derives the Asset Alloca on and Model
Por olio(s) strategy objec ves together.
The behaviour of the deriva on process depends on the system parameter DERIVATION_ONE_PASS, which lets you decide if you want to ac vate the one-pass deriva on process. The permi ed values for DERIVATION_ONE_PASS are:
0 = The deriva on process begins with the Asset Alloca on then derives the weights of the Model Por olios (default - old behaviour).
1 = The deriva on is done in one pass, considering constraints on both Asset Alloca on and Model Por olios altogether.
Two-pass deriva on process (summary)

This sec on briefly describes how the two-pass deriva on process works for a single por olio. If you run a func on on more than one por olio, the process is repeated for each one. For more detailed explana on, see sec on Two-pass deriva on
process (detailed).
Briefly, the two-pass deriva on process is:
1. Front Office - PM retrieves the strategies and the constraints linked to the por olio.
2. Using data from these strategies and constraints, Front Office - PM completes and calculates the appropriate formula.
The general problem is to find the derived objec ve Wj_final that minimises the func on:
under the constraint that can be expressed as
,
where the first equa on applies to equality constraints and the second to inequality constraints.
3. Once the strategy and constraint data has been included in the equa on, Front Office - PM computes all Wj_final values.
4. This solu on makes it possible to compute the derived strategies. In other words, the strategies that are as close as possible to the ini al strategies, as implied by the func on F, that respect the Modelling
Constraints.
The mathema cal formula must take the following rule into account:
If the ini al weight is 0 % in a Market Segment for the Asset Alloca on and an instrument for a Model Por olio, the deriva on process does not affect this weight. From the business point of view, a 0 % weight means that the client does not really
want to invest in the specific area. Deriva on must not affect this decision. From the mathema cal point of view, this objec ve is a known value.
The process of deriva on involves several steps, as follows:
1. Construc on of a mathema cal problem based on the Asset Alloca ons and the Alloca on Constraint. The mathema cal problem is based on weight contribu ons.
Computa on of the derived weight for the Asset Alloca on contribu ons by running an op miser.
Computa on of the weight contribu ons for Asset Alloca ons on totals and sub-totals, taking into account the difference between ini al contribu ons and derived contribu ons.
Computa on of the weights for the Asset Alloca on.
2. Update of the weight contribu ons in the Model Por olios following the new Asset Alloca on weight contribu ons.
3. Construc on of a mathema cal problem based on the Model Por olios and the security constraints. The mathema cal problem is based on weight contribu ons.
Computa on of the derived weight contribu ons of the Model Por olios by running an op miser.
Computa on of the weight contribu ons for Model Por olios on totals and sub-totals, taking into account the difference between ini al contribu ons and derived contribu ons.
Computa on of weights for Model Por olios.
One-pass deriva on process (detailed)

In the following sec ons that relate to the one-pass deriva on process, you will learn in detail about:
Cost func on
Security In Constraint
Alloca on Constraint on a single Market Segment

Alloca on Constraint on a list of Market Segments
Removing unnecessary variables
Removal of fixed variables
Effect on propor onality
Cost func on
The solver will solve the following problem:
Find that minimise the cost func on under the constraints
where can be wri en as
The solver tries to minimise the difference between the derived objec ve and the ini al objec ve for all variables. The difference is squared because it is be er to have a sum of small differences than one large difference and other differences
equal to 0.
The first term gives more priority to the Market Segments that are at the top of the hierarchical market structure. Instruments are given less priority than the Market Segment they belong to.
Security In Constraint
A Security In Constraint is a structured Modelling Constraint on an instrument or on a list of instruments.
Conversion from a quan ty or an amount into a weight

Even if the constraint is defined using a quan ty or an amount, the value should be converted in weight. The mathema cal problem only includes variables that represent a weight.
A constraint on a single instrument can be defined in weight, quan ty, or amount.
A constraint on a list of instruments can be defined in weight or amount. The constraint impacts the sum of the objec ve weights of the instruments (it does not apply to each instrument individually).
A constraint in quan ty can be converted in weight using the following method:
1. Get the price of the instrument.

2. Add possible accrued interests.
3. Mul ply by the quan ty of the constraint.
4. Convert this amount from the instrument price currency to the por olio currency.
5. Divide this amount by the market value of the por olio.
A constraint in amount can be converted in weight using the following method:
1. Convert the amount of the constraint from the constraint currency to the por olio currency.
2. Divide this amount by the market value of the por olio.
Constraint on a single instrument

This sec on contains the following subsec ons:
Instrument appears in the objec ves

Instrument does not appear in the objec ves
Instrument appears in the objec ves
This is the most frequent use case. Every instrument appears in the objec ves. To include the constraint, modify the “min weight” a ribute of the consolidated posi on.
For a “fixed” constraint, the minimum and the maximum weights will be set to the objec ve.
Example 1:
Constraint1: Minimum 30% of UBS
Constraint2: Maximum 20% of BCV
Min Max
Market Segment Instrument Objec ve Derived Objec ve
weight weight
Stock 80% 30% 100% 80%
Stock/CHF 50% 30% 100% 50%
Stock/CHF/Banking 50% 30% 100% 50%
Stock/CHF/Banking UBS 25% 30% 100% 30%
Stock/CHF/Banking BCV 25% 0% 20% 20%
Stock/USD 30% 0% 100% 30%
Bond 20% 0% 100% 20%
The minimum weight set on UBS is also applied to its parent objec ve. This mechanism is useful to know the domain of possible values for each variable. It will be used while applying propor onality constraints. Note that we can only apply a
propor onality constraint on a variable if its objec ve is not outside the minimum and maximum weights, which are updated by constraints.

The result returned by DONLP2 is given in the column “Derived Objec ve”.
Example 2:
Constraint1: Minimum 30% of UBS

Constraint2: Minimum 25% of BCV
Min Max
weight weight
Stock 80% 55% 100% 80%
Stock/CHF 50% 55% 100% 55%
Stock/USD 30% 0% 100% 25%
Bond 20% 0% 100% 20%
Here, both constraints modify the objec ve of the related instrument. The Parent Market Segments have a minimum weight that equals the sum of the minimum weights of the two children.
Note that the minimum weight of Stock/CHF and of Stock/CHF/Banking is greater than the objec ve weight. This case is not allowed in the two-pass deriva on process but allowed when using the one-pass method. We can see, looking at the
derived objec ves, that the segments will reach 55% (the addi onal 5% is taken from the Stock/USD segment).
The logic is to impact the closest Market Segments first. Here, Stock/USD is a “brother” to Stock/CHF, which is why it is impacted and not the Bond segment.
Example 3:
Constraint1: Maximum 10% of UBS

Constraint2: Maximum 20% of BCV
Min Max
weight weight
Stock 80% 0% 100% 80%
Stock/CHF 50% 0% 30% 30%
Stock/USD 30% 0% 100% 50%
Bond 20% 0% 100% 20%
This example shows that the maximum weight of the Market Segment is also a consolida on of the maximum weights of the children.
Instrument does not appear in the objec ves
The system must create a new objec ve for this instrument and a ach it to the right Market Segment.
Constraint on a list of instruments

A Modelling Constraint on a list of instruments impacts the sum of the objec ve weights of the instruments; it does not apply to each instrument individually.
Constraints on lists work with weights and amounts (no quan ty). For constraints in amounts, the system needs to compute the weight that this amount represents. This computa on is described in sec on Instrument appears in the objec ves.
When a constraint on a single instrument is analysed, the minimum and/or the maximum weights of the constrained objec ve are used to store the informa on, which are put in the vect_min and vect_max arrays of the mathema cal data. We
cannot use the same approach for constraints on list.
For constraints on lists, we use mathema cal matrixes that allow inser ng a rela on between elements and constraining them together. If the constraint is fixed (minimum weight = maximum weight), we use H, the equality matrix, otherwise we
use G, the inequality matrix.
The first step is to get all elements from the objec ves that are referenced by the constraint, and then add the constraint in the concerned matrix.
If the list of instruments that are in the por olio contains only one element, we can apply the same treatment as a constraint on a single instrument.
If the constraint is fixed:
1. Add a new line in H matrix.

2. Set 1 to each instrument that is listed in the constraint, and 0 to all other.
3. Add a new value to Rhse equal to the fixed weight.
If the constraint is not fixed, and has a minimum weight:
1. Add a new line to G matrix.

2. Set 1 to each instrument that is listed in the constraint, and 0 to all other.
3. Add a new value to Rhsi equal to the minimum weight of the constraint.
If the constraint is not fixed, and has a maximum weight:

1. Add a new line to G matrix.
2. Set -1 to each instrument that is listed in the constraint, and 0 to all other.
3. Add a new value to Rhsi equal to the nega ve value of the maximum weight of the constraint.
Alloca on Constraint on a single Market Segment

The constraint must be defined in weight or in amount; for amount, it must be translated into weight using the market value of the por olio and an exchange rate, if needed.
The percentage is then set to the minimum or maximum weight of the objec ve represen ng the Market Segment.
But several constraints impact the same Market Segment. Every me a new constraint is added, the value of the minimum and the value of the maximum are analysed at the parent level.
The minimum weight of a parent objec ve is equal to the sum of the minimum weights of the children (Market Segment or Instrument), unless a Modelling Constraint on the parent itself exists and is more restric ve (the value of the minimum is
superior).
The maximum weight of a parent is equal to the sum of the maximum weights of the children, unless a Modelling Constraint on the parent itself exists and is more restric ve (the value of the maximum is inferior). The maximum weight of a
consolidated posi on without any constraint is 100%, and for every sum that is superior to 100%, we set 100%.
In an itera ve approach of an algorithm where constraints are added one by one, the following principles respect the rules above.
Inser on of a new constraint.

New min weight = MAX(constraint min weight, old min weight).
New max weight = MIN(constraint max weight, old max weight, 100%).
Computa on of the minimum and maximum weight of the parents a er inser ng a constraint.
New min weight = MAX(sum children min weights, old min weight).
New max weight = MIN(sum children max weights, old max weight, 100%).
Alloca on Constraint on a list of Market Segments

This feature allows pu ng a constraint on what is called global Market Segment or totalizer.
Example
Constraint: Minimum 75% of CHF
Min Max
Market Segment Instrument Variable number Objec ve
weight weight
Stock 1 80% 0% 100%
Stock/CHF 2 50% 0% 100%
Stock/CHF UBS 3 25% 0% 100%
Stock/CHF BCV 4 25% 0% 100%
Stock/USD 5 30% 0% 100%
Stock/USD Microso 6 30% 0% 100%
Bond 7 20% 0% 100%
Bond/CHF 8 15% 0% 100%
Bond/CHF CHF B1 9 15% 0% 100%
Bond/USD 10 5% 0% 100%
Bond/USD USD B1 11 5% 0% 100%
CHF 65% 75% -
USD 35% - -
Some Front Office - PM formats allow for the inser on of such Alloca on Constraints. CHF is not a real Market Segment but a “totaliser” of all sub-CHF Market Segments in the alloca on. Here, CHF is the consolida on of Market Segment
‘Stock/CHF’ and ‘Bond/CHF’.
Even if it would be technically possible to put a constraint on a list of individually chosen Market Segments, the current development only uses the exis ng user interface.
Technically, we do not need to create a new objec ve for the CHF element; we will use the matrixes. The principle is the same as for the list of instruments:
1. Get the list of impacted Market Segments.

2. Add a new line in the matrix and a new value in the corresponding right-hand side using the same rules as the ones define for the list of instruments.
A line is added to G matrix (inequali es) to represent the new equa on with a constraint at 75% for the set of related Market Segments.
Removing unnecessary variables
Update of the minimum and maximum weights

Before removing the possible fixed elements, we need to ensure that all minimum and maximum weights are recursively updated.
For the minimum weight, if an instrument, for example, has a minimum weight set, this Market Segment should be updated to integrate this minimum, and so do the parent segments. The minimum weight of a parent objec ve should be equal
to the sum of the minimum weight of its direct children (unless the parent has its own minimum weight greater than the sum of the children).
For a maximum weight, we can update the maximum weight of a parent objec ve if the sum of the maximum weights of its direct children is less than 100% (and less than its own actual max weight).
Constraint with an objec ve of 0%

This case happens when a strategy objec ve is set directly to 0% or if the instrument has no objec ve. This is considered as a strong inten on to sell the instrument’s posi ons.
In the construc on of the derived objec ve, we set the maximum objec ve weight to the minimum objec ve weight. This means that we want this objec ve to have a derived weight that is equal to 0, or if there is a Security In Constraint defining
a minimum, we want the derived weight equal to the minimum set by the constraint.
For this type of derived objec ve, we can consider that the derived weight is trivial and we can fix it without calling the mathema cal solver.

Removal of fixed variables
Before calling the mathema cal solver, when all posi ons, objec ves, and constraints have been taken into account, we can remove the derived objec ves for which we already know the derived weight.
The goal is to have the simplest mathema cal problem so that DONLP2 can find the solu on quicker. It is also important because, by removing fixed variables, we can eventually have a mathema cal problem that is so simple that it does not
require calling the mathema cal solver anymore (this case is called a “trivial deriva on”).
We can remove derived objec ves for:
Posi ons with a minimum objec ve weight that equals the maximum objec ve weight (this case includes instrument having an objec ve of 0% (see sec on Constraint with an objec ve of 0%)).
Instruments that we cannot rebalance automa cally (genera ng orders on such instruments does not make sense).
In the first case, the derived objec ve weight is set to the minimum weight, which is equal to the maximum weight. In the second case, we set the derived objec ve weight to the actual weight.
We can then remove the consolidated posi on and update the other ones.
Effect on propor onality

The propor onality constraint is set to keep as much as possible the ra o between the investment objec ves (see sec on Propor onality).
Two-pass deriva on process (detailed)

This sec on describes in detail how Front Office - PM computes the derived strategies. This informa on is mainly technical and can be skipped by business users who are not interested in the detailed process.
Front Office - PM retrieves all strategies linked to a por olio and all linked constraints. For the purposes of deriva on, Front Office - PM only uses the Asset Alloca ons, Model Por olios, and Modelling Constraints (Alloca on and Security). More
precisely, Front Office - PM only deals with the strategies that are part of the main hierarchy.
In the following sec ons that relate to the two-pass deriva on process, you will learn in detail about:
Asset Alloca on deriva on

Upda ng objec ves of the Model Por olio
Deriving the Model Por olio
Dynamic weights deriva on
Dummy Model Por olio deriva on
Asset Alloca on deriva on

At this stage, Front Office - PM only processes the Asset Alloca ons and Alloca on Constraints (or Modelling Constraints of nature Alloca on).
The first step is to construct a mathema cal problem to produce the equa ons that represent the Alloca on Constraints:
Front Office - PM counts the unknown values of the problems. In fact, this refers to all cells that are not totals or sub-totals, that have no linked Sub-Asset Alloca on and that are not fixed by se ng Fixed Cell
Flag = yes in the Alloca on Constraint.
Front Office - PM associates a variable to each unknown value.
Front Office - PM translates the equality constraints into equality equa ons and inequality constraints into inequality equa ons. In fact, if an inequality equa on involves just one variable, this variable is
converted into a bound.
Front Office - PM adds propor onality constraints between Market Segments of the same level. This process is itera ve. If one of these constraints prevents the system from finding a solu on, it is removed.
At this point, Front Office - PM has to take into account the weight contribu ons linked to the Asset Alloca ons. For example, if we have a fixed equality constraint on the Market Segment ‘Stock-Euro’ and an Asset Alloca on is linked under this
Market Segment, then the equa on is that the sum of the unknown values linked to the Market Segments (total and sub-totals excluded) under Stock-Euro must equal the ini al contribu on.
Once the mathema cal problem is constructed, a set of equali es, inequali es and bounds is passed to a mathema cal op miser that computes the weight contribu ons minimising the func on F (described above). The unknown derived weight
contribu ons are grouped into a vector at this stage.
Once the solu on is obtained (w_j_final – vector solu on), it is assigned to the corresponding Market Segment weight contribu ons.
This step only produces the contribu on for non-total or sub-total Market Segments. The total and sub-total weight contribu ons must s ll be computed. This computa on is the sum of the differences between the ini al weight contribu ons
and the derived weight contribu ons.
Finally, the last step computes all the derived weights from the derived weight contribu ons.
Upda ng objec ves of the Model Por olio

Once the new contribu ons for the Asset Alloca on have been computed, the contribu ons linked to the Model Por olios implicitly change. In compu ng terms, this means that the weight contribu ons linked to all the instruments composing
the Model Por olios and the contribu ons linked to the sub-totals and totals by Market Segment (for a Model Por olio based on a grid or list of grids) must be updated.
This means simply mul plying the ini al weights of the Model Por olios by the derived weight contribu on of the Parent Market Segment to which the Model Por olio is linked.
The result at this stage is contribu ons in Model Por olios that do not equal the ini al contribu ons. However, they are not fully derived since at this point the Model Por olio has not been derived.
Deriving the Model Por olio

This step is similar to the first step in which the Asset Alloca ons were derived, but in this case the Model Por olio strategies are derived with the security constraints taken into account.
First, a mathema cal problem is constructed. This produces the equa ons that represent the security constraints. In this case, there are also implicit equa ons to build to ensure that the sum of the contribu ons of all instruments that belong to
the Model Por olio equal the contribu ons of the Parent Market Segment. This construc on is as follows:
Front Office - PM counts the unknown values of the problem. All instruments without an equality constraint are involved.
Front Office - PM associates a variable with each unknown value.
Front Office - PM translates the equality constraints into equality equa ons and the inequality constraints into inequality equa ons. If an inequality equa on involves just one variable, it is converted into a
bound.
Front Office - PM builds the equality equa ons to ensure that the sum of the contribu ons linked to the instruments in a Model Por olio equals the contribu ons of its Parent Market Segment.
Front Office - PM adds propor onality constraints between instruments belonging to the same Market Segment. If one of these constraints prevents the system from finding a solu on, it is removed.
The system, when transla ng the constraint into equa on, performs a constraint rounding if the constraint concerns a single instrument. This computa on is done to avoid a Constraint Breach due to the order quan ty rounding. The computa on
takes into account the instrument characteris cs and the rounding method to compute minimum and maximum values. For example, if the por olio contains 5% of Novar s and the constraint on Novar s is minimum=10%, maximum=25%, the
minimum will be 11% if the rounding method is down and 10% if the rounding method is up or nearest. The maximum weight will be 25% if the rounding method is down and 23% if the rounding method is up or nearest.
Once the mathema cal problem is constructed, a set of equali es, inequali es and bounds to a mathema cal op miser that computes the weight contribu ons, minimising the func on F (described above). The unknown derived weight
contribu ons are grouped into a vector at this stage.
The solu on (w_j_final – vector solu on) is added to the corresponding instrument weight contribu ons.
At this point, there is only the contribu on in instruments. The total and sub-total weight contribu ons must s ll be computed. This calcula on is the sum of the differences between the ini al weight contribu ons and the derived weight
contribu ons.
The last step is to compute the derived weights from the derived weight contribu ons.
Dynamic weights deriva on

This sec on describes how the process of deriva on works when you use the dynamic weights features.
To ensure that the constraints are respected each me, the deriva on process is based on dynamic weights. This means that the deriva on weights cannot be stored in the database because the ini al weights will change every day.
In fact, the deriva on process itself does not change at all. The only difference is in the ini al weights w_j_init. If dynamic weights are not computed, the investment objec ves defined in the Strategy Elements are used as ini al weights. If
dynamic weights are computed, the deriva on process uses the weight computed by Front Office - PM as the ini al weight.
Dummy Model Por olio deriva on

This sec on describes how the process of deriva on works when you have dummy Model Por olios in your strategy hierarchy.
The presence of a dummy Model Por olio in the main strategy hierarchy can cause the same problem as that arising from dynamic weight computa on. The affect is the same, namely:
There is no use saving the derived strategy in the database. Strategy deriva on is useless.

The ini al weights (w_j_init) used by the deriva on for instruments are those computed by the valua on of the dummy por olio.
Failed deriva ons

This sec on describes how Front Office - PM handles failed strategy deriva ons.
There can be several reasons why the deriva on might fail. The main risk is that some constraints are not consistent. For example, consider a situa on where you have the following constraint in an Asset Alloca on:
Stock-EUR > 30 %
Stock <= 25 %
There is no solu on to the above contradic on. This example is very simple but a more complex example can lead to the same problems. You cannot always see immediately why a problem occurs.
Since a pre-processor evaluates all the mathema cal problems, it is possible to give the user a clue as to which constraint caused the problem. Hence, if the deriva on fails, Front Office - PM adds an entry to the Deriva on Failed Reason field of
the extended strategy link en ty. More precisely, the informa on is placed in the head link. The field is an enumerated field with the following available values:
Value Descrip on
0 Deriva on Succeeded, no problem occurred.
1 AA Equali es Incompa ble. Some equality constraints are in contradic on with

equali es in the Alloca on Constraints. These are fixed cell or real equali es.
2 MP Equali es Incompa ble. Some equality constraints are in contradic on with

equali es in the security constraints. These are real equali es or equali es that are
implicit and ensure that the sum of the contribu ons linked to the instruments is equal
to the contribu on of the Market Segment.
3 AA Inequali es Incompa ble. Some inequality constraints are in contradic on with

inequali es in the Alloca on Constraints.
4 MP Inequali es Incompa ble. Some inequality constraints are in contradic on with

inequali es in the security constraints.
5 AA Zero Unknown Equality. An equality has no mathema cal variable linked to it. This
probably means that you have too many constraints defined for a given Market
Segment. Check if there are contradictory Alloca on Constraints.
6 MP Zero Unknown Equality. An equality has no mathema cal variable linked to it. This
probably means that you have too many constraints defined for single instruments or a
list of instruments. Check if there are contradictory security constraints.
7 AA Eqty-Ineqty Contradic on. There is a contradic on between equality and inequality

on Alloca on Constraints.
8 MP Eqty-Ineqty Contradic on. There is a contradic on between equality and inequality

on Alloca on Constraints.
9 AA Zero Unknown Inequality. An inequality has no mathema cal variable linked to it.
This probably means that you have too many constraints defined for a given Market
Segment. Check if there are contradictory Alloca on Constraints.
10 MP Zero Unknown Inequality. An inequality has no mathema cal variable linked to it.
This probably means that you have too many constraints defined for single instruments
or a list of instruments. Check if there are contradictory security constraints.
11 AA Op misa on Failed. The deriva on failed but the pre-processor is not able to detect
the reason for the failure. Check your Alloca on Constraints.
12 MP Op misa on Failed. The deriva on failed but the pre-processor is not able to detect
the reason for the failure. Check your security constraints.
13 Invalid Grid. The grid on which the Alloca on Constraints are based is not the same as
the one used for the strategy. The constraints are no longer valid. Typically, this results
from a Strategy Link modifica on.
14 No Deriva on with No onals. The deriva on process does not support deriva on with
No onal Instruments defined in the strategies.
15 Uncovered Out Locking. A mandatory Security Out Constraint is defined for a por olio
that does not hold the quan ty corresponding to the constraint. This excep on is not
raised if the constraint processing has been set as op onal.
16 No Strategy for Min Constraint. A minimum constraint has been set for an instrument
where its related Market Segment has no defined strategy (i.e., Model Por olio).
17 Sum of Min Contrib > MS Weight. The sum of the minimum constraints is greater than
the Market Segment weight defined by the ini al alloca on or by the Alloca on
Constraints.
18 Failed to convert Qty to %. A quan ty cannot be converted to a percentage.
Propor onality
The deriva on process used to compute op mal objec ves is based on a mathema cal algorithm, which does not consider the propor ons of the ini al objec ve weights. The consequence is that when the objec ves must be modified because
of constraints, the realloca on of missing or excessive weights will be unsa sfactory from a business point of view.
To improve this process, Front Office - PM adds propor onality constraints in the mathema cal problem, which ensures that the final objec ve weights will be computed respec ng the propor ons of the original strategy objec ves.

These constraints are not a business type of constraints. The user will not see them in any screen. They are part of the internal algorithm to generate be er results and are added between Market Segments of the same level (equality Alloca on
Constraints) and between instruments of the same Market Segment (equality Model Por olio constraints).
Propor onality example

In this example, we focus on an alloca on (but the process used for Model Por olios is the same).
Without propor onality constraints, there is no indica on in the mathema cal problem that the propor ons between the original objec ve weights must be kept as close as possible.
We have an Alloca on Constraint on the Market Segment ‘Stock’ defining a minimum of 90% and affects the ini al objec ve weight, which is 60%. The current result is:
Market Segment Actual weight Objec ve weight Constraint objec ve weight
Stock 35.00% 60.00% 90.00%
Stock/CHF 15.00% 5.00% 12.50%
Stock/USD 7.00% 20.00% 27.50%
Stock/EUR 8.00% 30.00% 37.50%
Stock/JPY 5.00% 5.00% 12.50%
The mathema cal solver has distributed the same addi onal weight (7.5%) to each child Market Segment.
When adding propor onality constraints, the result is:
Market Segment Actual weight Objec ve weight Constraint objec ve weight
Stock 35.00% 60.00% 90.00%
Stock/CHF 15.00% 5.00% 7.50%
Stock/USD 7.00% 20.00% 30.00%
Stock/EUR 8.00% 30.00% 45.00%
Stock/JPY 5.00% 5.00% 7.50%
The extra weight needed to reach the Market Segment ‘Stock’ minimum has been distributed in respect of the propor ons between the ini al objec ves: each child Market Segment objec ve has increased by 50%.
The process to add propor onality constraints is itera ve. Front Office - PM adds them level by level, star ng from the top level Market Segments. It checks (at each itera on) that there is s ll a solu on, which means that it checks whether it can
s ll find constraint objec ve weights that do not break any constraints (i.e., user constraints and propor onality constraints). If it is not the case, the latest added propor onality constraints are removed.
Furthermore, Front Office - PM does not add propor onality constraints on Market Segment or Instrument for which:
the objec ve weight is 0%

the objec ve is outside the minimum or maximum weight allowed (due to a constraint)
in the case of an instrument, a Security In Constraint on a list of instruments exists and includes this instrument.
Adding propor onality constraints gives be er results from a business point of view, but has a performance impact. To remove this feature, a system parameter exists: DERIV_USE_PROPORTIONALITY. Set it to 0 to disable the feature (default
value is 1).
What is not supported by the deriva on process

The following are not supported by the deriva on process:
Locked posi ons: These are not integrated in the op misa on.
Recommenda on Lists: These are currently taken into account a er the deriva on. The system takes each Market Segment that is managed by recommenda ons, takes the derived objec ves given by the
op miser, and then computes the possible moves.
No onal instruments: These are not considered by the op misa on process.
Structured Trading Constraints: These were known from former OCS components and are not supported by the financial server.
Alterna ve financial func ons allowed by the deriva on process

The strategy deriva on is ini ated by the Deriva on field (deriva on_e) of the domain.
The possible values are:
Value Descrip on
No No deriva on is computed.
Yes Deriva on is computed for strategies for which there are no valid derived strategies in
the database (see below for further details).
Online All strategies are derived.
Note that the system checks if there are constraints linked to the por olio. If this is not the case, then no derived strategies are computed. More precisely, if there are no Alloca on Constraints, the Asset Alloca on is not derived; and if there are
no security constraints, Front Office - PM does not derive the Model Por olios. This feature shortens processing me. If there are no constraints (alloca on/security), there are no business requirements to derive the related strategies (Asset
Alloca ons / Model Por olios).
Deriva on only applies to the main strategy hierarchy.
If a strategy deriva on is run, Front Office - PM replaces the investment objec ves with the derived objec ves.
The following sec ons describe the alterna ve financial func ons allowed by the deriva on process:
Check Strategy and Strategy Reconcilia on

Asset Alloca on and Model Por olio
Strategy Deriva on

Check Strategy and Strategy Reconcilia on
Note that running the Check Strategy func on or the Strategy Reconcilia on func on does not save derived strategies in the database. Strategy Deriva on is the only func on that saves derived strategies.
Asset Alloca on and Model Por olio

When you run Strategy Reconcilia on (Produc vity > Reconcile Strategy) with the Deriva on field set to Yes, Front Office - PM loads the derived strategy from the database and checks whether the derived strategies are valid as described in the
following sec ons:
Asset Alloca on derived strategies

Model Por olio derived strategies
Asset Alloca on derived strategies

The set of derived strategies of the Asset Alloca on nature is considered valid if:
All derived strategies come from an Asset Alloca on in the main hierarchy
All Asset Alloca ons from the main hierarchy have a derived strategy
The date at which the derived strategies were computed must be greater than:
The last date an Alloca on Constraint was modified
The last date any Asset Alloca on in the hierarchy was modified
No Asset Alloca ons are of the dummy nature (not yet implemented)
The user did not run the func on with the Dynamic flag set to Yes
Model Por olio derived strategies

The set of derived strategies of the Model Por olio nature is considered valid if:
All the derived strategies come from a Model Por olio in the main hierarchy
All Model Por olios in the main hierarchy have a derived strategy
The date at which the derived strategies were computed must be greater than:
The last date a security constraint was modified
The last date of any Model Por olio in the hierarchy was modified
No Model Por olios are of the dummy nature
The user did not run the func on with the Dynamic flag set to Yes
The derived strategies of the alloca on nature are valid. This condi on is necessary since the Asset Alloca on weights directly affect the contribu on in the Model Por olio.
Strategy Deriva on
The Strategy Deriva on func on computes derived strategies and stores them in the database. The func on does the following (for a single por olio):
1. Loads the strategies and the constraints linked to the por olio.
2. Filters out everything but Asset Alloca ons and Model Por olios in the main hierarchy.
3. Performs a deriva on with Deriva on = Yes. The parameter is forced to Yes (hard-coded) to gain me if a derived strategy is valid (there is no need to compute it again).
4. Saves the derived strategies (Asset Alloca ons and Model Por olios) in the database if the deriva on succeeded.
Case Management Component

Case Management Component (CMC) was developed to replace the Constraint Breach func on and to enhance the way constraints' viola ons are handled. With CMC, Front Office - PM extends the possibility to manage the consequences of
constraints’ viola on, to any constraint type and to Objec ve Margins. CMC provides be er coverage of the MiFID Direc ve and is available for Allocate Order, Reconcile Strategy, and Order Entry func ons. For informa on about MiFID, see
sec on Appendix: MiFID compliance.
CMC is also applied to risk compliance, but handled differently from other cases. The cases based on risk compliance are managed by a Case Rule. For more informa on, refer to sec ons Case Rule and Risk compliance.
CMC is based on two facili es: (1) Case crea on – as Format – when any constraint is violated and (2) the Clarifica on process.
This sec on provides detailed informa on about the Case Management Component in the following sec ons:
Defini on of Case Management Component terms

Saved / Deleted Cases and Clarifica ons of a session
Examples of genera ng Cases
Case Inquiry func on
A ributes of Cases
Case messages templates
Available standard contextual menus
Crea ng Clarifica ons
Messages when Order Session is submi ed for compliance check
System default values
Delivery of Formats
System parameters used by Case Management Component
Migra ng from Constraint Breach to Case Management Component
Defini on of Case Management Component terms

The following sec ons provide details of the terms related to the Case Management Component:
Violated Constraint
Case
Severity
Clarifica on
Violated Constraint
By Constraint, we understand structured ones (such as Alloca on Constraints or Security In) and unstructured (scripted such as Trading and Holding Constraints). An Objec ve Margin on Alloca on Strategy and Model Por olio is also considered
as a Constraint.
Each Constraint or Objec ve Margin can be linked to a severity (known as cri calness). This severity determines the ac ons that you must do regarding your Order Session.
A violated Constraint is a Constraint that is not respected (regarding the Orders proposal) during the Pre-Trade Compliance Check or Simula on processes (e.g., Allocate Order, Order Entry, and Reconcile Strategy func on).
The following points summarise how a Constraint is violated:
A Security In Constraint defines a minimum and/or maximum percentage or quan ty applied to a specific instrument or list of instruments. If the Order Session proposal does not reach a minimum or passes a
maximum, the Security In is violated.
Trading and Holding Constraints are scripted, which means that a script is evaluated and depending of its result, the script’s defini on is or is not respected. When the script’s evalua on is not compliant, Front
Office - PM considers it as a viola on.
From a func onal point of view, the Objec ve Margin viola on is effec ve when a margin is passed on an Alloca on Strategy or a Model Por olio. In other words, when a Market Segment’s weight (Alloca on) or an Instrument’s weight (part of a
Model Por olio) is under-weighted or over-weighted, Front Office - PM will consider that the objec ve is not reached.

Case
A Case is a record that is created when there is one violated Constraint. Every me a rule associated to a severity (different than <none>) is detected as violated by the system, a Case is created.
Cases are linked to an Order Session (generated via Allocate Order, Order Entry, or Reconcile Strategy).
There is a one-to-one rela onship between Constraints and Cases’ sub-natures; the following table shows how Cases and Constraints are linked:
Constraints Cases’ Natures Cases’ Sub-Natures
Alloca on Strategy Strategy Alloca on

(Margin objec ves)
Model Por olio Model Por olio

(Margin objec ves)
Alloca on Constraints Modelling Constraint Alloca on Constraint
Security In Security In
Holding Constraints Trading Holding Constraint Holding Constraint
Trading Constraints Trading Constraint
Severity
The constraint's severity lets the bank define the degree of importance that a Constraint must have regarding the compliance check process. The severity for the Case Management Component (CMC) is based on the Cri calness a ribute
(cri calness_e). This a ribute is available for:
Strategies: Alloca on, Model Por olio, and Constraint Set.

Constraints: Security In, Alloca on, Trading, and Holding.
Strategy Elements' objec ve margin: via Edit Strategy Objec ves and Edit Alloca on Constraints.
For Strategies and Alloca on Constraints, the severity set at the Strategy or Constraint levels are populated for all their Strategy Elements.
If a higher severity is set at the Strategy Element level, this higher severity is used to check the viola on of the Constraint.
Example with a Strategy defined with a Severity = Medium
Example (via Edit Strategy Objec ves screen)
In the following example, the Model Por olio has been defined with a Severity = Medium.
The Bank decides to consider the objec ve on the instruments T_AI_CHF_ALV and T_AI_CHF_BAER with a High severity. For other instruments, there is no par cular severity.
When this Model Por olio goes for compliance check:
The first two Strategy Elements containing instruments T_AI_CHF_ALV and T_AI_CHF_BAER are considered with a Severity = High.
All other Strategy Elements are considered with a Severity = Medium. If these Strategy Elements have a Severity = Not Cri cal or Low, they would have inherited the Strategy’s severity (Severity = Medium).
Impact of Severity's level on Save Session

The cri calness a ribute impacts the Save Session in the following ways:
Check against the SESSION_BLOCK_CRITICALNESS system parameter.

A Case’s severity will or will not permit the con nua on of the Save Session process.
If there is at least one Case that has a Severity equal or higher than this system parameter, there is no possibility to save the Order Session.
The Order Session must be enhanced, and submi ed once again to the Pre-Trade Compliance Check if the user wants to con nue the ordering process.
Check against the STRAT_BLOCKCONSTR_CRITICALNESS system parameter:
A Case's severity determines if a Case must be - or must not be - clarified before saving an Order session.
If there is at least one case that must be clarified, the Order session cannot be saved at this stage.
A jus fica on must be entered into the Clarifica on free text field, and the case’s status set to Clarified.
Clarifica on
A Clarifica on is a free text field that you fill in to explain or jus fy why you agree with the Case descrip on. By se ng a Clarifica on, you are able to con nue the ordering process. You can enter a Clarifica on for one, several or all Cases.
A Case is considered as clarified when there is at least one Clarifica on linked to it, and the Case’s status is set to Clarified. When Clarifica on(s) have been entered, and the Cases’ status updated to Clarified, the Save Session bu on becomes
ac vated.
Saved / Deleted Cases and Clarifica ons of a session

When you apply the Save Session, Front Office - PM saves Cases and their linked Clarifica ons.
Cases and Clarifica ons are linked to a session. As the Pre-Trade Compliance Check compares the por olio including orders against the objec ves, a viola on is not necessarily due to an individual order. For example, if the session contains three
buy stock orders, and this leads to an over-alloca on in the stock market segment, this viola on cannot be a ributed to a single order.
The only excep on to this rule is the Case that refers to a violated Trading Constraint. These types of Cases are duplicated and linked to orders.
For the dele on of an Order Session, the following rules apply:
If the session (i.e., func on result) is in status Final when it is deleted, the reference to the session in the related Cases is removed (set NULL), and the Cases with their Clarifica ons are kept.
If the session is in a lower status (i.e., Dra status, Checked status) when it is deleted, the related Cases are deleted with it because the orders have not gone to market and therefore, the Cases are not relevant.
Examples of genera ng Cases

The examples provided in the following sec ons demonstrate how the Case Management Component (CMC) is impacted using the following system parameters:
CMC is ac vated: the system parameter CASE_ACTIVATION_FLAG is set to 1. The "old" Constraint Breach treatment is unplugged.
The bank decides that Cases with a Severity = Medium must be clarified: the system parameter STRAT_BLOCKCONSTR_CRITICALNESS is set to 3.

The bank considers that if there is at least one case with a Severity = High, there is no possibility to save the Session (coming from Allocate Order, Order Entry, or Reconcile Strategy): the system parameter
SESSION_BLOCK_CRITICALNESS is set to 4.
Example 1: Cases with High severity block the Order Session

Users run a Strategy Reconcilia on, Order Entry, and Allocate Order on the same Por olio with the following orders’ characteris cs.
Order Session on Order Entry:
Order Session on Allocate Order:
Then, the error message “There is at least one Case with a severity that does not permit to save the Session” is displayed. From a func onal view, this means that there is at least one Case with a Severity = High (check against the
SESSION_BLOCK_CRITICALNESS system parameter). Therefore, the Save Session bu on is not ac vated.
Users review a Case Format for Strategy Reconcilia on (SYS_CMC_SR).
One of the orders that blocked the Save Session is the sell order on instrument T_AI_CHF_NESN (the same was entered into Allocate Order and Order Entry).
At this stage, users can decide whether to discon nue the order process or to modify their Order Session. If the decision is to modify the Order Session, the user does not confirm the Order on T_AI_CHF_NESN that blocked the Save Session into
Order Entry.
The confirm flag is set to No (0).
The User clicks Save Dra bu on and then, clicks the Compl. Check bu on to resubmit the modified Order Session. An error message “There is at least one Case that requires Clarifica on” is displayed.
Because the order T_AI_CHF_NESN was not confirmed, when checked, the Order Session no longer has a Case with Severity = High.
Example 2: Reconcile Strategy proposes orders that violate Trading Constraints with High severity
When Case Management Component (CMC) is ac vated, all orders that violate a Trading Constraint with a High severity are proposed into the Order Session. In this example, the following images show that there is one Trading Constraint that
was violated by an order. The user decides not confirm the order, saves the updated Session as a dra , and resubmits it to a compliance check via the Simula on bu on.

In this case, when the user ac vates the Simula on bu on, there is no new computa on of orders; only a check of ini al proposed orders.
Example 3: Clarifica on process and Order Session process

The Clarifica on process can only begin if there are no blocker Cases (e.g., all Case’s severity are lower than the value of the SESSION_BLOCK_CRITICALNESS system parameter).
The Order Session process can only be achieved when Case(s) with a severity at least equal to STRAT_BLOCKCONSTR_CRITICALNESS value are clarified.
The following examples are based on the assump on that the highest Case's severity is medium.
As the STRAT_BLOCKCONSTR_CRITICALNESS value is set to 3, the Order Session cannot be saved un l all Cases with a Medium severity:
are clarified, which means that a Clarifica on must be entered for these Cases (see Example A: Crea ng a Clarifica on for one, several, or all Cases below).
have their Status updated to Clarified (see Example B: Update Case Status below).
Example A: Crea ng a Clarifica on for one, several, or all Cases
1. From the Strategy Reconcilia on screen, you can right-click on one Case, and select Create Clarifica on. To create a Clarifica on for several Cases, you must select all desired Cases before right-clicking on the
highlighted selec on of the Cases. When crea ng one Case, the Code field represents the concatena on of Case’s code and an increment. When crea ng several Cases at the same me, the same code is
associated to all selected Cases, which is the concatena on of the [date-GEN-increment].
The Create Case Clarifica on screen is displayed.

2. You must enter text in the Reason field to explain the case. This free text field can store up to 2000 characters.
Click Save to save the informa on.

Example B: Update Case Status
In Example A, Clarifica ons were created for one or several Cases that had Severity = Medium. In this sec on (Example B), we demonstrate how to update one, several, or all the Cases’ status. Cases must be updated to Clarified status a er their
Clarifica ons are created.
1. From the Strategy Reconcilia on screen, you can right-click on one Case, and select Update Case Status in the context menu. To update the status of several Cases, you must select all desired Cases before right-
clicking on the highlighted selec on of the Cases to get the context menu displayed.
The status of all selected Cases is updated to Clarified (as shown in the Status column) and the Save Session bu on is enabled.
2. Click the Save Session bu on to save the Order Session.
At this stage, the Clarifica on process is completed and the ordering process can con nue.
Example C: Edi ng a Clarifica on
A er a Case has been clarified, the User can modify it, one case at a me.
1. From the Strategy Reconcilia on screen, right-click on one Case and select Modify Clarifica on.
The Modify Case Clarifica on screen is displayed.

2. In the Reason field, add addi onal text below the exis ng Clarifica on text to modify it.
Case Inquiry func on

The Case Inquiry func on, available through the menu item Audit, lets you retrieve Cases and their Clarifica ons that are stored in the database.
Using the Case Inquiry func on

A dedicated Domain with a mul -criteria entry lets you retrieve stored Cases.
1. From the menu bar, select Audit > Case Inquiry.

2. Complete the fields to define the criteria to narrow the search.
3. Click Apply, then click OK to retrieve the Cases and Clarifica ons that match the criteria.

The Case Inquiry Format screen is displayed.
4. (Op onal) To view the business context that generated the Case (originally saved Order Session), right-click on the desired Case to display the context menu, and select Load Session.
The following types of informa on are displayed in columns on the Case Inquiry Format screen:
Administra on columns (e.g., Case’s crea on date, the User who generated the financial func on that created the Case, the last User who managed the Clarifica on, and the number of Clarifica ons that are
linked to the Case).
The main a ributes columns of the Case (e.g., Severity, Status (clarified or not clarified), Sub-nature, Por olio). When saving the Order Session, all Cases are saved, including the ones that have not been
clarified.
The Case’s Descrip on and its Last Clarifica on columns. The Last Clarifica on column shows only the latest clarifica on for audit purpose. Previous ones are stored in the database.
Depending of STRAT_BLOCKCONSTR_CRITICALNESS value, only Cases with a Medium severity must be clarified. In the Use Case context, cases with severity Not Cri cal or Low are not clarified.
Cases and Clarifica ons on Trading Constraints are duplicated

A Format is delivered in the Front Office - PM standard packaging that only concerns Cases (and their Clarifica on) on Trading Constraints.
Order Session can be deleted so, from a technical point of view, as Cases are linked to an Order Session, Cases can be deleted. Therefore, Cases related to Trading Constraints are duplicated and saved accordingly.
For general informa on about Formats, refer to the WealthSuite Front Office - Por olio Management - User Guide.
A ributes of Cases
When a Constraint is violated, a Case is created. A Case is defined by several a ributes. These a ributes are mainly func onal such as:
Crea on Date
Last Modifica on Date
Cri calness
Nature
Sub-nature
Type
Por olio
Descrip on
Status
User
Last Modif. User
Instrument is also part of the Case’s descrip on when a Trading Constraint is violated.
While other a ributes are technical such as:
Iden fier (id)

Code
Main En ty
Main Object
Session id.
For more informa on, refer to the WealthSuite Front Office - Por olio Management - Data Model Reference Guide for a list of the table’s a ributes.
Case messages templates

Cases are generated with messages for every violated constraint to provide informa on or warnings to users. These messages are based on Case message templates that are managed via the Case Message Template facility.
By default, all Case message templates have Priority = 10 (see sec on System default values).
Case Message templates must be implemented. Those included in the standard packaging are:
Case
nature
Template code Message
Case sub-
nature
SYS_CMC_ALLOC_DEF Strategy The objec ve [objec ve weight] +/- [objec ve margin] is

violated: effec ve weight: [effec ve weight].
Alloca on
SYS_CMC_AC_DEF Modelling If a maximum weight or maximum amount is

violated, the message is “The maximum
Alloca on [weight or amount] for [Market Segment] is
Constraint violated; effec ve weight: [effec ve weight].”
If a minimum weight or minimum amount
violated, the message is “The minimum
[weight or amount] for [Market Segment] is
violated; effec ve weight: [effec ve weight].”
If an interval is not respected in terms of
weight or amount, the message is “The
interval [min weight – max weight or min
amount – max amount] for [Market Segment]
is violated; effec ve weight: [effec ve
weight].”
SYS_CMC_HC_DEF Trading The constraint [code] [denomina on] has been violated.
Holding
Constraint
Holding
Constraint
SYS_CMC_MP_DEF Strategy The objec ve [objec ve weight] +/- [objec ve margin] for
[instrument] is violated; effec ve weight: [effec ve
Model weight].
Por olio

Case
nature
Template code Message
Case sub-
nature
SYS_CMC_SI_DEF Modelling If a maximum weight or maximum amount is

violated, the message is “The maximum
Security [percentage or quan ty] of [Instrument] is
In violated; effec ve weight: [effec ve weight].”
If a minimum weight or minimum amount
violated, the messages is “The minimum
[percentage or quan ty] of [Instrument] is
If an interval is not respected in terms of
weight or quan ty, the message is “The
interval [min percentage – max percentage or
min quan ty – max quan ty] of [Instrument] is
SYS_CMC_TC_DEF Trading The order [buy or sell] [quan ty] [instrument] violates the
Holding constraint [code] – [constraint’s denomina on].
Constraint
Trading
Constraint
SYS_CMC_DEFAULT Default A Case has been generated.
Default
In the following sec ons, you will learn about:
Crea ng and managing templates of Case messages

Selec ng the best Case messages to display
Crea ng and managing templates of Case messages

1. From the GUI menu bar, go to Administra on > Configura on > Case Msg Template.
The Find Select Case Msg Template screen is displayed.

2. To create a Case message template, click Create. At this step, you also have the op on to view, copy, modify, or delete exis ng templates.
The Create Case Msg Template screen is displayed.

3. Complete the fields to create the Case message template, especially the mandatory fields in red.
Code field must be completed.
Denomina on field can be used to provide a name to the template.
Case Nature and Case Sub Nature fields must be completed.
Type field can be completed (previously defined into Infrastructure).
Priority field can be completed to define priority level.
Main En ty field must be completed.
Default Language field must be completed.
Note: By default, Temenos delivers Case Message Templates with SYS_CMC_* codes. These default templates have Priority = 10 and are available
in English, French, and German.
4. Click Save to save the data.
The Defini on bu on is enabled.

5. Click Defini on.
The Select Case Msg Template Case Defini on screen is displayed.

6. Click Create.
The Create Case Msg Template Defini on screen is displayed.

7. (Op onal) The default language is displayed in the Language field. You can choose to create the message in a different language by selec ng the language from the drop-down list.
8. Click Save.
The Defini on screen is displayed.

9. Type the Case’s message in the free-text zone, which can contain up to 2000 characters.
10. Click Save to save the message.
Selec ng the best Case messages to display

By defining Case message templates with a Nature, Sub-Nature, Type, and Priority and a language, the system will determine the best message to display. The system first sorts Case message templates by Nature, Sub-Nature, and Type, and then
applies the following matrix rule:
Nature Sub-Nature Type
1 (higher) ü ü ü
2 ü ü û
3 ü û ü
4 ü û û
5 (lower) û û û
ü means the field exists at the Case level and Case message template.
û means the field is not part of a Case’s defini on and/or Case message template.

When found, if there are at least two Case message templates that match the same matrix criterion, the system applies the Priority and then, the language.
Available standard contextual menus

The following func ons are delivered as standard contextual menus and can be accessed using the right-click facili es:
Crea ng or modifying Clarifica on func ons

Upda ng Status of a Case
Crea ng or modifying Clarifica on func ons

When a Case is displayed in a Format, you can use the right-click facility to:
Create a Clarifica on using the Create Clarifica on func on. For more informa on, refer to sec on Crea ng Clarifica ons.
Modify an exis ng Clarifica on using the Edit Clarifica on func on.
You cannot create or modify Clarifica ons from the Case Inquiry func on.
Upda ng Status of a Case

A er you clarified a Case, its status can be updated from “Not Clarified” to “Clarified” by one of the following methods:
Ac va ng automa c update of Case Status func on

Ac va ng manual update of Case Status func on
It is the client’s decision to determine which method is implemented onsite. Each method has advantages and disadvantages that are summarised in the table below:
Method Advantages Disadvantages
Automa c There is no need for the user This method is not provided in the standard
update to manually change the Case packaging and must be implemented on the client's
Status. A er the Case is site, using scripts on input control and format
clarified by a user, the Case element. With the automa c update method, the
Status is automa cally user is not permi ed to manually control the Case
updated. Status.
Manual The user has control over The user must clarify the Case in two steps (rather
update the Case Status and can than in one step):
decide when to update it
a er a clarifica on is given. Create a clarifica on.
Update the Case Status.
Ac va ng automa c update of Case Status func on

The automa c update method automa cally updates the Case Status from “Not Clarified” to “Clarified” a er the Case is clarified by the user. No manual process is required.
To ac vate the automa c update method:
1. From the toolbar, go to Administra on > Configura on > Script > Input Control.
The Input Control screen is displayed.

2. On the Input Control screen:
In the En ty field, select case_clarifica on.
In the Nature field, select User GUI Control Value.
In the Script field, insert the following code:
IF(reason_c <> NULL,AUTOCREATE( GET_ENTITY("case_management"), INSERT_UPDATE, &code := case_id.code, &status_e := 1))
Note: For more informa on about crea ng an input control, refer to the WealthSuite Front Office - Por olio Management - Script Language
Reference Guide.
3. Click Save.
4. Modify the format element used to display the Case's Status as follows:
a. From the main menu, go to Administra on > Configura on > Format. The Select Format screen is displayed.
b. Select the format that contains the element that is used to display the Case's status a er the execu on of a financial func on (e.g., formats like SYS_CMC_OE, SYS_CMC_SR and SYS_CMC_AO), and click
Modify. The Modify Format screen is displayed.
Tip: If you cannot find your format from the list displayed, you can search for it by entering the first few characters of the format’s code in
the blank field below the list. Then, press Tab on your keyboard, and the list is refreshed.
c. Click Format Element. The Select Format Element screen is displayed.
d. Select the relevant format element to modify, and click Modify. The Modify Format Element screen is displayed.

e. In the A ribute field, delete the default value (usually “status_e”).
f. In the Edit field, ensure that the checkbox is not checked (which removes the possibility for the user to manually edit the value).
g. Click Defini on. The Defini on screen is displayed.
h. Enter the script (as shown in the image above) to get the value directly from the database rather than from memory.
i. Click Save, then click OK to exit the screen.
j. On the Modify Format Element screen, click Save, then click OK to exit the screen.
k. On the Modify Format screen, click Save, then click OK to exit the screen.
Ac va ng manual update of Case Status func on

With the manual update method, the user has control of the Case Status and can decide when to update it a er a clarifica on. When one, several, or all Cases have been clarified, users can use the right-click facility to update the Status of the
cases from “Not Clarified” to “Clarified”.
To be able to use this func on, it must be part of the user’s Func on Security Profiles, which is delivered by default in the Func on Security Profile PCK_PM_FUNC_SEC_PROF.
The right to update a Case is based on the following condi ons:

If a
Clarifica on
exists, then
the Case’s
status can
be
updated.
The update
of Case’s
status is an
incremental
one: +1.
Crea ng Clarifica ons

When Cases are generated, users can clarify them by using the Create Clarifica on func on. A Clarifica on can be created for:
one case (see sec on Crea ng a Clarifica on for one Case)

several or all Cases (see sec on Crea ng a Clarifica on for several or all Cases)
Crea ng a Clarifica on for one Case

1. From a Format based on Cases, click on one Case to select it.
2. Right-click on the selected Case, and choose the Create Clarifica on func on.
The Create Case Clarifica on screen is displayed with the Clarifica on’s Code field and Case Management field automa cally completed.
The Clarifica on’s code is the concatena on of Case’s code and an increment.
3. You must complete the Reason field. (This is a mandatory field.)
4. (Op onal) If you want to associate a Type to the Clarifica on, the Type field must be completed by selec ng an op on from the drop-down list.
5. Click Save.
6. To view (only) details of the Case, right-click on the Case’s code.
Crea ng a Clarifica on for several or all Cases

1. From a Format based on Cases, click on several or all Cases to select them.
2. Right-click on the selected Cases, and choose the Create Clarifica on func on.
The Clarifica on screen is displayed. As there are at least two selected Cases, the individual Case codes are not displayed. Instead, the
same Clarifica on code will be associated to all selected Cases, which is the concatena on of the [date-GEN-increment].
3. You must complete the Reason field. (This is a mandatory field.)
4. (Op onal) If you want to associate a Type to the Clarifica on, the Type field must be completed by selec ng an op on from the drop-down list.
5. Click Save.
Messages when Order Session is submi ed for compliance check

The following system messages are generated when the Order Session (from Allocate Order, Reconcile Strategy, and Order Entry) is submi ed to Pre-Trade Compliance Check.
Messages Descrip on
“There is at least one This message appears when there is at least one case with a severity
Case with a severity equal to the value of SESSION_BLOCK_CRITICALNESS system
that does not permit to parameter. The current session of the user cannot be saved because
save the Session.” of this blocker.

Messages Descrip on
“There is at least one This message appears when there is at least one case with a severity
Case that requires equal or higher than the value of
Clarifica on.” STRAT_BLOCKCONSTR_CRITICALNESS system parameter. The
user must clarify the case(s) before proceeding to next step.
System default values

When a Constraint is violated (i.e., its severity is different than <none>), a Case is created. By default, the descrip on of the Case is computed using the Case message template with Priority = 10.
A ribute En ty System default value
descrip on_c case_management CASE_MSG(,,10,10)
Delivery of Formats
In the standard delivery, the following formats are delivered:
Formats for produc vity func ons

Formats for Case Inquiry func on
The Case Management Component only runs when there is a Format defined for the func on that the user wants to use.
Formats for produc vity func ons

All Formats for the produc vity func ons (e.g., Allocate Order, Order Entry, and Reconcile Strategy) have the same structure (code like SYS_*). The Format elements are Severity, Status, Sub-Nature, Por olio, and Descrip on and these are sorted
by Severity, Por olio, and Sub-Nature.
Formats that are delivered in the standard packaging:
Func on Code
Allocate Order SYS_CMC_AO
Order Entry SYS_CMC_OE
Reconcile Strategy SYS_CMC_SR
Formats for Case Inquiry func on

In the standard delivery, the Formats for Case Inquiry are (1) one for all Cases, and (2) a second one for duplicated cases on Orders that violates a Trading Constraint.
Formats that are delivered:
Func on Code
Case Inquiry SYS_CMC_CI
SYS_CMC_DupCases
System parameters used by Case Management Component

The following system parameters are used to manage the Case Management Component (CMC):
CASE_ACTIVATION_FLAG
SESSION_BLOCK_CRITICALNESS
STRAT_BLOCKCONSTR_CRITICALNESS
CASE_ACTIVATION_FLAG
The CASE_ACTIVATION_FLAG parameter permits – or not – to ac vate the CMC.
0: not ac vated
1: To ac vate the CMC, the bank must set this system parameter to 1.
SESSION_BLOCK_CRITICALNESS
The SESSION_BLOCK_CRITICALNESS parameter defines the minimum level of the case’s severity that does not permit to save a Session.
0: <none>
1: Not Cri cal
2: Low
3: Medium
4: High (default): If there is at least one case with a High severity, the order session cannot be saved.
5+: No case severity is considered as blocker. If the Bank does not want to block Order Session with any case’s severity, the system parameter must be set to value 5 or higher.
STRAT_BLOCKCONSTR_CRITICALNESS
Defines the minimum level of case’s severity that requires a clarifica on.
0: <none>
1: Not Cri cal
2: Low
3: Medium
4: High
With the STRAT_BLOCKCONSTR_CRITICALNESS parameter, during the Pre-Trade Compliance Check, its value is compared to the value of the severity (cri calness_e) of a violated constraint. The following table summarises this interac on:

Constraint Breach Case Management
Constraint Security In, Trading or Holding. Security In, Trading or Holding and
applica on’s Objec ves' margin devia on for
area Alloca on Strategy and Alloca on
Constraints.
Order’s An order that violates a constraint with a A Case that is created with a
confirm flag severity equal or higher than this system severity equal or higher than this
(confirm_f) parameter's value is, by default, not system parameter's value must be
confirmed (confirm_f = 0). clarified.
An order that violates a constraint with a All orders, even those which
severity level higher than this system violate constraints, are displayed.
parameter’s value cannot be confirmed.
Severity
The cri calness a ribute set for constraints is fully reused for the Case Management Component (CMC); it has been extended to Strategies (Asset Alloca on and Model Por olio) and objec ve’s margin strategy elements. Security Out constraints
are not supported in CMC.
Migra ng from Constraint Breach to Case Management Component

The following sec ons describe considera ons for migra ng from Constraint Breach to the Case Management Component:
Database
System parameters
Front Office - PM func ons to run CMC
Items included in the standard packaging
Case Management Component objects
Default implementa on
Database
If you are migra ng from a release prior to Release 4.40, constraint_breach table records are automa cally copied into the case_management table. The constraint_breach table is truncated from database and remains only as a view over the
Case Management Component (CMC).
System parameters
For Release 4.40 and earlier:
Applica on parameters have equivalent behaviour to Constraint Breach in Release 4.30:

CASE_ACTIVATION_FLAG = 0 (Case Management Component is disabled)
SESSION_BLOCK_CRITICALNESS = not applicable because Case Management Component is disabled
STRAT_BLOCKCONSTR_CRITICALNESS=Keep same value as in Release 4.30
ORDER_CONFIRMEDFLAG_MGMT=1
For Release 4.40 and onward:
If CASE_ACTIVATION_FLAG = 0 and if ORDER_CONFIRMEDFLAG_MGMT=0: the confirm_f in the order stays True (1) whatever the severity of the Constraint Breach. The orders are no longer rejected.
If CASE_ACTIVATION_FLAG = 0 and if ORDER_CONFIRMEDFLAG_MGMT=1: the confirm_f in the order is set to False (0) if the severity of the Constraint Breach is higher or equal to the severity set in
STRAT_BLOCKCONSTR_CRITICALNESS. The orders with confirm_f set to False are not published.
Front Office - PM func ons to run CMC

Certain Front Office - PM func ons are necessary to run the Case Management Component (CMC), and are extensively described in the WealthSuite Front Office - Por olio Management - Orders and Produc vity User Guide.
The user’s Func on Security Profile must contain the two following func ons:
Update Case Status - Permits (via right-click) upda ng the case’s status from “not clarified” to “clarified”. When required, a clarifica on is mandatory to save a session.
Case Inquiry - Enables the user to retrieve all cases and their clarifica ons.
Items included in the standard packaging
Case message templates

For informa on about what is delivered in the standard packaging, see sec on Case messages templates.
Formats
Exis ng Formats on constraint_breach can be used in Release 4.40, but they are only a view on the case_management table. To be able to use the Case Management Component (CMC) features, the bank must implement Formats based on the
case_management en ty.
For informa on about what is delivered in the standard packaging, see sec on Delivery of Formats.
Case Management Component objects

Script keywords
CASE_MSG()
CASE_LINKED_OBJECT
CURRENT_CASE()
Database tables
Case Clarifica on (case_clarifica on)
Clarifica on is the en ty that permits users to fill in a free-text zone and explain (or jus fy) why they agree with the Case descrip on. Se ng a
Case Clarifica on also allows the ordering process to con nue.
Case Link (case_link): Technical table that permits linking one or many en es to a Case.
Case Management (case_management): When a Constraint (e.g., Strategy, Modelling constraint, Trading Constraint) is violated, a Case is created.
Case Message Template (case_msg_template): Permits messages to be defined to be used by the Case Management Component.
Case Message Template Defini on (case_msg_template_def): Permits the storing of Case Message Template's defini on.
Default implementa on
System parameters
CASE_ACTIVATION_FLAG=0
SESSION_BLOCK_CRITICALNESS=4
STRAT_BLOCKCONSTR_CRITICALNESS=3
Security profiles
The Func ons Security Profile PCK_PM_FUNC_SEC_PROF contains the func ons related to the Case Management Component (CMC) - Update case status and Case Inquiry.
The Format Profile PCK_PM_FMT_PROF contains all formats related to CMC.

Risk compliance
Risk compliance aggregates two services:
Check Risk service links objec ves and current values of risk indicators to calculate the compliance, and stores the result in the Risk Strategy Element structure.
Risk Value service calls an external risk tool and stores the answer (i.e., risk indicator values) in the Risk Value structure.
The image below describes the integra on of risk compliance in our solu on:
Note: Only formats and screens, which are designated for display in the WUI, are delivered in the standard packaging.
In this sec on, the following topics are covered in detail:
Risk Strategy structure

Risk Value structure
Risk indicators
Check Risk service
Risk Value service
Risk evalua on on Investment Profile strategy
Implementa on
Risk Strategy structure

The Risk Strategy structure is an extension of the Extended Strategy Element already computed by the Check Strategy func on or the Pre-Trade Compliance Check (PTCC) func on. This structure aims to analyse the compliance of the risk (i.e.,
analysis of objec ve and actual value of a set of risk indicators (see sec on Risk indicators)).
A Risk Strategy Element is linked to one Extended Strategy Element; for each Risk Strategy Element, the compliance of risk indicators is computed. Only composi ons with at least one objec ve, or the actual value set, are kept. The comple on of
this en ty is managed by default values, which are executed before applying the format defined for this en ty. Standard default values are delivered. It includes the risk compliance calcula on at the por olio level, and the ability to store the
value of risk indicators for several levels: por olio, market segment, and instrument.
Risk objec ves

Risk objec ves can be defined in a strategy with nature "risk strategy" or, in compliance chrono, as "indicator" compliance nature. In the standard packaging, objec ves of indicators that are expressed as a % or a number are retrieved in the
strategy, and the objec ves of indicators that are expressed as an amount are retrieved in compliance chrono.
Note that for objec ves of indicators that are expressed as a %, this % is shown as a number (e.g., 0.17 for 17%).
Objec ves are retrieved by the script keyword GET_RISK_OBJECTIVE. For more informa on, refer to the WealthSuite Front Office - Por olio Management - Script Language Reference Guide.
Risk strategy
Only one risk strategy is used. This strategy can be directly linked to the por olio or integrated into an investment profile. Alterna vely, the risk strategy can also be indirectly linked by a por olio list.
If several risk strategies are linked to a por olio, the following rule is applied in order to choose only one:
A direct link is chosen before an indirect link.

Where there are several risk strategies within the same linked object type (direct or indirect), the selec on is done first on the more recent (begin date) and a er, on the priority.
When objec ves are retrieved in a risk strategy, the severity of each indicator can be replaced by the severity of the strategy, if this one is the highest.
Actual value of risk indicators

Actual value of risk indicators are retrieved in the Risk Value structure (see sec on Risk Value structure).
Risk compliance calcula on

Risk compliance is defined by default values. The standard packaging follows the same compliance rules as objec ves Compliance and Constraint Compliance and integrates the Case Management Component.
Risk compliance values defined in the standard packaging are:
0 - No risk objec ve defined.

1 - No risk actual value - Objec ve not evaluated.
2 - Risk compliant.
3 - Not Risk compliant with a low severity.
4 - Not Risk compliant with a medium severity.
5 - Not Risk compliant with a high severity.
6 - Not Risk compliant without Case Management Component ac vated.
In the standard packaging, the compliance calcula on is done on minimum objec ves, if they are defined; otherwise on objec ves, but not on maximum objec ves.
Risk Value structure

The Risk Value structure holds risk values. Risk values can be calculated by a risk external tool called by the Risk Value service (see sec on Risk Value service) or can also be imported.

The Risk Value structure is adapted to the Extended Strategy Element; data can be stored at the por olio, market segment, or posi on level. For each level, a set of risk indicators can be stored. Two en es make up this structure:
risk_value_element and risk_value_element_compo.
The Risk Value service needs an external service defini on. For more informa on about external services, refer to the WealthSuite Front Office - Por olio Management - User Guide. Using specific screens defined in the external service,
risk_value_element and risk_value_element_compo are generated.
When the Check Risk service is launched (see sec on Check Risk service), risk values are retrieved by the script keyword GET_RISK_VALUE (for more informa on, refer to the WealthSuite Front Office - Por olio Management - Script Language
Reference Guide). Note that risk values mean risk measure and risk contribu on.
Risk indicators
Risk indicators are managed by the compliance chrono en ty and nature a ribute. This a ribute has an enum datatype and new values can be added by customisa on.
List of risk indicators delivered in our solu on:
Defini on Descrip on
Vola lity A financial risk measure that measures the varia on of a financial value over
me.
Vola lity is measured via the standard varia on and is applicable to the price of
instrument, market value, or return of por olio or asset classes.
VaR A financial risk measure applicable for por olio management.
VaR is the threshold defining the maximum loss for a por olio or an asset class
for a me horizon and a given probability.
The probabili es retained are generally 90% (10%), 95% (5%), and 99% (1%). For
example, a 3% month VaR at 95% defines that there is more than a 95% chance
that the loss for the next month does not exceed 3%.
Expected A financial risk measure applicable for por olio management; it is o en used as
Shor all an alterna ve measure to the VaR.
Expected Shor all provides the expected return of the por olio in the worst %
of cases.
Synonym: Condi onal Value at Risk (CVAR), Average Value at Risk (AVaR),
Expected Tail Loss.
Tracking Error A financial risk measure to provide a comparison between a benchmark and a
por olio.
Tracking Error is measured as the standard devia on of the gap between a

por olio and a benchmark/index return.
Marginal VaR Addi onal amount of risk generated by a posi on in a por olio.
Marginal VaR is o en defined as the difference of the VaR of a por olio with
and without a posi on.
Diversifica on A measure of the effect of the por olio or asset class diversifica on on the risk
Effect exposure measure through the VaR.
Shor all A risk measure that provides the probability that the return of a por olio falls
Probability below a threshold.
Risk Grade A calibrated risk measure about an asset based on a standardised measure of
the vola lity, including all components of the market risk such as equity, interest
rate, currency, and commodity risk.
Marginal The contribu on to the VaR of a posi on (instrument or asset class/market

CVaR segment) in a por olio.
Marginal CVaR is o en defined as the difference in the VaR of a por olio with
and without a posi on.
Synonym: Marginal Expected Shor all
Entropic A financial risk measure applicable for por olio management; it is o en used as
Value At Risk an alterna ve measure to the VaR.
(EVaR)
Entropic Value At Risk (EVaR) includes the risk aversion of the client through the
exponen al u lity func on.
Marginal Same principle as Entropic Value at Risk (EVaR) above.

EVaR
Marginal The contribu on of a posi on to the vola lity of a por olio.

Vola lity
Synonym: systema c contribu on to vola lity
Marginal The marginal contribu on of a posi on to the tracking error of a por olio.
Tracking Error
O en defined as the difference of the tracking error with and without the
posi on.
Tail Value at Quan fies the expected value of the loss given that an event outside a given
Risk (TVaR) probability level has occurred.
Synonym: Tail Condi onal Expecta on (TCE), Condi onal Tail Expecta on (CTE)
Marginal Same principle as marginal VaR descrip on above.

TVaR

Defini on Descrip on
Beta Same principle as marginal VaR descrip on above.
Super The price for hedging a por olio. It defines the greatest value that can be paid
Hedging Price so that in any possible situa on for a specified future me, you have a second
por olio worth less or equal to the ini al one.
Informa on Measures the ac ve return of an investment manager divided by the amount of

Ra o risk the manager takes rela ve to a benchmark.
Sharpe Ra o Excess return for a por olio vs a risk-free return.
Treynor Ra o A measurement of the returns earned in excess of that which could have been
earned on a riskless investment (per each unit of market risk assumed).
Jensen's Jensen's alpha (or Jensen's Performance Index, ex-post alpha) is used to
Alpha determine the excess return of a por olio of securi es over the benchmark
theore cal expected return.
Expected Measurement of the profit or loss an investor an cipates on an investment that

Return has known or expected rates of return.
Risk Level Risk indicator that is available to manage a risk level on por olio, instrument,
and Investment Profile.
In the standard packaging, the por olio risk level is calculated by weighted
average on held instruments.
Product Risk Measurement for single instruments, which does not consider por olio aspects.
Classifica on The PRC is a risk indicator that allows investors to compare the financial risk of
investment products of different kinds and asset classes. The three relevant risk
factors – market risk, credit risk, and liquidity risk – are all incorporated into the
PRC.
Check Risk service

Check Risk service is a part of the Check Strategy and Pre-Trade Compliance Check (PTCC) func ons. This service is triggered when the domain a ribute "computa on mode" is ac vated (see sec on regarding Check Strategy in the WealthSuite
Front Office - Por olio Management - Orders and Produc vity User Guide). This service generates the Risk Strategy structure (risk_strategy_element and risk_strategy_element_compo). For more informa on about Risk Strategy structure, see
sec on Risk Strategy structure.
The goal of Check Risk service is the risk compliance calcula on. The main steps to realise this calcula on are:
Search objec ves linked to the por olio. The objec ves can be defined in a risk strategy or in compliance chrono (see sec on Risk objec ves).
Search risk indicator values stored in the Risk Value structure. This structure is managed by the Risk Value service (see sec on Risk Value service) and can also be built using import files.
Calculate the risk compliance (see sec on Risk compliance calcula on).
Store the result in the Risk Strategy structure. Result means objec ves, risk values, and risk compliance.
Risk Value service

Risk Value service is a part of Check Strategy and Pre-Trade Compliance Check (PTCC) func ons. This service is triggered when the domain a ribute "computa on mode" is set to “online”, “pre computed”, or “force update” (see sec on regarding
the Check Strategy func on in the WealthSuite Front Office - Por olio Management - Orders and Produc vity User Guide). This service generates the Risk Value structure (risk_value_element and risk_value_element_compo) by integra ng the
result of the risk calcula on from an external tool. For more informa on about Risk Value structure, see sec on Risk Value structure.
The goal of Risk Value service is the risk calcula on. The main steps to realise this calcula on are:
Build a request to call an external risk tool. The request is based on extended strategy element en ty, and the request builds a specific structure adapted to an external tool (structure defined as an extended
en ty). The link between source and target en es is managed in the external service using a screen (for more informa on about external services, refer to the WealthSuite Front Office - Por olio Management
- User Guide).
Call the external risk service. This service is defined in the external service (for more informa on about external services, refer to the WealthSuite Front Office - Por olio Management - User Guide).
Retrieve the response to build the Risk Value Structure. The response is based on a specific structure adapted to an external tool (structure defined as an extended en ty), and the response builds risk value
en es. The link between source and target en es is managed in the external service using a screen (for more informa on about external services, refer to the WealthSuite Front Office - Por olio Management
- User Guide).
Note that informa on is added into the server log to indicate converted item number of the request and responses, as well as saved item number in risk value.
Pre-Trade Compliance Check

When the service is included in the Pre-Trade Compliance Check (PTCC) func on, then risk services are called twice:
A first call is launched without orders; only with exis ng posi ons. This call is done with the computa on mode of the domain and depending on its value, the Risk Value service may or may not be launched.
A second call is always launched in online mode and this call always includes orders. The result of the second call is never stored in Risk Value en es; it only stays in memory during PTCC execu on.
Unlike cases on objec ves and constraints, cases based on risk compliance are managed by a Case Rule. For more informa on about Case Rule, see sec on Case Rule as well as the WealthSuite Front Office - Por olio Management - User Guide. An
example of Case Rule is delivered in the standard packaging.
Risk evalua on on Investment Profile strategy

Risk can be evaluated on an Investment Profile in the same way as a por olio. However, unlike por olios, the instrument quan ty is replaced by the instrument weight and these instruments are defined by Model Por olios. Therefore, an
expected Investment Profile defini on is to have a linked Model Por olio on each market segment with a defined weight on the main Asset Alloca on.
This risk evalua on on an Investment Profile is done by the View Por olio Objec ve func on.
If this func on is launched on a por olio, the deriva on can be applied so that the result has to be stored in Risk Value Element en es on both iden fiers: por olio with its Investment Profile.
If this func on is launched directly on an Investment Profile, the result has to be stored in Risk Value Element en es on iden fier Investment Profile only.
Implementa on
An example of implementa on is delivered in the standard packaging with a Risk Simulator tool. It is helpful to understand how to add real risk tools.
Note that the risk provider EdgeLab has a real implementa on available.
Objec ves defini on

Objec ves can be defined in risk strategy or compliance chrono.
In the standard packaging, risk indicators expressed as either a percentage or number are defined in a risk strategy. Risk indicators expressed as an amount are defined in a risk compliance chrono (see sec on Risk objec ves).
Risk Rule

When using the standard packaging, at least one rule must be defined, with at least a composi on with rank = 1 and a type = PCK_GL_RULE_DEFAULT.
In the standard packaging, the default values on ris_strategy_elt_compo en es as well as the WUI screen on domain are based on the following values:
By se ng a Risk Rule in the domain, when the Risk Strategy structure is built, the search of risk value (GET_RISK_VALUE keyword) is based on the level of confidence and me horizon of the domain Risk Rule
with rank = 1 and a type = PCK_GL_RULE_DEFAULT.
By se ng a Risk Rule in the domain, when the external service request is built, it is based on the level of confidence and me horizon of the domain Risk Rule with rank = 1 and a type = PCK_GL_RULE_DEFAULT.
Same values of level of confidence and me horizon are included in the generated Risk Value structure.
The risk module is enhanced to call mul ple external services that can calculate different risk indicator values with different se ngs (confidence level and me horizon).
For more informa on about Risk Rule, refer to the WealthSuite Front Office - Por olio Management - User Guide.
Case Rule
A system Case Rule “SYS_RISK_CASE_RULE", which is included in the standard packaging, creates cases for risk indicators that are not compliant (see sec on Risk compliance calcula on).
This rule can be deac vated and specific rules can be added. For more informa on about Case Rule, refer to the WealthSuite Front Office - Por olio Management - User Guide.
External risk tool

To establish a dialogue between Front Office - PM and an external risk tool, informa on such as technical defini on and por olio posi ons is needed.
En es linked to external risk tools

To calculate risk indicator values, por olio posi ons are requested by risk tools but each risk tool needs different data and returns different data.
At least two en es are defined as extended en es:
One en ty to define the request; this en ty is filled with extended_strategy_element data. Our example in the standard delivery is pck_risk_sim_request.
One en ty to define the response; the risk value en es are filled with data from this en ty. In the standard delivered, example of the response is split into two en es in order to easily manage a variable risk
indicator number: pck_risk_sim_response and pck_risk_sim_response_compo
The pck_risk_sim_response is defined with the same a ributes as the pck_ds_sim_request
The pck_risk_sim_response_compo is linked to the previous one and gives a value for one risk indicator. Several rows can be linked to the same pck_ris_sim_response as long as risk indicators are
managed.
External service
The external service to use is specified by the External Service Profile. The external service defines the URL and port number to access the risk tools.
The external service composi on defines which en es are involved to build the dialog.
Request defini on
The source en ty is always the en ty for ext_strategy_element.
The target en ty is the defined en ty for the request.
A screen based on target en ty lets you define with a default value, the way to build each a ribute (i.e., from which a ribute of ext_strategy_element).
A filter lets you reduce the number of ext_strategy_element used by selec ng, for example, only posi ons and por olio levels so that all other levels like market segments can be excluded.
Response defini on with a low rank
The source en ty is always the en ty for the response.
The target en ty is the defined risk_value_element.
A screen based on target en ty lets you define with a default value, the way to build each a ribute (i.e., from which a ribute of response).
Response defini on with a higher rank (only if the response is split into two en es)
The source en ty is always the en ty for response_compo.
The target en ty is the defined risk_value_element_compo.
A screen based on target en ty lets you define with a default value, the way to build each a ribute (i.e., from which a ribute of response compo). Note that to easily compose the link between
risk_value_element and risk_value_element_compo, use a specific a ribute defined in the request such as the "code" a ribute in our example with the risk simulator.
The risk indicator is described as a nature; its permi ed values are defined in the nature_e of compliance_chrono en ty.
ServiceAdapter - Java web applica on

ServiceAdapter is a mechanism provided to allow interac ons from Front Office - PM financial servers to external data or compu ng provider. This mechanism is needed for each risk tool and is based on request and response en es therefore,
the en es must be described in order to be known in Java. In the standard packaging, this descrip on is done with Design Studio tools by impor ng the Front Office - PM meta-dic onary and crea ng a specific dataset on each en ty.
A simulator is available in Front Office - PM Web implemented via the ServiceAdapter. You can get it at /remo ng/public/serviceAdapter/RiskSim/execute.
For more informa on about ServiceAdapter, refer to the WealthSuite Front Office - Por olio Management Web - ServiceAdapter Customisa on Guide.
Lombard compliance check

Lombard compliance check allows the integra on of a third-party system for the control of margin lending rules during the Pre-Trade Compliance Check func on within Front Office - PM.
The pre-packaged service is designed for the interac on with Core Banking, the Temenos back-office system standard so ware. With customisa on, interac ons with other systems are possible.
The services is based on the valuated posi ons of a por olio a er orders, which are read from the Front Office - PM structure ext_strategy_element. These posi ons are sent to the external system, which calculates the margin values at the
posi on level, and a Lombard compliance result at the por olio level. The result at the por olio level also contains an indicator, if the Lombard compliance check was successful (i.e., the collateral is sufficient) or had failed (i.e., there is a collateral
shor all).
The result of the Lombard compliance check is integrated within the Pre-Trade Compliance Check func on and is displayed to the user together with the check results for input controls, strategies, and constraints.
If a user can proceed with an order session, the Case Management Component can be used to determine which session will have problems containing the Lombard compliance result (error or possibility to release the session for trading a er
entering a clarifica on).
Limita ons
The Lombard compliance check is only executed for single order entries and for order sessions with mul ple orders on the same por olio. This is to avoid technical problems due to long response mes for the
external service.
For sell orders on securi es, no Lombard compliance check is executed because in this case, the Lombard value of the por olio cannot decrease.
The structure of the result set from the external system must be limited to one line per instrument / por olio, plus one line at the por olio level, for each por olio. Posi ons in the same instrument and
por olio, which are split between several deposits or sub-posi ons, must be consolidated by the external tool before sending the reply back to Front Office - PM.
The check of the Lombard values can only be executed within the Pre-Trade Compliance Check, not within Check Strategy.
Only formats, which are designated for the display of the results in the WUI, are delivered in the standard packaging.
Implementa on
This sec on covers the following topics:
Flag at por olio level

Func on Security Profile
External Service Profile
Case Rules templates
Flag at por olio level

The flag margin_lending_e at the por olio level can be used to indicate whether the bank offers a margin lending facility for the por olio. For por olios that have this flag set to No, the external service will not be called.

Func on Security Profile
The Lombard compliance check func on of Front Office - PM must be added to the Func on Security Profile of the users who will execute the Lombard compliance check.
External Service Profile

The External Service Profile must contain a Lombard of the external service to call for the Lombard compliance check.
A default service PCK_DS_LOMBARD_CHECK is delivered in the standard packaging.
This service is composed of an outbound direc on component and an inbound direc on component. The outbound service component transforms the data in the extended strategy element into the outbound structure pck_lombard_request.
This transforma on is done by:
the filter, which restricts the result to the data at the instrument level only
the screen PCK_DS_LOMBARD_REQUEST, which transforms the Front Office - PM data into a structure that is understood by Core Banking. This transforma on contains mainly:
posi ons in deriva ves
posi ons in FX Forwards and FX Swaps
The inbound service component transforms the result of the external system (in the logical table pck_lombard_response) into the target en ty lombard_check by means of the screen PCK_DS_LOMBARD_RESPONSE. A simulator is available in
Front Office - PM Web implemented via the ServiceAdapter. You can get it at /remo ng/public/serviceAdapter/RiskSim/execute.
For more informa on about ServiceAdapter, refer to the WealthSuite Front Office - Por olio Management Web - ServiceAdapter Customisa on Guide.
Case Rules templates

The following case templates are provided in the standard packaging:
SYS_CASE_RULE_LMB_THRESHOLD
SYS_CASE_RULE_LMB_SHORTFALL
SYS_CASE_RULE_LMB_TECH_ERROR
SYS_CASE_RULE_LMB_CALCUL_CONDITION
SYS_CASE_RULE_LMB_THRESHOLD
Creates a case if the Lombard compliance value of the por olio is s ll posi ve but is ge ng smaller (i.e., falls below a given percentage of the por olio market value).
The threshold and the severity for the case can be defined in the system parameters PCK_GL_LOMBARD_THRESHOLD and PCK_GL_LOMBARD_WARNING_SEV.
SYS_CASE_RULE_LMB_SHORTFALL
Creates a case if there is a Lombard compliance shor all (i.e., the collateral is not sufficient). The severity for the created case is defined in the system parameter PCK_GL_LOMBARD_SHORTFALL_SEV.
SYS_CASE_RULE_LMB_TECH_ERROR
Creates a case if a technical error occurs (e.g., the external service is not reachable or med out during execu on of the Lombard compliance check). The severity for this case is defined in the system parameter
PCK_GL_LOMBARD_TECH_ERROR_SEV.
SYS_CASE_RULE_LMB_CALCUL_CONDITION
Creates a case to inform the user that no Lombard compliance check has been executed in the following situa ons:
Order session with more than one por olio (except "order proposal at client level”).
Not even one security buy order for the por olio (in this case, there is no need to perform the Lombard check, because the Lombard value can only get be er).
Appendix: MiFID compliance

The current regula ons of Markets in Financial Instruments Direc ve (MiFID I and MiFID II) are implemented in Front Office – PM via input controls in the Order Entry screens for the WUI and via input controls and filters in the Order Entry
screens for Channels. All controls can be ac vated or deac vated by system parameters.
These input controls can also serve as example for banks, which want to define an own set of rule (for example, in countries outside the European Union, where similar regula ons apply. This sec on describes the implement controls and the
infrastructure, which is used by them.
For some checks, different methods are provided as the correctness of the check depends mainly on the data quality for the instrument, client, and por olio en es in the Front Office - PM database. The availability of data in Front Office – PM
depends mainly of what can be provided from the back office system of the bank.
References:
MiFID I Direc ve 2004/39/EC
MiFID II Direc ve 2014/65/EU
Categories of por olio, client, and instrument

Por olio
Third Party: Client Classifica on
Instrument
Por olio
Service Type (service_type_e)

This field is used to specify whether a por olio is 'Discre onary', 'Advisory', 'Execu on only', or 'Other'.
This data is used in each input control applied in a context of a Suitability and Appropriateness tests.
Permi ed values:
0 - <None>
1 - Discre onary
2 - Advisory
3 - Execu on only
4 - Others
Suitability Tolerance Date (suitability_tolerance_d)

This field is used to store a date up to when the system generates a warning message instead of an error message.
Third Party: Client Classifica on
Reference
This field is used to specify whether the reference is ‘MiFID I’ or ‘Annex II’.

Client Classifica on (cli_classif_e)
This field manages the client's categorisa on, which can be ‘Retail Client’, ‘Professional per Se’, or ‘Professional on Request’.
Private clients required a higher level of protec on than professional clients. For professional clients, a higher level of exper se, experience, and knowledge is assumed.
Private clients are generally seen as ‘Retail Client’ and professional clients as ‘Professional per Se’.
Professional client can demand to be treated as ‘Retail Client’ and are then classified in this category.
Private clients can demand to be treated as Professional clients and are then classified as ‘Professional on Request’.
Permi ed values:
0 - None
1 - Retail
2 - Professional Per Se
3 - Professional on Request
Client Classifica on Date (cli_classif_d)

This field permits persis ng the date from which the current client's classifica on is valid.
No treatment is done except update of the date.
Instrument
Market Direc ve Category (mkt_direc ve_category_e)

This field permits defining the market direc ve category to which the instrument belongs. It can be used to define various investment restric ons preven ng investment proposals that are not suitable or appropriate to the client.
By default, it proposes the following categories, which are fully customizable:
0 – None
1 – Security Deriva ve
2 – Currency Deriva ve
3 – Interest Deriva ve
4 – Index Deriva ve
5 - Commodity Deriva ve
6 – Credit Deriva ves
7 - Economic Sta s cs Deriva ve
99 – Other Complex Instrument
Suitability
Defini on
MiFID I Ar cle 19 (4), part 2
MiFID II Ar cle 25 (2), part 2
For each investment proposal, the suitability with respect to the market expecta ons and risk profile of the investor has to be considered.
Available infrastructure
Financial instrument
Risk Level (risk_level_n)

This field is numerical. The standard implementa on relies on the fact that the higher the risk of the instrument, the higher the value in this a ribute. If it cannot be provided from the back office directly, it might be set by a default value in
dependence on the instrument nature, type, sub-type, currency, issuer, etc.
Strategy
Inv. Prof. Risk level (inv_prof_risk_level_n)

This field stores the level of the risk that the Investment Profile can take.
Instr Filter List (instr_filter_list_id)

This field references a list of instruments, which are admissible for a por olio, that is linked to the given investment profile.
Packaged standard checks
Input Control / Filtering - Method 1

This method is based on the comparison on the risk level in the instrument and the risk level in the investment profile. For the check, it is assumed that for the instrument, the higher the risk, the higher the value of the risk level. In the
investment profile, the risk level indicates the maximum risk level of instruments allowed.
Input Control: For buy orders on securi es and opening orders on deriva ves, check if the risk level of the instrument is less than or equal to the risk level as defined in the investment profile of the por olio. If not, there is a viola on. Depending
on the client and por olio, a warning or an error is created. Warning, if risk level of investment profile is NULL or risk level of instrument is NULL.
Filtering (for Channels only): Instruments that violate the above input control rule (error level) are not proposed for buying.

This method is based on an instrument list, which is referenced in the investment profile. This instrument list defines the instruments that are allowed for por olios with the given investment profile. Banks will have to define these lists, generally
as constraint list with condi ons on instrument a ributes (e.g., nature, sub-nature, currency, issuer, etc.).
Input Control: For buy orders on securi es and opening orders on deriva ves, check if the instrument in contained in the list, which is referenced in the investment profile of the por olio.
Filtering (for Channels only): Instruments that violate the above input control rule (error level) are not proposed for buying
Dependency on client and por olio

Check only for por olios of service type “Discre onary”, “Advisory”, and “Robo-Advisory”.
For category ‘Retail Client’, viola on generates an error, if the suitability tolerance date of the por olio is empty or before the trade date of the order. Else, it is a warning.
For categories ‘Professional per Se’ and ‘Professional on Request’, viola on is generally a warning.
System parameter

Permi ed values for system parameter PCK_GL_MIFID_SUITABILITY_CHECK:
0 = No check
1 = Check according to method 1
2 = Check according to method 2
Packaged Trading Constraint template
PCK_PM_MFD_SUIT1
Check according to Method 1:
For buy orders on securi es and opening orders on deriva ves, check if the risk level of the instrument is less than or equal to the risk level as defined in the investment profile of the por olio. If not, there is a viola on.
PCK_PM_MFD_SUIT2
Check according Method 2:
For buy orders on securi es and opening orders on deriva ves, check if the instrument is contained in the list, which is referenced in the investment profile of the por olio. If not, there is a viola on.
In contrast to the input controls, Trading Constraints do not have condi ons on clients or por olios.
On implementa on, the bank must make sure that the templates are used to create constraints on the matching por olio (e.g., create the constraint for a por olio list of discre onary mandates), and set the cri calness differently for retail or
professional clients.
Appropriateness
Defini on
MiFID I Ar cle 19 (4), part 1
MiFID II Ar cle 25 (2), part 1
For each investment proposal, the appropriateness with respect to the knowledge and comprehension of the investor has to be considered.
Third Party: Client’s Educa on, Knowledge, and Experience
Level of Educa on (educa on_level_e)

This field is used to specify the level of educa on of the client. This could be one argument used to set default values for the a ributes of knowledge in complex instruments. It will not be evaluated in the standard check.
Permi ed values:
0 = None
1 = Not Defined
2 = High School
3 = Graduate
4 = Post-Graduate
Know Complex Instruments (complex_instr_know_f)

This flag is used to specify whether the client knows complex instruments.
Permi ed values:
0 = No - The client has no knowledge on complex instruments.

1 = Yes - The client has knowledge on complex instruments.
Specific complex instruments knowledge

This approach provides a more precise way to specify which category of complex instruments that the client knows. Therefore, several fields are needed for these specifica ons:
Know/Exp Commod. Deriv (commod_deriv_know_e): Used for commodi es deriva ves.

Know/Exp Credit Deriv. (credit_deriv_know_e): Used for credit deriva ves.
Know/Exp Curr. Deriv. (curr_deriv_know_e): Used for currency deriva ves.
Know/Exp Econ. Deriv. (economic_stat_know_e): Used for economic sta s cs.
Know/Exp Fin. Indices Deriv. (indice_deriv_know_e): Used for index deriva ves.
Know/Exp Interest Deriv. (int_deriv_know_e): Used for interest rate deriva ves.
Know/Exp Secu Deriv. (sec_deriv_know_e): Used for security deriva ves.
Know/Exp Other Complex Instr. (other_complex_know_e): Used for other complex instruments.
Permi ed values (same for each a ribute):
0 = None
1 = Not Defined
2 = Have Know/Expe -The client has knowledge or experience.
3 = Have No Know/Expe - The client has no knowledge or experience.
Financial instrument
Complexity (complexity_f)
This field is used to specify the complexity of an instrument.
It could be ini alised by a default value based on other a ributes of the instruments such as the nature, the risk-nature, the currency, the market, etc.
Permi ed values:
0 = No
1 = Yes

This method relies on the se ng of the complex flag in the instrument master data. This flag must either be delivered from the back office, or set by a default value in func on of other a ributes of the instrument (e.g., nature / sub-nature / type
/ sub-type, etc.). For the client, only the general knowledge of complex instruments is evaluated.
Input control: For buy orders on securi es and opening orders on deriva ves, check if the instrument has the complex flag set in its master data. If the client does not have knowledge of complex instruments, there is a viola on.
Filtering (Channels only): Instruments that violate the above input control rule (error level) are not proposed for buying.

This method is a more fine-grained check of complex securi es. Banks must define instrument lists that represent the different types of complex instruments (generally as constrained lists with condi ons on a ributes of the instrument (e.g.,
nature / sub-nature / type / sub-type, etc.). For the client, the fine-grained knowledge is evaluated.
Input control: For buy orders on securi es and opening orders on deriva ves, check if the instrument belongs to one of the market direc ve category (mkt_direc ve_category_e). If so, check if the client has knowledge of the corresponding
complex instrument category. If this is not the case (value <> 2), there is a viola on.

Check only for por olios of service type “Discre onary”, “Advisory”, and “Robo-Advisory”.
For category ‘Retail Client’, viola on generates an error.

For categories ‘Professional per Se’ and ‘Professional on Request’, viola on generates a warning.
System parameters
Permi ed values for system parameter PCK_GL_MIFID_APPROPRIATE_CHECK:
0 = No check (default)
1 = Check according to Method 1
Packaged Trading Constraint template
PCK_PM_MFD_APP1
For buy orders on securi es and opening orders on deriva ves, check if the instrument has the complex flag set in its master data. If the client does not have knowledge of complex instruments, there is a viola on.
PCK_PM_MFD_APP2_CODPCK_PM_MFD_APP2_CRDPCK_PM_MFD_APP2_CUDPCK_PM_MFD_APP2_ESDPCK_PM_MFD_APP2_IDDPCK_PM_MFD_APP2_INDPCK_
For buy orders on securi es and opening orders on deriva ves, check if the instrument belongs to one of the lists, which represent the complex instruments (see sec on System parameters). If so, check if the client has knowledge of the
corresponding complex instrument type. If this is not the case (value <> 2), there is a viola on.
Execu on-only por olios
Defini on
MiFID II Ar cle 25 (4)
Execu on-only trades are limited to certain instruments (without complexity).
Input control / Filtering

The idea is to check that the traded instrument belongs to the instruments that are admissible for execu on-only mandates. This list has to be defined by the bank, generally as a constraint list based on instrument criteria such as nature, sub-
nature, type, sub-type, etc.
Input control: For buy orders on securi es and opening orders on deriva ves, check if the instrument belongs to the list of instruments that are allowed. If this is not a case, there is a viola on.

Check for por olio of service type “Execu on Only”.
Independent of the client classifica on, a viola on will always result in an error.
System parameters
Permi ed values for system parameter PCK_GL_MIFID_EXEC_ONLY_CHECK:
0 = No check
For system parameter PCK_GL_MIFID_EXEC_ONLY_INSTR, it takes on as value the code of the list of instruments that are allowed for “execu on only”. Default values are NULL.
Packaged Trading Constraint templates
PCK_PM_MFD_EX_ONLY
For buy orders on securi es and opening orders on deriva ves, check if the instrument belongs to the list of instruments that are allowed. If this is not a case, there is a viola on.
Best Execu on Policy
Defini on
MiFID II Ar cle 27
Investment firms have to select a market venue that will guarantee best possible results with respect to cost, possibility of execu on, and speed of execu on.
Execu ons on a Non-Regulated Market require explicit agreement of the client.
Third Party (Client)
Best Execu on Policy Status (best_exec_e)

This field indicates whether a Best Execu on Policy is signed or not.
Permi ed values:

0 = None
1 = Not Defined
2 = Not Signed
3 = Signed
4 = Pending
5 = Missing
Best Execu on Policy Version (best_exec_n)

This field is used to store the number/version of the Best Execu on Policy signed. This field is only used for informa on purposes only; it is not processed.
Third Party (Market)
Market Venue Type (market_venue_type_e)

This field is used to specify whether an instrument is traded on a regulated market or not (what is also known as Venue).
Permi ed values:
0 = None
1 = Regulated Market
2 = Non-Regulated Market
Execu on on Markets according to Best Execu on Policy

If the client has signed a Best Execu on Policy, and the market of the order (buy or sell) does not belong to the trading places of the instrument, a warning is raised.
Non-Regulated Market
If the market of the order (buy or sell) is denoted as Non-Regulated Market in its sta c data, a warning is raised.
Dependency on Client and Por olio

All service types are affected.
Check1 is only done, if a Best Execu on Policy has been signed.
System parameters
The permi ed values for system parameter PCK_GL_MIFID_BEST_EXEC_POL:
0 = No check
1 = Check against trading places
2 = Check for Non-Regulated Markets
3 = Both
Packaged Trading Constraint templates
PCK_PM_MFD_BE_MKT
Checks whether the market place in the order belongs to the list of trading places for the instrument. If not, there is a viola on.
PCK_PM_MFD_BE_NRM
Checks whether the market in the order is a Non-Regulated Market. If so, there is a viola on.
Published on: 22/04/2019

Compliance Reference Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Compliance Reference Guide

Uploaded by

Copyright:

Available Formats

5/21/2019 Compliance Reference Guide

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/Compliance Reference Guide.htm#_Toc528938570%3FTo… 1/61

Compliance Reference Guide

About this document

Diﬀerent types of strategies to deﬁne investment objec ves.

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/Compliance Reference Guide.htm#_Toc528938570%3FTo… 2/61

Classiﬁca ons used to build the Investment Grid above:

Concepts of alloca ons are explained in the following sec ons:

Investment targets and margins

The Fluctua on Margin is deﬁned as equal to 1% in the Model Por olio.

Chemicals Objec ve: 10%

The computa on of the Fluctua on Margin is as follows:

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/Compliance Reference Guide.htm#_Toc528938570%3FTo… 3/61

Equity Bonds Liquidity Other

CHF Weight = 15% Weight = 25% Weight = 6%

Euro Weights = 5% Weight = 15%

Life > 2 years

USD Weight = 8% Weight = 8% Weight = 3%

Return > 15% Dura on = 8

Model Por olio or

Other Weight = 3% Weight = 5% Weight = 7%

Minimum ra ng: AAA

Equity Bonds Liquidity Other

CHF 15% 25% 6%

Small Caps Mid Caps Large Caps Other

Finance 5% 10% 20%

Technology 15% 10% 15%

Market Segment: Other

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/Compliance Reference Guide.htm#_Toc528938570%3FTo… 4/61

Model Por olio

Stock Target Margin

Model Por olio with grid

Model Por olio with grid

Schindler bon 12.5%

UBS nom. 12.5%

Zürich nom. 12.5%

Algroup nom. 12.5%

Note that the default values are not re-executed.

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/Compliance Reference Guide.htm#_Toc528938570%3FTo… 5/61

Real Model Por olios

The relevant informa on to create a real Model Por olio is as follows:

Nature Model Por olio.

Sub-nature Dummy por olio.

Rela ve Absolute, Rela ve, or Unweighted Absolute.

Fluctua on Fluctua on margin value.

Parent As with any strategy you can specify a parent strategy.

The valua on parameters are as follows:

Example (2% as absolute Fluctua on Margin):

Instrument Weight Margin

Alcatel 12% +/- 2%

Bri sh Telecom 10% +/- 2%

Daimler 13% +/- 2%

Volvo 13% +/- 2%

Unilever 24% +/- 2%

Paribas 24% +/- 2%

Example (sector grid):

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/Compliance Reference Guide.htm#_Toc528938570%3FTo… 6/61

Sector Grid Weight Margin

Sector Grid 100%

Finance 24% +/- 2%

Paribas 24% +/- 2%

Transports 26% +/- 4%

Daimler 13% +/- 2%

Volvo 13% +/- 2%