Constraints
Product Overview
Constraints are set of conditions placed on portfolios or transactions so as to prohibit (and /or) report certain type of activity on a portfolio or
a transaction based on defined rules at Global and Institutional levels.
The constraints processing are dealt in the Securities module at both Transaction Input and Holding Comparison levels through SC.S-
ECURITY.CONSTRAINT and at Transaction Input level for all modules through EB.GC.CONSTRAINTS.
Securities
T24 uses applications SC.SECURITY.CONSTRAINT & RESTRICTION to define rules which can either be applied to individual or a group of
portfolios depending on the market need.
It provides extended functionality to application SC.SECURITY.CONSTRAINTS.
Given below are the functionalities extended to constraints processing.
l Increased flexibility for constraint definition.
l Extendedfunctionality to define generic holding type constraints.
Holding type constraints to support economic exposure calculation.
Generic
T24 uses applications EB.GC.CONSTRAINT & RESTRICTION to define rules which can be applied to individual contract depending on the
bank requirement.
It provides new set of applications to support contract level constraint processing across all T24 applications.
l Constraints can be specified for any application within T24
l Constraints can be applied specifically to Customer/Portfolio/Account/Currency
l Fields can be specified from other records/applications to define constraints testing
l Constraints processing must be able to handle I-types
l Local routines can be used to select constraints and extract or process data to be compared
l Operand can be selected to define relationship between data within constraint
l Constraints can raise errors or overrides (if applicable)
l Error/Override messages can be defined on the constraint
l Flexibility
l Fast processing time
Constraints- Release R13.00 -Page 2 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints Setup
Transaction–based Constraints
SEC U R ITIES
RESTRICTION
This application is used to set up relationships between certain customers, portfolios, accounts or all customers and trading restrictions.
This allows certain transactions to search through this file and obtain lists of restrictions (SC.SECURITY.CONSTRAINT), which apply to that
transaction.
The key to the application is constructed in the following way:
KEYTYPE.PRODUCT
PRODUCT - This is a valid T24 product located in the EB.PRODUCT application, however it is currently only applicable to SC.
KEYTYPE - Four different types of key can be entered and they are as follows:
ID Type Description Example
ALL All transactions are applicable to this group of restrictions ALL.SC
CUSTOMERThis group of restrictions will only apply to this customer number100113
PORTFOLIOThis group of restrictions will only apply to this portfolio 100113-1
ACCOUNT This group of restrictions will only apply to this account number 18934
If a customer, portfolio or account restrictions are entered the following screen format appears:
There are two types of restriction, “ONLINE” or “BATCH”.
“BATCH” is used when the system is in BATCH mode. BATCH mode is usually during the Close of Business procedure and “ONLINE” is used
during normal operation of the system.
The restriction(s) can be limited to a date range or if the dates are omitted the restriction(s) will remain valid until the record is updated accord-
ingly.
If the APPLICATION field is populated the restriction will be limited to the application(s) entered. If this field is left blank, then the restriction
(s) will apply to all applications.
The RESTRICTION field is mandatory and contains a user defined ID which indicates the restriction(s) that will apply should all the selection
criteria be met. The field must start with “R-“. The field is sub-valued to allow multiple restrictions to be applied to the selection criteria.
For further information, refer to the Securities Trading User Guide, of which the above is an excerpt.
Constraints- Release R13.00 -Page 3 of 44 - (c) Temenos Systems 2013 05/07/2013
AM.ENTITY
Modelling analysis portfolio positions on different axis (view) are based on basic data. This basic data (also named attribute) is defined in
AM.ENTITY. Depending on the type of the position (security, account, etc…) the basic information has to be extracted from a different file,
using different fields.
Example: The currency for an account is the field CURRENCY in the file ACCOUNT , but the currency for a security is the field SECU-
RITY.CURRENCY in the file SECURITY.MASTER.
Thus the application AM.ENTITY lets a user define for each type of position how the system will get information.
SC.SECURITY.CONSTRAINT
This facility is used to configure trading restrictions for certain applications. These applications are SEC .TRADE, SEC .OPEN.ORDER, SECU-
RITY.TRANSFER and POSITION.TRANSFER but if the user does not want to have the check in all these applications, he can specify them one
by one.
The ID of the record can be:
Constraints- Release R13.00 -Page 4 of 44 - (c) Temenos Systems 2013 05/07/2013
PriorityID Description Example
1 Security If the key is a security number then the restrictions will only apply to that security. 000001-
Master 000
2 Domicile If the key is ‘D- US’ then the restrictions will apply to all securities that have US in the SECU- D-US
RITY.DOMICILEfield.
3 Local Ref-If the key is ‘L-10’ then restrictions will apply to all customers that have a particular local reference field equal L-10
erence to 10. The local reference field concerned will be identified in the PRODUCT.TYPEfield on the SC.P-
ARAMETER file.
4 Sub Asset If the key ‘S-301’ then the restrictions will apply to all securities that have a SUB.ASSET.TYPE of 301. S-301
Type
5 Asset TypeIf the key ‘A-10’ then the restrictions will apply to all securities that have an ASSET.TYPE of 10. A-10
6 RestrictionIf the key ‘R-CCYGT30’ then the restrictions will apply to all Securities Holdings that have an individual cur-R-
rency holding more than 30 %. CCYGT30
Example of a Restriction Constraint – showing that an override will be displayed if any Currency total is greater than 30% of the portfolio hold-
ing.
A ll A pplic a tions
There are 5 main Files that need to be set up for Global Constraints
EB.GC.PARAMETER - System and Company level Parameter File
EB.GC.ACTIVE - Application Level Definition File
EB.GC.CONSTRAINTS - Constraints Definition File
EB.GC.GLOBAL - Global Fields Definition
EB.GC.GROUP - Global Constraints Group Definition
EB.GC.PARAMETER
This file should be set up for each company where Constraints processing is to be used and also for SYSTEM which is used as default.
SYSTEM Level
Constraints- Release R13.00 -Page 5 of 44 - (c) Temenos Systems 2013 05/07/2013
Here Com Processing is set to NO specifying that no constraint processing or diagnostics recording will be done. Note this can be overridden
at Company level, as well at Application level.
Com Diag is set to OFF specifying that no diagnostics of constraints breaching will occur.
Com Diag Life is set to 1 denoting that the diagnostic will stay on record for 1 day only, this is used to calculate the expiry or Death date of the
diagnostic record.
The Com Method is significant on how constraints are to be processed and here it is set to SINGLE specifying that the constraint which has a
precedence of 1 if it exists, will be tested first and so on to the next if not. Only one constraint will be checked whether successful or not. Note
that if CUMULATIVE is set then all Constraints will be checked and reported as necessary.
Normally for certain cases with less restrictive constraints, it may be easier to use SINGLE however for more restrictive and additional con-
straints, CUMULATIVE is suggested.
There are 5 Precedence fields pertaining to User, Currency, Account, Portfolio and Customer , and to each a unique value of 1 to 5 can be spec-
ified to define the order of checking. These if set, will take priority over all other institutional constraints.
COMPANY level
The example shows that for Company US0010001, Constraints processing as well as diagnostics are on. The Precedence is unchanged. These
will override the SYSTEM setting when the Company US0010001 is being used
Constraints- Release R13.00 -Page 6 of 44 - (c) Temenos Systems 2013 05/07/2013
Similarly the parameter setting for Company DE0010001 can be different. Constraints processing as well as diagnostics are on. The Prec-
edence may be changed. These will override the SYSTEM setting when the Company DE0010001 is being used.
EB.GC.ACTIVE
Apart from the precedence, the EB.GC.PARAMETER setting can be overridden at the Application level by setting up the EB.GC.ACTIVE param-
eter for the application.
It also defines which fields on the application relate to Customer, Portfolio, Account, Currency and Date and also whether they are associated
to the Customer or not. Furthermore, if any special routine is to be used then this can be defined as well.
The total number of active Constraints relating to the application is updated during the Close of Business processing.
Constraints- Release R13.00 -Page 7 of 44 - (c) Temenos Systems 2013 05/07/2013
The above DX.TRADE example shows that for the application Constraint processing, diagnostic reporting are on and the CUMULATIVE App
method denotes that all constraints will be processed.
The Customer fields on DX.TRADE are identified, and so are the Account, Currency and the Transaction Date fields.
The SELECTION.ROUTINE is set with the name of the selection routine that is being used else blank.
As there are more than one customer field, the portfolio field PORTFOLIO.FLD is linked to the CUSTOMER.FLD within the same multi-value
set on the source application, the field PORT.FLD.ASSOC is set to 'CUSTOMER'. Similarly as the ACCOUNT.FLD is linked to the CUS-
TOMER.FLD within the same multi-value set on the source application, the field ACCT.FLD.ASSOC is set to 'CUSTOMER'
Again if the CURRENCY.FLD is linked to the CUSTOMER.FLD within the same multi-value set on the source application, the field
CURR.FLD.ASSOC is set to 'CUSTOMER'. If set to 'CUSTOMER', both ACCT.FLD.ASSOC and PORT.FLD.ASSOC must also be set to 'CUS-
TOMER'.
The following two examples show the possible set up for Foreign Exchange and Funds.Transfer.
For each application for which Constraints processing is needed, the corresponding EB.GC.ACTIVE needs to be defined.
Constraints- Release R13.00 -Page 8 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints- Release R13.00 -Page 9 of 44 - (c) Temenos Systems 2013 05/07/2013
EB.GC.CONSTRAINTS
This defines a set of rules which together constitutes the constraint for transactions that fall under this application constraint record. Any
breach of a single rule is a breach of the whole constraints record.
Record key is APPLICATION (This can be a valid T24 Application, a valid Group name or ‘GLOBAL’)/ optional key fields where the Optional
key fields are CUSTOMER / PORTFOLIO / ACCOUNT / CURRENCY/USER.
Examples
An input of DX.TRADE/CY USD/AC 23442/CU 50030/PO 50030- 1/UR INPUTTis translated as DX.TRADE/50030/ 50030- 1/2344-
2/USD/INPUTTER as the constraint ID.
An input of DX.TRADE/CYUSD/CU 50030/PO50030-1 is translated as DX.TRADE/50030/50030-1//USD as the constraint ID, with the
account and User not set.
An input of DX.TRADE/CU50030/PO50030-1 is translated as DX.TRADE/50030/50030-1 as the constraint ID, with the account currency
and User not set.
An input of DX.TRADE is translated as DX.TRADE as the constraint ID, with the four optional keys not set.
Constraints- Release R13.00 -Page 10 of 44 - (c) Temenos Systems 2013 05/07/2013
This example shows the constraint DX.TRADE/50030 that displays an override with a narrative of TEST CUSTOMER 50030 if the
Pri.Cust.No is equal to 50030.
When creating constraints that result in an Override being raised (Error Override set to OVERRIDE) the target application is checked to make
sure that it has an Override field.
Constraints- Release R13.00 -Page 11 of 44 - (c) Temenos Systems 2013 05/07/2013
In case an application that doesn’t have an Override field is subsequently added to a ‘GLOBAL’ constraint resulting in an Override being raised,
further validation takes place. If an override is raised against an application that doesn’t have an override field, an Error Message is raised
against the test field that generated the override.
Constraints- Release R13.00 -Page 12 of 44 - (c) Temenos Systems 2013 05/07/2013
For field description of EB.GC.CONSTRAINTS see Appendix A.
EB.GC.GLOBAL
EB.GC.GLOBAL enables the definition of common fields across multiple T24 applications. This allows constraints to be established at a
GLOBAL level against multiple applications. In the example below a record has been created that defines the Nominal fields on SEC.TRADE,
SECURITY.TRANSFER and SEC.OPEN.ORDER.
The above Global field can be applied to ‘GLOBAL’ constraints records to test a condition set against the ‘NOMINAL’ fields. E.g. A customer is
unable to trade over a certain Nominal value in GBP.
In the example below, any SEC.TRADE, SECURITY.TRANSFER or SEC.OPEN.ORDER input with Customer 1025, Currency GBP and User
INPUTTER are tested against the following constraint. The EB.GC.GLOBAL record defines the corresponding field to test for each application.
EB.GC.GROUP
EB.GC.GROUP enables Applications to be placed in logical groups (i.e. a subset of a GLOBAL constraint). In the example below, the appli-
cations SEC.TRADE and SECURITY.TRANSFER are included in the SECURITIES group.
Constraints- Release R13.00 -Page 13 of 44 - (c) Temenos Systems 2013 05/07/2013
The above record can be applied to EB.GC.CONSTRAINTS in order to create rules for the applications included in the Group.
In the example below, any SEC.TRADE or SECURITY.TRANSFER input with Customer 1031, Currency GBP and User CWILLS1 are tested
against the following constraint. The EB.GC.GLOBAL record NOMINAL defines the corresponding field to test for each application.
EB.GC.ACTIVE records all Groups that the Application belongs to: -
Constraints- Release R13.00 -Page 14 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints Deal Processing
SC Security Constraints Examples
C ON STR A IN T FA ILU R E s e t a s MU LTIPLE
SC.PARAMETER for US0010001, showing that a MULTIPLE Constraint Failure is set.
Constraints- Release R13.00 -Page 15 of 44 - (c) Temenos Systems 2013 05/07/2013
The ALL.SC restriction shows that any SC online input will be checked using the Sc.Security.Constraint R-NOBNDHLD as defined below.
While the specific restriction 50028-1.SC instructs the SC input that when dealing with portfolio 50028-1 then use the security constraint R-
CCYGT30 as well.
If we now input a Sec.Trade, we will see the effect of the constraints.
Constraints- Release R13.00 -Page 16 of 44 - (c) Temenos Systems 2013 05/07/2013
The above shows that for portfolio 50029-1, the constraint R-NOBNDHLD has been checked using the Restriction ALL.SC as there is nothing
specific for 50029-1.
Similarly if we input a Sec trade for portfolio 50028-1, then both restrictions 50028-1.SC and All.SC come into effect, if conditions are met, as
the Constraint Failure field on SC.PARAMETER is set up as Multiple.
Constraints- Release R13.00 -Page 17 of 44 - (c) Temenos Systems 2013 05/07/2013
C ON STR A IN T FA ILU R E s e t a s SIN GLE
As can be seen, there is no effect for Portfolio 50029-1 as restriction ALL.SC is used.
Constraints- Release R13.00 -Page 18 of 44 - (c) Temenos Systems 2013 05/07/2013
However if we do a similar Sec.Trade for portfolio 50028-1, the above overrides are displayed; note that only the Restriction 50028-1.SC has
been used and not also ALL.SC because the Constraint.Failure is set as SINGLE on SC.PARAMETER.
EB.GC.CONSTRAINTS Examples
This is not dependent on SC.PARAMETER but on EB.GC.PARAMETER
Here the Constraint Failure is replaced by the Com Method on the EB.GC.PARAMETER to define whether SINGLE or CUMULATIVE (MUL-
TIPLE) constraints are to be processed.
As per the precedence, the Account if it exists will be checked first, for SINGLE processing.
Constraints- Release R13.00 -Page 19 of 44 - (c) Temenos Systems 2013 05/07/2013
C U MU LA TIVE Pr oc e s s ing
Although at the Company level, the Com.Method was set as SINGLE, here at the Application level DX .TRADE the method is set as CUMU-
LATIVE thus overriding Company default.
Therefore we can list all the DX.TRADE constraints to see what will be checked.
The following example is a DX.TRADE constraint. Note however that this example uses a Test routine @DAT.CONV.NUM.PLUSONE which is
a dummy test routine that returns the value of the customer number plus one; hence here if customer passed is 50030 then return value is
50031 thus generate an override of PRI CUST IS 50030.
Also if either the CONTRACT.CCY or the TRADE.CCY is GBP, it generates an override NON DEALING CCY.
Constraints- Release R13.00 -Page 20 of 44 - (c) Temenos Systems 2013 05/07/2013
The next DX constraint is checking that if the PRI.ACCOUNT is 23442 to generate an override of TEST ACCOUNT 23442.
Finally the DX constraint that generates an Override ‘WARNING AC 34778 IS BEING USED’ if the SEC.ACCOUNT equals to 34778.
Constraints- Release R13.00 -Page 21 of 44 - (c) Temenos Systems 2013 05/07/2013
All the overrides are shown as expected TEST ACCOUNT 23442
PRI CUST IS 50030
NON DEALING CCY
SIN GLE Pr oc e s s ing
However, if the App Method is not set then it should default to the Company method of SINGLE.
The overrides are shown as expected TEST ACCOUNT 23442
Constraints- Release R13.00 -Page 22 of 44 - (c) Temenos Systems 2013 05/07/2013
NON DEALING CCY
I.e. Two Single Constraints, one for each leg of the DX transaction. The DX.TRADE///23442 is checked first as the Precedence Acct is set as 1
in EB.GC.PARAMETER.
GLOB A L C ons tr a int Pr oc e s s ing
Constraints- Release R13.00 -Page 23 of 44 - (c) Temenos Systems 2013 05/07/2013
GR OU P C ons tr a int Pr oc e s s ing
Constraints- Release R13.00 -Page 24 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints- Release R13.00 -Page 25 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints Enquiries
EB.GC.DIAGNOSTIC Examples
Above is a list of DX.TRADE diagnostic records.
Note that the EB.GC.DIAGNOSTIC record has a Death.Date of 27 MAY 2003, this was calculated using the input plus the App.Diag.Life set-
ting in EB.GC.ACTIVE else Com.Diag.Life in EB.GC.PARAMETER.
When the system date is greater than this Death.Date, the record is move to history.
Constraints- Release R13.00 -Page 26 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints- Release R13.00 -Page 27 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints- Release R13.00 -Page 28 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints- Release R13.00 -Page 29 of 44 - (c) Temenos Systems 2013 05/07/2013
Note that the EB.GC.DIAGNOSTIC record has a Death.Date of 27 MAY 2003, this was calculated using the input plus the App.Diag.Life set-
ting in EB.GC.ACTIVE else Com.Diag.Life in EB.GC.PARAMETER.
When the system date is greater than this Death.Date, the record is move to history.
Constraints- Release R13.00 -Page 30 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints- Release R13.00 -Page 31 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints- Release R13.00 -Page 32 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints- Release R13.00 -Page 33 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints- Release R13.00 -Page 34 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints Appendix
Appendix A
Fie lds D e s c r iption EG.GC .C ON STR A IN TS
Test File Multi Value Set. Optional. File from which to retrieve data to test, if not base application
Test Key This is mandatory if Test File is input.
Key to the test file or base application, if same as current record then use @ID else specify the field name within the base appli-
cation.
Test Field Field within base application or TEST.FILE from which to retrieve data to test.
Test Assoc Field with which TEST.FIELD is associated. Used to iterate TEST.FIELD when TEST.FIELD belongs to a multi-value set.
Test Routine Optional API or local subroutine for pre-processing of test data. Must be prefixed by '@'.
Operand Mandatory operand for comparison of TEST.SUB.DATA with EVAL.SUB.DATA. If comparison equates to a logical value of true,
processing continues, otherwise constraint rule is breached.
Eval File File from which to retrieve data to evaluate against, if not base application.
Eval Key Key for EVAL.FILE or base application.
If key for EVAL.FILE is to be the same as for the current record, specify as '@ID'
If key for EVAL.FILE is found within a field in base application, specify field name.
Mandatory if EVAL.FILE specified
Eval Field Field within base application or EVAL.FILE from which to retrieve data to test.
Mandatory if EVAL.KEY is specified.
Eval Value Value or set of values to compare test data against. Alternatively can used to specify an API or local routine (prefixed by '@' sym-
bol) for pre-processing of data from EVAL.FIELD.
Must be on or after FIRST.VALID.DATE
Separator Mandatory. Delimiter used to separate list of values specified in EVAL.VALUE.
Error Override Mandatory. Specifies whether an ERROR or an OVERRIDE should be raised.
If OVERRIDE is specified, then if the condition is met then an Override message as per the Narrative below is displayed to which
the User can override.
However if ERROR is specified and the condition is met, then the Narrative Error message is displayed and the processing is halted until the
User takes action so that the condition no longer exists.
Narrative Mandatory. Specifies text to be used for error id or override message.
First Valid Date Mandatory. Specifies date on which constraint becomes active. Where the transaction date as mapped within
EB.GC.ACTIVE falls before this date, the whole constraint is deemed invalid and processing passes to the next valid constraint.
Must be on or after System Date.
Last Valid Date Specifies date after which constraint expires. Where the transaction date as mapped within EB.GC. ACTIVE falls after this
date, the whole constraint is deemed invalid and processing passes to the next valid constraint.
Constraints- Release R13.00 -Page 35 of 44 - (c) Temenos Systems 2013 05/07/2013
If specified, it must be on or after FIRST.VALID.DATE and when the System date is greater than this date, the record is moved to History.
Note if it is left i.e. unspecified it stays indefinitely
Appendix B
Ge ne r ic Globa l C ons tr a ints A PI
The API EB.GC.CHECK.CONS.FOR.APP can be used to check any application in T24 including live files against Generic Global (transactional)
Constraints as defined in EB.GC.CONSTRAINT as detailed in the preceding sections.
The API will take the application, record key and record as a dynamic array and return the results of any constraints breached, including for
each breach, whether the breach results in an error or an override, the narrative that would be reported in the error or override, the field (multi-
value and sub-value, if applicable) against which the constraint breach occurred and the key of the EB.GC .CONSTRAINT record containing the
rule that was breached.
The calling application should then raise any errors or overrides for itself via the standard methods, as when invoked via the API, the Generic
Global Constraints functionality will not do so as regards errors or overrides normally raised as a result of constraint breaches.
The API is called with arguments as in the following example:
CALL EB.GC.CHECK.CONS.FOR.APP(REF.APPLICATION, REF.ID, REF.RECORD, RESVD01, RESVD02, RESULT, NARRATIVE,
CONS.POS, CONS.ID)
The arguments are defined as:
Argument In/Out Description
REF.APPLICATION In Application for which the constraint is to be checked
REF.ID In Record id for the record which is to be checked
REF.RECORD In Record passed in for constraint checking (as dynamic array)
RESVD01 In Reserved for future use
RESVD02 In Reserved for future use
RESULT Out Designates whether 'ERROR' or 'OVERRIDE' generated (or blank)
NARRATIVE Out Narrative of errors or overrides (or blank if none generated)
CONS.POS Out Field]multivalue]subvalue numbers generating constraint.
CONS.ID Out Constraint ids for each constraint breached.
RESVD03 Out Reserved for future use
RESVD04 Out Reserved for future use
Note that the arguments RESULT, NARRATIVE, CONS.POS and CONS.ID can contain multiple related values, separated by field marks (con-
straint checking may return multiple constraint breaches if constraint 'method' in EB.GC.PARAMETER or EB.GC.ACTIVE is cumulative).
Note that the EB.GC.DIAGNOSTIC record has a Death.Date of 27 MAY 2003, this was calculated using the input plus the App.Diag.Life set-
ting in EB.GC.ACTIVE else Com.Diag.Life in EB.GC.PARAMETER.
When the system date is greater than this Death.Date, the record is move to history.
Constraints- Release R13.00 -Page 36 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints- Release R13.00 -Page 37 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints- Release R13.00 -Page 38 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints- Release R13.00 -Page 39 of 44 - (c) Temenos Systems 2013 05/07/2013
Note that the EB.GC.DIAGNOSTIC record has a Death.Date of 27 MAY 2003, this was calculated using the input plus the App.Diag.Life set-
ting in EB.GC.ACTIVE else Com.Diag.Life in EB.GC.PARAMETER.
When the system date is greater than this Death.Date, the record is move to history.
Constraints- Release R13.00 -Page 40 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints- Release R13.00 -Page 41 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints- Release R13.00 -Page 42 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints- Release R13.00 -Page 43 of 44 - (c) Temenos Systems 2013 05/07/2013
Constraints- Release R13.00 -Page 44 of 44 - (c) Temenos Systems 2013 05/07/2013
