Resolución del Concejo en Pleno

Before getting down to the technical explanation of the procedures and logic behind the access right to the T2S allocation and management process, it is worthwhile to specify that if the client decides to opt for a direct connection to the T2S platform, it is required to manage dedicated preparatory activities related to access right allocation in T2S.

The latter consists of a series of actions summarised below and reported in the table under heading 4.1: Plan of the activities and Pre-migration Synchronisation Points:

1. The DCP client is required to request Monte Titoli to set up and grant the access for an administrator user. The administrator user will then be responsible to assign the privileges internally.

Conversely, the DCP client has to request their Central Bank the grant of an administrator user for the management of all access rights related to the role assigned to National Central Banks.

2. The DCPs are required to carry out the registration process with the Network Service Providers. Indeed, each DCP participant that takes part in a specific migration wave has to complete the special registration with the NSPs through their respective CSD/CB for the test environment.

3. The DCP clients must request specific certificates/tokens for access to the T2S system according to criteria and rules set up by the NSP chosen by the client.

It should be noted that the following paragraph only concerns the DCP clients.

Indeed the clients that opt for an indirect (ICP) connection to the T2S platform via Monte Titoli are not required to carry out any activity related to the management of access rights to the T2S platform.

In light of the above, the ICP clients can consider the content of this chapter for purely descriptive and knowledge improving purposes.

8.1 Introduction to management of access rights to T2S

The management of the access rights allocation process in T2S follows the hierarchic structure of the Party Model established by the new T2S platform.

Indeed, the T2S Party organization is developed according to a hierarchic structure that envisages three different levels, where it may be distinguished between:

 1^st level party, meaning the T2S Operator at the head of the hierarchic structure;

 2^nd level party, meaning the CSDs and the CBs;

 3^rd level party, meaning the clients of the CSDs (CSD participants) and the clients of the CBs (Payment Banks).

The process to grant roles and privileges follows the hierarchic structure described in the diagram above, on the basis of which each entity is responsible for the allocation of roles and privileges to the users that belong to the categories at a lower level in the structure itself.

In light of the above, the T2S Operator is directly responsible to grant roles and privileges to the CSDs and CBs, which, in their turn, shall grant the new roles and privileges to the CSD Participants and the Payment Banks.

8.2 Main concepts and definitions

In order to facilitate an understanding of the mechanisms behind the allocation of roles and privileges, we provide a list of the main concepts and definitions on which the management of access right to T2S is based.

8.2.1 User Function

The XML messages and GUI functionalities represent the procedures by which the user may interact with T2S, either in the A2A or U2A modes.

Based on the set of XML messages and the functions offered by the GUI, a set of «T2S user functions» may be defined for the users (e.g. sending a settlement instructions, creating a Party, etc.), both in A2A and U2A mode.

8.2.2 Privileges

A privilege identifies the capability of triggering different «T2S user functions» and represents a basic element to assign access rights to users. Depending on the application environment, distinctions may be done between the following privileges:

 System Privileges: refer to the «T2S user functions» that do not apply to specific static or dynamic data (for example: a query on the current phase of the settlement day);

 Object Privileges: refer to the «T2S user functions» that apply to a specific static or dynamic data ( e.g. user function to display the reference data of a securities account).

The system privileges are assigned basing on a top-down approach, as shown in the graphic representation provided below:

The object privileges, unlike the previous category, are assigned on the basis of a top-down and/or transverse approach:

8.2.3 Secured Object

A "secured object" is a static data object (party, security, securities account and T2S DCA) on which a specific privilege-object is granted.

8.2.4 Secured Group

A «secured group» is a homogeneous group of «secured objects» (for example: a group of parties or securities accounts).

8.2.5 Role

A role is a set of privileges.

8.2.6 User

A user is an individual or an application that interact with T2S triggering the «T2S user functions».

8.2.7 Data Scope

Given the hierarchic structure defined by T2S and described in the introduction, T2S defines the so called default data scope for each individual privilege, meaning the established set of static or dynamic data to which the individual user may apply the T2S functions. In particular:

 The Users of the T2S Operator have visibility on all static and dynamic data object and can act on a objects only in exceptional circumstances and on the basis of specific agreements with the participant in question;

c

 The Users of the CSDs and the CBs users have visibility on all static and dynamic data belonging to the same system entity;

 The User of the CSD participant and User of the Payment Banks have visibility on static and dynamic data that is directly or indirectly linked to the same Party.

From the graph provided below it can be seen how users X, Y and Z (placed on a different hierarchic level of the Party Model in T2S) fall within a different default data scope. In particular:

 User X, being a participant of the CSD Part. B acquires by default the data scope of the CSD Part .B. It should be noted that the data scope also includes the SAC2 as it is the only securities account of the CSD Part. B. User X does not send settlement instructions that refer to other securities accounts on T2S;

 User Y of the CSD1 acquires by default the data scope marked within the blue area that includes the SAC1 and SAC2 securities accounts seeing as these securities accounts belong to the CSD participant (thus CSD Part.A and CSD Part.B) of the CSD1.

 User Y may not send settlement instructions that refer to other securities accounts in T2S that are not included within the above data scope (see the blue area in the graph);

 User Z of the T2S Operator, being the first level of the hierarchic structure of the Party model in T2S, acquires by default the data scope (green area) that includes all securities accounts loaded on T2S.

The default data scope may be extended or reduced depending on the specific business requirements.

The two next paragraphs provide two examples of both extension and reduction of the default data scope.