T2S Functional Design
General Functional Specifications
1.1
Author
Functional Coordination Group
Version
1.1
Date
20/01/2009
Status
Draft
Classification
Internal
Accessible
4CB-ECB
Classified until
Unlimited
FOREWORDS DISCLAIMER
After the User Requirements phase, the T2S project has entered into the specification phase that
encompasses functional and technical design. This phase aims at designing the solution that will enable
the T2S platform to provide the services required by users in the User Requirements documentation.
The Advisory Group has agreed that the ECB will validate the GFS and confirm their consistency with the
URD. This draft of the GFS has been prepared by the 4CB (first delivery of the full documentation on 29
November 2008) and thereafter revised with the T2S project team input to come to an intermediate
version for discussion with CSD experts. So, the present version is published for the sake of transparency
and in order to foster interaction with the market. However, it should be clear that it is a working
document still under the process of validation by the ECB.
In this version, a number of specific elements of the general functional architecture needed to turn the
URD into a live system can be treated in different ways; it is important to make the best informed choice
at this stage in the project.
The main functional points already identified for discussion are:
•
end-to-end business process from the message to the final processing of information for
different types of instructions and ISO transaction codes;
•
transactional data model and interactions between LCMM and settlement modules;
•
status management model for all types of instructions, including liquidity management,
maintenance of settlement instructions and static data management;
•
multi-currency aspects of T2S;
•
interactions with external systems and more specifically with the RTGS systems;
•
the graphical user interface.
In addition, the formatting of each functional and process description will be harmonised and identified
through a unique reference in order to optimise their management. In particular, a matrix to map UR,
general specification and user detailed specification will help for ensuring the completeness of testing and
the updating of any documentation.
Further harmonisation of the presentation of each individual specification will enhance the document
clarity.
T2S General Functional Specifications
Table Of Content
1. APPROACH TO T2S FUNCTIONAL DESIGN...................................... 7
1.1. PRESENTATION OF THE DOCUMENT ........................................................... 7
1.2. METHODOLOGICAL ELEMENTS .................................................................... 7
1.3. REFERENCE DOCUMENTS ............................................................................ 9
1.4. SPECIFICATIONS REFERENCES – CROSS-REFERENCING URD ................ 9
1.5. CONVENTIONS USED .................................................................................... 9
2. GENERAL FUNCTIONAL OVERVIEW .............................................. 11
2.1. INTRODUCTION ............................................................................................ 11
2.1.1. Objective and scope of T2S ............................................................ 11
2.1.2. T2S Actors ....................................................................................... 19
2.1.3. Multi-currency in T2S ...................................................................... 25
2.1.4. Other systems interacting with T2S................................................ 27
2.2. OVERALL HIGH LEVEL DIAGRAM ................................................................ 28
2.3. DESCRIPTION OF FUNCTIONAL DOMAINS................................................. 29
2.3.1. Interface ........................................................................................... 30
2.3.2. Static Data Management.................................................................. 32
2.3.3. Lifecycle Management and Matching (LCMM)................................ 33
2.3.4. Settlement ........................................................................................ 39
2.3.5. Liquidity Management ..................................................................... 47
2.3.6. Statistics, Queries, Reports and Archive ....................................... 49
2.3.7. Operational Services ....................................................................... 53
2.4. DATA MODEL OVERVIEW ............................................................................ 56
2.4.1. General Introduction........................................................................ 56
2.4.2. Static Data ........................................................................................ 57
2.4.3. Dynamic Data ................................................................................... 62
2.5. SECURITY MANAGEMENT ........................................................................... 66
3. FUNCTIONAL DESCRIPTION ............................................................ 69
3.1. INTRODUCTION ............................................................................................ 69
3.2. INTERFACE ................................................................................................... 70
3.2.1. General Introduction........................................................................ 70
3.2.2. Description of the role of the domain ............................................. 73
3.2.3. Dynamic data managed by the domain .......................................... 75
3.2.4. Access Management ....................................................................... 77
3.2.5. Structure and Syntax Check ........................................................... 81
3.2.6. Flow Management............................................................................ 85
3.3. STATIC DATA MANAGEMENT ...................................................................... 97
3.3.1. General Introduction........................................................................ 97
3.3.2. Dynamic data managed by the domain ........................................ 100
Final_T2S_GFS_110.doc
Page 3
T2S General Functional Specifications
Table Of Content
3.3.3. Static Data Management use cases .............................................. 102
3.3.4. Processing of Static Data Management Use Cases ..................... 104
3.3.5. Functions ....................................................................................... 109
3.3.6. Input / Output ................................................................................. 115
3.3.7. Data Accessed ............................................................................... 116
3.3.8. Common Information..................................................................... 116
3.3.9. Party Data Management ................................................................ 118
3.3.10. Security Data Management ......................................................... 123
3.3.11. Securities Account Data Management ........................................ 128
3.3.12. T2S Dedicated Cash Account Data Management ....................... 131
3.3.13. Rules and Parameters Data Management................................... 135
3.4. LIFECYCLE MANAGEMENT AND MATCHING ............................................ 161
3.4.1. General Introduction...................................................................... 161
3.4.2. Dynamic data managed by the domain ........................................ 164
3.4.3. Settlement Instructions (SI) use cases ......................................... 180
3.4.4. Processing of Settlement Instructions Use Cases ....................... 183
3.4.5. Instruction Validation .................................................................... 208
3.4.6. Maintenance Instruction (MI) Use Case ........................................ 230
3.4.7. Processing of Maintenance Instructions Use Cases ................... 232
3.4.8. Instruction Maintenance ................................................................ 244
3.4.9. Instruction Matching...................................................................... 258
3.4.10. Status Management ..................................................................... 268
3.4.11. Settlement Eligibility.................................................................... 278
3.5. SETTLEMENT ............................................................................................. 285
3.5.1. General Introduction...................................................................... 285
3.5.2. Dynamic data managed by the domain ........................................ 287
3.5.3. Processing of Settlement Instructions Use Cases ....................... 301
3.5.4. Standardisation and Preparation to Settlement ........................... 327
3.5.5. Sequencing .................................................................................... 348
3.5.6. Validation, Provisioning and Booking .......................................... 357
3.5.7. Recycling and Optimisation .......................................................... 379
3.5.8. Auto-collateralisation .................................................................... 400
3.6. LIQUIDITY MANAGEMENT.......................................................................... 421
3.6.1. General Introduction...................................................................... 421
3.6.2. Dynamic data managed by the domain ........................................ 423
3.6.3. Liquidity Transfers (LT) use cases ............................................... 430
3.6.4. Processing of Liquidity Transfers use cases ............................... 433
3.6.5. Liquidity Control ............................................................................ 454
3.6.6. Notification and Information Management ................................... 459
3.6.7. NCB Business Procedures ............................................................ 462
3.7. STATISTICS, QUERIES, REPORTS AND LEGAL ARCHIVING ................... 465
Final_T2S_GFS_110.doc
Page 4
T2S General Functional Specifications
Table Of Content
3.7.1. General Introduction...................................................................... 465
3.7.2. Dynamic Data managed by the domain ........................................ 466
3.7.3. Statistical Information ................................................................... 468
3.7.4. Query Management ....................................................................... 476
3.7.5. Report Management ...................................................................... 485
3.7.6. Legal Archiving .............................................................................. 491
3.8. OPERATIONAL SERVICES ......................................................................... 498
3.8.1. General Introduction...................................................................... 498
3.8.2. Operational Monitoring ................................................................. 500
3.8.3. Data Migration................................................................................ 509
3.8.4. Events ............................................................................................ 517
3.8.5. Billing ............................................................................................. 527
4. APPENDICES ................................................................................... 539
4.1. LIST OF USE CASES .................................................................................. 539
4.1.1. Presentation ................................................................................... 539
4.1.2. Devising the use cases ................................................................. 539
4.1.3. Settlement Instruction ................................................................... 541
4.1.4. Maintenance Instruction ................................................................ 555
4.1.5. Static Data Management................................................................ 560
4.1.6. Queries ........................................................................................... 565
4.1.7. Reports........................................................................................... 570
4.1.8. Liquidity Transfers ........................................................................ 576
4.1.9. Data Migration................................................................................ 578
4.1.10. Events .......................................................................................... 580
4.1.11. Billing ........................................................................................... 580
4.1.12. Legal Archiving ............................................................................ 580
4.2. LIST OF REPORTS TYPES ......................................................................... 582
4.2.1. Statement of Holdings ................................................................... 582
4.2.2. Statement of Transactions ............................................................ 582
4.2.3. Statement of Pending Instructions ............................................... 583
4.2.4. Statement of Settlement Allegements .......................................... 584
4.2.5. Statement of End-of-Day Balance ................................................. 585
4.2.6. Statement of Static Data ................................................................ 585
4.2.7. Billing Data Report ........................................................................ 586
4.2.8. Current Settlement Day Cash Information Report ....................... 586
4.2.9. Following Settlement Day Cash Forecast Report ........................ 586
4.3. LIST OF QUERY TYPES .............................................................................. 587
4.3.1. Securities Settlement Instruction Queries.................................... 587
4.3.2. Securities Account Position Queries ............................................ 589
4.3.3. T2S Dedicated Cash Account Balance Queries ........................... 590
Final_T2S_GFS_110.doc
Page 5
T2S General Functional Specifications
Table Of Content
4.3.4. Static Data Queries ........................................................................ 594
4.4. LIST OF CHANGE REQUESTS ................................................................... 605
4.4.1. List of Change Requests Included in GFS V1.1 ........................... 605
4.4.2. List of Change Requests Not Included in GFS V1.1 ..................... 614
4.5. DATA MODEL .............................................................................................. 615
4.6. UR INDEX .................................................................................................... 615
Final_T2S_GFS_110.doc
Page 6
T2S General Functional Specifications
Approach to T2S Functional Design
Presentation of the document
1. Approach to T2S Functional Design
1.1. Presentation of the document
This document aims at presenting from a functional perspective the solution envisaged for T2S. To that
purpose, the structure of this document aims at providing an overall picture of the functional design
envisaged for T2S before entering into more an in-depth description of each domain, module and
function.
As regards general descriptions, after giving an overview of the approach retained for the T2S functional
design in the current first chapter of the GFS, the second chapter relates to the general functional
overview of T2S. This second chapter provides an overall description of the objective and the scope of
T2S, as well as an overall picture of the T2S functional architecture with a high-level functional diagram
representing the interactions between domains and modules, irrespective of implementation choices. This
chapter provides an overview of the Data Model foreseen for T2S with both static and dynamic data as
well as general description of the relationship between the different entities of the data model (detailed
description of entities and attributes are provided in the relevant chapters of the functional description).
This overall description is complemented by an overview of the security management issues for T2S.
On the basis of this general view of the functional solution envisaged for T2S, the third chapter provides a
functional description of the domains and modules identified in the overall high level diagram. For each of
these domains, this chapter describes the role and behaviour of their respective modules and functions by
presenting their respective data flow processes. It also covers a presentation of the processing of some
representative use cases illustrating the respective roles and interactions of modules in this processing.
This graphic and text description of use cases processing aims at facilitating the understanding of the
internal behaviour of the system to answer the requests originating from external parties.
1.2. Methodological elements
The Functional Design process is based on a phased approach leading to design in a first step the GFS on
the basis of the T2S User Requirements and then expand the GFS into detailed functional specifications.
The functional specifications aim at describing from a functional perspective the architecture of the future
platform (i.e. description of the different functional domains and modules and identification of their
internal interactions) with an increasing level of granularity and comprehensiveness at each stage of the
process.
Final_T2S_GFS_110.doc
Page 7
T2S General Functional Specifications
Approach to T2S Functional Design
Methodological elements
The methodology retained for this process relies on a waterfall approach according to which the GFS
should be delivered before moving to the next phase. The functional documentation is structured to
ensure full consistency, upward compatibility and reusability between the successive deliverables (i.e.
parts of GFS documentation can be reused for being expanded and enriched in the following phase).
In this process, the GFS provide a description of the overall solution envisaged for the T2S functional
design. More precisely, the GFS encompass (i) the complete logical data model (with both static and
dynamic data and the description of entities and attributes), (ii) the exhaustive list of use cases for
ensuring self consistency of the design and (iii) the descriptions of the functionalities of the future
platform according to a hierarchical description in three levels: domains, modules and functions:
•
the concept of “Domain” refers to the highest level of the hierarchical description of the T2S
functionalities. Each of the seven domains identified for T2S covers several modules
consistently grouped together according to their proximity of activity. The breakdown into
domains has been done with a view to stick to the largest possible extent to the breakdown
already identified in the T2S User Requirements;
•
the concept of “Module” refers to the second level of the hierarchical description of the T2S
functionalities. Each module covers several functions consistently grouped together according
to their proximity of activity. For the provision of the T2S services identified in T2S User
Requirements, each module can exchange information with T2S Actors as well as with
external systems via the Interface domain and with other modules belonging to the same or
different domains, as illustrated in the High-Level Diagram;
•
finally, the concept of “Function” refers to the most detailed level of the hierarchical
description of the T2S functional solution in the GFS. In this context, a function is a process
unit having access to permanent data with a view to process and exchange data flows with
other functions or external T2S Actors and systems via the Interface domain.
The provision of services identified in the T2S User Requirements relies on the intervention of one or
several functions pertaining to one or several module(s) and domain(s).
Since the GFS document is to be published, the UML (Unified Modelling Language) formalism is used for
the graphical representation of the aforementioned concepts. As market-standard representation for the
functional descriptions of T2S it aims at easing the reading and understanding of functional deliverables,
via the provision of symbols and diagrams adequate to different representations of a system such as the
functional requirements view, static structural view and dynamic behaviour view (see section 1.4conventions used).
Final_T2S_GFS_110.doc
Page 8
T2S General Functional Specifications
Approach to T2S Functional Design
Reference documents
1.3. Reference documents
The present version 1.1 of the GFS relies on the version 4.0 of the T2S User Requirements document
approved by the Governing Council of the ECB on 17th July 2008 enriched with the change requests
approved by the November 2008 T2S Advisory Group and presented in appendix.
The next version 2.0 of the GFS currently scheduled for publication in March 2009 should cover all UR
based on version 4.1 of the URD.
1.4. Specifications references – cross-referencing URD
[Not yet implemented in this version of the GFS but will be for the next version]
In order to enable cross-referencing individual specifications and user requirements, each specification will
be identified specifically via a unique number. This ensures that:
•
Each requirement is implemented.
•
Each specification can be justified with expressed requirements.
•
Once agreed, the GFS cannot be modified without full consideration of all its implication on
all related documents in particular the User requirements.
•
It will allow investigating how requirements will be implemented in the future, by looking at
all related specifications.
The design of test cases will be easier and specific to the original requirements.
For each specification, the list of all User requirements addressed by this specification will be provided.
The use case should also be uniquely – and specifically - referenced together with the user requirements
implemented in the use case.
1.5. Conventions used
UML proposes a large choice of diagrams allowing the description of systems under several perspectives.
In the context of T2S GFS, the following subset of UML diagrams is used:
•
Use case diagrams showing interactions between the T2S platform and external entities to
T2S;
•
Sequence diagrams, focusing on communications between various objects over time and the
messages triggering those communications;
Final_T2S_GFS_110.doc
Page 9
T2S General Functional Specifications
Approach to T2S Functional Design
Conventions used
•
Activity diagrams showing the workflow from a start point to the finish point and detailing the
different decision paths existing in the progression of events contained in the activity;
•
Class diagrams describing the data structure with the entities, the attributes and the relations
between these entities and Object diagrams proposing some concrete examples of data
entities instances in specific business conditions. For example, while a “Party class diagram”
will describe in general the attributes that allow describing a party, a “Party object diagram”
will show the values taken by these attributes for a specific party.
The UML formalism provides a useful basis for the description of the behaviour of a module or a function,
but the text accompanying the diagrams is critical for the understanding of this behaviour.
Final_T2S_GFS_110.doc
Page 10
T2S General Functional Specifications
General Functional Overview
Introduction
2. General Functional Overview
2.1. Introduction
2.1.1. Objective and scope of T2S
On the basis of selected extracts and abstracts of the User Requirements reflected in italics, this section of
the GFS aims at providing an overview of the scope of the business of T2S, the processing schedule and
calendar.
2.1.1.1. Scope
This section aims at covering the securities categories and type of transactions, by quoting when relevant
the Principles of T2S and the URD.
Securities categories
“T2S includes all securities that comply with the following eligibility criteria, i.e. that:
•
have an ISIN code, as instrument identifier;
•
are held with a CSD in T2S;
•
settle in book-entry form; and
•
are fungible (from a settlement process perspective).
These criteria should cover all securities currently settling in EU CSDs. Eurobonds, for example,
have an ISIN code, settle in book-entry form and are fungible. Therefore, they are eligible for
settlement in T2S if they are held with a CSD in T2S. In addition, certain securities, compliant with
the first three criteria, but non-fungible from a settlement perspective, may still be entered in and
processed by T2S under specific conditions. T2S would identify these securities as specific nonstandardised securities pertaining to certain markets (...)” {T2S.02.010}.
When prior or subsequent steps to the settlement procedure are required to register, identify or update
additional codes (registration codes, reference numbers, etc), those procedures are executed by CSDs as
currently done. These criteria should cover all securities currently settling in EU CSDs. Nevertheless, T2S
may process (under specific conditions) specific categories of securities which may not be fungible from a
settlement process perspective.
Final_T2S_GFS_110.doc
Page 11
T2S General Functional Specifications
General Functional Overview
Introduction
Type of instructions
The scope of T2S:
“is restricted to settlement services, including the functionalities required to support settlement
activities relating to asset-servicing business. Activities that extend beyond the provision of
settlement services, such as the management of corporate events, lie outside the T2S business
scope. However, T2S processes the settlement instructions in relation to those CSD processes. T2S
settles only those settlement transactions with a central bank money cash leg (or no cash leg). T2S
does not provide settlement in commercial bank money” {T2S.02.020}.
“T2S provides for a set of transaction types that allow transactions to be distinguished according to
one or more of the following parameters:
•
priority;
•
deadline;
•
recycling period;
•
lifecycle type;
•
matching mechanism; and
settlement process.” {T2S.02.030}
According to chapter 5.2.1 of the User Requirements:
“the instruction types covered by T2S are the following:
•
FoP (Free of Payment) consists of DFoP (Delivery Free of Payment) and RFoP (Receive
Free of Payment). In both cases, securities are delivered / received without payment
being made;
•
DvP (Delivery versus Payment) and RvP (Receive versus Payment) define an exchange of
securities for cash;
•
DvD (Delivery versus Delivery) defines an exchange of securities between the parties
concerned. For example, collateral substitution uses a DVD instruction;
•
DwP (Delivery with Payment) defines the delivery of cash and securities from one party to
another. For example, trade netting by a CCP may result in such instructions;
•
PFoD (Payment Free of Delivery) defines an exchange of cash without the delivery of
securities;
•
Settlement restriction (the action of setting or removing a settlement restriction)
comprises the blocking, reservation, earmarking and segregation of positions within the
Final_T2S_GFS_110.doc
Page 12
T2S General Functional Specifications
General Functional Overview
Introduction
overall position in a security in a securities account as well as the blocking and reservation
of a cash balance in a T2S dedicated cash account”.
2.1.1.2. Schedule
This section aims at presenting an outline of the T2S settlement day, service availability, specific deadlines
and calendar. It must be noted that the timing and deadlines are only indicative.
Settlement day structure
T2S provides a single harmonised timeframe for the centralised settlement procedures in central bank
money. The settlement day is divided in several periods, such as SOD period, first night-time cycle,
Maintenance window and daytime period.
T2S “Assigns a status to the schedule of the settlement day. The value of this status corresponds to
the ongoing period or main process of the settlement day.” {T2S.03.010}
The transition between the various periods is managed as an event and for each event T2S manages a
planned time, a revised time and an effective time {T2S.03.015}:
“The planned time is the time of the standard schedule that T2S applies by default for every
settlement day. It can be changed by the T2S Operator on a permanent basis when there is a
permanent change in the regular schedule” {T2S.03.016}.
The revised time is the foreseen time for the current settlement day, which usually coincides with the
planned time except when a delay has occurred {T2S.03.017}. The effective time is the time at which
the event has actually occurred for the current settlement day {T2S.03.018}.
T2S “changes its settlement day before the start of a new settlement day”.
The indicative time for the change of the settlement day is 18.45 {T2S.03.020}.
The diagram below provides a graphic illustration of the different periods of the T2S Settlement day as
currently envisaged in the URD. This graphic is complemented by a text description providing an outline of
the main features of the different periods considered.
Final_T2S_GFS_110.doc
Page 13
T2S General Functional Specifications
General Functional Overview
Introduction
High level settlement processing timetable
Final_T2S_GFS_110.doc
Page 14
T2S General Functional Specifications
General Functional Overview
Introduction
Start of day SOD
There is a start-of day procedure after the change of the settlement date and prior to the start of nighttime settlement period, in order to prepare the night-time settlement {T2S.03.030}.
Final_T2S_GFS_110.doc
Page 15
T2S General Functional Specifications
General Functional Overview
Introduction
During the SOD period, T2S:
•
validates all instructions received until the end of the previous settlement day against the
static data valid as of the new settlement date {T2S.03.050};
•
identifies the instructions eligible for settlement in the course of the new settlement day
{T2S.03.040};
•
valuates the securities for the new settlement day for auto-collateralisation purposes
{T2S.03.060}.
The Start of day period also “includes the processing of the liquidity transfer from the central bank
money payment systems” {T2S.03.070}.
Night-time settlement period
The Night-time settlement period
“starts after the end of the “start of day period” and finishes prior to the start of the maintenance
window. The night-time settlement period mainly processes settlement instructions that were input
on previous days with an intended settlement date that corresponds to the current settlement date.
T2S performs night-time settlement on existing settlement instructions that are collected and
prioritised at the start of the process and subsequently place them in a queue for settlement”.
{T2S.03.080}
Additionally, T2S provides a continuous service during the night-time by processing.
“settlement instructions received during the night-time settlement period and eligible for settlement
at the first settlement opportunity, i.e. during the night-time settlement cycle that follows their
receipt by T2S or during daytime settlement when they are received while the last night-time cycle
is running” {T2S.03.090}.
The night-time settlement period
“includes several settlement cycles with minimum gaps between them” {T2S.03.100}.
At the end of each night-time settlement cycle, T2S handles into the next night-time settlement cycle (or
into the daytime settlement if it is the last night-time cycle) all eligible instructions which have not been
previously settled {T2S.03.110}. At the end of each settlement cycle, T2S reports on the results of the
considered settlement cycle {T2S.03.120}. At the end of the night-time settlement period and before
the maintenance window, T2S reports the result of the entire night-time settlement period (including all
cycles) {T2S.03.130}.
Final_T2S_GFS_110.doc
Page 16
T2S General Functional Specifications
General Functional Overview
Introduction
Maintenance window
T2S has a technical window for system maintenance purposes {T2S.03.140} during the period where
the lowest volumes and least critical settlement activity are expected {T2S.03.150}.
Daytime processing period
The daytime settlement period starts after the end of the maintenance window. It is mainly used for T+0
instructions and for settling instructions that failed to be settled during the night-time settlement period
{T2S.03.160}.
End of day period (EOD)
The end of day period starts after the end of the daytime processing and finishes before the change of
the settlement date. Once the “EOD” period is initiated, settlement is no longer possible until the start of
the next settlement day’s night-time settlement {T2S.03.170}. The EOD period
“includes automated liquidity transfers from the T2S dedicated cash accounts to the RTGS system”
{T2S.03.180},
as well as the purging of instructions they have past their last recycling day {T2S.03.190}. The end of
day reporting is also included in this period {T2S.03.200}.
Service availability
The lifecycle management and matching services and static data services are available continuously
during settlement days, except during the maintenance window {T2S.03.210} {T2S.03.220}.
T2S interface services are also available continuously during settlement days but are restricted during the
maintenance window. This means that settlement instructions and the static data updates received in
application-to-application mode during the maintenance window are queued for processing at the end of
this maintenance window. The static data interfaces in user-to-application mode and the queries are not
available during the maintenance window {T2S.03.230}.
Finally, T2S settlement services are available continuously – but exclusively –, during the night-time and
the daytime settlement periods {T2S.03.240}.
Specific deadlines
Several deadlines or “cut-off” times are applicable in T2S.
DvP instructions
The deadline for receiving DvP instructions for same-day settlement is 16.00. All DvP instructions, eligible
for settlement and arriving before this deadline are submitted to a settlement attempt. DvP settlement
instructions arriving after this deadline are moved to the night-time settlement period on the next
Final_T2S_GFS_110.doc
Page 17
T2S General Functional Specifications
General Functional Overview
Introduction
settlement day (if not cancelled). The recycling of DvP fails resulting from earlier attempts is stopped after
this deadline. If not cancelled, the latter are recycled for the next settlement day {T2S.03.250}.
Bilaterally agreed treasury management instructions
The deadline for receiving bilaterally agreed treasury management instructions for same-day settlement is
set to 18.00. When eligible, the latter are submitted to a settlement attempt. The cash generated is not
used for other settlement purposes, i.e. for the recycling of DvP failures {T2S.03.270}.
Intraday Free of Payment
The deadline for receiving FOP instructions for same-day settlement is set to 18.00. FOP instructions
eligible for settlement and received before this deadline are submitted to settlement attempt. Those FoP
settlement instructions arriving after this deadline are moved to the night-time settlement period on the
next settlement day (if not cancelled). The intraday recycling of unsettled FoP resulting from earlier
attempts is stopped after this deadline {T2S.03.280}. If not cancelled, the latter are recycled for nextday settlement.
Central Bank operations
The deadline for receiving instructions for central banks operations for same-day settlement is 18.00,
whether it is a DvP or an FOP instruction. Provided they are received before this deadline and are eligible
for same-day settlement, these instructions are submitted to settlement attempt. The cash generated is
not used for other settlement purposes, i.e. for recycling DvP fails {T2S.03.290}.
First night-time settlement cycle
The deadline for receiving settlement instructions for settlement in the first night-time settlement cycle is
19.30. After this deadline T2S moves all received instructions to the second night-time settlement cycle
{T2S.03.300}.
Calendar
T2S is open for the settlement of the FoP from Monday to Friday every week, independently of TARGET2
closing days {T2S.03.305}. For settlement in Euro central bank money (i.e. settlements against
payment or free of delivery), the calendar is the same as the calendar of TARGET2 {T2S.03.310}.
For the settlement in non-Euro central bank money, the calendar is established according to the opening
days of the relevant central bank {T2S.03.320}.
At the end of the Friday settlement day, the system moves to the Monday settlement date and performs
the related schedule until the end of the night-time settlement period (finishing during the night between
Friday and Saturday). On Monday, T2S starts performing the schedule with the preparation of the daytime
settlement as the continuation of the same settlement day {T2S.03.340}.
Final_T2S_GFS_110.doc
Page 18
T2S General Functional Specifications
General Functional Overview
Introduction
During the weekends, T2S interfaces and processes are not available on a regular basis {T2S.03.350}.
Nevertheless, T2S should be technically capable to provide those services seven days a week based on
specific needs (migration, issuance in direct holding countries), when required {T2S.03.360}.
2.1.2. T2S Actors
On the basis of selected extracts and abstracts of the User Requirements reflected in italics, this section of
the GFS aims at describing the various T2S Actors. A T2S Actor is any legal entity or organisation
interacting with T2S either directly or indirectly, i.e. through a CSD in T2S, for the purpose of securities
settlement. The T2S Actors are:
•
CSDs in T2S;
•
T2S Parties;
•
T2S Operators;
•
National Central Banks in T2S;
•
Payment Banks.
T2S Actor is a business concept to be kept separate from the more technical concepts of T2S System User
- which is an individual or a technical process/application allowed to log into T2S with a login name and
password - and role that defines the access rights a T2S System User is granted. As a consequence, the
T2S services are not accessed by T2S Actors but, more precisely, by T2S System Users (belonging to
these T2S Actors) linked to their relevant roles.
Although distinguished, the aforementioned concepts are strictly linked: each T2S Actor, in fact, may have
one or more T2S System Users whose role/s are different depending on the typology of the T2S Actor
itself, meaning that there is a specific association among each T2S Actor type and the list of roles its T2S
System User/s can be granted.
Here below the definition of each T2S Actor typology is provided with a general description of the possible
roles their respective T2S System User/s can be granted. Such roles are described, just as examples, from
a business perspective, not being specified, for the time being, the exhaustive, detailed list of available
privileges to be granted to each specific role.
2.1.2.1. CSD in T2S
A CSD in T2S is a CSD that (i) is recognised under Article 10 of the Settlement Finality Directive; (ii)
settles in central bank money in a T2S eligible currency; and (iii) is a legal entity that has entered into a
contractual relationship for the use of T2S.
Final_T2S_GFS_110.doc
Page 19
T2S General Functional Specifications
General Functional Overview
Introduction
"The CSD role classification includes all T2S system users of a CSD participating in T2S. It does not
include the T2S System Users of the CSD’s participants. T2S makes no differentiation between the
roles of Investor CSD and Issuer CSD. Most CSDs take on both aforementioned roles. With the
exception of possible national specificities, T2S provide the harmonised scope of services to CSDs”
{T2S.04.050}.
1 – CSD System Administrator
This role is “responsible for
•
the user administration for all of the CSD’s T2S System Users, including the assignment of
roles;
•
•
the configuration of roles for the T2S System Users of the CSD’s T2S Parties;
and the day-to-day monitoring of system applications, processes, and communication
channels at the CSD”.
CSDs are “responsible for defining for their T2S Parties the functionality that those parties can use.
Therefore, it is possible for CSDs to configure roles and access rights for their T2S Parties to
functionality, based on their business requirements”. {T2S.04.060}:
2 – CSD business user
This role is “responsible for:
•
maintaining the CSD’s securities account static data in T2S;
•
the parameterisation of its securities account structure;
•
maintaining T2S Party static data, including securities accounts, for its participants;
•
maintaining CSD-specific instrument static data and, where applicable, the instrument
static data across all CSDs;
•
maintaining any settlement restrictions;
•
the possibility of querying T2S dedicated cash account balances linked to the securities
accounts of its participant at that CSD, when granted this privilege by the relevant NCB
and Payment Bank;
•
maintaining privileges for all positions, settlement instructions and static data for the CSD
and its participants that are required for business support.” {T2S.04.070}
Final_T2S_GFS_110.doc
Page 20
T2S General Functional Specifications
General Functional Overview
Introduction
2.1.2.2. T2S Party
A T2S Party is a legal entity or, in some markets, an individual that has a contractual relationship with a
CSD in T2S for the processing of its settlement-related activities in T2S. It does not necessarily hold a
securities account with the CSD. Examples of such parties (non-exhaustive) are:
• Indirect and direct CSD participants, (including those acting as Payment Banks for other CSD
participants);
• stock exchanges and multilateral trading platforms that route pre-match trades or settlement
instructions to CSDs on behalf of trading participants;
• central counterparts (CCPs);
• central banks as CSD participants;
• CSDs as participants of other CSDs; and
• securities processing outsourcer that process securities transactions on behalf of other financial
institutions.
“The T2S Party role includes all T2S System Users that a CSD maintains for the legal entities with
which it has a legal relationship and which have direct connectivity to T2S. The model supports two
types of role: T2S Party system administrator and T2S Party business user” {T2S.04.080}.
1 – T2S Party system administrator
This role is “responsible for user administration for all T2S System Users of the T2S Party of a
specific CSD, including the assignment of roles”. {T2S.04.090}
2 – T2S Party business user
“The scope of functions and processes that a T2S Party business user can access depends on the
business services provided by the CSD. However, the data access of a T2S Party is limited to its
own accounts, positions and transactions”. {T2S.04.100}
2.1.2.3. T2S Operator
The T2S Operator is the legal and/or organisational entity/entities that operates/operate the T2S platform.
“The T2S operator is the top level of the hierarchical role and access rights model. The T2S
Operator role classification includes all T2S System Users of the entity, which are responsible for
the day-to-day operation and management of T2S. The T2S actors managed by this entity are CSDs
and NCBs participating in T2S. At the highest level, the T2S operator has access to all data and
functionality in the subordinate level” {T2S.04.020}.
Final_T2S_GFS_110.doc
Page 21
T2S General Functional Specifications
General Functional Overview
Introduction
A T2S System User of a T2S Operator can be granted access rights to functions and data of the platform
according to the following roles.
1 – T2S System Administrator
This role is “responsible for: {T2S.04.030}:
•
the user administration for all T2S System Users of the T2S Operator;
•
the user administration for the CSD system administrators;
•
the user administration for the NCB system administrators;
•
the
day-to-day monitoring
of
system
operations,
applications,
processes,
and
communication channels;
•
the configuration of privileges and privilege classes in T2S;
•
the configuration of roles for the T2S System Users of the CSDs and NCBs;
•
the configuration of roles for T2S business and operations support users;
•
the archiving of production data and the retrieval of archived data;
•
contingency operations, e.g. starting and stopping processes outside of the normal
operating schedule, in T2S;
•
and the configuration of CSDs and NCBs as system entities”.
2 – T2S business and operations support user
This role is “responsible for {T2S.04.040}:
•
maintaining T2S Party static data, excluding securities accounts, for CSDs participating in
T2S;
•
maintaining T2S Party static data, excluding T2S dedicated cash accounts, for NCBs
participating in T2S;
•
providing business and operations support to CSDs and NCBs;
•
maintaining T2S domains for global and CSD-specific attribute lists, i.e. the valid list of
values for a field;
•
technical support (e.g. network and communications) for directly connected T2S Parties;
•
and query and maintenance privileges for business functions and data of all T2S Actors
for provision of business and operations support.
Final_T2S_GFS_110.doc
Page 22
T2S General Functional Specifications
General Functional Overview
Introduction
Maintenance and query privileges of CSDs, the CSDs’ participants, and NCBs with respect to
business data, such as securities and cash positions and transactions, are limited to contingency
response situations only. The T2S system administrator restricts access to maintenance and query
functionality to a subset of T2S business and operations support users, based on the support
requirements of CSDs and NCBs. For example, maintenance privileges in relation to a CSD could be
limited only to the business support user for that specific CSD.”
2.1.2.4. National Central Bank in T2S
A National Central Bank in T2S provides cash account services to banks for securities settlement in T2S in
central bank money.
“The NCB role classification includes all T2S System Users of a NCB as a liquidity provider through
T2S dedicated cash accounts”. {T2S.04.110}
1 – NCB system administrator
This role is “responsible for {T2S.04.120}:
•
the user administration for all T2S System Users of the NCB, including the assignment of
roles;
•
and the configuration of roles for the T2S System Users of the NCB’s participating
Payment Banks”.
2 – NCB business user
This role “describes all T2S System Users in NCBs that require access to the static and transactional
data of Payment Banks operating T2S dedicated cash accounts. The role enables the T2S System
User of the NCB to {T2S.04.130}:
•
maintain the Payment banks with dedicated T2S cash accounts as T2S Parties;
•
maintain the limits for payment banks on T2S dedicated cash accounts;
•
query all T2S dedicated cash accounts for which the NCB is responsible;
•
query the credit line utilisation on T2S dedicated cash accounts;
•
grant a CSD the privilege of querying T2S dedicated cash account balances;
•
identify the postings resulting in the utilisation of liquidity;
•
identify the expected postings of cash on a T2S dedicated cash account;
•
identify the owner of every T2S dedicated cash account;
Final_T2S_GFS_110.doc
Page 23
T2S General Functional Specifications
General Functional Overview
Introduction
•
identify the cash leg of a settlement instruction(s), posted on the T2S dedicated cash
account by providing a unique transaction reference;
•
and query the balances and postings on T2S dedicated cash accounts for which the NCB
is responsible.
However, it is not possible for the NCB to query the settlement instructions, securities transactions
and securities positions of a T2S securities account unless the CSD participant and the CSD have
granted this privilege explicitly to an NCB for the securities account. This also includes the securities
leg associated with a cash posting”.
2.1.2.5. Payment Bank
A Payment Bank is either a central bank or a private bank used to settle the cash leg of securities
settlements: it provides the cash account to support the settlement of the securities transactions of
another financial institution in central bank money (CeBM).
“The Payment Bank role includes all T2S System Users of Payment Banks that require access to the
T2S dedicated cash account balances and postings of the T2S dedicated cash accounts they provide
for the purpose of securities settlement”.{T2S.04.140}
1 – Payment Bank system administrator
This role is “responsible for the user administration of the T2S System Users of the Payment Bank,
including the assignment of roles”. {T2S.04.150}
2 – Payment Bank business user
“The business user role for Payment Banks includes all T2S System Users of Payment Banks
providing a T2S dedicated cash account for securities settlement. The role enables the T2S System
User of the Payment Bank to {T2S.04.160}:
•
maintain the limits for Payment Banks on T2S dedicated cash accounts;
•
grant a CSD the privilege of querying its T2S dedicated cash account balances;
•
maintain standing instructions for the transfer of liquidity between the TARGET2 RTGS
account and the T2S dedicated cash account(s);
•
query all its T2S dedicated cash accounts and the balances on those accounts;
•
query the credit line utilisation on T2S dedicated cash accounts;
•
query the postings resulting in the utilisation of liquidity;
•
maintain limits for banks using their T2S dedicated account(s) for securities settlement;
Final_T2S_GFS_110.doc
Page 24
T2S General Functional Specifications
General Functional Overview
Introduction
•
query the corresponding securities transaction of a cash posting against the T2S
dedicated cash account(s);
•
and query the balances and postings on its T2S dedicated cash account(s).
It is not possible for the Payment Bank to query the settlement instructions, securities transactions
securities positions of a T2S securities account unless the CSD participant and the CSD have
granted this privilege explicitly to the Payment Bank for the securities account. This also includes
the securities leg associated with a cash posting”.
2.1.3. Multi-currency in T2S
Although the primary focus of T2S shall be settlement services in Euro (Principle 9), according to Principle
10 T2S must be technically capable of settling currencies others than Euro. The T2S User Requirements
Document specifies that T2S must be “multi-currency capable” from its first release on {T2S.02.040}.
Furthermore, it should be possible for a granted user (T2S system administrator) to add a new currency
{T2S.16.340}, to update it {T2S.16.350} and to delete it {T2S.16.360}.
For this multi-currency capability, the T2S User Requirements distinguish:
•
“T2S Settlement Currencies” for which T2S provides settlement in central bank money on
T2S dedicated cash accounts for securities transactions; T2S Settlement Currencies are
currencies for which an appropriate arrangement has been put in place between T2S and the
central bank issuing the currency (or a central bank authorised to hold T2S dedicated cash
accounts denominated in this currency and to settle transactions on these accounts) to
ensure cash settlements in central bank money on T2S dedicated cash accounts denominated
in this currency {T2S.08.440}. Only CeBM is accepted as a T2S settlement currency;
•
“T2S Recognised Currencies” for which T2S provides only validation, matching and reporting,
where the settlement of the cash leg of the securities transaction is outside T2S.
The settlement services provided by T2S for a given currency depend on the type of the currency. The
table below gives some examples of the differences between the services provided by T2S for T2S
Settlement Currencies and T2S Recognised Currencies:
TYPE OF
T2S
DENOMINATION
MATCHING OF
CASH
AUTO-
SECURITIES
CURRENCY
DEDICATED
OF SECURITIES
CASH LEG
SETTLEMENT
COLLATERALISAT
SETTLEMENT
ION
CASH
ACCOUNTS
T2S
Settlement
Yes
Yes
Possible in T2S
In T2S
Possible in T2S
In T2S
T2S
Recognised
No
Yes
Possible in T2S
Outside T2S
Not possible in
T2S
In T2S
Final_T2S_GFS_110.doc
Page 25
T2S General Functional Specifications
General Functional Overview
Introduction
In spite of its multi-currency capability, T2S should not be considered as a foreign exchange settlement
platform, since T2S does not provide any service to manage foreign exchange risks (e.g. cross-currency
limits) or process cross-currencies settlements (no cross-currencies payment versus payment services):
•
a T2S dedicated cash account is denominated in only one currency;
•
each single settlement transaction has one single cash leg in one single currency;
•
cash netting is impossible between instructions having cash legs in different currencies.
However, T2S will support the settlement of T2S eligible securities issued in one currency and settled in
another T2S Settlement Currency {T2S.02.070}, e.g. euro cash settlement will be allowed for securities
issued in non-euro currencies (and vice versa).
The following paragraph highlights where the different aspects of the T2S multi-currency capacity are
dealt with in the GFS [DOMAIN – Module]:
•
matching facility for T2S Settlement Currency and T2S Recognised currencies [LCMM –
Matching];
•
ability for a T2S Party to hold several T2S dedicated cash accounts in different T2S
Settlement Currencies with the relevant NCBs [STATIC DATA];
•
linked transactions can be denominated in different T2S Settlement Currencies within a
collection and a security denominated in any currency can be settled in any T2S Settlement
Currency [LCMM – Validation];
•
applicability of the same optimisation procedures and auto-collateralisation facilities for all
T2S Settlement Currencies (provided an agreement is established with the relevant central
bank for auto-collateralisation); in that respect it is worthwhile indicating that all settlement
instructions (and hence relating settlement transactions) are processed together through one
single settlement process, whatever their respective currency denominations; of course, this
does not result in providing foreign exchange services in T2S (since a cash debit on a T2S
dedicated cash account denominated in a given T2S Settlement Currency always results in a
cash credit on another T2S dedicated cash account denominated in the same T2S Settlement
Currency); however, this optimises the use of securities resources when several instructions
denominated in different T2S Settlement Currencies aim at settling the same ISIN
[SETTLEMENT – Recycling and Optimisation, Auto-collateralisation];
•
ability to transfer liquidity from T2S to the relevant RTGS system for all T2S Settlement
Currencies [LIQUIDITY MANAGEMENT – Liquidity Control];
Final_T2S_GFS_110.doc
Page 26
T2S General Functional Specifications
General Functional Overview
Introduction
•
all T2S processing parameters (e.g. Tolerance amounts for T2S Settlement and T2S
Recognised Currencies, limits for T2S settlement currency) are defined independently for
each currency [STATIC DATA];
•
T2S takes into account the calendar of the RTGS system for T2S Settlement Currencies
[STATIC DATA];
•
T2S accepts the currency as a parameter for most of the available queries [SRQA – Queries];
•
Securities valuation can be done in any T2S recognised currency [STATIC DATA];
•
Auto-collateralisation limits and Auto-collateralisation eligibility can be defined for each T2S
settlement currency [SETTLEMENT –Auto-collateralisation].
Finally, in order to support the provision of cash settlement services in T2S Settlement Currencies,
interactions between T2S and RTGS and collateral management systems are handled on an equal footing
[INTERFACE]:
•
the interaction between T2S and non-Euro RTGS systems will be based on the same interface
as the one to be developed between T2 and T2S;
•
the interface to collateral management systems is designed following an “open” concept in
such a way that the same interface can be used to connect CCBM2 and any other collateral
system for non-Euro NCBs.
2.1.4. Other systems interacting with T2S
T2S also interacts with the following external systems:
•
Euro and non-Euro RTGS systems providing liquidity, in CeBM, for settlement purposes;
•
Collateral management systems providing data for collateral evaluation.
Although distinguished from the T2S Actors such systems exchange communication with T2S passing
through the Interface domain.
2.1.4.1. Euro and non-Euro RTGS systems
Depending on the decision taken by the relevant NCB, T2S interacts with Euro and non-Euro RTGS
systems for the processing of liquidity transfers from such systems to T2S and vice versa, aiming at
providing T2S dedicated cash accounts with the liquidity needed for settlement.
Final_T2S_GFS_110.doc
Page 27
T2S General Functional Specifications
General Functional Overview
Overall high level diagram
2.1.4.2. Collateral management systems
T2S receives from CCBM2 (or other collateral management systems) a daily update of the static data for
the valuation of securities positions to be used in the ambit of auto-collateralisation functionalities.
2.2. Overall high level diagram
The high-level functional diagram aims at providing an overview of T2S at domains level. It refers to a
functional conceptual representation, irrespective of the technical choices to be retained for the
implementation of the aforementioned domains.
The following elements are presented on the diagram:
•
Domains;
•
Modules;
•
Data-flows exchanged between the modules and with the outside of the platform.
Final_T2S_GFS_110.doc
Page 28
T2S General Functional Specifications
General Functional Overview
Description of functional domains
Only a limited number of flows figures on the diagram in order to limit the complexity of the
representation. The exhaustive list of detailed flows can be found in the domains and modules
descriptions of chapter 3.
T2S Actor, RTGS, Collateral Management System
Communication U2A/
A2A
Certificate
Issuance
Rejection
Status/Response/Notification message
Structure and Syntax
Check
Access Management
Flow Management
Interface
Operational
data
Migration
Data
Invoice data
Scheduling
data
Billing
Data Migration
Archive
Request
Data
Report Data
Immediate
Liquidity
Transfer Data
Statistical
Data
Query Data
Allegement
Data
Status Data
Settlement /
Maintenance
Instruction
Data
Report
Management
Notification and
Information
Management
Status Management
Instruction Validation
Query
Management
NCB Business
Procedures
Instruction
Maintenance
Instruction Matching
Liquidity Control
Settlement Eligibility
Securities Account
Data
Management
LCMM
Statistics, Reports,
Queries and Archive
Liquidity
Transaction
Data
Request for
Maintenance
Data
Status Data
Sequencing
Scheduling
Statistical
Information
Operational
Monitoring
Legal
Archiving
Settlement
Instructions
Data
Standardisation and
Preparation to
Settlement
Settlement
Operational
data
System data
Archived
data
T2S Operator
Technical
infrastructure
T2S Actor
Party Data
Management
Security Data
Management
Liquidity Management
Operational services
SD Change
Data
Auto-collateralisation
Validation
Provisioning and
Booking
Recycling and
Optimisation
T2S Dedicated
Cash Account Data
Management
Rules and
Parameters
Data Management
Static Data
Management
2.3. Description of functional domains
This section of the GFS aims at providing a synthetic description of the role of each domain identified
above in the overall high-level diagram and at recalling the different modules and functions covered by
each domain and described in a more detailed way within the chapter 3.
Final_T2S_GFS_110.doc
Page 29
T2S General Functional Specifications
General Functional Overview
Description of functional domains
2.3.1. Interface
The T2S interface handles all incoming and outgoing communication with all T2S Actors1 and other
external systems2 (like RTGS systems and Collateral Management systems), manages the use of the
appropriate communication medium and undertakes the relevant technical entry checks. In turn, T2S
Actors connecting to T2S have to comply with the formats and specifications defined in T2S.
T2S supports the connectivity needs of CSDs and T2S parties as follows:
•
T2S communication is available by using messages as well as through online-screen based
activities, i.e. either in application-to-application mode (A2A) to allow direct communication
between software applications via XML messages and in user-to-application mode (U2A)
concerning activities performed manually by T2S users via on-screen display.
•
For the T2S communication via messages the ISO 20022/UNIFI is the single standard,
concerning both inbound and outbound communication. In addition, the T2S Interface
complies with Giovannini protocol recommendations for both inbound and outbound
communication. Therefore, all messages exchanged between T2S and T2S Actors are based
on XML technology and comply with the ISO 20022 standards on messages. They are sent to
T2S either individually or within a file containing one or several messages.
The T2S interface services are available continuously during settlement days. However, their availability is
restricted during the maintenance window and is not ensured during weekends and closing days (except
exceptional cases).
The T2S interface domain encompasses three modules:
2.3.1.1. Access Management
The access management module checks that the communication is transmitted via a secure network by a
trusted party in order to protect T2S functionality and data against intrusion and unauthorised access.
The access management module also provides (i) authentication mechanisms to check whether the T2S
system user connected is allowed to use the system (check of its identity via a certificate of T2S system
user) and (ii) authorisation mechanisms to check whether the user has the appropriate privileges required
to use the given function.
The access management module is composed of three functions:
•
The Access Control function ensures the strong authentication mechanism to avoid intrusions
and unauthorised accesses to T2S for every incoming communication;
1
For some tasks of the T2S operator (e.g. operational monitor, technical tools, and alternative access in emergency situations) a direct access to the
relevant tool is envisaged.
2
See chapters 2.1.2 “T2S Actors” and 2.1.4 “Other systems interacting with T2S” for a detailed description.
Final_T2S_GFS_110.doc
Page 30
T2S General Functional Specifications
General Functional Overview
Description of functional domains
•
The Certificate Management function ensures (i) the administration, the generation and the
storage of certificates and (ii) the provision of answers to requests of the Access Control
function when a concrete access attempt to T2S takes place and a certificate has to be
checked;
•
The Roles Control function ensures the answers to requests of the Access Control function
related to the roles assigned to the requested sender.
2.3.1.2. Structure and syntax check
The structure and syntax check module receives different communication types from the access
management module (e.g. settlement instructions, maintenance instructions or query requests) and
performs a series of checking procedures. This module determines the addressee domain of T2S by the
incoming communication and identifies the concrete underlying T2S operation type (e.g. settlement
instruction, static data maintenance…) for the subsequent checks. During its entry check the relevant
technical validation processes regarding the specific structure, format and syntax of messages related to
the concrete T2S operation are executed. These processes apply to both A2A and U2A mode.
The structure and syntax check module is composed of two functions:
•
The Communication Identifier function ensures the technical validation of incoming files and
their split into single messages. This function also ensures the file validation, the
identification of (i) communication means, (ii) communication channel, (iii) nature of
communication and the forwarding of messages to the next function;
•
The Entry Check function ensures that each single message (including bulk messages)
forwarded to the Flow Management module is well-formed and valid.
2.3.1.3. Flow management
Receiving the validated communication from the structure and syntax check module, this module acts as
an information editor and router. Regarding its inbound dimension the module extracts all the relevant
communication data from the messages received in order to structure the information to be processed by
the subsequent modules. Moreover, it determines the relevant modules and routes the structured data to
them. Concerning its outbound dimension, this module generates the relevant messages based on data
received by the respective domain (status messages, response messages to queries, etc.) and sends them
to the relevant T2S Actors or to be displayed on-screen. Furthermore, it identifies the specific subscription
preferences for all outbound communication by interacting with the static data module.
The Flow Management module is composed of two functions:
•
The Information Router function manages the inbound and outbound communication flows;
Final_T2S_GFS_110.doc
Page 31
T2S General Functional Specifications
General Functional Overview
Description of functional domains
•
The Message Generator function forwards the appropriate messages, in correct structure,
syntax and format, on basis of information received from the others domains.
2.3.2. Static Data Management
The Static Data Management domain provides T2S System Users with an integrated and consistent set of
common information thanks to a single access point for the creation, update and deletion of static data
"relevant" for T2S in performing its functions, such as, Party, Securities and Cash accounts among others.
T2S system users of this domain belong to CSDs, NCBs, ECB, T2S parties, Payment Banks and T2S system
operator - each T2S system user accessing and using static data management facilities according to its
own specific access profile. Different T2S system users have different roles assigned and, as a
consequence, are allowed to see and possibly change different pieces of information.
T2S Operators belong to a specific user category devoted to system administration activities. With respect
to static data management, they are responsible for entering and managing CSDs and NCBs data and a
set of global rules and parameters. They can also act on behalf of other user categories in order to
perform some specific actions or within some pre-defined contingency scenarios.
Two different interaction modes are envisaged to use the functions belonging to this domain: interactive
mode (concerning activities performed on single static data entities) and batch mode (e.g. for massive
upload of portion of the data store).
All changes in static data can be executed both in two eyes and four eyes mode, the actual mode to be
adopted being established by the data owner. Proper functions are envisaged in order to allow each
domain of the system to access the needed set of static data or to feed the other domains using some
specific load procedures.
Versioning facilities allow the implementation of data history and data revision features, in order to keep
track of all past data changes and to enter changes meant to become effective at a future date.
The static data management functions are grouped in five modules, each module being in charge of a
given subset of T2 static data: Party Data Management, Security Data Management, Securities Accounts
Data Management, T2S Dedicated Cash Account Data Management and Rules and Parameters Data
Management.
Each Static Data Management module is composed of seven functions:
•
The Static Data Access function enables authorized T2S system users to access static data
objects according to their own specific access rights, i.e. to view information about the
objects they are granted access to;
Final_T2S_GFS_110.doc
Page 32
T2S General Functional Specifications
General Functional Overview
Description of functional domains
•
The Static Data Consistency Check function checks the consistency of the Static Data
Maintenance Request against the relevant static and dynamic data;
•
The Static Data Maintenance Execution function enables authorized T2S system users to
maintain Static Data objects according to their own specific access rights, i.e. to create new
objects or to update or delete existing objects;
•
The Static Data Notify Maintenance function sends a Maintenance Notification to the LCMM
domain so to allow it performing all the necessary re-validation of instructions potentially
impacted by the static data changes and possibly sending a message both to the CSD and to
the instructing party in order to inform them in case of a negative result of the revalidation. ;
•
The Request Enqueue function handles the queuing of any maintenance request or
maintenance approval request received during a night-time settlement cycle, in order to
defer its execution until the cycle itself;
•
The Notify Reception function sends a Receipt to the requestor, in order to notify the
reception and the deferred execution (i.e. at the end of the current night-time settlement
cycle) of a maintenance request or a maintenance approval request;
•
The Retrieve Queued Requests function is triggered by at the end of each night-time
settlement cycle and it retrieves all the queued maintenance requests or maintenance
approval requests (i.e. all the requests received while the last night-time settlement cycle
was running), in order to submit them to the Static Data Maintenance Execution function for
processing.
2.3.3. Lifecycle Management and Matching (LCMM)
The LCMM domain deals with instructions received through the Interface domain. It is responsible for
(i) the validation and matching of individual settlement instructions, before they are submitted to the
Settlement domain, and (ii) the management and execution of maintenance instructions.
This domain is also in charge of checking the possible impact of static data changes on pending
instructions, managing the consequences of such impact when relevant and keeping tracks of the changes
in the lifecycle of instructions. The services provided by this domain are available continuously during the
whole day T2S operating hours, with the exception of the maintenance window.
The LCMM domain encompasses five modules:
2.3.3.1. Instruction Validation
The Instruction Validation module checks the consistency of instructions sent to T2S by a CSD or directly
connected T2S Party. These consistency checks ensure that each incoming instruction is consistent with
Final_T2S_GFS_110.doc
Page 33
T2S General Functional Specifications
General Functional Overview
Description of functional domains
T2S Static Data. No syntax (or format) checks are performed by this module, as this kind of validation is
carried out by the Interface domain.
T2S validates all incoming instructions received during the operating day, based on a harmonised set of
validation rules. Maintenance instructions (which amend, cancel, hold or release settlement instructions)
are validated as well.
The Instruction Validation module is composed of eight functions:
•
The Duplicate Check function checks for and rejects duplicate or multiple submission of
incoming new instructions; this checking is based on a combination of the T2S Actor
identifier and the instruction reference assigned by the instructing party. This check is done
vis-à-vis the same category of T2S instructions (settlement or maintenance instructions), the
non-settled individual settlement instructions and also the individual settlement instructions
settled during the previous days (the number of days being a parameter to be configured at
T2S level);
•
The Validation Flow Management function monitors that the instruction (either settlement or
maintenance) is routed to the appropriate sub-functions of the Settlement Instruction
Validation function or of the Maintenance Instruction Validation function; this function also
stores the nature and the outcome of the different validations and reports all errors to the
Validation Status Management function;
•
The Settlement Instruction Validation function performs all the validations on settlement
instructions;
•
The Maintenance Instruction Validation function performs all the validations on maintenance
instructions;
•
The Instruction Management function has two different purposes: (i) it splits the “groups of
instructions”, the already matched instructions entered as a single instruction or two legged
instructions and (ii) it generates a settlement instruction for the unsettled part of a partially
settled instruction;
•
The Selection of Instruction to be revalidated function selects and revalidates the individual
settlement instructions that have been introduced into the system and have already been
validated on basis of information from the Static Data Management domain on the different
updates in static data;
•
The Validation Status Management function gathers the information sent by the Validation
flow management function in order to identify the validation processes already achieved by
each instruction according to their processing attributes, assigns a new Validation status
value to the instruction taking into consideration the result of each validation process and
Final_T2S_GFS_110.doc
Page 34
T2S General Functional Specifications
General Functional Overview
Description of functional domains
creates the individual settlement instructions, once the action related to a settlement
instruction is accepted;
•
The Routing function routes the validated instructions to the appropriate subsequent module:
Instruction Matching module, Settlement Eligibility module or Instruction Maintenance
module, according to their processing attributes.
2.3.3.2. Instruction Matching
The Instruction Matching module compares the settlement details provided by the buyer and the seller of
securities to ensure that both parties agree on the settlement terms of the transaction. The Matching
Module matches trading instructions in a standardised way (compliant to ECSDA matching proposals).
Matching is a real-time process which may occur throughout the whole T2S settlement day (except the
maintenance window).
Those instructions which do not require matching are forwarded from the validation module to the
Settlement eligibility Module for its processing, and therefore are not under the scope of the Matching
module. Similarly, already matched instructions (i.e. matched outside T2S) are not reprocessed by the
Matching Module.
For settlement instructions which require matching and are already validated, the Matching Module looks
for the counterparty instruction among a repository of accepted and unmatched instructions already
stored in T2S. Settlement instructions that enter T2S can be matched whether they are “on hold” or in a
“release” status.
The Instruction Matching module is composed of three functions:
•
The Matching Algorithm function performs (i) different sequential matching processes, in
order to select the instruction(s) that can match together and (ii) when several instructions
can match together due to a cash tolerance amount, chooses the most suitable instruction to
match against (i.e. the one with the smallest cash amount difference); when instructions are
matched, a common T2S matching reference is assigned to both individual settlement
instructions;
•
The Matching Status Management function updates the matching status values of the
individual settlement instruction(s) depending on the result of the previous function;
•
The Matching Allegement function (i) collects the data of the unmatched individual
settlement instruction and forwards it to the Interface domain in order to send an allegement
message to the relevant T2S Actor and (ii) checks if a matching allegement message was
previously sent for an individual settlement instruction and triggers the removal of the
Final_T2S_GFS_110.doc
Page 35
T2S General Functional Specifications
General Functional Overview
Description of functional domains
allegement if the considered instruction has been matched since the sending of the
allegement message.
2.3.3.3. Instruction Maintenance
The Instruction Maintenance module handles maintenance instructions that amend, cancel, hold or
release a settlement instruction and release or cancel a settlement instruction and maintenance
instructions that release or cancel a settlement instruction for Conditional Securities Delivery purpose:
•
Amend: modification of a settlement instruction. After matching of the settlement instruction,
only non-matching fields can be modified;
•
Cancel: cancellation of settlement instruction. Both counterparties’ cancellation is needed
after matching;
•
Hold and release mechanisms: allow CSD participants, CSDs and directly connected T2S
participants to hold back or release instructions for settlement. T2S Parties may send
maintenance instructions to hold and to release as many times as required;
•
Conditional Securities Delivery (CoSD) functionality: this mechanism allows the settlement of
instructions that require the fulfilment of a previous condition outside T2S.
•
This module is also in charge of the cancellation of unmatched instructions that remain as
such after a standard period beyond their intended settlement day, or the date of their last
status value change, and also those instructions which have reached the end of their
recycling period. Finally it sends requests to the settlement domain if necessary to perform
actions on transactions.
The Instruction Maintenance module is composed of nine functions:
•
The Maintenance Instruction Routing function identifies the action category and routes it to
the relevant
Instruction
Maintenance
function:
Instruction Amendment,
Instruction
Cancellation, Hold/Release Mechanisms or CoSD Release/Cancel Maintenance Instruction;
•
The Instruction Amendment function allows amending business data present in the existing
individual settlement instructions, depending on the current values for the eligibility status
and the validation status;
•
The Instruction Cancellation function allows cancelling the affected individual settlement
instructions sent by a T2S Actor, according of its current status value. A Cancellation of
individual settlement instructions is allowed until their settlement and can be done
unilaterally or bilaterally;
Final_T2S_GFS_110.doc
Page 36
T2S General Functional Specifications
General Functional Overview
Description of functional domains
•
The Instruction cancellation by the system function cancels individual settlement instructions
after a standard period of time as defined in Static Data according the following cases:
expiration after the recycling period, expiration of standard period of working days after the
intended settlement for the unmatched instructions;
•
The Hold/Release mechanism function checks the status value of the affected individual
settlement instruction and validates the hold or release of the instruction;
•
The Maintenance Allegements function sends the allegement messages to the involved T2S
Actors when the counterpart sends any of the following actions: cancellation, amendment
(partial settlement allowed), hold or release;
•
The Conditional Securities Delivery (CoSD) Instruction maintenance: Release/Cancel function
handles administering party(ies)’ requests to release or cancel settlement instructions which
flagged by T2S as CoSD instructions;
•
The Maintenance Status management function forwards all status values updates of the
individual settlement instruction and of the maintenance instruction to the Status
Management Module;
•
The Process Settlement Status function receives requests from the functions of the
Instruction Maintenance Module “Request” and the Instruction Validation Module “Request”
in order to ask the settlement domain for the logical deletion of the settlement transactions
affected.
2.3.3.4. Status Management
The Status Management module receives status values changes information from the LCMM and
Settlement modules, collects the relevant data, and forwards it to the T2S Interface for transmission to
the directly connected T2S parties and CSDs as per the message subscription service.
This module also records all the data needed for building up and tracking the life cycle of an instruction,
any time the status value of a settlement instruction is changed or the settlement instruction itself is
amended by the execution of a maintenance instruction.
All the modules dealing with changes in the status values of the settlement instructions (and/or the
settlement instruction itself) activate this module by providing this module with relevant information on
the changes carried out on the settlement instruction.
The Status Management module is composed of four functions:
•
The Life Cycle Track function stores the updates of the values of the instructions’ attributes
during the entire life cycle of individual settlement instructions. Each record includes the date
Final_T2S_GFS_110.doc
Page 37
T2S General Functional Specifications
General Functional Overview
Description of functional domains
and time of each update and the unique identifier of the T2S Party or Actor performing the
change;
•
The Data Collection for Messages function receives information from the Life Cycle Track
function on all updates performed, collects the data to be sent as a message to the
corresponding T2S Actor(s) (T2S Actor instruction reference, T2S reference in case of split
instructions, any other information required to compose the correspondent message
including reason codes for all kind of rejections …). Afterwards this information is forwarded
to the Interface domain.
•
The further processing Identification function manages the remaining unsettled amount of
the unsettled part of partially settled individual settlement instructions and triggers the
liquidity rebalancing process for corporate action instructions for which the cash proceeds
has to be rebalanced to an RTGS account;
•
The Collateral Instruction Settlement management function complements the data received
from Validation, Provisioning and Booking module the information about the settlement
transaction created by the Auto-collateralisation Manager function and the settled settlement
transaction created by an Intraday Credit Reimbursement Manager function to store an
individual settlement instruction. This instruction is then assigned with a settlement status
value set to “settled” and forwards this status value update to the Data Collection for
Messages function.
2.3.3.5. Settlement eligibility
The Settlement Eligibility module is in charge of making a distinction between eligible and non-eligible
instructions.
The module is called as a Start of Day (SoD) process in order to check the statuses and the modes of the
individual settlement instructions in the data store and select the instructions which are eligible.
After the SoD procedures, during the business day (meaning day time and night time, independently of
the cycles), the Settlement Eligibility module checks on a continuous basis the new incoming individual
settlement instructions which are in line with the settlement eligibility criteria.
The Settlement Eligibility module is composed of five functions:
•
The Start of Day Eligibility Check function selects, at the start of day, into the data store the
individual settlement instructions fulfilling the requested properties for being submitted to
settlement;
Final_T2S_GFS_110.doc
Page 38
T2S General Functional Specifications
General Functional Overview
Description of functional domains
•
The Continuous Eligibility Check function checks during the business day that the individual
settlement instructions received fulfil the requested properties for being submitted to
settlement, including the compliance with the different cut-off times;
•
The Linked Eligibility Check function implements complementary checks on linked individual
settlement instructions (instructions having link indicator “with”, “after”, “before”, two-legged
instructions or instructions with common repo reference) in order to ensure the joint or
successive eligibility of those linked instructions according to the nature of the link;
•
The Updating Instructions Status function updates the eligibility status value of the individual
settlement instruction and directs the eligible ones to the Settlement domain;
•
The Fail Management function updates, at the end of day period, the settlement status value
to “failed” for the individual settlement instructions being on hold (i.e. with a “Hold” Hold And
Release status) or for the individual settlement instructions linked to another individual
settlement instruction that is still missing in T2S (i.e. having a “With” or “After” link when the
linked individual settlement instruction is missing).
2.3.4. Settlement
The modules belonging to the settlement domain are in charge of the settlement both on a continuous
basis during the day-time and in cycles and sequences during the night-time. Their objectives are to
maximise the volume and value of settlement with the available securities and cash resources and to
minimise the time for settlement.
Once the instructions are set as eligible within the LCMM domain, they are prepared for settlement:
transactions are generated in a standard format, taking notably into account specific use-cases such as
cross-CSD settlements (module Standardisation and Preparation to Settlement). Transactions are routed
for settlement, either in the day-time queue or grouped in sequence for the night-time (module
Sequencing).
During the day-time, a first settlement attempt is systematically made (module Validation, Provisioning
and Booking). If not successful, recycling through optimisation processes tries to identify sets of
transactions to be settled together, in order to resolve gridlocks (module Recycling and Optimisation).
During the night-time, sequenced transactions are submitted together and optimised, through the module
Recycling and Optimisation. Identified set of transactions that can settle successfully are sent to the
module Validation Provisioning and Booking for their actual settlement. Lastly, at the end of the last night
cycle and during the last 15 minutes of day-time, partial settlement procedures are used if requested.
Both for day-time and night-time, auto-collateralisation procedures are used in order to reduce the
number of case with lack of cash (module Auto-collateralisation).
Final_T2S_GFS_110.doc
Page 39
T2S General Functional Specifications
General Functional Overview
Description of functional domains
2.3.4.1. Standardisation and Preparation to Settlement
The Standardisation and Preparation to Settlement (SPS) is the entry module in the settlement domain for
“Eligible” individual settlement instructions. This module analyses the “Eligible” individual settlement
instructions and determines the settlement context of the transactions to be generated (Cross and in/out
CSD, CoSD, Transfer of basket of collateral, Blocking / Reservation, or standard instructions). Then it
generates the appropriate (linked) settlement transaction(s) containing all the movements on securities
and cash needed to be settled. The settlement transactions are then completed and updated to be
submitted to the Sequencing module.
Lastly this module handles requests received from the Instructions Maintenance module with the aim to
ensure consistency between changes on individual settlement instructions performed in the LCMM domain
and changes performed on settlement transactions.
The Standardisation & Preparation to Settlement module is composed of seven functions:
•
The three first functions analyse the individual settlement instructions and set a SPS
Codification in order to internally route them to the appropriate manager function:
-
(i) The Restriction Instruction Analyser function detects the incoming “Eligible” individual
settlement instructions related to the set-up or cancellation of restrictions or CoSD
(blocking, reservation, CoSD activation or cancellation…) and redirects them to the
appropriate subsequent manager function (see below);
-
(ii) The Cross and In/Out CSD Instruction Analyser function identifies the incoming
individual settlement instruction (not related to a restriction) as an Intra CSD, Cross CSD
or In/out T2S settlement according to the role (Investor or Technical Issuer CSD) and the
position (internal or external to T2S) of the CSDs involved in the settlement;
-
(iii) The Conditional In/Out Instruction Analyser function identifies for individual
settlement instructions (for In/ Out T2S settlement) if they are conditional and subject to
CoSD blocking or CoSD release processing and redirects them to the relevant function
Manager;
•
Two functions generate the settlement transactions with the relevant movements according
to the SPS Codification set by the previous functions: (i) the Position Restriction Transaction
Manager function for those related to restrictions and (ii) the Standard Transaction Manager
function for settlement transactions not related to restrictions;
•
The Harmonised Transaction Generator function complements all generated settlement
transactions by all the data necessary for settlement and submits them to the Sequencing
module;
Final_T2S_GFS_110.doc
Page 40
T2S General Functional Specifications
General Functional Overview
Description of functional domains
•
The Actions on Transactions and Limits function ensures the consistency between changes
on individual settlement instructions performed in the Instructions Maintenance module and
changes performed on settlement transactions and then sends the answer to the Instructions
Maintenance module.
2.3.4.2. Sequencing
This module determines, during the settlement day, the mode of submission of incoming settlement
transactions to a settlement attempt either to the Validation Provisioning & Booking module or to the
Recycling and Optimisation module.
The module is also in charge of updating the settlement transaction status value of unsettled transactions
at the cut-off times, and handles the end-of-day procedures aimed at launching the release of the cash
restrictions and the intraday credit reimbursement process.
The Sequencing module is composed of four functions:
•
The Routing function receives the “Created” settlement transactions from the Standardisation
and Preparation to Settlement (SPS), the Auto-collateralisation, or the Liquidity Control and
sends them:
-
To the Night-time Sequencing function during the Night-time settlement period;
-
To the VPB module, for a real-time settlement attempt, during the Day-time settlement
period and the end of day period.
•
The Night-time Sequencing function operates during the Night-time settlement period, sends
collections of settlement transactions through a pre-defined number of cycles and sequences
to the Recycling & Optimisation module.
•
•
The Cut-off Processing function, deletes:
-
At the “DvP” cut-off time, the unsettled “DvP” settlement transactions;
-
At the “end of day” cut-off time, all the remaining unsettled settlement transactions
The End of Day Release function performs at the end of day period, sending:
-
Data to SPS for cash restriction release purposes;
-
A
time
event
to
the
Auto-collateralisation
module
triggering
intraday
credit
reimbursement.
Final_T2S_GFS_110.doc
Page 41
T2S General Functional Specifications
General Functional Overview
Description of functional domains
2.3.4.3. Validation, Provisioning and Booking
This module receives collections of settlement transactions for their actual settlement through the update
of the relevant cash and securities accounts.
The core function of this module is to execute the cash and securities movement as they are described in
the collections of settlement transactions submitted. As such the module does not make any selection or
de-selection of transactions inside a collection. Notably the partial settlements and the split of transactions
deriving are executed in the Recycling and Optimisation module. As a consequence this module always
operates on an “All or None” principle, except for transactions having an "after"/"before" link.
This module behaves similarly in the day-time and the night-time settlement periods.
For that purpose, the module receives in its entry queue:
•
Single or linked settlement transactions from the Sequencing module for a real-time
settlement attempt during the day-time settlement period;
•
Optimised set of settlement transactions from the Recycling & Optimisation module during
both the day-time and the night-time settlement periods.
The Validation, Provisioning and Booking module is composed of eight functions:
•
The Intraday Restriction Check function checks that no intraday restriction is applicable on
any of the traded ISIN, currency, accounts or T2S Party involved in the collection;
•
The Limits Check function checks that the settlement of the collection does not exceed the
remaining quantity or amount of the applicable Net Buying Limits or Earmarking restrictions;
•
The Provision Checking function checks if the securities positions and cash balances allow the
settlement of the collection by preparing the use of restricted resources, calculating the
Provisioning Net Flows, executing the provision-checking (from the Provisioning Net Flows,
taking into account when appropriate partial execution of settlement transactions allowed to
do so, such as segregation, reservation, or blocking) and sending a request for autocollateralisation in case of remaining lack of cash;
•
The Pre-empting function handles the pre-emption of incoming resource (securities or cash)
on a main securities position or cash balance with an associated reservation partially filled
due to the following cases:
-
A settlement transaction reserving cash or security has been partially executed. An
incoming cash or security resource is pre-empted in order to complete the previous
reservation,
Final_T2S_GFS_110.doc
Page 42
T2S General Functional Specifications
General Functional Overview
Description of functional domains
-
A restricted cash balance has been automatically released during the end of the previous
settlement day. An incoming cash resource is pre-empted in order to re-generate the
restriction for the new settlement day.
•
The Booking function updates the security positions, the cash balances, the limit utilisations,
the Journaling of Limit Utilisations and the settlement status values and checks the Floor and
Ceiling to inform the Liquidity Management module, and unlocks the entities;
•
The Earmarking Restriction Manager function handles the earmarking and unearmarking
settlement transactions to set up, update or delete earmarked restrictions;
•
The Settlement Status function provides the other relevant modules with the result of the
settlement process;
•
The Rebuilding securities positions or cash balances function rebuilds the securities positions
or cash balances from the parameters filled in the event received from the Operational
Monitoring module in real time and sends the rebuilding report to the Operational Monitoring
function.
2.3.4.4. Recycling and Optimisation
This module runs optimisation procedures aiming at identifying collection of settlement transactions that
can be submitted to a settlement attempt, with an expected success:
•
Out of sequenced settlement transactions that have been selected by the Sequencing module
during the night-time settlement period;
•
Out of all unsettled settlement transactions that failed to settle in a first settlement attempt
during the day-time settlement period.
•
Optimisation procedures are designed in order to obtain the optimum balance3 between
volume and value of settlement with the available securities and cash resources (cash
received from RTGS, cash proceeds of selling settlement transactions, cash transfers from
other T2S Dedicated Cash Accounts, cash stemming from intraday credit provision through
auto-collateralisation).
•
These procedures resort on series of optimisation algorithms launched by the Optimisation
Algorithm Manager which is in charge of calling the most efficient one. They are launched
according to a strategy that depends on the triggering event and the settlement period.
3 The URD defines the optimum balance between the maximisation of volume and value as aiming at avoiding situations where only volume
optimisation would be sought (that could lead to favour settlement of low value retail transactions at the detriment of transactions with higher value)
or situations where only value optimisation would be sought (what could lead to favour the settlement of high value transactions at the detriment of
many retail transactions with lower value).
Final_T2S_GFS_110.doc
Page 43
T2S General Functional Specifications
General Functional Overview
Description of functional domains
Each launched Optimisation Algorithm tries to identify collections of settlable of transactions (i.e.
collections of transactions with a successful simulated provision-checking as computed by the Simulated
Provision Checking (SPC) function). Once identified, the collection of settlable settlement transactions is
sent to VPB for their actual settlement.
The Optimisation Algorithms can be categorised in two families:
•
The “De-selection based” algorithms work on the full set of unsettled settlement transactions.
They are multi-currency, mono or multi-ISIN, and bilateral or multi-participants. They
progressively deselect the settlement transactions causing failures until the settlement of
remaining settlement transactions is possible;
•
The “Build up based” algorithms build settlable chains by searching for market situations,
such as simple circles and back-to-back or more complex circles or by Recycling unsettled
settlement transaction with new incoming resources.
Launch strategies implemented by the Optimisation Algorithm Manager function can be summarised as
follows:
•
During the night-time period, the series of optimisation algorithms:
-
Starts with “De-selection based” Optimisation Algorithms efficient on a large number of
transactions;
-
Is followed by a “Gross Settlement Attempt” for all remaining settlement transactions
efficient to reduce the stock;
-
Ends with “Build up based” Optimisation Algorithms efficient on the remaining reduced
stock;
•
During the day-time period, series are composed of “Build up based” Optimisation
Algorithms. They are launched after each new unsettled settlement transaction or upon the
arrival of new resources or on a regular basis with a high frequency;
•
During the day-time and the night-time period, additional series with “De-selection based”
Optimisation Algorithms are launched on demand and apply to the whole unsettled
settlement transactions.
The efficiency of the launch strategies depends on the Optimisation Algorithms actually called per
settlement period and triggering event as well as on the characteristics of the settlement transactions
being submitted to optimisation.
The Recycling and Optimisation module is composed of three functions:
•
The Optimisation Algorithm Manager function launches series of Optimisation Algorithms
according to the settlement period and the triggering event. This function launches the
Final_T2S_GFS_110.doc
Page 44
T2S General Functional Specifications
General Functional Overview
Description of functional domains
following series of Optimisation Algorithms: the Night-time Optimisation Series, the Day-time
Unsettlement Event Series, the Day-time Settlement Event Series, the New Resources Time
Event Optimisation Series and the Optional Day-time Optimisation Series;
•
The Optimisation Algorithms functions aim at identifying a collection of settlement
transactions that can be settled together successfully. These algorithms share common
features (framework, priority management and multi-currency management) and have
dedicated features per family of Optimisation algorithms in order to reach this common
objective through dedicated approaches;
•
The Simulated Provision Checking function verifies whether the settlement of a collection of
settlement transactions is possible with the objective to simulate the provision checking,
similarly to the same way it should be achieved in the Validation, Provisioning and Booking
module, within a context of the optimisation process, by means of an iterative approach.
2.3.4.5. Auto-collateralisation
During the settlement, in order to reduce the number and value of transactions failing to settle, one of the
optimisation mechanisms offered to the settlement banks is auto-collateralisation, in case of lack of cash.
For the NCBs which choose to offer this mechanism, they provide intraday credit by triggering additional
dedicated auto-collateralisation transactions, linked with the underlying transactions they intend to settle.
Those auto-collateralisation transactions fit to each NCB context (pledge or repo) through pre-defined
procedures.
Furthermore, auto-collateralisation is offered both on stock and on flow for eligible counterparts and
eligible instructions, both during night-time and real-time settlement windows.
In addition to this main feature, the module also manages the dynamic reimbursement or automated
substitution in case of fail during settlement due to a lack of securities already collateralised and the
intraday credit reimbursement requested by a T2S Party due to a decreased NCB limit during the
settlement day or due to the End-Of-Day process.
The Auto-Collateralisation module is composed of eleven functions:
•
The Auto-collateralisation manager function treats, one by one in the iterative approach, the
“Auto-collateralisation” request from Validation, Provisioning and Booking and the “Simulated
Auto-collateralisation” request from Recycling & Optimisation. When all the lacks of cash are
filled in, the function sends:
-
In case of “Simulated Auto-collateralisation” request, a positive “Simulation Autocollateralisation” answer to Recycling & Optimisation,
Final_T2S_GFS_110.doc
Page 45
T2S General Functional Specifications
General Functional Overview
Description of functional domains
-
In case of “Auto-collateralisation” request, the collateral settlement transactions created
to the Collateral Transactions Generator function.
•
The T2S Party eligibility check function checks, on receipt of a cash “Lack Description”, if the
T2S Party which owns the T2S Dedicated Cash Account is set as eligible to autocollateralisation by the relevant NCB;
•
The Auto-collateralisation limits check function checks if the remaining amounts in the
applicable limits allow filling in the considered lack of cash. If a limit is modified during the
settlement day the function takes this modification into account (i) during the day-time
period, without delay and (ii) during the night-time period, only for the next cycle or at the
start of the day-time settlement period;
•
The Intraday credit capacity function checks, for a T2S Dedicated Cash Account with a lack
of cash, the T2S Parties agreements to use flow and/or stock as collateral and calculates its
intraday credit capacity (The Intraday credit capacity -ICC- of the T2S Dedicated Cash
Account is the sum of the ICC on flow resulting from the collection and of the ICC on stock);
•
The Collateral selection function selects the collateral among Collateral Net Flows and
securities positions with an Intraday Credit Capacity previously calculated. When both flows
and stocks are available, the function selects first collateral on flows and, if necessary,
complements with stocks;
•
The Collateralised Securities Check function checks if collateralised securities coming from
the considered securities position can fill in the lack and sends the “Lack Description” to the
Dynamic Reimbursement function;
•
The Dynamic Reimbursement Manager function calculates the amount necessary to
reimburse the underlying intraday credit, checks on the main balance of the T2S Dedicated
Cash Account which received the intraday credit and eventually completes with the positive
cash net flow received on this balance in the underlying collection of settlement transactions;
•
The T2S Party’s Reimbursement Manager function handles the reimbursement request sent
by a T2S Party at any time of the day-time period;
•
The Forced Reimbursement Manager function handles the forced reimbursement of intraday
credit due to an intraday credit already provided higher than a decreased autocollateralisation NCB limit;
•
The End-Of-Day Intraday Credit Reimbursements Manager function generates the automatic
reimbursements of all intraday credit amounts with all the available liquidity during the endof-day processing;
Final_T2S_GFS_110.doc
Page 46
T2S General Functional Specifications
General Functional Overview
Description of functional domains
•
The Collateral Transactions Generator function is triggered when the Auto-collateralisation
Manager function or one of the Intraday Credit Reimbursement function has successfully
performed created collateral transactions, collateral release transactions or liquidity transfers
settlement
transactions. It
receives
created
collateral
settlement
transactions and
complements them before sending (i) in case of “Auto-collateralisation” request, an “Autocollateralisation Answer” or (ii) in case of reimbursement request, the Settlement
Transactions to the appropriate modules.
2.3.5. Liquidity Management
The Liquidity Management Domain is responsible for all the activities related to liquidity transfers between
RTGS accounts and T2S Dedicated Cash Accounts as well as between two T2S Dedicated Cash Accounts.
The domain performs the overall preparation of immediate, predefined and standing order liquidity
transfer orders on the T2S Dedicated Cash Accounts. Furthermore it triggers the related communication
(notifications) between T2S and the involved RTGS system.
The liquidity management domain is made of 3 modules. The initiator of a liquidity transfer order can be
both a payment bank as the account holder of the T2S Dedicated Cash Account and another party which
is authorised by the account holder.
When initiating a liquidity transfer between T2S Dedicated Cash Accounts and the RTGS system, the
liquidity transfer order is checked and treated according to the specific features of the different liquidity
transfer types by the Liquidity Control module.
Liquidity transfers between a RTGS system and T2S are based on the exchange of notifications and on
the use of dedicated transit accounts (both in the RTGS system and in T2S) managed by the Notification
and Information Management module in order to enable the other system to align its accounting.
At the end of the business day, liquidity available on T2S Dedicated Cash Accounts is automatically
transferred to the relevant RTGS accounts and the specific end-of-day procedures are implemented by the
NCB Business Procedures module.
2.3.5.1. Liquidity Control
This module ensures the checking and management of liquidity transfer orders between T2S Dedicated
Cash Accounts or towards RTGS system (and vice versa), taking notably into account the specific features
of the different transfer types. A transaction is then generated for booking.
Final_T2S_GFS_110.doc
Page 47
T2S General Functional Specifications
General Functional Overview
Description of functional domains
The Liquidity Control module is composed of three functions:
•
The Validation Check function checks and validates incoming immediate liquidity transfer
orders and incoming notifications (mentioned accounts, currency, contractual agreement,
duplicate submission of the incoming message);
•
The Order Management function creates the relevant liquidity transfer orders if necessary,
stores the incoming or created order in the Liquidity Transfer data store (with update of its
status value), decides to use the pro rata rule and calculates the percentage to be
transferred by each liquidity transfer order through exchange with the Settlement domain (in
case of several standing liquidity transfer orders at the same time), answers requests from
the Interface regarding the status of an order and sends alert data to Notification and
Information Management module in case of no liquidity available at all;
•
The Liquidity Transaction Generator function creates out of the information resulting from
the previous function a liquidity transaction or a forced RTGS transfer. Then, this function
sends the liquidity transaction to the Sequencing Module and the forced RTGS transfers to
the Auto-collateralisation module.
2.3.5.2. Notification and Information Management
Liquidity transfers between a RTGS system and T2S are based on the exchange of notifications, since
these transfers require the use of technical transit accounts. This module manages incoming and outgoing
notification communication in order to enable the other system to align its accounting. Moreover, it
provides information on special booking events (ceiling, floor, and partial execution) to T2S Actors.
The Notification and Information Management module is composed of two functions:
•
The Storage and Status Management function keeps record on and manages the flow of all
notifications from and to a RTGS system by storing and updating the various status values of
all incoming and outgoing notifications in the Liquidity Transfer data store, creating outgoing
notifications when necessary and forwarding execution data to the following function;
•
The Information Manager function provides T2S system users with information on special
booking events on T2S Dedicated Cash Accounts.
2.3.5.3. NCB Business Procedures
This module is responsible for the end-of-day liquidity transfers between T2S and a RTGS system. It is in
charge of the automated transfer of surplus liquidity at the end of the day as well as triggering linked
liquidity transactions in case of insufficient liquidity (pending intraday credit). Additionally it triggers the
bookings at the end-of-day between the RTGS dedicated transit accounts and the “T2S technical account
EoD”.
Final_T2S_GFS_110.doc
Page 48
T2S General Functional Specifications
General Functional Overview
Description of functional domains
The NCB Business Procedure module is composed of two functions:
•
The Account Balance Check function (i) checks the balances of all T2S Dedicated Cash
Accounts not owned by a Central Bank and (ii) checks the balances of all RTGS dedicated
transit accounts owned by a Central Bank to prepare the work for the subsequent function;
•
The Account Number Retrieval function matches (i) information (respective T2S Dedicated
Cash Account, remaining amount, link indicator) of pending intraday credit received from
Auto-collateralisation Module with the corresponding RTGS accounts and forwarded to the
Liquidity Control Module as EoD data for a forced RTGS transfer from the RTGS system to
T2S and (ii) the cash account balances with the corresponding RTGS accounts and sends the
EoD data (amount, T2S Dedicated Cash Account, RTGS account) to the Liquidity Control
Module.
2.3.6. Statistics, Queries, Reports and Archive
This domain includes modules proposing data exploration services to the T2S system users according to
their needs in terms of time scope, nature of data accessed (detailed or aggregated), of flexibility of the
tools, and of response time.
2.3.6.1. Statistical Information
The Statistical Information module is expected to provide T2S system users (i.e. the T2S operator and, on
an optional basis, CSDs and NCBs) with a business intelligence tool to be used for statistical analysis and
as a decision support system.
It stores information on accounts (including position changes and event information), on instruction and
on queries and reports (including volumes generated).
The scope of this module is twofold:
•
To provide statistics to the T2S operator and the CSDs for some operational purpose, on the
level of use of the different components of the platform over time, to support the proper
management of the system. Such statistics are based on a “short term” repository including
data up to three months and the whole instruction life history (including all status changes
and relevant timestamps)4.
4 This period is meant as three months after the day the concerned data item (e.g. a static data object, a settlement instruction and so forth) has
reached its final status (e.g. settled, cancelled, deleted).
Final_T2S_GFS_110.doc
Page 49
T2S General Functional Specifications
General Functional Overview
Description of functional domains
•
To offer to CSDs and NCBs on an optional basis wider scope statistics for analysis and
regulatory reporting purposes. These statistics are based on a “long term” repository storing
data with their final status. These statistics are available on data older than three months.
Both repositories are separated from the live data repositories, in order to provide an easy access to high
quality and business oriented data without the risk of impacting the performance of the operational
settlement environment.
In the present document, both dimensions are covered within the scope of the single Statistical
Information module. Nevertheless, this general description will be followed, during the next phase of the
project, by detailed specifications aiming at serving as a basis of the design of the technical (development
and infrastructure) solution(s): (i) one covering the statistics needed for the monitoring and management
of the platform by the T2S operator and (ii) the second covering wider scope statistics for analysis and
regulatory reporting purposes by CSDs and NCBs, on an optional basis.
The Statistical Information module provides functions to perform statistical query and reporting and multidimensional analysis.
The specific set of available statistical data and functions depends on the specific privileges of each T2S
system user.
The Statistical Information module is composed of five functions:
•
The Extraction, Transformation and Loading function manages a three-step process
consisting, at each step, in extracting data from a source repository, transforming them to fit
the relevant business needs and loading them in a destination repository:
-
In the first step, the function extracts raw data from the operational datastore,
transforms them and finally loads them into the detailed data repository,
-
During the second step, data are extracted from the detailed data repository, transformed
and finally loaded into the aggregated data repository;
-
In the final step, the function extracts data from the detailed and aggregated data
repositories, transforms them and finally loads them into the relevant T2S system user
repositories.
•
The Statistical Workspace Management function allows statistical workspace administrators
to create and manage workspaces for each user profile;
•
The Multi-dimensional Analysis function allows advanced statistical users to perform their
multi-dimensional analysis, i.e. to analyze their data via the relevant statistical workspace
defined by the statistical workspace administrator and to create new statistical queries and
Final_T2S_GFS_110.doc
Page 50
T2S General Functional Specifications
General Functional Overview
Description of functional domains
reports and make them available to the basic statistical users (or to a specific sub-set of
them);
•
The Statistical Query and Reporting function allows basic statistical users to perform their
query and reporting analysis, i.e. to view a set of standard statistical queries and reports
executed automatically and periodically or to run a pre-defined (by the advanced statistical
user) set of queries and reports with the possibility to input a specific set of search criteria.
Each basic statistical user is able to view and run only the set of queries and reports for
which the advanced statistical user has granted access. The statistical reports showing time
series analysis are available both as tables and in several graphic formats;
•
The Export Data function allows both basic and advanced statistical users to export the result
of their analysis in many different formats for further utilization with other tools.
2.3.6.2. Query Management
The Query Management module allows different categories of real-time queries and historical queries on
the production data (instructions, securities balances, cash balances, static data, audit trail, invoice and
billing). All requested data are extracted from the respective datastores and then delivered back to the
interface.
The Query Management module is composed of four functions:
•
The Plausibility Check function performs a plausibility check (zero-result queries, not plausible
characters, non valid ISINs, voluminous User Queries, …) on the received User Query;
•
The Check Permission On Query Request function checks T2S System User privileges against
the access authorisations guaranteeing that the requesting T2S System User only receives
only the queried data in a scale he is permitted to access;
•
The Extracting Data for Query function extracts the requested data from the relevant data
stores and sends the results as Queried Data to the Interface;
•
The Error Handling function, when a User Query fails or an error is detected, translates the
reason of the failure into Error data that is forwarded to the Interface.
2.3.6.3. Report Management
This module provides T2S Actors with a number of reports for periodical information (securities
instructions, balance and static data reports) which, however, do not have to cover the regulatory
reporting. These reports are set up as XML messages and comply to the largest possible extent with ISO
20022 standard.
Final_T2S_GFS_110.doc
Page 51
T2S General Functional Specifications
General Functional Overview
Description of functional domains
All reports are available for all CSDs in T2S, T2S parties and NCBs. Reports can be sent to CSDs and
directly connected T2S parties, containing information on one or several accounts. T2S reports can either
be based on a business event or be sent at a fixed time.
The Report Management module is composed of seven functions:
•
The Extracting Data For Report function allows the selective extraction of business raw data
for report from the relevant T2S data stores. All required data is extracted taking into
account the privileges of the requesting T2S system user;
•
The Calculating Report function processes the received raw data calculate sums, products,
totals or averages;
•
The Formatting Report function (i) formats, sorts and groups the received report data (raw
data and calculated data) and (ii) adds a timestamp reflecting the point in time when the
data was extracted;
•
The Store/Load Report function (i) stores any newly generated Report in the report data
store and (ii) loads the indicated Report from the report data store and forwards it to the
Interface domain;
•
The Validate Report Request function provides the business validation (e.g. plausibility) for all
received requests;
•
The Error Handling function creates error data that is forwarded to the Interface domain,
when a request fails or an error is detected;
•
The Delete Report function automatically deletes all reports stored in the Reports data store
after a time period of two days.
2.3.6.4. Legal Archiving
The Legal Archiving module aims at storing for a given period static data (including revisions and history)
and transactional data5. The module is triggered daily during the maintenance window, and on arrival of a
request from the Interface.
The Legal Archiving module is composed of six functions:
•
The Data Extraction for Archiving function selects the settlement instructions in their final
status for more than three months, the incoming and outgoing files in their original format
and along with the related dynamic data and static data;
5 The module does not address the needs for Data Revision (replication of static data structures as revision tables) and Data History (data stored with
“valid from” and “valid to” date attributes) described in UR section 16.4.
Final_T2S_GFS_110.doc
Page 52
T2S General Functional Specifications
General Functional Overview
Description of functional domains
•
The Data Archiving function archives the incoming “Files To Archive” received from the
previous function for duration defined in the applicable “Archiving Rules”;
•
The Data Physical Deletion function searches the archiving date to physically delete, checks if
the related archiving date has the “Archived” status and Proceeds to the actual physical
deletion of the static and dynamic data occurrences which have been previously logically
deleted;
•
The Archived Data Extraction function (i) realises a first check to control the T2S Actor access
authorisation and the type of requested data for this T2S Actor, and (ii) extracts the relevant
archived data. The sending of the requested archived data to the T2S Actor is performed in a
maximum response time of 3 days;
•
The Archive Data Restitution function posts the considered restitution file received from the
previous function and sends “Requested archived data availability” information to the
Interface in a way to inform the requester of the availability of the restitution file in T2S.
Then, the requester can get back the restitution file via both U2A and A2A modes;
•
The Archived Data Purge function checks the archived files for which the archiving duration is
reached and purges them. The archiving duration can be different for each CSDs or NCBs.
2.3.7. Operational Services
This domain includes modules providing functions specific to the T2S operational teams.
2.3.7.1. Operational Monitoring
The aim of this module is to support the T2S operator and, for some specific tasks, other T2S system
users (e.g. online access to the Trouble Management System for CSDs and authorized T2S parties) in the
monitoring of T2S, from two different angles:
•
The operational monitoring for the detection of functional or operational problems in realtime, the monitoring related to the SLA indicators, and the information provisioning for crisis
management scenarios;
•
The technical monitoring for the detection of hardware and software problems via real-time
monitoring of all the technical components involved in the processing, including the network
connections.
Furthermore, this module provides an overview of the message flows in the whole system to the T2S
operator.
Final_T2S_GFS_110.doc
Page 53
T2S General Functional Specifications
General Functional Overview
Description of functional domains
The Operational Monitoring module is composed of six functions:
•
The Data integration and extraction function integrate data coming from different sources
(statistical information repositories, live data base, external data sources), extracting,
merging and organising data in the format required for the presentation to the T2S system
users and compares the current behaviour of T2S (and of its components) with a set of
predefined thresholds and with the information stored in the statistical information
repository, in order to signal to the T2S operator any deviation from the normal expected
behaviour;
•
The Operational data and status presentation function presents the output of the monitoring
activity in an organised and readable form to the T2S operator;
•
The Technical monitoring and compare function provides the T2S operator with the
possibility to monitor every single component of the platform with real-time information. It
also provides the T2S operator with hints related to the actions to be taken to solve the
relevant incident;
•
The Technical status presentation function provides a graphical display of the T2S processes
and indicators in order to present a global view on the whole system for monitoring
purposes;
•
The Trouble case maintenance function encompasses aspects related to the management
and processing of trouble cases via a specific Trouble Management System (TMS) application
(service request, incident, problem);
•
The Trouble case access function allows read-only access to Trouble cases, for information
purposes, to all T2S actors linked to a specific Trouble Case and allows all involved T2S
parties constantly monitoring the status of the case.
2.3.7.2. Scheduling
This module contains a set of functions for the management of operating day events and related business
processes. The current business date event schedule can be changed at run-time, in order to insert,
update, time-shift and delete an event instance or a set of events. The broad categories of events are
EoD/SoD events, End of cycle events, Maintenance events and Dynamic events.
The Scheduling module is composed of six functions:
•
The Daily Planner function creates the new business date time schedule by using the Default
Event Schedule based on the Operating Day Type, at every business date change;
•
The Daily Scheduler function checks and identifies, on a regular basis, the event instances
that have been reached, depending on the current business day schedule, receives a
Final_T2S_GFS_110.doc
Page 54
T2S General Functional Specifications
General Functional Overview
Description of functional domains
notification when the process is completed and updates the event’s end time value for the
current business day accordingly;
•
The Operating Day Management function allows the T2S Operator or the owner of a specific
Event Type performing manual changes on the current day schedule;
•
The Access to Current Day Schedule function provides the current business date, as well as
detailed information on the current day schedule, in response to enquiries performed by a
generic function within the T2S system;
•
The Business Date Change function, following an EoD event, replaces the “business date”
contained in the scheduler with the value stored in "next business date";
•
The T2S Closing Day User Update function allows the T2S Operator manually updating the
days in which T2S will not be open for business, for instance in case of contingency
situations.
2.3.7.3. Billing
This module automatically or on request produces monthly bills containing all billable events (e.g. events
related to the lifecycle of an instruction), fixed and variable fees. At the end of a billing period, an invoice
is sent to the CSDs and sums up all the relevant billing information per T2S Party. All invoices are stored
electronically and are available for later inquiries.
The Billing module is composed of seven functions:
•
The Check permission for request function checks each request of a T2S system user against
the permission rights of the respective user stored in a data store, in order to route the
request to the appropriate function;
•
The Extracting data for billing function extracts all relevant data for the billing from the T2S
data store, at the end of the billing period or if an invoice generation is requested (in this
case, the billing period can be defined);
•
The Calculating bill function calculates on the basis of the raw data for billing the positions of
the CSD’s bill;
•
The Formatting invoice function creates invoices on the basis of the billing data;
•
The Store/Load invoice function stores the already formatted invoices in the invoice data
store and then delivers them to the CSDs via the Flow Management module immediately
after creation at the end of a billing period. In case of an invoice request, this function
uploads the requested invoice from the invoice data store;
•
The Cancel invoice function carries out the cancellation of an invoice;
Final_T2S_GFS_110.doc
Page 55
T2S General Functional Specifications
General Functional Overview
Data Model Overview
•
The Error handling function prepares an error text and sends it to the respective user via the
Flow Management, in case of a request failure due to insufficient user permissions.
2.3.7.4. Data Migration
The Data Migration module provides the migration functionality which will allow the CSDs and the NCBs to
automatically transfer the major part of relevant data (eg. securities account data, party master data,
securities positions, securities master data) from the securities settlement systems of the respective CSD
and relevant data from NCBs to T2S. For the transfer and upload of the migration data any kind of means
is envisaged: flat file, excel file, paper and in any case GUI to key in or correct static data. A standard fallback plan is established, made available before the first migration period and the fall-back plan and the
roll-back procedures are tested before the beginning of the migration.
The Data Migration module is used for setting up test environments before go-live of T2S and before an
additional CSD joins T2S (e.g. in later migration windows). There is no migration of any historical data of
the CSDs.
The Data Migration Tools module is composed of four functions:
•
The Data Entry function deals with static and dynamic data which has to be imported to T2S.
This includes party master data, securities account data, securities account balances data
and securities master data and the BIC directory;
•
The Convert Migration Data function converts the migration data coming in from the previous
function via standardised input tables into the T2S data format;
•
The Validation Check and Store Migration Data function checks if the conversion was
successful (e.g. whether the data are readable) and complies with the requirements of T2S;
In this case, the function stores only the successfully converted data in the respective Static
Data datastore and sends a success report to the Flow Management;
•
The Error Handling function analyses the failed data received from the other functions and
sends an error data to the Flow Management covering all relevant information.
2.4. Data Model Overview
2.4.1. General Introduction
The aim of this section is to provide a high level description of the T2S data model, describing the basic
entities and the main relationships among them. The complete data model, covering both static and
dynamic data, is presented in appendix.
Final_T2S_GFS_110.doc
Page 56
T2S General Functional Specifications
General Functional Overview
Data Model Overview
A complete and detailed description of the data model, including all entities and relationships, is provided
in the relevant chapters, according to the following table:
DATA MODEL
Static Data
CHAPTER
3.3 Static Data Management
Communication
3.2 Interface
Message
Settlement Related Instruction
3.4 Lifecycle Management and Matching
Individual Settlement Instruction
Instructions Link Set
Settlement Transaction
3.5 Settlement
Collection
Dynamic Data
Securities Movement
Cash Movement
Securities Position
Cash Account Balance
Limit Utilisation
Liquidity Transfer
3.6 Liquidity Management
Queries
3.7 Statistics, Queries, Reports and Archives
Reports
2.4.2. Static Data
Static Data includes all reference data defined in T2S for parties (e.g. CSDs, NCBs, CSD participants,
payment banks), securities, securities accounts, T2S dedicated cash accounts, configuration rules and
parameters. A short description of the main entities involved is provided hereafter:
1 – Party
This entity defines all reference data for any legal entity or organisation defined in T2S. For each party,
the following data are stored: code (i.e. the primary BIC assigned to the party), name, legal address, plus
some business and technical parameters (e.g. status, recycling period, matching required, technical
addresses) defining its status and characteristics within the platform.
The following party types are foreseen in T2S:
•
T2S Operator;
•
Payment Bank;
Final_T2S_GFS_110.doc
Page 57
T2S General Functional Specifications
General Functional Overview
Data Model Overview
•
Central Securities Depository (CSD);
•
CSD Participant;
•
External CSD;
•
National Central Bank (NCB);
•
CCP;
•
Trading Platform / Stock Exchange.
It should be noticed that, since a legal entity or organisation may establish legal relationships with several
CSDs and NCBs in T2S, the same legal entity or organisation might be defined several times as a party in
T2S, i.e. once for each legal relationship6.
2 – Security
This entity defines all reference data for any security defined in T2S. For each security, the following data
are stored: ISIN, name, CFI, final maturity or expiry date, a set of parameters (e.g. settlement type,
minimum settlement unit or nominal, settlement volume multiple, auto-collateralisation) defining the way
the security can be processed within the platform, plus all the daily valuation information and possible
deviating nominal values for the security.
3 – Securities Account
This entity defines all reference data for any securities account defined in T2S. For each securities
account, opening and (possible) closing dates and business status are stored, plus all the parameters
(e.g. auto-collateralisation, hold-release default, negative position) needed for securities settlement in
T2S.
The following securities account types are foreseen in T2S:
•
CSD participant account;
•
CSD mirror account;
•
Inter-CSD account;
•
T2S technical offset account.
6 For instance, an account operator having its securities accounts opened with two different CSDs would be defined as two distinct parties in T2S, the
former linked to the first CSD and the latter linked to the second CSD. As another example, a NCB having a securities account opened with a CSD
would be defined as two distinct parties in T2S, the former as a NCB (linked to the T2S Operator) and the latter as a CSD Participant (linked to the
relevant CSD).
Final_T2S_GFS_110.doc
Page 58
T2S General Functional Specifications
General Functional Overview
Data Model Overview
4 – T2S Dedicated Cash Account
This entity defines all reference data for any T2S dedicated cash account defined in T2S. For each T2S
dedicated cash account, opening and (possible) closing dates and business status are stored, plus all the
parameters (e.g. floor and ceiling information amounts) needed for cash settlement in T2S.
The following T2S dedicated cash account types are foreseen in T2S:
•
RTGS dedicated transit account;
•
T2S central bank account;
•
T2S dedicated cash account;
•
T2S technical account EoD.
5 – Market-Specific Restriction Type
This entity defines all reference data for any market-specific restriction type defined in T2S. A restriction
type is a set of attributes that define the specific processing characteristics for one of the following
objects: parties, securities accounts, T2S dedicated cash accounts, securities positions and cash balances.
Moreover, for each restriction type, one or many allowed instructing profiles define the set of possible
actions that can be performed on the restricted object and the set of parties that are allowed to perform
such actions.
The following restriction types are possible in T2S:
•
Blocking;
•
Earmarking;
•
Reservation;
•
Segregation.
6 – Currency
This entity defines all reference data related to currencies defined in T2S, according to the ISO 4217
standard.
Final_T2S_GFS_110.doc
Page 59
T2S General Functional Specifications
General Functional Overview
Data Model Overview
The following diagram shows the basic Static Data entities just described and their mutual relationships.
A description of the relationships shown in the diagram is given hereafter, entity by entity:
•
Party. Each party is linked to the party with which it has a legal relationship (e.g. a CSD
participant is linked to its CSD), may be linked to one or many party restrictions7. Moreover,
each party owning an account in T2S is linked to the relevant securities and T2S dedicated
cash accounts. Finally, each party may be linked to one or more securities accounts for the
definition of the relevant close links8 and to one or more securities the party (i.e. a CSD or
the T2S Operator) restricted from settlement;
•
Security. Each security is linked to one issuer or technical issuer CSD and can be linked to
one or many investor CSDs9 and one or many parties for the definition of the relevant close
links. Furthermore, each security is linked to its issue currency and may be linked to one or
many security restrictions10;
7
For each party restriction, a period of validity must be specified. Only one restriction for a party can be valid at any given point in time.
8
Each close link defines a security not eligible as collateral for a given party.
9 For each link to a CSD, a period of validity, the type of link (i.e. if the CSD is issuer, investor or technical issuer for the relevant security) and a
Boolean value indicating if the CSD is responsible for maintaining the security must be specified (for each security one and only one CSD can be
responsible for its reference data maintenance).
10 For each security restriction, a period of validity and a restricting party (i.e. the T2S operator or a CSD) must be specified. Only one restriction for a
security can be valid at any given point in time.
Final_T2S_GFS_110.doc
Page 60
T2S General Functional Specifications
General Functional Overview
Data Model Overview
•
Securities Account. Each securities account is linked to its relevant party (i.e. CSD or CSD
participant) that owns the account. Furthermore, each securities account may be linked to
one or many securities account restrictions11;
•
T2S Dedicated Cash Account. Each T2S dedicated cash account is linked to its relevant party
(i.e. NCB or payment bank) that owns the account. Furthermore, each T2S dedicated cash
account is linked to its relevant currency and may be linked to one or many T2S dedicated
cash account restrictions12;
•
Market-Specific Restriction. Each market-specific restriction type can be linked to one or
many restricted parties, securities, securities accounts and T2S dedicated cash accounts.
•
Currency. Each currency is linked to all the securities issued on the same currency and to all
the T2S dedicated cash accounts defined on the same currency.
7 – Rules and Parameters
Besides the entities described so far, it is worth mentioning that Static Data also includes reference data
concerning the rules and parameters defined in T2S. The main ones are listed hereafter:
•
currencies, for the definition of currencies eligible for settlement in T2S;
•
closing days and scheduling, for the definition of the T2S calendar and the events of each
operating day;
•
sequencing rules, to define the correct sequence for processing of settlement instructions;
•
settlement priority defaults, based on instruction type, transaction type and party type;
•
tolerance amounts, to define tolerance amount values for currencies eligible for settlement in
T2S;
•
partial settlement thresholds, to define thresholds for partial settlement at party (i.e. CSD or
CCP) or system level (i.e. T2S Operator);
•
conditional securities delivery rules, to define and configure all the parameters that must be
used for the processing of conditional securities delivery instructions;
•
service subscription, to define and configure services provided by T2S;
•
message subscription, to configure the set of messages that each connected party will
receive from T2S;
11
For each securities account restriction, a period of validity must be specified. Only one restriction for a securities account can be valid at any given
point in time.
12 For each T2S dedicated cash account restriction, a period of validity must be specified. Only one restriction for a T2S dedicated cash account can
be valid at any given point in time.
Final_T2S_GFS_110.doc
Page 61
T2S General Functional Specifications
General Functional Overview
Data Model Overview
•
SWIFT BIC directory.
2.4.3. Dynamic Data
Dynamic Data includes all data defined in T2S for messages, settlement instructions, individual settlement
instructions, settlement transactions, securities and cash movements, securities positions, cash account
balances and limits utilisations. A short description of the main entities involved is provided hereafter:
1 – Message
This entity contains all the data needed for processing a message in T2S: entry date/time, message type,
status and status description, XML message content.
2 – Settlement Related Instruction
This entity stores both settlement instructions (new instructions submitted to T2S) and maintenance
instructions (any kind of message, related to the settlement process that is submitted to T2S in order to
amend an already existing instruction). It includes all the information needed by T2S for processing
settlement instructions, e.g.: entry date/time, sending and instructing party, instruction type, matching
information, status.
3 – Individual Settlement Instruction
Once the validation process is completed successfully, new individual settlement instruction(s) is(are)
created, including all the information needed for settlement in T2S, e.g.: individual instruction type, ISO
transaction code, first and final party, first and final CSD, intended settlement date.
4 – Settlement Transaction
This entity includes all the information about security and cash movements optimised for the settlement
processing, e.g.: entry date/time, partial settlement indicator, settlement transaction status, priority
5 – Securities Movement
This entity includes all the information about securities movements related to settlement transactions, i.e.:
quantity, partial quantity, first and final position.
6 – Cash Movement
This entity includes all the information about cash movements related to settlement transactions, i.e.:
amount, partial amount, first and final balance.
Final_T2S_GFS_110.doc
Page 62
T2S General Functional Specifications
General Functional Overview
Data Model Overview
7 – Securities Position
This entity includes all the information about securities positions, in terms of amount of a security held
into securities accounts at a specific point in time, e.g.: position and position date, (possible) restriction
type.
8 – Cash Balance
This entity includes all the information about cash balances, e.g.: balance and balance date, (possible)
restriction type.
9 – Limit Utilisation
This entity includes all the information about limits utilisation, in order to track of the limit utilisation for
each party during the business day, e.g.: date, limit utilisation, remaining limit.
10 – Collection
This entity contains all the information related to groups of (linked) settlement transactions submitted
together for a settlement attempt in the Validation Provisioning and Booking module.
11 – Securities Provisioning Net Flow
This entity stores the net flows calculated by technical netting during the provisioning for each securities
position involved in an underlying collection of Settlement Transactions.
12 – Cash Provisioning Net Flow
This entity stores the net flows calculated by technical netting during the provisioning for each cash
balance involved in an underlying collection of Settlement Transactions.
Final_T2S_GFS_110.doc
Page 63
T2S General Functional Specifications
General Functional Overview
Data Model Overview
The relations between these entities are described into the following diagram:
A description of the relationships shown in the diagram is given hereafter, entity by entity:
•
Message. Each (settlement related) message is linked to the relevant settlement related
instruction, i.e. either to the settlement instruction or to the maintenance instruction it refers
to;
•
Settlement Related Instruction. Each settlement related instruction is linked to the relevant
message (i.e. the message containing the settlement related instruction) and to the security
it refers to. Furthermore, for each validated settlement related instruction, from one to many
individual settlement instructions are created and linked to it. Non validated settlement
related instructions are not linked to any individual settlement instruction;
Final_T2S_GFS_110.doc
Page 64
T2S General Functional Specifications
General Functional Overview
Data Model Overview
•
Individual Settlement Instruction. Each individual settlement instruction is linked to the
settlement related instruction from which it was created and to the relevant settlement
transactions. More in detail, in most of the cases, two matched individual settlement
instructions lead to the creation of one settlement transaction. For Conditional Securities
Deliveries (CoSD), two matched individual settlement instructions lead to more than one
settlement transaction (one for the CoSD blocking on the basis of the two initial Individual
Settlement Instructions, another one for the CoSD to be released or to be cancelled). For
Cross-CSD, only one settlement transaction is created. Finally, each individual settlement
instruction is linked to the relevant instructing party and may also refer to another (“linked”)
individual settlement instruction;
•
Settlement Transaction. Each settlement transaction is linked to the relevant individual
settlement instructions, i.e. to the individual settlement instructions from which it was
created. Moreover, from each settlement transaction one or many securities movements and
one cash movement may be created. Settlement transactions may exist linked to securities
movements only (FoP instructions) or to a cash movement only (cash settlement
instructions). Finally, each settlement transaction may be part of one or many collections
(see below);
•
Securities Movement. Each securities movement is linked to settlement transaction from
which it was created, and to the relevant securities accounts (link not figured on the
diagram) and security;
•
Cash Movement. Each cash movement is linked to the settlement transaction from which it
was created and to the relevant debit and credit T2S dedicated cash accounts;
•
Collection. Each collection is linked to all the settlement transactions which are part of the
collection itself, with their related cash and securities net flows;
•
Securities Provisioning Net Flow. Each securities provisioning net flow is linked to the
collection it belongs to and to the securities position it refers to;
•
Cash Provisioning Net Flow. Each cash provisioning net flow is linked to the collection it
belongs to and to the cash balance it refers to;
•
Securities Position. Each securities position is linked to the securities account and security it
refers to and may be referenced by many securities provisioning net flows;
•
Cash Balance. Each cash balance is linked to the T2S dedicated cash account it refers to and
may be referenced by many cash provisioning net flows;
•
Limit Utilisation. Each limit utilisation is linked to the limit it refers to.
Final_T2S_GFS_110.doc
Page 65
T2S General Functional Specifications
General Functional Overview
Security Management
2.5. Security Management
This section of the GFS aims at providing a generic functional description of the way the GFS integrate the
security requirements expressed in the UR document, notably in the chapter 18 “Information Security
Requirements”, but also in chapter 5 “Instruction Lifecycle Management and Matching Requirement”, in
chapter 10 “securities Positions and Cash Balances” and in chapter 16 “Static Data Requirements”. The
solutions (i.e. tools or specific developments) to be implemented to meet these requirements will be
defined and described in detail in the detailed functional specifications.
This transversal subject is analysed in each domain/module/function, particularly the functions which (i)
update the data, (ii) send or/and receive flows and (iii) ensure the interface with T2S Actors and external
systems.
At this level, the analysis remains rather general and defines the methodology that will be implemented in
the next phase of the functional design. Indeed, applying this methodology, the relevant security
measures will be identified at the function level.
The objective of the methodology is ensuring that the security issues are exhaustively and consistently
addressed, in each function. It consists of raising and answering the following questions at functional level
with respect to the kind of treatments performed by the considered function:
•
Should the function enforce any confidentiality requirement, i.e. ensuring that information is
accessible only to authenticated and authorised parties?
-
What is the business sensitivity (level of confidentiality) of the processed information?
-
Who / what has a good reason to access the function (need to know principle)?
-
Is the function expected to receive the information from the sender or send the
information to the recipient?
In the current functional design, the access control to T2S is performed by the Interface
domain.
•
Should the function enforce any integrity requirement, i.e. safeguarding the accuracy and
completeness of information through the various processing, transmitting and storage
methods?
-
To what extent must the input to application be validated to ensure that this data is
correct and appropriate?
-
To what extent must validation checks be incorporated into applications to detect any
corruption of information through processing errors or deliberate acts?
Final_T2S_GFS_110.doc
Page 66
T2S General Functional Specifications
General Functional Overview
Security Management
-
To what extent must the output of an application be validated to ensure that the
processing of stored information is correct and appropriate?
In the current functional design, the integrity and the segregation of information are ensured
by the Static Data Management domain.
•
Should the function enforce any authentication (origin and recipient sides) requirements, i.e.
determining whether someone or something (function, component…) is, in fact, who or what
it is declared to be?
-
What is the level of trust required in the identity of the counterparty before giving
authorisation for accessing/transmitting the information?
-
What are the legal requirements enforcing the application to:
ensure that a party cannot deny having received or sent a message (non
repudiation requirement)?
log the needed legal proofs for being able to establish this non repudiation in a
long-term period ?
appeal to a notarization service for trusted third party witnesses legally recognised
in case of dispute?
make use of timestamps proving the existence of a document at a given time?
In the current functional design, the authentication requirements are ensured by the
Interface domain.
•
Should the function enforce any monitoring requirements, i.e. detecting unauthorised
information
processing
activities
and
recording
appropriate
information
for
future
investigations?
-
What are the legal requirements in terms of monitoring and logging activities?
-
What event must be logged such as access, change of system configuration, use of
privileges, and deactivation of protection systems, faults, system administrator and
operator activities…?
-
What information details (user ids, date time…) must be logged and how long must the
archived data be retrievable for future investigations?
-
How is the logged and archived information protected against tampering and
unauthorised access?
In the current functional design, the monitoring requirements are ensured by the Operational
monitoring module.
Final_T2S_GFS_110.doc
Page 67
T2S General Functional Specifications
General Functional Overview
Security Management
•
Should the function enforce any availability requirement, i.e. ensuring that authorised users
have access to information and associated assets when required (need to have principle)?
-
What is the business criticality of the information (need for accessibility/ availability) i.e.
what the business risk is if this information would not be available (Business continuity)?
-
How fast should the function return information?
-
How to react if incoming information is not received when needed? How to react if
information cannot be sent when expected?
The availability of the T2S services is ensured by the Infrastructure design.
•
Should the function enforce any “auditability”13 requirement (audit trail), e.g. the possibility
of establishing whether a system is functioning properly and that it has worked properly?
-
What are the requirements in terms of “auditability”, particularly coming from the service
auditors examining the system in accordance with recognized auditing standards such as
“Statement on Auditing Standards (SAS) N°70”?
-
What appropriate documentation will provide sufficient knowledge about the system and
its structure, functions, controls, etc?
-
What kind of integrity-related modifications to the system and its data must be made
visible for proving the proper functioning?
-
What are the requirements in terms of Audit reports?
In the current functional design, the “auditability” of the T2S services is ensured by the
design of the Data Model and the legal archiving module.
For obvious efficiency reasons, it is planned for the next phases to draw up an inventory of the global
functional assets mentioning their sensitivity, criticality and identifying their owners. This inventory will be
used as a common validated reference for helping the functional designer answering the above listed
questions.
13
Also called « Controllability »
Final_T2S_GFS_110.doc
Page 68
T2S General Functional Specifications
Functional Description
Introduction
3. Functional Description
3.1. Introduction
On the basis of this general view of the functional solution envisaged for T2S, this chapter provides a
functional description of the domains and modules identified in the overall high level diagram. For each of
these domains, this chapter describes the role and behaviour of their respective modules and functions by
presenting their respective data flow processes. It also includes a presentation of the processing of some
representative14 use cases illustrating the respective roles and interactions of modules in this processing.
This graphic and text description of representative use cases processing aims at facilitating the
understanding of the internal behaviour of the system to answer the requests originating from external
parties. For each domain, these representative use cases are described through:
•
A sequence diagram showing the interactions between the T2S modules in the processing of
the use case;
•
A description of the processing of the use case and of the role of each module into this
processing.
The approach for the choice of the representative use cases is explained for each category.
14 Considering the huge number of defined use cases in some categories and the very similar processing of some “close” use cases, the description is
limited in each category to a set of representative uses cases chosen in each category. For the other uses cases, the reference of the relevant
representative use case is given into the lists of use cases provided in appendix.
Final_T2S_GFS_110.doc
Page 69
T2S General Functional Specifications
Functional Description
Interface
3.2. Interface
3.2.1. General Introduction
T2S actors
Communication
U2A/A2A
(Incoming)
Interface
Certificate
Issuance
Communication
U2A/A2A
(Rejection)
<<data store>>
SD
Communication
U2A/A2A
(Status/response/
notification/
message)
Access Management
Not ok (access
denied)
<<data store>>
CM
Ok
Communication
A2A/U2A
(Incoming)
<<data store>>
XF
Structure and Syntax Check
Certificate
Maintenance
Certificate
management
Not ok
No Certificate
management
Ok
<<data store>>
SD
Technically validated
instruction/request/
notification/order
Flow Management
See diagram 1 for
detailed flows with
Operational
Services
See diagram 2 for
detailed flows with
Statistics, Reports,
Queries and Archive
See diagram 3
for detailed
flows with Static
Data
See diagram
4 for detailed
flows with
LCMM
See diagram 5
for detailed flows
with Liquidity
Management
OPERATIONAL
SERVICES
STATISTICS,
QUERIES, REPORTS
AND ARCHIVE
STATIC DATA
MANAGEMENT
LCMM
LIQUIDITY
MANAGEMENT
Final_T2S_GFS_110.doc
Page 70
T2S General Functional Specifications
Functional Description
Interface
Diagram 1:
Diagram 2:
Diagram 3:
Final_T2S_GFS_110.doc
Page 71
T2S General Functional Specifications
Functional Description
Interface
Diagram 4:
Diagram 5:
The T2S Interface handles all incoming and outgoing communication with all T2S actors, manages the use
of the appropriate communication medium and undertakes the relevant technical entry checks. In turn,
T2S actors connecting to T2S have to comply with the formats and specifications defined in T2S
{T2S.12.230}, {T2S.12.240}.
All T2S communication functionalities are available by using messages as well as online screen based
activities (Graphical User Interface) {T2S.12.260}, {T2S.12.280}, {T2S.12.310}, {T2S.12.320},
{T2S.12.330}, i.e. T2S can be accessed:
•
in application-to-application mode (A2A) to allow direct communication between software
applications via XML messages. For the T2S communication via messages the ISO
20022/UNIFI is the single standard, both inbound and outbound. In addition, the use of ISO
20022 complies with Giovannini protocol recommendations for both inbound and outbound
communication {T2S.12.040}, {T2S.12.050} and
•
in user-to-application mode (U2A) concerning activities performed manually by T2S system
users via Graphical User Interface {T2S.12.250}.
The Graphical User Interface is part of the Interface Domain. A detailed description of each
function/screen available in U2A mode will be delivered at a later stage {T2S.11.090} {T2S.11.100}
{T2S.11.330} {T2S.12.020} {T2S.11.280} {T2S.11.520}
Final_T2S_GFS_110.doc
Page 72
T2S General Functional Specifications
Functional Description
Interface
The access of different T2S system users takes into account the privileges stored in the Static Data
{T2S.12.060}.
Furthermore, T2S actors have the possibility to combine several T2S connections for several types of
activities {T2S.12.010}, {T2S.12.290}, {T2S.12.300}.
The Interface is also used for communication between T2S and TARGET2 or any other non euro RTGS
system (depending on the decision of the relevant NCB) and CCBM2 (or any other collateral management
system for euro and for non-euro NCBs). The Interface design follows an “open” concept in such a way
that the same Interface specifications can be used to connect TARGET2 and other RTGS systems
{T2S.12.340} or collateral management systems for euro and for non-euro NCBs to T2S. For the
communication with collateral management systems, a single set of standard messages is used.
{T2S.12.350}, {T2S.12.360}
The T2S Interface services are available continuously during settlement day. However, the availability of
Interface services is restricted during the maintenance window. On weekends and closing days the
Interface is only available when required, based on specific needs (migration, issuance in direct holding
countries) {T2S.03.320}, {T2S.03.350}, {T2S.03.360}.
The T2S Interface domain is composed of the three following modules:
•
Access Management;
•
Structure and Syntax Check;
•
Flow Management.
The Message Subscription Service gives flexibility for all CSDs and directly connected T2S parties to
choose the messages they wish to receive or not, in order to handle their business activities
{T2S.13.010}, {T2S.13.020}, {T2S.13.030}, {T2S.13.040}, {T2S.13.050}. The selection of the
messages they wish to receive is done on the basis of a predefined list including all messages available in
T2S and stored in Static Data.
3.2.2. Description of the role of the domain
Since the modules of the Interface domain are playing a similar role into all the use cases processing
described into this chapter, these modules and the related flows are not replicated into each sequence
diagram presented within each domain.
Final_T2S_GFS_110.doc
Page 73
T2S General Functional Specifications
Functional Description
Interface
In each diagram, the behaviour of the Interface domain is to be considered as follows:
INTF:
Structure and
Syntax Check
INTF: Access
Management
T2S System
User
INTF: Flow
Management
All Business
Modules
Communication
U2A/A2A
Rejection
Communication
U2A/A2A
Rejection
Technically validated request/
instruction/notification/order
Request / instruction /
notification / order data
Status / response / notification /
message
Status / response / notification
data
Inbound processing:
The incoming message enters the system via the Interface. In a first step Access Management module
checks whether the incoming communication was sent by a secured and recognised address
(authentication). Furthermore an authorisation of the intended actions based on a roles check takes place.
Positive checked communication is sent afterwards to the Structure and Syntax Check module otherwise a
rejection message is sent to the T2S Actor. The Structure and Syntax Check module performs series of
checking and validation procedures (i.e. technical validation process). In case of a negative result the
message is rejected and otherwise forwarded to the Flow Management module. Within the Flow
Management module, all relevant communication data from the message is extracted in order to structure
the information to be processed by the subsequent modules and the structured data is routed to the
relevant T2S module.
Outbound processing:
Based on the data received by the respective functional domain, the Interface domain modules generate
the relevant messages (status messages, response messages to queries, etc…) to be sent to the relevant
T2S Actors or to be displayed on-screen. Furthermore, it identifies the specific message subscription
preferences of the T2S actors for all outbound communication.
Final_T2S_GFS_110.doc
Page 74
T2S General Functional Specifications
Functional Description
Interface
3.2.3. Dynamic data managed by the domain
T2S actors send or receive Communication to/from T2S. Communication is a collective term for messages
and files. Files may contain several messages. A message contains different business data to be processed
by T2S:
Task:
ATTRIBUTE
Task Status
DESCRIPTION
Status of the processing on Task level
Message:
ATTRIBUTE
DESCRIPTION
Entry Date/Time
Point in time of the last update.
Message Type
Type of message received.
XML Message Content
Actual XML message content.
Status
Status of the processing on message level.
Status Description
Additional status information (e.g. error code)
Communication:
ATTRIBUTE
Header Information
Final_T2S_GFS_110.doc
DESCRIPTION
Header information of the received communication (e.g. Sender BIC)
Page 75
T2S General Functional Specifications
Functional Description
Interface
ATTRIBUTE
DESCRIPTION
Entry Timestamp
Point in time when the communication was received by T2S.
Input Channel
Identifier for the channel that was used for communication (e.g. Network
provider, dedicated line, etc.)
Status
Status of the processing on communication level
Status Description
Additional status information (e.g. error code)
All incoming/outgoing communication is stored for sake of audit trail and traceability, and functionality to
ensure non repudiation is foreseen.
In case of T2S operations, called tasks, where a 4-eye principle is applicable (due to the T2S system
user’s role or activity itself) it must be ensured that a second authorised T2S system user has confirmed
the T2S operation before the execution of this operation. Details related to the processing of tasks are
provided in Flow Management Module (Information Router Function).
Final_T2S_GFS_110.doc
Page 76
T2S General Functional Specifications
Functional Description
Interface
3.2.4. Access Management
3.2.4.1. Diagram of the module
3.2.4.2. Description of the module
T2S functionalities and data must be protected against intrusion and unauthorised access. The Access
Management Module checks that the communication is transmitted via a secure network and by a trusted
party.
Furthermore, it provides authentication and authorisation mechanisms:
•
Authentication: the T2S system user’s identity is proved (as a real person or as an
application) by checking the identity with a certificate of the T2S system user;
Final_T2S_GFS_110.doc
Page 77
T2S General Functional Specifications
Functional Description
Interface
•
Authorisation: the functions a T2S system user can perform in T2S are based on a business
role model. Whenever a T2S system user interacts with T2S, Access Management checks that
this T2S system user has the appropriate roles that are required for this activity.
3.2.4.3. Description of the functions of the module
1 – Access Control
This function ensures a strong authentication mechanism to avoid intrusion and unauthorised access to
T2S {T2S.18.770}.
For every Communication U2A/A2A (incoming) the function identifies the sender and sends a request to
the Certificate Management. Access Control validates the received certificate in order to ensure that the
communication is sent from a secured and recognised technical address {T2S.12.110}, {T2S.12.120}.
The Access Control Function rejects the Communication U2A/A2A (Rejection, access denied) in case the
connecting party cannot be authenticated. The involved T2S party receives the information concerning the
rejection including the respective error code.
After positive authentication of the sender Access Control sends another request to Roles Control in order
to assign the appropriate user roles to the certified T2S system user. The Access Control checks that the
sender of an incoming communication is authorised to perform the intended business operations in T2S
by checking the user roles assigned to the T2S system user. The Access Control rejects the message in
case the T2S system user does not have at least one assigned user role or in case of a negative result of
the authorisation validation. The sender is informed about any rejection (Communication U2A/A2A
(Rejection, access denied)) including the cause of rejection.
After passing successfully the authentication and authorisation checks, the incoming communication is
routed to the Structure and Syntax Check Module.
2 – Certificate Management
This function manages the certificates in T2S through the following features:
•
the administration, the generation and the storage of certificates;
•
the provision of answers to requests of the Access Control when a access attempt to T2S
takes place and a certificate has to be checked.
Certificates are issued and revoked in accordance to the T2S system user registration operations of an
authorised T2S system administrator. The list of registered and valid certificates is stored in a certificates
data store within the Certificate Management.
Final_T2S_GFS_110.doc
Page 78
T2S General Functional Specifications
Functional Description
Interface
The function offers the following possibilities to ensure a proper administration of the stored certificates:
•
generate/issue certificate: This sub-function creates a new certificate registered and stored in
the certificates data store and issued to a specific T2S system user. It is possible to connect
one certificate to several T2S system users belonging to the same T2S party;
•
revoke certificate: This sub-function gives the T2S operator the possibility to delete the
relationship between a T2S system user and a certificate;
•
enable/disable certificate: The sub-function authorises T2S system administrators to enable
or disable a certain user’s certificate. It is only possible to disable a certificate if it is not
assigned anymore to a T2S system user. A deletion of a certificate is not foreseen;
•
manage trusted Certificate Authority (CA): Via the Certificate Management a T2S system
administrator can register, amend or un-register trusted Certificate Authorities.
T2S system administrators who can manage certificates are not able to manage roles and vice versa. It
has to be inhibited that the underlying user roles are assigned to the same T2S system user.
3 – Roles Control
Access to T2S is based on the business role of a T2S system user.
Data related to roles are stored in the Static Data and are accessible by the Interface.
This function answers requests of the Access Control related to the roles assigned to the requested
sender. It checks the roles and gives an adequate answer back to the Access Control. As for some
validations in the subsequent modules the information on the user roles is needed. This information is
forwarded with the communication.
There is a hierarchical structure in the concept of privileges which defines the level of information the T2S
system user is able to see. A T2S actor is only allowed to see its own data while a T2S operator by
definition is able to see the data of all T2S actors.
Each level of this hierarchy (T2S operator, CSD, T2S party, NCB, payment bank) has another distinction
within the entity: system administrator and business user. A system administrator is allowed to maintain
the T2S system users of the entity while a business user has only privileges to perform business
operations.
Each T2S actor is responsible for managing his T2S system users, meaning he is responsible for the
designation of T2S system users and the assignment of specific roles to each T2S system user. In this
regard T2S actors are able to administrate the management of their user’s roles taking into account the
legal, regulatory and contractual requirements of and between the T2S actors {T2S.18.730}. Some
CSDs may configure different roles for their participants in order to provide a differentiated service
offering.
Final_T2S_GFS_110.doc
Page 79
T2S General Functional Specifications
Functional Description
Interface
Static data change requests like a maintenance instruction for the change of a role or a user-to-role
assignment in Static Data is treated by the Interface like any other Static Data maintenance instruction.
The message passes all the validations in the Interface and is routed to the Static Data Domain for the
actual processing.
3.2.4.4. Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Communication
U2A/A2A
(Incoming)
IN
Messages and files
(U2A/A2A)
T2S actors
Communication
U2A/A2A
(Rejection, access
denied)
OUT
Rejection delivered in
U2A/A2A
T2S actors
Certificate issuance OUT
Certificate
T2S actors
Communication
U2A/A2A
(Incoming)
OUT
Messages and files
(U2A/A2A) validated by
Access Management
Structure and Syntax
Check
Certificate
maintenance
IN
Certificate maintenance
request
Flow Management
3.2.4.5. Data accessed by the module
DATA
ACCESS MODE
STATUS
COMMENTS
Certificate Management Read/Write
Certificates
Static Data
Roles
Final_T2S_GFS_110.doc
Read
Page 80
T2S General Functional Specifications
Functional Description
Interface
3.2.5. Structure and Syntax Check
3.2.5.1. Diagram of the module
3.2.5.2. Description of the module
The module receives communication from the Access Management and performs a series of checking and
verification procedures. During the entry check, the relevant technical validations regarding the specific
structure, format and syntax of messages are executed.
Final_T2S_GFS_110.doc
Page 81
T2S General Functional Specifications
Functional Description
Interface
3.2.5.3. Description of the functions of the module
1 – Communication Identifier
The function Communication Identifier is required to match the correct schema files respectively split files
into single messages for technical validations. Therefore, this function includes the following subfunctions:
Identify communication means
The Communication Identifier detects the communication which is used by the T2S actor. Communication
can be message and file based {T2S.12.130}.
Identify communication channel
The Communication Identifier identifies the communication channel used for accessing T2S:
•
in user-to-application mode (U2A) for activities performed manually by T2S system users via
onscreen display;
•
in application-to-application mode (A2A) to allow direct communication between software
applications via XML messages.
File operations
The file structure is based on XML technology and ISO 20022 standard {T2S.12.080}, {T2S.14.010}.
The Communication Identifier ensures that inbound files are not lost and that the recommendations of the
Giovannini file transfer rulebook (generic rules for file construction and best practices for file transfer
operations) are applied {T2S.12.090}.
It is validated if the file is readable and if it has a proper structure (i.e. file header, file trailer and the
messages that the file includes must be identifiable).
If there are file transfer or structure problems the files are rejected entirely {T2S.12.100}. A
Communication U2A/A2A (Rejection) is immediately created and sent to the sender of the file including
the error code/reason for the rejection.
During the maintenance window the availability of Interface services is restricted {T2S.03.230}. In case
a file enters the Interface Module during the maintenance window, the Communication Identifier stores
the file and processes it afterwards in the order of entrance {T2S.20.030}.
To allow the subsequent entry checks this sub-function splits files and multiple requests into single
messages {T2S.12.100}, {T2S.16.167}.
On file level the function does a duplicate emission check {T2S.12.090}. The duplicate emission check
for messages is done by subsequent modules.
Final_T2S_GFS_110.doc
Page 82
T2S General Functional Specifications
Functional Description
Interface
Identify nature of communication
The Communication Identifier checks the nature of the communication (bulk message or single settlement
instruction, query request, static data change request, liquidity transfer order, etc.). This information is
used by the Flow Management Module (Information Router Function) for the routing of business data.
Forward messages to Entry Check Function
Once the splitting and the identification of the incoming communication are completed the single message
(instruction / request / notification / order) is forwarded to the Entry Check Function to execute the
relevant technical validation checks.
2 – Entry Check
The function performs the relevant technical validations for the received communication. It ensures that
each message (including bulk messages) that is forwarded to the Flow Management is well-formed and
valid {T2S.12.105}.
The syntax and structure of messages required by T2S is based on XML technology, ISO 20022 standard
{T2S.12.070}, {T2S.14.010} and Giovannini protocol recommendations {T2S.12.050}. This applies
to all kinds of messages {T2S.12.040}.
Technical validations
Each kind of message can be connected to only one XML schema file. Therefore the validation is done
against these schemas. Each message must be in line with ISO 20022 standard. It must be ensured that:
•
the XML message is well-formed (i.e. each opening tag has a corresponding closing tag);
•
the structure of the message corresponds to the schema file. This includes:
•
-
the correct order (hierarchy) of blocks and elements,
-
the naming of blocks and elements.
the occurrence of the elements is correct: elements can appear once or repetitively in an
XML message;
•
all mandatory blocks and elements of the XML message are filled;
•
the tags of the message are filled in the correct format: including the data type (e.g. text,
alphanumeric, amount, etc.) and the format (e.g. maximum and minimum length).
Message in case of negative result
In case of any negative result out of the Entry Check this sub-function creates a Communication U2A/A2A
(Rejection) to be sent to the sender of the original message (T2S actor) including the error code/reason
for the rejection.
Final_T2S_GFS_110.doc
Page 83
T2S General Functional Specifications
Functional Description
Interface
During the maintenance window the availability of Interface services is restricted {T2S.03.230}. The
processing during the maintenance window depends on the message type and on the communication
channel:
•
static data updates received in A2A mode during the maintenance window and settlement
instructions received during the maintenance window are queued for processing at the end
of the maintenance window;
•
queries received in A2A mode are rejected during the maintenance window {T2S.14.040};
•
static data updates and queries in U2A mode are not possible because the related screens
are not available.
In case of rejection, the Entry Check generates a Communication U2A/A2A (Rejection) indicating that T2S
is currently not available due to the maintenance window.
Forward message to Flow Management Module
Having completed the entry checks the communication (technically validated instruction / request /
notification / order) is forwarded to the Flow Management Module.
3.2.5.4. Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
Access Management
TO
Communication
U2A/A2A (Incoming)
IN
Messages and files
(U2A/A2A) validated by
Access Management
Technically validated
instruction, request,
notification, order
OUT
Technically validated
messages
Flow Management
Communication
U2A/A2A (Rejection)
OUT
Rejection delivered in
U2A/A2A
T2S actors
3.2.5.5. Data accessed by the module
DATA
Message Format
Final_T2S_GFS_110.doc
ACCESS MODE
STATUS
COMMENTS
Read
Page 84
T2S General Functional Specifications
Functional Description
Interface
3.2.6. Flow Management
3.2.6.1. Diagram of the module
INTF:Structure and Syntax Check
INTF:Access Management
T2S actor
Certificate
maintenance
Communication U2A/A2A
(Status/response/notification/
message)
Technically validated
instruction / request /
notification / order
Flow Management
<<data store>>
SD
Information Router
<<data store>>
XF
Certificate
maintenance
Communication U2A/A2A
(Status/response/
notification/message)
Message Generator
See diagram1 for detailed flows with
Biling, Query Management, Static
Data Modules, Report Management
OPSR:Billing
SQRA:
Query Management
Static Data Modules
See diagram 2 for detailed flows with Statistical
Information, Scheduling, Data Migration, Oerational
Monitoring
SQRA:Statistical
Information
SQRA:
Report Management
Final_T2S_GFS_110.doc
OPSR:
Scheduling
OPSR: Operational
Monitoring
OPSR:
Data Migration
See diagram 3 for detailed flows with Liquidity Control,
Legal Archiving, Instructions Validations and Notification
and Informatiion Managment
LQMG:
Liquidity Control
LQMG:
Notification and Information Management
SQRA:
Legal Archiving
LCMM:
Instructions Validation
See diagram 4 for detailed flows with
Billing, Static Data Modules, Report
Management, Query Management
OPSR:Billing
SQRA: Report
Management
SQRA:
Query Management
Static Data Modules
See diagram 5 for detailed flows with
Operational Monitoring, Statistical
Information, Data Migration, Legal
Archiving, Scheduling
OPSR: Operational
Monitoring
OPSR:
Data Migration
Page 85
SQRA: Statistical
Information
SQRA: Legal
Archiving
OPSR:
Scheduling
See diagram 6 for detailed flows with Status Management,
Instruction Maintenance, Instruction Matching, Liquidity
Control, Notification and Information Management
LCMM:
Status Management
LCMM:
Instructions Matching
LCMM: Instruction
Maintenance
LQMG:
Liquidity Control
LQMG:Notification and
Information Management
T2S General Functional Specifications
Functional Description
Interface
Diagram 1:
Diagram 2:
Diagram 3:
Final_T2S_GFS_110.doc
Page 86
T2S General Functional Specifications
Functional Description
Interface
Diagram 4:
Diagram 5:
Diagram 6:
3.2.6.2. Description of the module
This module receives the technically validated communication (technically validated instruction / request /
notification / order) from the Structure and Syntax Check Module and subsequently acts as an information
editor and router. It has an inbound and an outbound dimension:
•
The inbound dimension of the Flow Management Module extracts all the relevant business
data from the received messages in order to structure in internal format the information to
be processed by the subsequent modules. Moreover, it determines the relevant T2S modules
and routes the structured data to them.
Final_T2S_GFS_110.doc
Page 87
T2S General Functional Specifications
Functional Description
Interface
•
The outbound dimension of this module generates the relevant messages based on data
received in internal format from the respective modules and sends these messages to the
relevant T2S actors according to their specific message subscription preferences. Only those
messages a T2S actor has opted for are delivered.
The term “internal format” is used in relation to all T2S internally exchanged flows between the Interface
(Flow Management Module) and the subsequent modules. This term indicates that not the original
message but only the business data included in the message is forwarded to the subsequent modules, so
that possible structure changes of XML messages only have an impact on the interface and not on the
whole system. Additionally the size of the business data exchanged between the Interface and the
subsequent modules is reduced in comparison to the original message.
3.2.6.3. Description of the functions of the module
1 – Information Router
The Information Router Function manages the inbound and outbound communication flows.
As far as the inbound dimension is concerned, this function {T2S.12.180}, {T2S.12.210}:
•
receives communication from Structure and Syntax Check Module;
•
extracts relevant business data from communication, depending on which business data are
needed by the subsequent modules (e.g. ISIN code, counterparty codes for settlement
instructions) and structures the business data to be processed by the subsequent modules;
•
is responsible for the routing of the business data related to the messages listed in the
following table:
MODULE
MESSAGE
FLOW
(INTERNAL FORMAT)
Incoming
notification
REMARKS
URD REFERENCES
Notification and
Information
Management
(LQMG)
Notification from
RTGS System
{T2S.06.060}
Liquidity Control
(LQMG)
Liquidity Transfer
Order
Immediate liquidity
transfer order
{T2S.06.190},
{T2S.06.195},
{T2S.06.200},
{T2S.13.083}
Status
Status information
{T2S.06.190},
{T2S.06.195}
Invoice request
{T2S.15.130}
RTGS answer
Billing (OPSR)
Invoice generation
request
Final_T2S_GFS_110.doc
Page 88
T2S General Functional Specifications
Functional Description
Interface
MODULE
MESSAGE
FLOW
(INTERNAL FORMAT)
REMARKS
URD REFERENCES
Invoice cancellation
request
Query
Management
(SRQA)
User Query
User query
{T2S.14.010},
{T2S.14.020}
Report
Management
(SRQA)
Report Request
Report request
{T2S.13.160},
{T2S.13.170}
Static Data
Modules
(SDMG)
Static Data
Maintenance
Approval Request
Static Data
Maintenance
approval request
Static Data
Maintenance Request
Static Data
Maintenance
request
incl. Standing/Predefined
liquidity transfer order
{T2S.12.170},
{T2S.13.140},
{T2S.16.163},
{T2S.16.165}
Notification from
Collateral System
Static Data
Maintenance
request
eligible securities for autocollateralisation and close
links
{T2S.06.430}
Legal Archiving
(SRQA)
Archive Retrieval
Request
Archive request
Instructions
Validation
(LCMM)
Settlement
Instruction,
Maintenance
Instruction, Blocking
Instruction,
Reservation
Instruction
Settlement/
Maintenance
instruction
Intraday credit
reimbursement
request
Settlement/
Maintenance
instruction
Report generation
request
Operational
Monitoring
(OPSR)
Scheduling
(OPSR)
Final_T2S_GFS_110.doc
{T2S.12.170}
{T2S.17.120}
including reservation, blocking
(T2S parties, accounts,
positions), cancellation,
amendment and hold-and
release requests
{T2S.05.350},
{T2S.05.390},
{T2S.05.410},
{T2S.06.120},
{T2S.08.890},
{T2S.09.180}
{T2S.12.200}
{T2S.08.820}
PULL data request
Trouble case access
request
Business date
update request
{T2S.11.040}
Access scheduling
information request
{T2S.11.040}
Event maintenance
request
{T2S.11.040}
Page 89
T2S General Functional Specifications
Functional Description
Interface
MODULE
MESSAGE
Statistical
Information
(SRQA)
Migration Tools
(OPSR)
•
FLOW
(INTERNAL FORMAT)
REMARKS
URD REFERENCES
Query and report
request
{T2S.15.010},
{T2S.15.020},
{T2S.15.030},
{T2S.15.040}
S.W.M. request
{T2S.15.010},
{T2S.15.020},
{T2S.15.030},
{T2S.15.040}
M.D. analysis
request
{T2S.15.010},
{T2S.15.020},
{T2S.15.030},
{T2S.15.040}
Data export request
{T2S.15.010},
{T2S.15.020},
{T2S.15.030},
{T2S.15.040}
Flat file
Flat file
{T2S.21.290}
Excel file
Excel file
{T2S.21.290}
is responsible for the management of T2S operations where a 4-eye principle is applicable
(due to the T2S system user’s role or the activity itself). These T2S operations, called tasks,
are stored as dynamic data directly after the entry of the related message. Each task gets a
unique Task ID. The business data of the task (internal format) and the Task ID is delivered
to the subsequent module. The related subsequent module executes business validations and
processes the business data, but without completing it. The related subsequent module
sends a response to the Interface which includes the result of the business validation, the
Task ID and, if needed, the reference of the subsequent module. In case of negative result
the task based on an incoming message is rejected. In case of positive result a second
authorised T2S system user has to confirm or cancel the task. A received confirmation
message is linked to the original request (Task ID). Then the confirmation including the Task
ID and, if needed, the reference of the subsequent module is forwarded to the subsequent
module. A received cancellation message is linked to the original request (Task ID) which is
rejected afterwards in coordination with the subsequent module. Related to the T2S system
user’s privileges the status of task processing is displayed in U2A mode. T2S system user
related tasks can also be requested in A2A mode.
As far as the outbound dimension is concerned, this function:
•
retrieves the T2S actor from the received data in internal format;
•
identifies the message subscription preference of the T2S actor;
Final_T2S_GFS_110.doc
Page 90
T2S General Functional Specifications
Functional Description
Interface
•
identifies the technical address of the relevant T2S actor to which the communication should
be routed;
•
sends messages received from Message Generator to the respective T2S actors.
The Information Router receives from the Message Generator the messages which have to be sent to the
T2S actors according to their message subscription preferences.
The Information Router retrieves all information regarding:
•
T2S actors entitled to receive certain information;
•
the message subscription preference of the T2S actor;
•
the technical addresses to which the respective communication should be routed from the
Static Data Domain.
This data is used to perform the outbound communication with the data from the different domains to be
considered {T2S.12.140}, {T2S.12.150}.
In A2A mode all messages are sent in due time to T2S actors and routed to the appropriate technical
address. To ensure that the information reaches the T2S actor requesting it, positive and negative
technical
acknowledgement
features
are
used.
Any message
can
manually
be
resent
until
acknowledgement is received from the network provider (chosen by the T2S actor for its communication
with T2S) or from the T2S actor himself {T2S.12.160}.
2 – Message Generator
The Message Generator receives all relevant data from modules of other domains that informs it about
the event which has to be communicated including all necessary data to generate the appropriate
messages in correct structure, syntax and format {T2S.12.030}, {T2S.12.190}, {T2S.12.220}. All
generated messages are forwarded to the Information Router Function without delay {T2S.13.060}.
Final_T2S_GFS_110.doc
Page 91
T2S General Functional Specifications
Functional Description
Interface
In detail this function handles the following messages from other modules:
MODULE
Status
Management
(LCMM)
MESSAGE
Validation Status,
Matching Status,
Maintenance
Instruction Status,
Blocking Status,
Reservation Status,
Settlement Status,
CoSD Status,
Eligibility Status
FLOW
(INTERNAL FORMAT)
Message data
REMARKS
settlement-related
information (settlement
confirmation, settlement
status message)
auto-collateralisation related
information
(transferring/blocking and
retransferring/unblocking
status message)
In the status message the
source of input is reported
(e.g. amendment of
instruction made by a CSD
following a corporate event
on a pending instruction
sent by a directly connected
T2S party).
Instructions
Matching
Allegement
Allegement data
Including allegement
removal and cancellation
URD REFERENCES
{T2S.03.120},
{T2S.05.250},
{T2S.05.280},
{T2S.05.330},
{T2S.05.380},
{T2S.05.430},
{T2S.05.480},
{T2S.05.530},
{T2S.06.440},
{T2S.06.450},
{T2S.09.220},
{T2S.09.230},
{T2S.09.250},
{T2S.12.220},
{T2S.13.070},
{T2S.13.080},
{T2S.13.090},
{T2S.13.100},
{T2S.13.110},
{T2S.13.120},
{T2S.13.130}
{T2S.05.340},
{T2S.05.440},
{T2S.05.540}
{T2S.13.133}
Instruction
Maintenance
(LCMM)
Status
Allegement data
Query
Management
(SRQA)
Query Result
Queried data
Error
Error data
(Queries)
Notification
Outgoing
notification
Alert
Alert data
{T2S.06.260},
{T2S.06.310},
{T2S.06.320},
{T2S.06.370},
{T2S.06.380},
{T2S.06.400},
{T2S.06.420}
Confirmation data
{T2S.13.086}
Notification and
Information
Management
(LQMG)
Final_T2S_GFS_110.doc
including Static Data
information
{T2S.14.010},
{T2S.14.020},
{T2S.14.825}
i.e. liquidity transfers from
T2S to RTGS systems
{T2S.06.060},
{T2S.13.086}
Page 92
T2S General Functional Specifications
Functional Description
Interface
MODULE
Liquidity Control
(LQMG)
Legal Archiving
(SRQA)
Report
Management
(SRQA)
Billing (OPSR)
Static Data
Modules
(SDMG)
MESSAGE
FLOW
(INTERNAL FORMAT)
Status
Status information
Error
Rejection
(Immediate
liquidity transfer
order)
Archive Retrieval
Response
{T2S.13.086}
(Non)
Acknowledgement
only (non)
acknowledgement sent to
requestor
{T2S.17.120}
Requested archived
data availability
information
The requested archived data
is now available for
download by the requestor
{T2S.17.120}
Report
Report
Error
Error data
(Reports)
Invoice
Invoice
Error
Error data (Billing)
Invoice Cancellation
Invoice cancellation
Static Data
Maintenance
Response
Static Data
Maintenance
response
Static Data
Maintenance Approval
Response
Static Data
Maintenance
approval response
Alert / Report
Scheduling
(OPSR)
Final_T2S_GFS_110.doc
URD REFERENCES
e.g. booking confirmation
messages
Static Data
Maintenance
receipt
Operational
Monitoring
(OPSR)
REMARKS
{T2S.13.160},
{T2S.13.170}
{T2S.15.100},
{T2S.15.110}
incl. Standing/Predefined
liquidity transfer order
{T2S.12.190},
{T2S.13.140}
{T2S.12.190},
{T2S.13.140}
Information about deferred
update
Alert / display /
report
Trouble case
access response
Business date
update response
{T2S.11.040}
Scheduling
information
response
{T2S.11.040}
Maintenance
response
{T2S.11.040}
Page 93
T2S General Functional Specifications
Functional Description
Interface
MODULE
MESSAGE
Statistical
Information
(SRQA)
Migration Tools
(OPSR)
FLOW
(INTERNAL FORMAT)
REMARKS
URD REFERENCES
Query and report
response
{T2S.15.010},
{T2S.15.020},
{T2S.15.030},
{T2S.15.040}
S.W.M. response
{T2S.15.010},
{T2S.15.020},
{T2S.15.030},
{T2S.15.040}
M.D. analysis
response
{T2S.15.010},
{T2S.15.020},
{T2S.15.030},
{T2S.15.040}
Formatted data
{T2S.15.010},
{T2S.15.020},
{T2S.15.030},
{T2S.15.040}
Success report
Error
Error data (Data
Migration)
3.2.6.4. Description of the Input/Output of the module
FLOW
IN/OUT
FROM
TO
Technically validated
instruction / request /
notification / order
IN
Incoming notification
OUT
Notification and Information
Management (LQMG)
RTGS answer
OUT
Notification and Information
Management (LQMG)
Immediate liquidity
transfer order
OUT
Liquidity Control (LQMG)
Status information
OUT
Liquidity Control (LQMG)
Invoice request
OUT
Billing (OPSR)
Invoice generation
request
OUT
Billing (OPSR)
Final_T2S_GFS_110.doc
Structure and Syntax
Check
Page 94
T2S General Functional Specifications
Functional Description
Interface
FLOW
IN/OUT
FROM
TO
Invoice cancellation
request
OUT
Billing (OPSR)
User query
OUT
Query Management (SRQA)
Report request
OUT
Report Management (SRQA)
Report generation
request
OUT
Report Management (SRQA)
Static Data Maintenance
approval request
OUT
Static Data Management
(SDMG)
Static Data Maintenance
request
OUT
Static Data Management
(SDMG)
Archive request
OUT
Legal Archiving (SRQA)
Settlement/Maintenance
instruction
OUT
Instruction Validation (LCMM)
Message data
IN
Status Management
(LCMM)
Action (Executed)
IN
Instruction Maintenance
(LCMM)
Allegement Data
IN
Instruction Maintenance
(LCMM)
Queried data
IN
Query Management
(SRQA)
Error data (Queries)
IN
Query Management
(SRQA)
Outgoing notification
IN
Notification and
Information Management
(LQMG)
Alert data
IN
Notification and
Information Management
(LQMG)
Confirmation data
IN
Notification and
Information Management
(LQMG)
Status information
IN
Liquidity Control (LQMG)
Rejection (Immediate
liquidity transfer order)
IN
Liquidity Control (LQMG)
Final_T2S_GFS_110.doc
Page 95
T2S General Functional Specifications
Functional Description
Interface
FLOW
IN/OUT
FROM
TO
(Non) Acknowledgement IN
Legal Archiving (SRQA)
Requested archived data IN
availability information
Legal Archiving (SRQA)
Report
IN
Report Management
(SRQA)
Error data (Reports)
IN
Report Management
(SRQA)
Invoice
IN
Billing (OPSR)
Error data (Billing)
IN
Billing (OPSR)
Invoice cancellation
IN
Billing (OPSR)
Static Data Maintenance
response
IN
Static Data Management
(SDMG)
Static Data Maintenance
approval response
IN
Static Data Management
(SDMG)
Static Data Maintenance
receipt
IN
Static Data Management
(SDMG)
Communication
U2A/A2A (Status/
response/ notification/
message)
OUT
T2S actor
Certificate maintenance
OUT
Access Management
PULL data request
OUT
Operational Monitoring
(OPSR)
Trouble case access
request
OUT
Operational Monitoring
(OPSR)
Business date update
request
OUT
Scheduling (OPSR)
Access scheduling
information request
OUT
Scheduling (OPSR)
Event maintenance
request
OUT
Scheduling (OPSR)
Query and report
request
OUT
Statistical Information (SRQA)
S.W.M. request
OUT
Statistical Information (SRQA)
M.D. analysis request
OUT
Statistical Information (SRQA)
Data export request
OUT
Statistical Information (SRQA)
Flat file
OUT
Data Migration (OPSR)
Excel file
OUT
Data Migration (OPSR)
Final_T2S_GFS_110.doc
Page 96
T2S General Functional Specifications
Functional Description
Static Data Management
FLOW
IN/OUT
FROM
TO
Alert / Display / Report
IN
Operational Monitoring
(OPSR)
Trouble case access
response
IN
Operational Monitoring
(OPSR)
Business date update
response
IN
Scheduling (OPSR)
Scheduling information
response
IN
Scheduling (OPSR)
Maintenance response
IN
Scheduling (OPSR)
Query and report
response
IN
Statistical Information
(SRQA)
S.W.M. response
IN
Statistical Information
(SRQA)
M.D. analysis response
IN
Statistical Information
(SRQA)
Formatted data
IN
Statistical Information
(SRQA)
Success report
IN
Data Migration (OPSR)
Error data (Data
Migration)
IN
Data Migration (OPSR)
3.2.6.5. Data accessed by the module
DATA
ACCESS MODE
Message Format
Read
Static Data
Read
STATUS
COMMENTS
Displayed in the activity diagrams as
“<<data store>> XF”. Basis of this data
store are the schema files of all XML
messages used in T2S.
3.3. Static Data Management
3.3.1. General Introduction
This domain includes the whole set of functions provided by T2S for the management of reference data
for parties (e.g. CSDs, NCBs, CSD participants, payment banks), securities, securities accounts, T2S
Dedicated cash accounts, configuration rules and parameters.
Final_T2S_GFS_110.doc
Page 97
T2S General Functional Specifications
Functional Description
Static Data Management
Static Data Management allows authorized T2S system users to input their own static data objects1 (e.g.
parties, securities, securities accounts) and to access and maintain them {T2S.11.460}, i.e. to create
new objects or to update or delete already existing objects {T2S.11.470}. For each T2S system user,
the specific set of available functions and data are determined by the relevant access rights
{T2S.11.480} {T2S.11.490}.
Static Data Management is always available during the business day, except during the technical
maintenance window, and can be accessed both via user-to-application and application-to-application
mode {T2S.03.220}. Any maintenance request can be processed both according to the two eyes or four
eyes principle (User-to-Application mode only)
{T2S.16.170} {T2S.06.210}. {T2S.16.163}
{T2S.16.310}:
•
two eyes principle: the maintenance request is processed immediately and the relevant
change is made active (i.e. available for processing in T2S) immediately, without the need of
any approval by a second T2S system user;
•
four eyes principle: the maintenance request is processed immediately, but the relevant
change is made active only after approval by a second T2S system user.
The Static Data Management domain is partitioned into five modules:
•
Party Data Management;
•
Security Data Management;
•
Securities Account Data Management;
•
T2S Dedicated Cash Account Data Management;
•
Rules & Parameters Data Management.
1 A static data object is a complex element of logically connected, self-consistent information. Each object usually comprises several static data items,
each item being a simple entity defined by a set of attributes. For instance, a party is considered as a static data object, made of several static data
items such as party code, party name, party address and so forth.
Final_T2S_GFS_110.doc
Page 98
T2S General Functional Specifications
Functional Description
Static Data Management
From a business logic perspective, each module provides a common set of functions, the only difference
being the impacted objects. For this reason, the following picture shows a generic activity diagram at
module level that can be considered valid for all the modules belonging to the Static Data Management
domain.
ALL DOMAINS
INTF:Flow Management
OPSR:Scheduling
Static Data
Management
Generic Module
Static Data
Access Request
Static Data
Maintenance
Receipt
Static Data
Maintenance Approval
Request
Static Data
Maintenance Request
Event
Static Data
Consistency
Check
No
Valid Request?
Yes
Validated
Request
Deferred execution?
Static Data
Access
Request
Enqueue
Yes
No
Static Data
Maintenance
Execution
Queued Request
Notify
Reception
Retrieve Queued
Requests
Retrieved Requests
Four eyes
principle?
Yes
No
Possible Side-effect?
Yes
Processed Static Data
Maintenance Request
Static Data Notify
Maintenance
No
Static Data
Access Response
ALL DOMAINS
Final_T2S_GFS_110.doc
Static Data
Maintenance
Response
Static Data Maintenance
Approval
Response
INTF:Flow Management
Static Data
Maintenance
Notification
LCMM:Instruction Validation
Page 99
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.2. Dynamic data managed by the domain
The following diagram shows the conceptual dynamic data model for static data maintenance instructions.
1 – Static Data Maintenance Instruction
This entity includes all attributes that are common to any static data maintenance instruction, i.e. either a
maintenance request or a maintenance approval request. It does not include any attributes, besides the
specific attributes relevant for the specialised entities Static Data Maintenance Request and Static Data
Maintenance Approval Request (see below).
Each static data maintenance instruction is linked its relevant message, to the user who submitted the
request and to one or many static data entities (due to the fact that any maintenance request may impact
multiple static data objects). It is also linked to one or many statuses (describing the different steps of its
processing) and it may be linked to one or many errors (encountered during its processing).
2 – Static Data Maintenance Request
This entity is a specialisation of the Static Data Maintenance Instruction entity and it includes all attributes
that are specific for maintenance requests.
ATTRIBUTE
Request Type
DESCRIPTION
Specifies the type of the static data maintenance request. Possible values
are:
Create
Update
Delete
Four Eyes Principle
Boolean attribute specifying whether the static data maintenance request
has to be processed according to the four eyes principle or not.
Final_T2S_GFS_110.doc
Page 100
T2S General Functional Specifications
Functional Description
Static Data Management
ATTRIBUTE
Change Type
DESCRIPTION
It specifies whether the static data maintenance request has to be applied
as a revision or as a historicization. Possible value are:
Revision
History
Each static data maintenance request is linked to the relevant static data maintenance instruction and
inherits all its attributes and relationships. Furthermore, if it was submitted according to the four eyes
principle, each request is also linked to the relevant maintenance approval request.
3 – Static Data Maintenance Approval Request
This entity is a specialisation of the Static Data Maintenance Instruction entity and it includes all attributes
that are specific for maintenance approval requests.
ATTRIBUTE
Approval Type
DESCRIPTION
Boolean attribute specifying whether the static data maintenance approval
request is an approval or a rejection.
Each static data maintenance approval request is linked to the relevant static data maintenance
instruction and inherits all its attributes and relationships. Furthermore, being related to a static data
maintenance instruction submitted according to the four eyes principle, each approval request is also
linked to the relevant maintenance request.
4 – Static Data Maintenance Instruction Status
This entity stores status information about each static data maintenance instruction.
ATTRIBUTE
Status Mnemonic
DESCRIPTION
It specifies the mnemonic for the status of a static data maintenance
instruction. Possible values are:
Validated
Pending (this value is possible for static data maintenance requests only)
Completed
Rejected
Each static data maintenance instruction status is linked to the relevant static data maintenance
instruction.
Final_T2S_GFS_110.doc
Page 101
T2S General Functional Specifications
Functional Description
Static Data Management
5 – Static Data Maintenance Instruction Error
This entity stores information about possible error encountered during the processing of any static data
maintenance instruction.
ATTRIBUTE
DESCRIPTION
Error Code
It specifies the type of error related to a static data maintenance
instruction.
Each static data maintenance instruction error is linked to the relevant static data maintenance
instruction.
3.3.3. Static Data Management use cases
Scope
This category of use cases describes the interaction between a T2S System User and the T2S static data.
Criteria
The criteria used to identify the use cases are: the instructing party, the access type, the mode to process
the request, the action type and function type of request, and the data type to be considered. The
possible criteria values are:
CRITERIA
POSSIBLE VALUES
COMMENT
Instructing Party
T2S Operator, CSD, CSD Participant, NCB,
Payment Bank, External systems (e.g. CCBM2)
Type of requestor
Access Type
U2A, A2A
Access to functionality starts from
User or from Application
Mode
2 eyes, 4 eyes
Identifies the kind of change
approval processes
Action Type
Maintenance Request, Access Request, Approval
Request
Type of request to be processed.
Function Type
Create, Update, Delete, Retrieve
Type of functionality
Data Type
Parties, Securities, Securities Accounts, T2S
Dedicated Cash Accounts, Rules and Parameters
Type of data to be considered
Final_T2S_GFS_110.doc
Page 102
T2S General Functional Specifications
Functional Description
Static Data Management
List of Use Cases
The criteria described above are reported in the following tree:
SD Management
T2S Operator
CSD
CSD Participant
Maintenance
Request
Parties
NCB
Payment Bank
U2A
A2A
2 eyes
4 eyes
Access Request
Create
Update
Securities
Securities
Accounts
External Systems
Approval Request
Delete
Retrieve
T2S Dedicated
Cash Accounts
Rules
Parameters
All the combinations of values are not relevant from a business point of view: the complete list of use
cases is presented in appendix.
Final_T2S_GFS_110.doc
Page 103
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.4. Processing of Static Data Management Use Cases
3.3.4.1. Selection of representative SM use cases
The use cases for static data management are structured according to the accessing user profile.
The following representative use cases are defined:
•
UC-SM-1 Static Data Maintenance;
•
UC-SM-2 Static Data Approval;
•
UC-SM-3 Static Data Access.
For UC-SM-1 and UC-SM-2, next diagram shows the interaction between different users with the Static
Data Maintenance and Static Data Approval use cases:
The diagram joins Create, Update and Delete scenarios for U2A and A2A users both 2-Eyes and 4-Eyes:
•
A Static Data Maintenance issued by a 4-Eyes user results in a pending instance to be
approved;
•
A different 4-Eyes user is needed to approve this pending instance;
•
A Static Data Maintenance issued by a 2-Eyes user results in an actual instance;
•
2-Eyes user can approve pending Static Data Maintenance instances;
•
A2A User can not approve a pending Static Data Maintenance instance.
Final_T2S_GFS_110.doc
Page 104
T2S General Functional Specifications
Functional Description
Static Data Management
For UC-SM-3, next diagram shows the interaction between different users with static Data Access use
case:
•
Static Data Access can be accessed by both A2A and U2A, with the same functionality and
different presentation layers;
•
No difference exists for 2-Eyes or 4-Eyes access mode.
3.3.4.2. Processing of UC-SM-1 Static Data Maintenance
This use case allows authorised T2S system users to create and manage Static Data objects according to
their own specific access rights.
Business assumption
As far as static data maintenance use case is concerned, different scenario based on the type of request
and the type of static data object involved are identified.
It is possible to apply a request of maintenance not only on the user's choice basis but also considering
the object involved.
In case of maintenance request, it is possible to have side-effect on the settlement process, where
“settlement process” is meant the whole set of processes (i.e. validation, matching, settlement and so on)
handling instruction in T2S, from their arrival in the system, until their settlement (or rejection).
In this context five possible scenarios are foreseen:
Final_T2S_GFS_110.doc
Page 105
T2S General Functional Specifications
Functional Description
Static Data Management
•
Scenario 1: maintenance request not concurrent with the settlement process and without
possible side-effects on it;
•
Scenario 2: maintenance request with possible side effect on the settlement process;
•
Scenario 3: maintenance request possibly concurrent with the settlement process;
•
Scenario 4: maintenance request possibly concurrent with the settlement process and with
possible side- effect on it;
•
Scenario 5: night-time maintenance request.
Processing
The following sequence diagram details the scenario 1:
The details for scenarios with possible side-effect with settlement process (2, 3, 4 and 5) are presented in
a different section of the document (see Static Data Maintenance Execution description in section 3.3.4) .
Final_T2S_GFS_110.doc
Page 106
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.4.3. Processing of UC-SM-2 Static Data Approval
This use case allows authorised T2S system users to approve pending Static Data objects maintenance
request according to their own specific access rights.
Business assumption
As far as static data approval use case is concerned, one possible scenario is identified with two possible
types of request: confirmation or rejection of the static data maintenance request waiting for approval.
Owing to the fact that only one request message both for approving or rejecting a static data change is
available, the two possibilities (i.e. confirmation or rejection) are managed via a type for the approval
request (with type=confirmation and type=rejection respectively).
Final_T2S_GFS_110.doc
Page 107
T2S General Functional Specifications
Functional Description
Static Data Management
Processing
The following sequence diagram details the scenario:
Static Data
Management
Domain
Interface
Domain
Requestor
Communication
SDM Approval Req
(Type)
Authorization Check
alt
[type= Confirmation]
SDMaintenance Execution
alt
[type=Rejection]
SDMaintenance Execution
SDM Approval Resp
SDM Approval Resp
3.3.4.4. Processing of UC-SM-3 Static Data Access
This use case allows authorised T2S system users to access static data objects according to their own
specific access rights.
Business assumption
As far as static data access use case is concerned only one scenario is identified.
Final_T2S_GFS_110.doc
Page 108
T2S General Functional Specifications
Functional Description
Static Data Management
Processing
The following sequence diagram details the scenario:
3.3.5. Functions
This section provides a description of the functions available within each of the five modules belonging to
the Static Data Management domain {T2S.16.160}.
1 – Static Data Access
This function enables authorized T2S system users to access static data objects according to their own
specific access rights, i.e. to view information about the objects they are granted access to.
The Static Data Access function receives as input an access request, already checked at syntax level by
the Interface domain. Each access request refers to the access to one or more objects of the same type
and it is processed immediately as follows: the data of the referenced objects that are accessible to the
relevant T2S system user are retrieved and collected in an output access response. In case the T2S
system user is not allowed to access none of the referenced objects, no data are retrieved and a negative
access response, containing the applicable error code, is issued.
Final_T2S_GFS_110.doc
Page 109
T2S General Functional Specifications
Functional Description
Static Data Management
In any case, as last step of the processing, the access response is provided in order to inform the
requestor about the result of the corresponding request.
This function can also used by the other domains to retrieve the information they need from the static
data repository. In this case, the access request is received directly from the relevant domain and the
access response is sent back to the same domain. Please note that, by convention, any access to Static
Data performed by other domains is represented in the respective activity diagrams with a direct data
flow between the relevant function and the Static Data datastore, in order to make the diagrams as
simple as possible. For this reason, data flows between other domains and the Static Data Access function
are not explicitly mentioned in those diagrams.
2 – Static Data Consistency Check
This function is the entry point for the processing of any object maintenance, both when using the two
eyes or the four eyes principle. As a consequence, it can receive as input both maintenance requests and
maintenance approval requests, both already checked at syntax level by the Interface domain.
{T2S.16.190} Authorized T2S system users are enabled to maintain static data objects according to
their own specific access rights, i.e. to modify information about the objects they are granted access to.
The consistency of a maintenance request is checked against the relevant static and dynamic data
{T2S.16.220}. On the other hand, when receiving a maintenance approval request, i.e. the second step
of an object maintenance performed according to the four eyes principle, the consistency with the
relevant static and dynamic data is checked against the result of the processing performed by the first
step, i.e. it is checked that the static data object created (and not yet available for processing because not
yet approved) during the first step is still consistent with the relevant static and dynamic data.
In any case, if the check result is negative, the maintenance process stops, the status of the request is set
to “Rejected” and the relevant information (i.e. status and error codes) is sent back to the Interface
domain, in order to inform the requestor about the object maintenance rejection. If the check result is
positive, the status of the request is set to “Valid” and the request is forwarded to the Static Data
Maintenance Execution function for further processing.
3 – Static Data Maintenance Execution
The Static Data Maintenance Execution function receives as input a validated request that is either a
maintenance request or a maintenance approval request (related to a previous maintenance request)
{T2S.16.180}, both validated by the Static Data Consistency Check function. Each maintenance request
refers to the maintenance of one or more objects of the same type {T2S.16.200} {T2S.11.720}. T2S
system users can also submit to T2S many maintenance requests related to many objects of different
types in one shot {T2S.16.210} (i.e. within a single file {T2S.16.490}). In this case, the file is split
into multiple single maintenance requests of one or more objects of the same type, which are processed
Final_T2S_GFS_110.doc
Page 110
T2S General Functional Specifications
Functional Description
Static Data Management
one by one by the functions of Static Data Management domain. The functional description of the splitting
process is given within the Interface domain (see the relevant chapter for more information).
Maintenance requests processing
Depending on the specific request and on the type of static data object involved, each maintenance
request submitted under the two eyes principle is processed according to one of the following scenarios2:
1
Maintenance request processing not concurrent with the settlement process3 and without possible
side-effects on it. The request is either related to a static data object that is not relevant for the
settlement process, i.e. that is not checked or changed in any way by the settlement process (e.g. update
of a party address), or not meant to be immediately valid (e.g. closing of a securities account as of a
future date). In this case, the request is processed immediately and the requested change is applied.
2
Maintenance request processing with possible side-effect on the settlement process. The request is
related to a static data object whose change may have an impact on the settlement process (e.g. update
of the tolerance amount for a specific currency and threshold), i.e. the object is checked but not changed
by the settlement process. In this case, the request is processed immediately and the requested change is
applied. Then, a maintenance notification is sent to the LCMM domain, so that the set of all individual
settlement instructions not yet settled and possibly impacted by the change can be revalidated against the
new data (see below the description of the Notify Maintenance function for more information).
3
Maintenance request processing possibly concurrent with the settlement process. The request is
related to a static data object that may be used concurrently by the settlement process (e.g. creation of a
new restriction on a securities account). In this scenario, two sub-cases are possible:
3.1 No settlement transactions that may use concurrently the relevant static data object are in the
“settlement in process” status (see the Validation, Provisioning and Booking module of the Settlement
domain for more information). The maintenance request is processed immediately and the requested
change is applied. In the meantime, no other settlement transactions that may concurrently use the
relevant static data object can reach the “settlement in process” status.
3.2 At least one settlement transaction that may concurrently use the relevant static data object is in the
“settlement in process” status. The maintenance request is not processed until all the relevant
settlement transactions leave this status and no other settlement transactions that may concurrently
use the relevant static data object can reach the “settlement in process” status. When the last
relevant settlement transaction leaves the “settlement in process” status, the maintenance request is
processed and the requested change is applied. Also during the maintenance request execution, no
2 The aim of what follows is only to describe the expected behaviour of the concurrent processes from a user perspective and not to provide a specific
technical approach. It will be part of the software design process to evaluate the different possibilities and to select the optimal solution for the
management of concurrent processes.
3 In this context, with “settlement process” is meant the whole set of processes (i.e. validation, matching, settlement and so on) handling instructions
in T2S, from their arrival in the system, until their settlement (or rejection).
Final_T2S_GFS_110.doc
Page 111
T2S General Functional Specifications
Functional Description
Static Data Management
other settlement transactions that may concurrently use the relevant static data object can reach the
“settlement in process” status.
4
Maintenance request possibly concurrent with the settlement process and with possible side-effect on
it. This is a combination of scenarios 2 and 3 in which the request is related to a static data object that
may be used concurrently by the settlement process and may have an impact on it (e.g. closing of a T2S
dedicated cash account). In this case, the request is processed as described for scenario 3 and the
requested change is applied. Then, like for scenario 2, a maintenance notification is sent to the LCMM
domain, so that the set of all individual settlement instructions not yet settled and possibly impacted by
the change can be revalidated against the new data (see below the description of the Notify Maintenance
function for more information).
5
Night-time maintenance request. Regardless of the relevant static data object, two sub-cases are
possible:
5.1 The request is received during a settlement cycle. The maintenance request can not be processed
immediately. T2S sends immediately a message to the sender, just to confirm the reception of the
request, whose status is set to “Pending”. The request is eventually processed at the end of the
current settlement cycle and the requested change is applied.
5.2 The request is received between two settlement cycles. The maintenance request is processed
immediately and the requested change is applied.
In case of a maintenance request submitted following the four eyes principle, such a request is processed
immediately anyhow (i.e. regardless of the specific request and the type of static data object involved),
but the requested change is not made active, waiting for a proper maintenance approval request.
Final_T2S_GFS_110.doc
Page 112
T2S General Functional Specifications
Functional Description
Static Data Management
The following table summarizes what has been described so far as to the processing of static data
maintenance requests:
ACTION
PRINCIPLE
RESULT
TWO EYES
A new object is created and it is made immediately available for processing. {T2S.16.230}
The request status is set to “Completed”.
FOUR EYES
A new object is created, but it is not made available, because a positive maintenance
approval request for this object maintenance is required. The request status is set to
“Awaiting approval”.
CREATE
All the requested changes are applied to the relevant object and its new version is made
immediately available. The request status is set to “Completed”.
TWO EYES
UPDATE
FOUR EYES
Each change is applied either as a revision or as a historicization, according to what is
specified in the request4. More in detail, in case of a revision the old version of the object is
made no longer available for processing, while for historicization both the new and old
versions are available for processing, but with different, non-overlapping validity periods.
All the requested changes are applied to the relevant object as revisions or historicization,
but its new version is not made available, because a positive maintenance approval request
for this object maintenance is required. The request status is set to “Awaiting approval”.
The relevant object is deleted and it is made immediately no longer available for processing.
The request status is set to “Completed”.
TWO EYES
Deletion is logical and not physical in order to keep track of entities that are no longer active
or valid. {T2S.16.270} {T2S.16.300}. This also makes possible the reactivation of a
logically deleted object (e.g. in case of a wrong deletion). {T2S.16.290}
Physical deletion of data revision and data history is applied {T2S.16.150} in the context
of archiving procedures in such a way as to ensure the referential integrity of static and
dynamic data and only after archiving processes have removed and archived the related
dynamic data. {T2S.16.280}
DELETE
FOUR EYES
The relevant object is provisionally deleted, but it is still available for processing, because a
positive maintenance approval request for this object maintenance object is required. The
request status is set to “Awaiting approval”.
Maintenance approval requests processing
Each maintenance approval request is processed as follows. If the approval is positive, the change
awaiting for approval is applied and the new (version of the) object is made available for processing,
according to the same scenarios described above for the processing of maintenance requests
{T2S.05.280} {T2S.16.610} {T2S.16.620} {T2S.13.150} {T2S.16.280}. The statuses of the
maintenance approval request and of the initial maintenance request are set to “Completed”. The
following table summarizes the possible results concerning the processing of a positive static data
maintenance approval request {T2S.17.100}:
4
Some data do not require historicization. For such data only revisions are allowed. Otherwise, either revisions or historicizations are possible.
Final_T2S_GFS_110.doc
Page 113
T2S General Functional Specifications
Functional Description
Static Data Management
ACTION
RESULT
CREATE
The object created during the processing of the relevant maintenance request is made available for
processing. The statuses of the maintenance approval request and of the initial maintenance request
are set to “Completed”.
UPDATE
DELETE
The new version of the object built during the processing of the relevant maintenance request is
made available for processing. The statuses of the maintenance approval request and of the initial
maintenance request are set to “Completed”.
As to the old version of the object, in case of a revision it is made no longer available for processing,
while for historicization it is made available for processing as well, but with different, non-overlapping
validity periods with the new version.
The object deleted during the processing of the relevant maintenance request is made no longer
available for processing. The statuses of the maintenance approval request and of the initial
maintenance request are set to “Completed”.
Conversely, if the approval is negative, the change awaiting for approval is rejected. The status of the
maintenance approval request is set to “Completed”, while the status of the initial maintenance request is
set to “Rejected”. The following table summarizes the possible results concerning the processing of a
positive static data maintenance approval request:
ACTION
RESULT
CREATE
The object created during the processing of the relevant maintenance request is not made available
for processing. The status of the maintenance approval request is set to “Completed”, while the
status of the initial maintenance request is set to “Rejected”.
UPDATE
The new version of the object built during the processing of the relevant maintenance request is not
made available for processing. The status of the maintenance approval request is set to “Completed”,
while the status of the initial maintenance request is set to “Rejected”. The old version of the object
remains available for processing.
DELETE
The object deleted during the processing of the relevant maintenance request is still available for
processing. The status of the maintenance approval request is set to “Completed”, while the status of
the initial maintenance request is set to “Rejected”.
In any case, as last step of the processing, the relevant information (i.e. a static data maintenance
response or a static data maintenance approval response) is sent to the Interface domain, in order to
inform the requestor about the result of the corresponding request.
4 – Static Data Notify Maintenance
This function notifies the LCMM domain about any changes made active on a static data object as a result
of a maintenance request or a maintenance approval request, when such changes may have side-effects
on the settlement process.
This case refers to scenarios 2 and 4 described above for the Static Data Maintenance Execution function,
when a change is applied to a static data object that may have an impact on the settlement process, i.e.
the change is related to an object that is checked but not changed by the settlement process.
Final_T2S_GFS_110.doc
Page 114
T2S General Functional Specifications
Functional Description
Static Data Management
In such a situation, this function sends a static data maintenance notification to the LCMM domain, so to
allow it re-validating against the new data the set of all individual settlement instructions not yet settled
and possibly impacted by the change and optionally sending a message both to the relevant CSD and
instructing party, in order to inform them in case of a negative result of the re-validation process.
{T2S.08.800} (please read the LCCM chapter for more information on the revalidation process).
5 – Request Enqueue
This function handles the queuing of any maintenance request or maintenance approval request received
during a night-time settlement cycle, in order to defer its execution until the cycle itself. By the end of its
processing, this function also triggers the Notify Reception function described below.
6 – Notify Reception
This function sends a Static Data Maintenance Receipt via Interface domain to the requestor, in order to
notify the reception and the deferred execution (i.e. at the end of the current night-time settlement cycle)
of the relevant maintenance request or maintenance approval request.
7 – Retrieve Queued Requests
This function is triggered by an event received from the Scheduler module at the end of each night-time
settlement cycle. When activated, this function retrieves all the queued maintenance requests or
maintenance approval requests (i.e. all the requests received while the last night-time settlement cycle
was running) and submit them to the Static Data Maintenance Execution function for processing.
3.3.6. Input / Output
FLOW
Static Data
Access Request
IN/OUT
FROM
TO
Request of access specific
information of Static Data
Interface
domain
Static Data Access
Static Data
Out
Access Response
Information retrieved from
Static Data as specified with
Access Request
Static Data
Access
Interface domain
Static Data
Maintenance
Request
In
Request of
insert/modify/delete
information present in Static
Data
Interface
domain
Consistency Check
Static Data
Maintenance
Approval
Request
In
Request of
confirmation/rejection of a
pending Static Data
maintenance request
Interface
domain
Consistency Check
Static Data
Maintenance
Response
Out
Response with result of Static
Data Maintenance Request
Static Data
Maintenance
Execution
Interface domain
Final_T2S_GFS_110.doc
In
DESCRIPTION
Page 115
T2S General Functional Specifications
Functional Description
Static Data Management
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Static Data
Maintenance
Approval
Response
Out
Response with result of Static
Data Maintenance Approval
Request
Static Data
Maintenance
Execution
Interface domain
Event
In
Event received by the end of
each night-time settlement
cycle.
Scheduling
Retrieve Queued
Requests
Static Data
Maintenance
Notification
Out
Notification of maintenance
with possible side-effect on
other modules.
Static Data
Notify
Maintenance
Life Cycle
Management &
Matching domain
Static Data
Maintenance
Receipt
Out
Notification of reception and
deferred execution of a
maintenance request or a
maintenance approval
request.
Notify
Reception
Interface
3.3.7. Data Accessed
DATA
ACCESS MODE
STATUS
COMMENT
STATIC DATA
All
Read / Write
All
None
DYNAMIC DATA
SD Maintenance
Instructions
Read / Write
n/a
None
Securities
Positions, Cash
Balances
Read
n/a
None
3.3.8. Common Information
All static data items have the following set of attributes in common for audit trail and static data change
management purposes {T2S.16.030} {T2S.16.040} {T2S.16.050} {T2S.16.060} {T2S.16.070}
{T2S.16.080} {T2S.16.090} {T2S.16.100} {T2S.16.110} {T2S.16.120} {T2S.16.260}:
ATTRIBUTE
DESCRIPTION
Technical Identifier
It is automatically assigned, as primary identifier, to all new static data items.
{T2S.16.010} To ensure uniqueness within multiple occurrences of a single static
data item which has undergone multiple updates, the technical identifier is used in
combination with a sequential revision number {T2S.16.130}.
Revision Number
Within the technical identifier, it marks every update of the items’ attributes so as to
ensure the uniqueness of a given item which has undergone several revisions.
{T2S.16.020}
Final_T2S_GFS_110.doc
Page 116
T2S General Functional Specifications
Functional Description
Static Data Management
ATTRIBUTE
Deletion Status
DESCRIPTION
It defines whether the static data may be available for processing in T2S or not.
Possible values are:
Active
Deleted
The static data item is available for processing only if its deletion status is “Active” and
it approval status (see below) is “Approved”.
Approval Status
It defines whether the static data has been approved or rejected by an authorized T2S
system user or if it is awaiting approval by the T2S system user. Possible values are:
Approved
Awaiting Approval
Rejected.
In case of updates of a static data item subject to an independent approval, the
modified version of the data will be created with status "Awaiting Approval" and it will
become either “Approved” or “Rejected” only after the decision of the second,
independent, authorized T2S system user {T2S.16.240}.
Furthermore, a System Entity Identifier attribute links each new static or dynamic data item to a CSD, a
NCB or to the T2S Operator for data segregation purposes (see section 3.3.13.10 for more information on
system entities). {T2S.11.110}
Finally, some static data items may have one or two additional attributes specifying a validity period:
ATTRIBUTE
DESCRIPTION
Valid From
It specifies the date from which the static data item is valid.
Valid To
It specifies the date until when the static data item is valid.
In the following sections, these two attributes will be indicated explicitly for the relevant entities.
To ensure the audit trail documenting events and status changes, static data management will keep the
date and time of every change and the unique identifier of the T2S system user requesting the change
{T2S.16.140}.
ATTRIBUTE
Timestamp
DESCRIPTION
Timestamp of the change.
Each audit trail record is linked to the T2S system user (or the application) responsible for the change and
to the before and after (static or dynamic) images of the records impacted by the change.
Final_T2S_GFS_110.doc
Page 117
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.9. Party Data Management
3.3.9.1. Data model of the module
The following diagram shows the conceptual data model for Party Data Management {T2S.16.530}.
3.3.9.2. Description of the module
This module allows the management of reference data related to parties, their links to the relevant
restrictions and the business relationships defined in T2S between different parties {T2S.16.540}. The
functions described in section 3.3.5 allow the authorized T2S system users to input their own parties and
to access and maintain them, i.e. to create new parties or to update or delete already existing parties.
When updating a party, each change is applied either as a revision or as a historicization, according to
what is specified in the relevant request.
3.3.9.3. Description of the entities
1 – Party
This entity includes all party reference data that do not require historicization, i.e. all the attributes having
only one valid value for a given party, regardless the point in time taken into account. {T2S.16.550}
ATTRIBUTE
Party Opening Date
Final_T2S_GFS_110.doc
DESCRIPTION
Opening date of the party.
Page 118
T2S General Functional Specifications
Functional Description
Static Data Management
ATTRIBUTE
DESCRIPTION
Party Close Date
Closing date of the party.
Party Status
Business status of the party. Possible values are:
Active
Closed
Recycling Period
Recycling period duration (expressed in business days). This attribute is
applicable for CSD or CCP party types only.
Compulsory Partial Settlement
It is applicable for CSDs and CCPs only. It is a boolean attribute specifying
whether the CSD or the CCP has made partial settlement mandatory or not
Party Type
It specifies a classification for the party {T2S.11.340}. Possible values
are:
T2S Operator
Payment Bank
Central Securities Depository (CSD)
CSD Participant
External CSD
National Central Bank (NCB)
CCP
Trading Platform / Stock Exchange
Securities Account Access Privilege
Boolean attribute specifying whether the party limits access of its T2S
system users to specific securities accounts or not.
Matching Required
Boolean attribute specifying whether FOP settlement instructions between
securities accounts belonging to the same party have to be matched or
not.
All party reference data requiring historicization are included in the entities Party Code, Party Name, Party
Address and Party Technical Address, described below. Each party is linked at least to one party code,
party name, party address and party technical address.
Each party is linked to the party with which it has a legal relationship (e.g. a CSD participant is linked to
its CSD), may be linked to one or many (deviating instructing) parties to which it has given power of
attorney to act on its behalf for all of its securities accounts5, to one or many party restrictions6
{T2S.16.680} {T2S.08.630} {T2S.16.505} and to one or many NCBs and currencies eligible for
auto-collateralisation. Finally, each party defined by a CSD (i.e. a CSD participant) may be linked to one or
many CSD-specific attributes (see section 3.3.13.8) {T2S.13.080} {T2S.05.510}.
5
For each deviating instructing party, a period of validity for the power of attorney and an allowed instruction profile must be specified.
6
For each party restriction, a period of validity and a market-specific restriction type must be specified.
Final_T2S_GFS_110.doc
Page 119
T2S General Functional Specifications
Functional Description
Static Data Management
2 – Party Code
This entity includes the information used to identify a party from a business perspective {T2S.16.570}.
Each party is identified in the financial market by its primary BIC, based on ISO 9326 standard. Since a
party may establish legal relationships with several CSDs and NCBs in T2S, uniqueness is ensured by the
couple <primary BIC, System Entity Identifier7 >. As a consequence, a party having established legal
relationships with multiple CSDs or NCBs will be defined multiple times as a party in T2S, i.e. once for
each legal relationship.
Party codes may change in time, but only one party code for a party must be valid at any given point in
time. For this reason, for each party code it is also necessary to specify its validity period.
ATTRIBUTE8
DESCRIPTION
Valid From
Starting validity date for the party code.
Code Type
Code type for the party. Currently, only BIC (as defined by ISO 9326 standard) is foreseen.
Party Mnemonic
Actual value for the party code, i.e. the primary BIC for the party.
Each party code is linked to its relevant party.
3 – Party Name
This entity includes long and short party names in a time line basis {T2S.16.560}. This is due to the fact
that party names may change in time, but only one long name and one short name for a party must be
valid at any given point in time.
ATTRIBUTE
DESCRIPTION
Valid From
Starting validity date for the party name.
Party Long Name
Full name of the party.
Party Short Name
Short name of the party.
Each party name is linked to its relevant party.
7
See section 3.3.13.10 for more information on system entities.
8
The System Entity Identifier is not explicitly mentioned as an attribute here, because it is part of the common information for all static data.
Final_T2S_GFS_110.doc
Page 120
T2S General Functional Specifications
Functional Description
Static Data Management
4 – Party Address
This entity includes legal addresses information for specific party types (i.e. T2S Operator, CSD, NCB and
Payment Banks) in a time line basis {T2S.16.580}. This is due to the fact that party legal addresses
may change in time, but only one legal address for a party must be valid at any given point in time.
ATTRIBUTE
DESCRIPTION
Valid From
Starting validity date for the party address.
Street
Name of the street for the address.
House Number
House number for the address.
City
Name of the city for the address.
Postal Code
Postal code for the address.
State or Province
State or province for the address.
Each party address is linked to its relevant party and country (see section 3.3.13.10).
5 – Party Technical Address
This entity includes information related to all of the technical addresses defined for a party
{T2S.16.700}. Each technical address is a BIC and it identifies a possible recipient technical address the
party can use in the message subscription service (see section 3.3.13.5 for more information).
ATTRIBUTE
Technical BIC Identifier
DESCRIPTION
Unique technical identifier of a BIC in the BIC Directory of T2S.
Each party technical address is linked to its relevant party.
Final_T2S_GFS_110.doc
Page 121
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.9.4. Object diagram
The next diagram represents a CSD Participant using two different Party Technical Addresses and
changing Party Address within the same jurisdiction.
Final_T2S_GFS_110.doc
Page 122
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.10. Security Data Management
3.3.10.1. Data model of the module
The following diagram shows the conceptual data model for Security Data Management.
3.3.10.2. Description of the module
This module allows the management of reference data related to securities, their links to the relevant
CSDs, settlement restrictions and valuation data, and the definition of close links {T2S.08.670}
{T2S.16.370}. The functions described in section 3.3.5 allow the authorized T2S system users (i.e. CSD
system administrators) to input their own securities and to access and maintain them {T2S.16.480}, i.e.
to create new securities or to update or delete already existing securities. When updating a security, each
change is applied either as a revision or as a historicization, according to what is specified in the relevant
request.
Final_T2S_GFS_110.doc
Page 123
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.10.3. Description of the entities
1 – Security
This entity includes all securities reference data that do not require historicization, i.e. all the attributes
having only one valid value for a given security, regardless of the point in time taken into account.
{T2S.16.380}
ATTRIBUTE
DESCRIPTION
CFI
Classification of the security according to ISO 10962 standard.
Current Security Market Status
Status of the security during its lifecycle. Possible values are:
When issued
Issued
Matured/De-listed
Maturity or Expiry Type
Type of the date specified in the Final Maturity or Expiry Date attribute.
Final Maturity or Expiry Date
Final maturity or expiry date of the security.
Settlement Type
Type of settlement foreseen for the security. Possible values are:
Units
Nominal
Minimum Settlement Unit or Nominal
Minimum unit or nominal of the security in accordance with the value
specified in the Settlement Type attribute.
Settlement Volume Multiple
Settlement multiplier for units or nominal.
All security reference data requiring historicization are included in the entities Security Code and Security
Name, described below. Each security is linked at least to one security code and security name.
Each security is linked to its country and currency of issuance9. Furthermore, it may also be linked to one
or many deviating security nominal values (see below) {T2S.16.500}, security restrictions10
{T2S.16.510} and to one or many currencies eligible for auto-collateralisation {T2S.08.590}
{T2S.08.760} {T2S.08.610} {T2S.16.385}. Furthermore, each security is linked to one issuer or
technical issuer CSD and can be linked to one or many investor CSDs11 {T2S.16.460} {T2S.16.470}
{T2S.16.710} and one or many parties for the definition of the relevant close links12 {T2S.08.670}.
Finally, each security is linked to all its valuation data (see below) {T2S.16.670} {T2S.16.690}.
9
See section 3.3.13.10 for a description of the Country and Currency entities.
10
For each security restriction, a period of validity, a restricting party (i.e. the T2S operator or a CSD) and a market-specific restriction type (see
section 3.3.13.9) must be specified.
11
For each link to a CSD, a period of validity, the type of link (i.e. if the CSD is issuer, investor or technical issuer for the relevant security) and a
Boolean value indicating if the CSD is responsible for maintaining the security must be specified (for each security one and only one CSD can be
responsible for its reference data maintenance).
12
Each link defines a close link between the relevant security and a party, i.e. the security is not eligible as collateral for that party.
Final_T2S_GFS_110.doc
Page 124
T2S General Functional Specifications
Functional Description
Static Data Management
2 – Security Code
This entity includes the information used to identify a security from a business perspective. Each security
is identified by its ISIN, based on ISO 6166 standard {T2S.16.420}. Since the ISIN may change in time,
more than one occurrence can be associated to a single security. Anyway, at a given point in time, only
one ISIN must be valid {T2S.16.430} {T2S.16.450}.
ATTRIBUTE
DESCRIPTION
Valid From
Starting date of validity for the security code.
Code Type
Code type assigned to the security. Currently, only ISIN (as defined by ISO 6166 standard)
is foreseen.
Security Mnemonic
Actual value for the security code, i.e. the ISIN for the security.
Each security code is linked to its relevant security.
3 – Security Name
This entity includes long and short security names in a time line basis {T2S.16.390}. This is due to the
fact that a security name may change in time, but only one long name and one short name for a security
must be valid at any given point in time {T2S.16.410}.
ATTRIBUTE
DESCRIPTION
Valid From
Starting date of validity for the security name.
Security Short Name
Short description of the security (FIDS) according to ISO 18774 standard.
{T2S.16.400}
Security Long Name
Long description of the security.
Each security name is linked to its relevant security.
4 – Deviating Security Nominal
This entity defines all the special conditions when the settlement quantity, unit or nominal, is not a
multiple of what is specified in the Security entity {T2S.16.500}.
ATTRIBUTE
Deviating Nominal
DESCRIPTION
Deviating nominal for the security.
Each deviating security nominal is linked to its relevant security.
Final_T2S_GFS_110.doc
Page 125
T2S General Functional Specifications
Functional Description
Static Data Management
5 – Security Valuation
This entity includes all the valuation data for a given security. {T2S.08.680} {T2S.16.520}
ATTRIBUTE
DESCRIPTION
Security Valuation Date
Date for which the valuation applies.
Exchange Rate
Conversion rate between the price currency and the Euro.
Market Code
Market Identifier Code (MIC) for the price source.
Price
Price of the security.
Price Type
Type of the price of the valuation for the security.
Price Date
Date of the price related. May differ from Security Valuation Date.
Price Qualifier
Qualifier of a price.
Pool Factor
Pool factor for asset-backed securities.
Pool Factor Valid From
Starting validity date for the pool factor.
Index Coefficient
Current index coefficient for an indexed-based debt security.
Index Coefficient Valid From
Starting validity date for the index coefficient.
Accrued Interest per Nominal
Amount per nominal of accrued interest.
Interest Calculation Method
Method used to calculate accrued interest for the security.
Last Interest Payment Date
Date from which the accrued interest has been calculated.
Haircut in %
Haircut applied for the valuation of the security.
Each occurrence of Security Valuation is linked to its relevant security and currency.
Final_T2S_GFS_110.doc
Page 126
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.10.4. Object diagram
The next diagram is a complex Security representation. The instance is linked to two different Security
Names which change in time, foresees two Deviating Security Nominal linked instances. CSD A, former
Issuer of the security, switches to Investor type while keeping Security Maintenance responsibility.
Three different types of Security Valuation and a Security Restriction apply to the Security.
Final_T2S_GFS_110.doc
Page 127
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.11. Securities Account Data Management
3.3.11.1. Data model of the module
The following diagram shows the conceptual data model for Securities Data Management.
3.3.11.2. Description of the module
This module allows the management of reference data related to securities accounts and their links to the
relevant parties, CSDs and restrictions. The functions described in section 3.3.5 allow the authorized T2S
system users (i.e. CSD system administrators) to input their own securities accounts and to access and
maintain them, i.e. to create new securities accounts or to update or delete already existing securities
accounts. When updating a securities account, each change is applied either as a revision or as a
historicization, according to what is specified in the relevant request.
3.3.11.3. Description of the entities
1 – Securities Account
This entity includes all securities account reference data required for settlement in T2S {T2S.16.590}.
ATTRIBUTE
DESCRIPTION
Opening Date
Legal opening date for the securities account.
Closing Date
Legal closing date for the securities account.
Final_T2S_GFS_110.doc
Page 128
T2S General Functional Specifications
Functional Description
Static Data Management
ATTRIBUTE
Securities Account Type
DESCRIPTION
It specifies a classification for the securities account for the
maintenance of CSD-account links. Possible values are:
CSD participant account
CSD mirror account
Inter-CSD account
T2S technical offset account13
Account Reference
Textual name, description or reference of the securities account.
Status
Business status for the securities account. Possible values are:
Open
Closed
Hold Release Default
Default setting for specific settlement instructions related to the
securities account. Possible values are:
Hold
Release
Negative Position
Boolean attribute specifying whether the securities account can
hold a negative position in a security or not.
Securities Account Access Privilege Identifier Unique technical identifier of an access privilege for the securities
account.
Each securities account is linked to its relevant party (i.e. CSD or CSD participant) that operates the
account {T2S.02.060}.
Furthermore, each securities account (as a CSD participant’s account of an investor CSD for a specific
security) may be linked to a mirror securities account, an inter-CSD securities account (within the same
investor CSD), one or many omnibus securities accounts (within the relevant technical issuer CSD for the
same security)14 {T2S.16.720} {T2S.16.730} {T2S.16.740} and to one or many currencies eligible
for auto-collateralisation {T2S.08.650}.
Furthermore, each securities account may be linked to one or many securities account restrictions15
{T2S.05.510} {T2S.08.630} {T2S.08.640} {T2S.16.585} {T2S.16.690}, CSD-specific attributes
(see section 3.3.13.8) and (deviating instructing) parties to which it has given power of attorney to act on
its behalf for the same securities account16 {T2S.10.040} {T2S.10.050} {T2S.16.670}.
13 This category is foreseen for direct holding markets.
14 For each link, a period of validity must be specified.
15
For each securities account restriction, a period of validity and a market-specific restriction type must be specified.
16
For each deviating instructing party, a period of validity for the power of attorney and an allowed instruction profile must be specified.
Final_T2S_GFS_110.doc
Page 129
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.11.4. Object diagram
The next diagram represents a simple Securities Account with two different Securities Account
Restrictions.
Final_T2S_GFS_110.doc
Page 130
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.12. T2S Dedicated Cash Account Data Management
3.3.12.1. Data model of the module
The following diagram shows the conceptual data model for T2S Dedicated Cash Account Data
Management.
3.3.12.2. Description of the module
This module allows the management of reference data related to T2S Dedicated cash accounts and their
links to the relevant currencies {T2S.02.050}, securities accounts, external RTGS cash accounts,
restrictions {T2S.06.100} and liquidity transfer order configurations {T2S.06.120}. The functions
described in section 3.3.5 allow the authorized T2S System Users (i.e. NCB system administrators)
{T2S.06.020}to input their own T2S Dedicated cash accounts and to access and maintain them
{T2S.06.030}, i.e. to create new T2S Dedicated cash accounts or to update or delete already existing
T2S Dedicated cash accounts {T2S.06.010} {T2S.06.110} {T2S.06.130}. When updating a T2S
Dedicated cash account, each change is applied either as a revision or as a historicization, according to
what is specified in the relevant request.
Final_T2S_GFS_110.doc
Page 131
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.12.3. Description of the entities
1 – T2S Dedicated Cash Account
This entity includes all T2S Dedicated cash account reference data.
ATTRIBUTE
DESCRIPTION
Floor Notification Amount
It specifies the lower threshold for notifying the cash manager.
Ceiling Notification Amount
It specifies the upper threshold for notifying the cash manager.
Account Status
Business status for the T2S Dedicated cash account {T2S.10.030}. Possible
values are:
Open
Closed
Account Type
It specifies a classification for the T2S dedicated cash account. Possible values are:
RTGS Dedicated Transit Account
T2S Central Bank Account
T2S Dedicated Cash Account
T2S Technical Account EoD
For T2S Central Bank Accounts, the account can have a negative balance.
Opening Date
Opening date of the T2S Dedicated cash account.
Closing Date
Closing date of the T2S Dedicated cash account.
Each T2S Dedicated cash account is linked to its the relevant party {T2S.05.060} {T2S.08.510},
currency and external RTGS cash account and may be linked to one or many T2S Dedicated cash account
restrictions17 {T2S.08.530} {T2S.16.670} {T2S.16.680}, parties (i.e. CSDs) authorised by the
account owner to initiate liquidity transfer on the same account, cash account link sets (see below) and
liquidity transfer order link sets (see below). {T2S.16.660}
2 – T2S Dedicated Cash Account Link Set
This entity includes all reference data for T2S Dedicated cash account link sets {T2S.16.640}, i.e.
groups of T2S Dedicated cash accounts linked to an individual securities account or to all securities
accounts of a specific party, which can be used for the settlement of the cash leg of settlement
instructions related to the linked securities account(s) {T2S.06.080} {T2S.06.090}.
ATTRIBUTE
17
DESCRIPTION
Valid From
It specifies the date from which the T2S Dedicated cash account link set is valid.
Valid To
It specifies the date to which the T2S Dedicated cash account link set is valid.
For each T2S Dedicated cash account restriction, a period of validity and a market-specific restriction type (see section 3.3.13.9) must be specified.
Final_T2S_GFS_110.doc
Page 132
T2S General Functional Specifications
Functional Description
Static Data Management
Each T2S Dedicated cash account link set is linked to the relevant currency18 {T2S.02.040}
{T2S.02.080} {T2S.06.040} and to one or many T2S Dedicated cash account links.
3 – T2S Dedicated Cash Account Link
This entity includes all reference data for T2S Dedicated cash account links {T2S.16.650}.
ATTRIBUTE
DESCRIPTION
Cash Account Default
Boolean attribute specifying whether the relevant T2S Dedicated cash account is
the default account or not within the relevant link set {T2S.07.280}. Only one
T2S Dedicated cash account in a link set is the default account.
Cash Account Link Type
It specifies a classification for the cash account link. Possible values are:
CASH (the link is dedicated to the settlement of the cash leg of a settlement
instruction)
COLL (the linked T2S Dedicated Cash Account can benefit from the collateral
earmarked on the relevant securities account for auto-collateralisation operations)
{T2S.08.630}
Each T2S Dedicated cash account link is linked to the relevant T2S Dedicated cash account and T2S
Dedicated cash account link set. {T2S.06.050}
4 – Liquidity Transfer Order Link Set
This entity includes all reference data for liquidity transfer order link sets, i.e. groups of liquidity transfer
orders linked to an individual T2S Dedicated cash account, which can be used for sequencing the
provision of liquidity from RTGS accounts of multiple liquidity providers to an individual T2S Dedicated
cash account {T2S.16.661}.
ATTRIBUTE
DESCRIPTION
Valid From
It specifies the date from which the liquidity transfer order link set is valid.
Valid To
It specifies the date to which the liquidity transfer order link set is valid.
Each liquidity transfer order link set is linked to one or many liquidity transfer order links and to the
relevant T2S Dedicated cash account.
18
All the T2S Dedicated cash accounts belonging to a T2S Dedicated cash account link set must be defined on the same currency.
Final_T2S_GFS_110.doc
Page 133
T2S General Functional Specifications
Functional Description
Static Data Management
5 – Liquidity Transfer Order Link
This entity includes all reference data for liquidity transfer order links {T2S.16.662}.
ATTRIBUTE
DESCRIPTION
Transfer Order Sequence
It specifies the sequence in which the relevant liquidity transfer order will be
executed within the link set when the relevant T2S Dedicated cash account requires
additional liquidity.
Each liquidity transfer order link is linked to the relevant liquidity transfer order and liquidity transfer order
link set.
6 – Liquidity Transfer Order
This entity includes all reference data for liquidity transfer orders.
ATTRIBUTE
DESCRIPTION
Amount
Amount to be credited or debited through the liquidity transfer order.
All Cash
Boolean attribute specifying whether the liquidity transfer order will transfer any
remaining liquidity on the debit cash account or not {T2S.08.520}. When this
attribute is set to “true”, then the Amount attribute must be set to zero.
Valid From Date
Date from which the liquidity transfer order is valid.
Valid To Date
Date to which the liquidity transfer order is valid.
Execution Type
Type of execution for the liquidity transfer order. Possible values are:
Event-based
Time-based
Execution
It specifies the time or the event that triggers the liquidity transfer order, according to
the setting of the Execution Type attribute.
Order Type
It specifies a classification for the liquidity transfer order. Possible values are:
Predefined
Standing Order
Each liquidity transfer order is linked to the relevant external RTGS cash account {T2S.16.600} and
liquidity transfer order link.
7 – External RTGS Account
This entity includes all reference data for external RTGS cash accounts.
ATTRIBUTE
DESCRIPTION
Account Number
Account number of the external RTGS cash account within the relevant RTGS system.
Account Status
Business status for the external RTGS cash account.
Final_T2S_GFS_110.doc
Page 134
T2S General Functional Specifications
Functional Description
Static Data Management
ATTRIBUTE
DESCRIPTION
Valid From Date
Date from which the external RTGS cash account can be referenced in T2S.
Valid To Date
Date to which the external RTGS cash account can be referenced in T2S.
Each external RTGS cash account is linked to the relevant RTGS system and currency {T2S.02.060}.
Furthermore, it may be linked to one or many T2S Dedicated cash accounts and liquidity transfer orders.
3.3.12.4. Object diagram
The next diagram is a complex representation of a T2S Dedicated Cash Account instance. Account
belongs to a Payment Bank and is linked to a CSD Participant Securities Account and the default External
RTGS Cash Account. Two Liquidity Transfer Orders are defined for the T2S Dedicated Cash Account: the
former will be the first to be executed and is based on a time constraint, the latter is linked to the End of
Day event. Different destination accounts belong to TARGET2 RTGS System sharing same currency EUR.
3.3.13. Rules and Parameters Data Management
3.3.13.1. Description of the module
This module allows the management of reference data related to rules and parameters defined in T2S.
The functions described in section 3.3.5 allow the authorized T2S system users to input their own rules
and parameters and to access and maintain them, i.e. to create new rules and parameters or to update or
delete already existing rules and parameters.
Final_T2S_GFS_110.doc
Page 135
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.13.2. Data model and description of the entities
The data model for Rules and Parameters Data Management is actually made of several components,
each of which is related to a specific set of rules and parameters. A list of such components is given
hereafter:
•
users, roles and privileges {T2S.11.370} {T2S.11.390};
•
service subscription {T2S.11.550};
•
message subscription;
•
attribute domains {T2S.11.270} {T2S.11.290};
•
scheduling;
•
CSD-specific attributes;
•
market-specific restrictions {T2S.11.660};
•
other rules and parameters.
The following part of this section provides a description of the data model and the entities for all the
above listed components.
Final_T2S_GFS_110.doc
Page 136
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.13.3. Users, roles and privileges
The following diagram shows the conceptual data model for users, roles and privileges management.
Each T2S function is linked to a privilege (i.e. the privilege to use this function) and set of privileges can
be grouped into privilege classes. Set of privileges and privileges classes can then be grouped into roles
Final_T2S_GFS_110.doc
Page 137
T2S General Functional Specifications
Functional Description
Static Data Management
{T2S.04.010}. Each user can be assigned one or more roles and privileges, which allow this user to use
all the functions linked to these roles and privileges {T2S.11.400} {T2S.11.430} {T2S.11.355}
1 – User
This entity includes all reference data for users {T2S.11.440}.
ATTRIBUTE
DESCRIPTION
Login Name
Username to be provided for authentication at login.
Name
Full name of the user.
Password
Password to be provided for authentication at login.
Authentication
Authentication type applied for the user at login.
Lockout Status
Boolean attribute specifying whether the user is blocked from logging or not.
{T2S.11.500} {T2S.11.510}
Lockout Timestamp From
Timestamp specifying the date and the time from which the user is locked
out from T2S.
Password Change on Next Login
Boolean attribute specifying whether the user must change the password on
the next login or not.
Users are linked to the party they belong to and to one or many roles and privileges {T2S.11.450}.
2 – Privilege
This entity includes all reference data for privileges {T2S.11.360}.
ATTRIBUTE
DESCRIPTION
Privilege Name
Name of the privilege.
Privilege Description
Description of the privilege.
Each privilege can be linked to one or many privilege classes and roles. Each privilege can be directly
linked to many users19.
3 – Privilege Class
This entity includes all reference data for privilege classes.
ATTRIBUTE
DESCRIPTION
Privilege Class Name
Name of the privilege class.
Privilege Class Description
Description of the privilege class.
Each privilege class can be linked to one or many roles and privileges {T2S.11.380}.
19 When linking a privilege to a privilege class, a role or a user, a boolean attribute specifies if the privilege is denied or granted to the relevant
privilege class, role or user.
Final_T2S_GFS_110.doc
Page 138
T2S General Functional Specifications
Functional Description
Static Data Management
4 – Role
This entity includes all reference data for roles.
ATTRIBUTE
DESCRIPTION
Role Name
Name of the role.
Role Description
Description of the role.
Each role can be linked to one or many privilege and privilege classes. Moreover, each role can be linked
to many users {T2S.11.530}.
In what follows, some sample object diagrams for users, roles and privileges are shown.
Sample T2SOperator User, Roles and Privileges object diagram
Final_T2S_GFS_110.doc
Page 139
T2S General Functional Specifications
Functional Description
Static Data Management
Sample for CSD with SAAP User, Roles and Privileges object diagram
Final_T2S_GFS_110.doc
Page 140
T2S General Functional Specifications
Functional Description
Static Data Management
Sample for CSD without SAAP User, Roles and Privileges object diagram
Final_T2S_GFS_110.doc
Page 141
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.13.4. Service subscription
The following diagram shows the conceptual data model for service subscription management.
A service is any report, query or message available in T2S {T2S.11.540}. Set of services can be
grouped into service configurations {T2S.11.590} {T2S.11.600} {T2S.11.535}.
5 – Service
This entity includes all reference data for services {T2S.11.560} {T2S.11.570} {T2S.11.580}.
ATTRIBUTE
DESCRIPTION
Service Name
Name of the service.
Service Description
Description of the service.
Service Type
It specifies a classification for the service. Possible values are:
Report
Query
Function
Message
Final_T2S_GFS_110.doc
Page 142
T2S General Functional Specifications
Functional Description
Static Data Management
ATTRIBUTE
Interaction
DESCRIPTION
It specifies a classification for the type of interaction with the service. Possible
values are:
Pull
Push
Interactive
Service Eligibility
Boolean attribute specifying whether the service is available to CSDs only or to
CSDs and their participants.
Technical Service Identification
It specifies how a service is identified from a technical point of view.
Each service can be linked to one or many service configurations.
6 – Service Configuration
This entity includes all reference data for service configurations {T2S.11.610} {T2S.11.620}
{T2S.11.630}.
ATTRIBUTE
DESCRIPTION
Service Configuration Name
Name of the service configuration.
Service Configuration Description
Description of the service configuration.
Each service configuration is linked to many services.
Final_T2S_GFS_110.doc
Page 143
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.13.5. Message subscription
The following diagram shows the conceptual data model for message subscription management.
Message subscription allows CSDs and NCBs to configure, for themselves and for their directly connected
parties, the specific set of messages they want to receive from T2S {T2S.11.640}.
Each CSD and NCB can set up several message subscription rule sets. Each message subscription rule set
defines the messages a specific interested party will receive via a sequence of message subscription rules.
Each message subscription rule specifies the parameters (e.g. message type, party, and securities account
number) that will have to be taken into account to identify the messages to be sent to the interested
party. Finally, message subscription rule sets may change in time, but no more than one message
subscription rule set for an interested party must be valid at any given point in time.
Final_T2S_GFS_110.doc
Page 144
T2S General Functional Specifications
Functional Description
Static Data Management
7 – Message Subscription Rule Set
This entity defines the set of message subscription rules defined by each CSD or NCB.
ATTRIBUTE
DESCRIPTION
Valid From
It specifies the date from which the rule set is valid.
Each message subscription rule set is linked to the relevant CSD or NCB, to a set of recipient addresses
(i.e. party technical addresses) of a single interested party (i.e. the party that will receive all the messages
identified by the message subscription rule set), and to a set of message subscription rules.
8 – Message Subscription Rule
This entity defines the message subscription rules defined by each CSD or NCB.
ATTRIBUTE
Rule Sequence
DESCRIPTION
It specifies the order in which the rule will be processed within the
relevant rule set.
Each message subscription rule belongs to a single message subscription rule set and it is linked to a set
of message subscription rule parameters.
9 – Message Subscription Rule Parameter
This entity includes the message subscription rule parameters defined within each message subscription
rule.
ATTRIBUTE
Rule Parameter Value
DESCRIPTION
It specifies a valid value for the rule parameter.
Each message subscription rule parameters belongs to a single message subscription rule and it is linked
to a specific message subscription rule parameter type.
Final_T2S_GFS_110.doc
Page 145
T2S General Functional Specifications
Functional Description
Static Data Management
10 – Message Subscription Rule Parameter Type
This entity defines all message subscription rule parameters types.
ATTRIBUTE
DESCRIPTION
Rule Parameter Type
It specifies a classification for the message subscription rule parameters. Possible values
are:
Message type
Instruction type
Message status
Party
Securities account
ISIN
T2S Dedicated cash account
Instruction status
The following object diagram provides an example of the data model for message subscription:
Final_T2S_GFS_110.doc
Page 146
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.13.6. Attribute domain
The following diagram shows the conceptual data model for attribute domain management
{T2S.11.210} {T2S.11.300} {T2S.11.310} {T2S.11.320} {T2S.11.770}.
Attribute domains provide valid lists of values allowed for an attribute {T2S.11.200}. Attribute domains
are used for field validations and for documenting the business definition of a value in an attribute.
Furthermore, it is possible to define additional reference values, mapped to an attribute specified by an
attribute domain definition.
Final_T2S_GFS_110.doc
Page 147
T2S General Functional Specifications
Functional Description
Static Data Management
11 – Attribute Domain
This entity includes all reference data for attribute domains {T2S.11.240}.
ATTRIBUTE
DESCRIPTION
Attribute Domain Name
Name of the attribute domain.
Attribute Domain Description
Description of the attribute domain.
Attribute Format
It specifies a classification for the attribute format. Possible values are:
Alphabetic
Alphanumeric
Numeric
Minimum Code Length
It specifies the minimum length of the code for a value in the attribute domain.
Maximum Code Length
It specifies the maximum length of the code for a value in the attribute domain.
Case
It specifies a classification for the case type of the attribute format. Possible
values are:
Upper case
Lower case
Both
Each attribute domain is linked to many attribute values (i.e. to all the values belonging to the domain)
and may be linked to one or many attribute references.
12 – Attribute Reference
This entity includes all reference data for attribute references {T2S.11.230} {T2S.11.240}
{T2S.11.250}
ATTRIBUTE
DESCRIPTION
Attribute Reference Name
Name of the attribute reference.
Attribute Reference Description
Description of the attribute reference.
Reference Format
It specifies a classification for the attribute reference format. Possible values
are:
Alphabetic
Alphanumeric
Numeric
Minimum Code Length
It specifies the minimum length of the code for a reference value.
Maximum Code Length
It specifies the maximum length of the code for a reference value.
Final_T2S_GFS_110.doc
Page 148
T2S General Functional Specifications
Functional Description
Static Data Management
ATTRIBUTE
Case
DESCRIPTION
It specifies a classification for the case type of the attribute reference format.
Possible values are:
Upper case
Lower case
Both
Mandatory
Boolean attribute specifying whether the input of a reference value is
mandatory or not.
Each attribute reference is linked to the relevant attribute domain and to many reference values (i.e. to all
the values belonging to the attribute reference).
13 – Attribute Value
This entity includes all reference data for attribute values {T2S.11.220}.
ATTRIBUTE
DESCRIPTION
Attribute Value
Value of the attribute.
Attribute Value Description
Description of the attribute value.
Each attribute value is linked to the relevant attribute domain and may be linked to one or many
references value.
14 – Reference Value
This entity includes all reference data for reference values.
ATTRIBUTE
DESCRIPTION
Reference Value
Value of the attribute reference.
Reference Value Description
Description of the reference value.
Each reference value is linked to the relevant attribute reference and attribute value.
Final_T2S_GFS_110.doc
Page 149
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.13.7. Scheduling
The following diagram shows the conceptual data model for scheduling management.
The scheduling of any actual operating day (see the section on Scheduling for more information) is based
on a set of pre-defined event types that can be combined, according to different default schedules, into
different operating day types {T2S.11.040}.
15 – Event Type
This entity includes all the information concerning the event types defined in T2S {T2S.03.250}
{T2S.03.270} {T2S.03.280} {T2S.03.290} {T2S.03.300} An event type is any possible kind of
event in T2S (e.g. EoD, SoD, Cut-off, Beginning of day time and so forth), regardless of its planned or
actual triggering time.
ATTRIBUTE
DESCRIPTION
Event Type Description
Description of the event type.
System Entity Insert
Boolean attribute specifying whether the system entity owner of the event type is
allowed to insert a specific event of this type in the time schedule or not.
System Entity Update
Boolean attribute specifying whether the system entity owner of the event type is
allowed to update a specific event of this type in the time schedule or not.
System Entity Delete
Boolean attribute specifying whether the system entity owner of the event type is
allowed to delete a specific event of this type from the time schedule or not.
Process to Start
It specifies the process that must be started when an event of this type is
triggered.
Final_T2S_GFS_110.doc
Page 150
T2S General Functional Specifications
Functional Description
Static Data Management
ATTRIBUTE
Process Parameters
DESCRIPTION
It specifies the parameters of the process that must be started when an event of
this type is triggered.
Each event type can be linked to many operating day types34.
16 – Operating Day Type
This entity includes all the information concerning the operating day types defined in T2S, so to allow the
T2S operator to define different kinds of operating days in T2S (e.g. to define specific business day types
in which some events must deviate from the standard schedule, or for testing purposes).
ATTRIBUTE
DESCRIPTION
Operating Day Type Code
Code of the operating day type.
Operating Day Type Description
Description of the operating day type.
Each operating day type is linked to all the event types foreseen for the operating day type itself.
17 – T2S Closing Day
This entity stores the days where T2S is not open for business.
ATTRIBUTE
DESCRIPTION
Date
It specifies a date in which T2S is not open for business.
Recurrent
Boolean attribute specifying whether the T2S closing day recurs every year
or not.
34 For each link between an event type and an operating day type, a default event schedule (i.e. a default event schedule time, a predecessor
constraint and a successor constraint) must be specified. More in detail, if a certain event has a predecessor constraint, then it will not be triggered
unless all predecessor events (i.e. events with an earlier scheduled time and with a successor constraint) have been completed.
Final_T2S_GFS_110.doc
Page 151
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.13.8. CSD-specific attributes
The following diagram shows the conceptual data model for CSD-specific attributes management
{T2S.16.750}.
It is possible for a CSD to define additional, specific attributes for its parties and securities accounts
{T2S.11.410}. These attributes give the possibility to add data both to parties and securities accounts
for informational purpose. Only the following validations are possible for these attributes:
•
Format validation: the value assigned to an attribute is validated against the format definition
for that attribute {T2S.16.780};
•
Mandatory check: if an attribute is defined as mandatory, each party or securities account for
which the attribute is defined must have a value assigned for it {T2S.16.790};
•
Uniqueness: if an attribute is defined as unique, each party or securities account for which
the attribute is defined must have a value assigned for it and this value must unique across
all parties or securities accounts {T2S.16.800};
•
Valid list value: the value assigned to an attribute must belong to a list of valid values for
that attribute {T2S.16.810}.
Final_T2S_GFS_110.doc
Page 152
T2S General Functional Specifications
Functional Description
Static Data Management
18 – CSD-Specific Attribute
This entity includes all the information concerning the CSD-specific attributes definition.
ATTRIBUTE
DESCRIPTION
CSD-Specific Attribute Name
Name of the CSD-Specific attribute.
CSD-Specific Attribute Type
Type of the CSD-Specific attribute. Possible values are:
Party
Securities Account
Mandatory
Boolean attribute specifying whether providing a value for the CSD-specific
attribute type is mandatory or not.
Unique
Boolean attribute specifying whether the value provided for the CSDspecific attribute type has to be unique or not.
Each CSD-specific attribute is linked to the relevant party or securities account (via its specialisation
entities CSD-Specific Party Attribute or CSD-Specific Securities Account Attribute), to all its CSD-specific
attribute values {T2S.16.770} and to the relevant attribute domain {T2S.11.420} {T2S.16.760}.
19 – CSD-Specific Attribute Value
This entity includes all the information concerning the CSD-specific attributes values.
ATTRIBUTE
Value
DESCRIPTION
Value specified for the CSD-Specific attribute.
Each CSD-specific attribute is linked to the relevant party or securities account and to the relevant CSDspecific attribute.
Final_T2S_GFS_110.doc
Page 153
T2S General Functional Specifications
Functional Description
Static Data Management
3.3.13.9. Market-specific restrictions
The following diagram shows the conceptual data model for market-specific restrictions management.
It is possible for CSDs and NCBs to define their own restriction types {T2S.11.670} {T2S.11.680}
{T2S.11.690}. A restriction type is a set of attributes that define the specific processing characteristics
for one of the following object types: parties, securities accounts, T2S Dedicated cash accounts, securities
positions and cash balances.
For each restriction type, one or many allowed instruction profiles define the set of possible actions that
can be performed on the restricted object and the set of parties that are allowed to perform such actions
{T2S.11.750}.
Finally, subordinate restrictions can be applied in addition to other restrictions.
Final_T2S_GFS_110.doc
Page 154
T2S General Functional Specifications
Functional Description
Static Data Management
20 – Market-Specific Restriction Type
This entity includes all the information concerning the market-specific restriction types definition
{T2S.11.650}.
ATTRIBUTE
DESCRIPTION
Restriction Type
It specifies a code defined by the CSD or the NCB to identify the restriction.
Restriction Description
Description of the restriction.
Object Restriction Type
It specifies a classification for the object type on which the restriction
applies. Possible values are:
Party
Security
Securities account
Securities position
T2S Dedicated cash account
Cash balance
Subordinate Position Restriction
Boolean attribute specifying whether it is possible to place a subordinate
position restriction of another type on the defined restriction or not.
Restriction Classification
It specifies a classification for the restriction type. Possible values are:
Blocking
Earmarking
Reservation
Segregation
Each market-specific restriction type is linked to one or many allowed instruction profiles35.
21 – Allowed Instruction Profile
This entity includes all the information concerning the allowed instructing profiles definition
{T2S.11.780} {T2S.11.790} {T2S.11.800} {T2S.11.810}.
ATTRIBUTE
DESCRIPTION
Allowed Instructing Profile Name
Name of the allowed instruction profile.
Allowed Instruction Profile Description
Description of the allowed instruction profile.
Each allowed instruction profile can be linked to one or many market-specific restrictions and to one or
many allowed instructions {T2S.11.760}.
35 For each link between a market-specific restriction type and an allowed instruction profile, an allowed instructing party (i.e. the party type allowed
to perform the actions specified by the relevant profile) must be specified.
Final_T2S_GFS_110.doc
Page 155
T2S General Functional Specifications
Functional Description
Static Data Management
22 – Allowed Instruction
This entity contains the information concerning the allowed instructions linked to an allowed instruction
profile.
ATTRIBUTE
DESCRIPTION
Instruction Type
Settlement instruction type to be allowed.
Transaction Code
Transaction code of the instruction as defined by ISO 20022 standard
Each allowed instruction can be linked to one or many allowed instruction profiles.
3.3.13.10. Other rules and parameters
This section describes all reference data concerning the following rules and parameters:
•
closing days {T2S.11.180};
•
conditional securities delivery rule;
•
country;
•
currencies {T2S.16.330};
•
limit;
•
partial settlement threshold;
•
sequencing rule;
•
settlement priority defaults;
•
system entity {T2S.11.120};
•
tolerance amount;
•
T2S BIC directory {T2S.11.700}.
23 – Closing Day
This entity defines the set of closing days for the T2S calendar.
ATTRIBUTE
Date
DESCRIPTION
The specified date is a closing day for the linked currency.
Each occurrence is linked to an occurrence of the Currency entity and defines a specific closing day for
the linked currency {T2S.20.020} {T2S.03.310} {T2S.03.320} {T2S.11.160} {T2S.11.170}.
Final_T2S_GFS_110.doc
Page 156
T2S General Functional Specifications
Functional Description
Static Data Management
24 – Conditional Securities Delivery Rule
This entity includes all reference data for conditional securities delivery rules {T2S.09.210}.
ATTRIBUTE
DESCRIPTION
COSD Rule Name
Name of the conditional securities delivery rule.
Security Reservation
Boolean attribute specifying if securities must be reserved in T2S for settlement or not.
Cash Reservation
Boolean attribute specifying if cash must be reserved in T2S for settlement or not.
Each conditional securities delivery rule is linked to the relevant (defining) party (i.e. CSD),
(administering) party, currency, transaction type, security and securities account. Furthermore, it may be
linked to the relevant place of settlement (i.e. CSD) and to up to four countries (i.e. country of issuance,
issuer CSD location, deliverer location and receiver location).
25 – Country
This entity includes all reference data related to countries defined in T2S.
ATTRIBUTE
DESCRIPTION
Country Code
Numeric code of the country according to the ISO 3166-1 standard.
Country Name
Name of the country according to the ISO 3166-1 standard.
26 – Currency
This entity includes all reference data related to currencies defined in T2S {T2S.16.320} {T2S.11.340}
{T2S.11.350} {T2S.11.360}.
ATTRIBUTE
DESCRIPTION
Currency Code
Unique code of the currency according to the ISO 4217 standard.
Currency Name
Name of the currency.
Number of Decimals
Number of decimals in which the currency is expressed.
T2S Settlement Currency
Boolean attribute specifying whether the currency is eligible for settlement in T2S or
not.
Final_T2S_GFS_110.doc
Page 157
T2S General Functional Specifications
Functional Description
Static Data Management
27 – Limit
This entity includes all reference data related to limits defined in T2S {T2S.08.810} {T2S.10.060}.
ATTRIBUTE
DESCRIPTION
Credit Consumer Primary BIC
When different from null, it specifies the primary BIC of the financial
institution for which the limit applies, regardless the number of CSDs with
which it hold an account, i.e. regardless the number of parties defined for the
financial institution. Otherwise, the credit consumer is defined by a link to a
specific party.
Credit Consumer Identifier Type
It specifies a classification for the credit consumer. Possible values are:
Primary BIC
Party Identifier from Party Reference Data
T2S shall use the party identifier from party reference data for the
payment/settlement bank to identify the credit consumer for an auto
collateralisation limit set by NCBs. T2S shall use the primary BIC to identify
the credit consumer for the auto collateralisation set by the payment bank.
This shall enable the payment bank to define one limit for a financial
institution, even when it holds accounts with several CSDs in T2S.
Limit Type
It specifies a classification for the limit {T2S.06.140} {T2S.08.630}.
Possible values are:
Net buying
Payment Settlement Bank Auto-collateralisation Limit
NCB Auto-collateralisation Limit
Limit Amount
It specifies the limit amount for the credit consumer for the relevant T2S
Dedicated cash account. It must be set to zero if the party has no limit for
the relevant T2S Dedicated cash account.
Valid From Timestamp
It specifies the date from which the credit limit is valid.
Each limit is linked to its relevant currency and to the relevant NCB {T2S.10.083}. Furthermore, it is
linked to a (credit provider) party and may be linked to a (credit consumer) party {T2S.06.140}
{T2S.10.070}. Finally, since each limit may apply to a sub-set only of the securities accounts of a credit
consumer, the same limit may be linked to one or many limit groups. Each limit group is in turn linked to
the sub-set of securities accounts just mentioned above {T2S.08.770}. If a limit is not linked to any
limit groups, then it is meant to be applied to all the securities accounts of the relevant credit consumer
{T2S.10.080}.
Final_T2S_GFS_110.doc
Page 158
T2S General Functional Specifications
Functional Description
Static Data Management
28 – Partial Settlement Threshold
This entity includes all reference data related to partial settlement thresholds defined in T2S
{T2S.08.290} {T2S.08.340}.
ATTRIBUTE
Threshold Type
DESCRIPTION
It specifies a classification for the threshold. Possible values are:
Cash
Nominal
Number of shares
Amount Type
It specifies a classification for the threshold value. Possible values are:
Absolute value
Percentage
Threshold Value
Value of the threshold.
Each partial settlement threshold is linked to its relevant party (i.e. CSD, CCP or the T2S Operator) or to
its relevant securities account {T2S.08.360} {T2S.11.730}.
29 – Securities Account Access Privilege
This entity includes all reference data related to access privileges that limit the access of the party’s T2S
system users to specific securities accounts of the party {T2S.16.585}.
ATTRIBUTE
DESCRIPTION
Valid From
It specifies the date from which the securities account access privilege is valid.
Privilege Name
Name of the securities account access privilege.
Privilege Text Description Textual description of the securities account access privilege.
Each securities account access privilege is linked to its relevant party and can be linked to one or many
users {T2S.11.532}.
30 – Sequencing Rule
This entity includes all the information needed to determine the sequence for processing of settlement
instructions {T2S.11.350}.
ATTRIBUTE
Sequence
DESCRIPTION
It specifies the order in which an instruction will be sequenced in T2S, based on its
instruction type, transaction type and sender party type.
Each sequencing rule is linked to the relevant (sender) party type, instruction type and transaction type.
Final_T2S_GFS_110.doc
Page 159
T2S General Functional Specifications
Functional Description
Static Data Management
31 – System Entity
This entity includes all reference data for system entities. System entities define the legal entities (i.e.
CSDs, NCBs and the T2S Operator) {T2S.11.110} {T2S.11.130} {T2S.11.140} {T2S.11.150} by
which data are segregated in T2S {T2S.11.050} {T2S.11.060} {T2S.11.080} {T2S.11.070}
ATTRIBUTE
DESCRIPTION
System Entity Type
It specifies a classification for the system entity. Possible values are:
T2S Operator
Central Securities Depository (CSD)
National Central Bank (NCB)
System Entity Mnemonic
It specifies a unique short code used to identify the system entity.
System Entity Name
It specifies the full name of the system entity.
Direct Holding CSD
Boolean attribute specifying whether the system entity is a CSD and
it operates in a direct holding market or not.
Direct Holding Technical Offset Account
It specifies the technical offset account that T2S requires for
settlement of settlement instructions in a direct holding market.
As already mentioned, each static data item is linked to a system entity (i.e. to a CSD, a NCB or the T2S
Operator).
32 – Tolerance Amount
This entity defines the set of tolerance amount values for each currency eligible for settlement in T2S.
{T2S.11.190}
ATTRIBUTE
DESCRIPTION
Cash Value Amount Limit
It specifies the cash value up to (and including) which the tolerance amount is valid.
Tolerance Amount
It specifies the tolerance amount value within the range identified by the cash value
amount limit and for the linked currency.
Valid From
It specifies the date from which a given set of tolerance amount values is valid.
Each tolerance amount is linked to the relevant currency.
Final_T2S_GFS_110.doc
Page 160
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
33 – T2S BIC Directory
This entity includes all the information needed to identify the legal entities to which SWIFT assigned the
BIC. {T2S.11.710}
ATTRIBUTE
BIC Source
DESCRIPTION
It specifies a classification for the BIC source. Possible values are:
Manual input
Automated monthly SWIFT BIC Directory update
Update through BIC Data+
BIC Type
It specifies a classification for the BIC type. Possible values are:
Official BIC
Internal technical BIC
BIC
8-character BIC, consisting of the bank code (financial institution), country code
and location code.
BIC Branch Code
3-character branch code for the financial institution.
Financial Institution Name
Three text fields with a length of 35 characters each to store the name of the
financial institution.
City Name
35-character name of the city in which the financial institution resides.
Branch Information
Two text fields with a length of 35 characters each to identify the branch of the
financial institution.
BIC Technical Identifier
This attribute shall specify the unique technical identifier of a BIC in T2S.
3.4. Lifecycle Management and Matching
3.4.1. General Introduction
The Life Cycle Management and Matching (LCMM) domain deals with the life cycle of the instructions
received in T2S which are directly related to settlement, i.e. the settlement related instructions. The
service is available during the whole settlement day, with the exception of the maintenance window. The
T2S instructions managed by this domain are:
•
Settlement instructions:
-
Trade settlement instructions derived from outright transactions, securities transfers and
repo transactions (comprising the new securities financing messages too).
-
Non-trade settlement instructions derived from settlement restrictions and settlement
transactions of corporate events.
Final_T2S_GFS_110.doc
Page 161
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
Maintenance instructions: those which cancel, amend, hold or release settlement instructions
already present in the system.
This domain includes the following modules:
•
Instruction Validation;
•
Instruction Maintenance;
•
Instruction Matching;
•
Status Management;
•
Settlement Eligibility.
Final_T2S_GFS_110.doc
Page 162
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Allegement Data
LCMM
Settlement Eligibility
Instruction Matching
INTERFACE
STATIC DATA
MANAGEMENT
Incoming (Settlement /
Maintenance) Instruction
Static Data Maintenance
Notification
Instruction Validation
Duplicate Check
Time Event
(SoD)
SoD Eligibility
Check
OPERATIONAL
SERVICES
Time Event
(EoD)
Matching Allegement
Removal
Continuous
Eligibility Check
Selection of Instructions
to be Revalidated
Instruction
Management
Matching Allegement
Sending
Validation Flow
Management
Linked Eligibility
Check
Fail
Management
Time Event
(SoD)
Matching Algorithm
Validation Status
Management
ISI
[Matched]
Matching Status
Management
Updating Instruction
Status
ISI
[Ready to be matched]
[Accepted] [On Hold/Release]
[None Cancellation Requested]
Settlement Instruction
Validation
Maintenance
Instruction Validation
Routing
ISI [Already Matched]
[Matching not Required]
Request
Maintenance Instruction
[Accepted]
Answer
Instruction Maintenance
Instruction Status
Information
Amended ISI
[Unmatched] [Accepted]
[On Hold/Release] [None
Cancellation Requested]
Instruction Status
Information / Maintenance
Instruction Status
Information
Status Management
Instruction Status
Information
Maintenance
Instruction Routing
Instruction
Amendment
Partially settled
instruction info
Instruction
Cancellation
CoSD Maintenance
Instruction:
Release/Cancel
Hold/Release
Mechanism
Request
SETTLEMENT
Restriction Status
Information
Collateral Settlement
Information (Release)
SETTLEMENT
End of Cycle
Information
Life Cycle Track
Process
Settlement Status
Collateral Instruction
Settlement Management
Data Collection
for Messages
Answer
ISI
[CoSD to be Released]
[CoSD to be Cancelled]
Further processing
Identification
Time Event
(EoD)
ISI Amended / reason code
Maintenance Status
Management
Maintenance
Allegements
Instruction Status
Information / Maintenance
Instruction Status Information
Final_T2S_GFS_110.doc
Message data
Liquidity Event
INTERFACE
LIQUIDITY
MANAGEMENT
SETTLEMENT
Allegement data
INTERFACE
Page 163
Instruction Cancellation
by the System
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.2. Dynamic data managed by the domain
Final_T2S_GFS_110.doc
Page 164
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.2.1. Description of the entities
1 – Settlement Related Instruction
The purpose of this Class is to store both “settlements instructions” (new instructions that enter to the
LCMM) and “maintenance instructions” (any kind of message, related to the settlement process that
comes to the LCMM in order to update something in an existing instruction).
This entity includes all the common information that is shared between the actions linked to this class.
Since a Settlement Related Instruction is received for the purpose of doing something related to
settlement instructions, each Settlement Related Instruction is linked at least to one Action.
The information stored in this entity is only part of the whole information received in relation with the
settlement instruction; this entity is also linked to the “Individual Settlement Instruction” when this one is
created. This situation only occurs when the type is “Settlement Instruction” and the status is “Accepted”.
Otherwise, this link doesn’t exist.
A list of the attributes for the Settlement Instruction entity is given hereafter:
ATTRIBUTE
Instruction Type
DESCRIPTION
Possible Values:
- SETTLEMENT INSTRUCTION
- MAINTENANCE INSTRUCTION
Sending Party
T2S Party who may send the instruction on behalf of the Instructing Party
Instructing Party
T2S Party who instructs
Entry Date/Time
Data about the date and the time of the message
Already Matched
Incoming flag, in case of two instructions matched before reaching T2S
Matched Instruction Reference
A reference number assigned by the system or the T2S Parties
Status
Possible Values:
- Accepted
- Rejected
- Incoming
This entity is linked to the “Individual Settlement Instruction” when the latter is created. This situation
only occurs when the type is “Settlement Instruction” and the status is “Accepted”.
It is also linked to “Securities”, “Action” and “Message” entities.
Final_T2S_GFS_110.doc
Page 165
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
2 – Action Error
This entity includes the information about the errors that have been detected during the validation of a
Settlement Instruction.
A list of the attributes for the Validation Error entity is given hereafter:
ATTRIBUTE
Error Code
DESCRIPTION
A reference code associated with respective error
Each Action Error is linked to its relevant Action and to its relevant Error Description.
-
When a maintenance instruction can not be executed because the affected individual
settlement instruction has been already settled, Action status is set to “cancelled” and the
value of the error code associated is set to “Affected ISI already settled”.
3 – Action
Information extracted from a message. Every message received is converted into one or several actions
(one physical registry into several logical registries) in order to start the validation process to each of
those logical actions. A validated action triggers the creation of an Individual Settlement Instruction.
A list of the attributes for the action entity is given hereafter:
ATTRIBUTE
Action Type
DESCRIPTION
Possible values:
- Creation
- Hold
- Release
- Cancel
- Amend
- CoSD Release
- CoSD Cancel
Status
Possible Values:
- Rejected
- Accepted
- Executed
- Cancelled
Each Action is linked to its relevant Settlement Related Instruction to which it belongs on the one hand
and, on the other hand, to the Action Parameter entity that stores the remaining parameters the T2S
Actor has included in the instruction.
Final_T2S_GFS_110.doc
Page 166
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Each Action is also linked to:
•
Action error in case the validation process done to the settlement or maintenance instruction
finds an error.
•
Individual Settlement Instruction in case the validation process performed to the settlement
or maintenance instruction has a successful result.
This double link is mutually exclusive to each other, i.e. if the link exists with the Action Error, it does not
exist with Individual Settlement Instruction and vice versa.
4 – Action Parameter
This Entity contains all parameters data that the Instruction sent by the T2S Actor includes.
A list of the attributes for the Action Parameter entity is given hereafter:
ATTRIBUTE
DESCRIPTION
Parameter Name
Description of the parameter
Parameter Value
The value that the parameter can have
Each Action Parameter is linked to its relevant action.
5 – Half Cash Movement
This entity includes all the information regarding the cash data of the instruction.
A list of the attributes for Half Cash Movement entity is given hereafter:
ATTRIBUTE
Operation
DESCRIPTION
Possible Values:
- Debit
- Credit
Original Amount
The amount that originally was order in the instruction.
Matched Amount
The amount to which the instruction was matched. This is the amount to
be settled.
Settled Amount
The amount that finally was settled.
Settlement Date/Time
The date and time when the movement has been done.
Default account
This attribute gets the value yes when the T2S dedicated cash account is
not included in the instruction and T2S shall consider the default cash
account specified by the T2S Actor in static Data.
Each Half Cash Movement is linked to its relevant Individual Settlement Instruction. It is also linked to its
related T2S Dedicated Cash Account and Currency entities.
Final_T2S_GFS_110.doc
Page 167
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
6 – Half Securities Movement
This entity includes all the information regarding the securities data of the instruction.
A list of the attributes for Half Securities Movement entity is given hereafter:
ATTRIBUTE
Operation
DESCRIPTION
Possible Values:
- Receive
- Deliver
Original Quantity
The quantity that originally was order in the instruction
Settled Quantity
The quantity that finally was settled.
Settlement Date/Time
The date and time when the movement has been done.
Each Half Securities Movement is linked to its relevant Individual Settlement Instruction, Security Account
and Security entities.
7 – Hold/Release Party
This entity includes the different commands that a Party can instruct for an Individual Settlement
Instruction in relation to Hold and Release maintenance instructions.
The single attribute of this entity is defined as follows:
ATTRIBUTE
Command
DESCRIPTION
Possible Values:
- Hold
- Release
Each Hold/Release Party is linked to its relevant Individual Settlement Instruction and to its relevant Party
and also Party Type.
8 – Individual Settlement Instruction Link Set
This entity includes information related to the group of links that establish a special relationship between
two or more Individual Settlement Instructions.
Each ISI Link Set is linked to their ISI Link that composes the group.
9 – Individual Settlement Instruction Link
This entity includes the link of this Individual Settlement Instruction with another one.
Final_T2S_GFS_110.doc
Page 168
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
It shall be possible for T2S actors to link instructions by making use of the ISO settlement link indicators
“AFTER”, “BEFORE” and all-or-none (“WITH”). These link indicators will be used in the settlement
process.
A list of the attributes for the entity is given hereafter:
ATTRIBUTE
Link Type
DESCRIPTION
- “AFTER” means that an instruction has to be settled after or at the same
time as the linked instruction
- “BEFORE” means that an instruction has to be settled before or at the
same time as the linked instruction
- “WITH” means that an instruction has to be settled at the same time as
the linked instruction
- “Starting Leg” to indicate the REPO instruction first leg.
- “Closing Leg” to indicate the REPO instruction second leg.
Each ISI Link is linked to its relevant Individual Settlement Instruction and to the Link Set that gathers
them.
10 – Individual Settlement Instruction
This entity includes the specific information of one instructing leg of the settlement instruction except the
information regarding the movements of the instruction (securities and cash). The detailed information of
the instruction may change in time due to T2S Actor actions, but only one Individual Settlement
Instruction is present in the system at any given point in time.
A list of the attributes for the individual Settlement Instruction entity is given hereafter:
ATTRIBUTE
Individual Instruction Type
DESCRIPTION
Possible values:
DVP/DWP
FOP/ PFOD
DVD
Blocking Instruction, Earmarking Instruction, Segregation Instruction,
Reservation Instruction.
Instructing Party
T2S Party who instructs
Trade Date
The date when the contract was made
Intended Settlement Date
The date when the instruction will be, at the first time, forwarded to
settlement
ISO Transaction Code
The ISO transaction codes set out under ISO 20022 {T2S.05.200}
First Party CSD
The CSD where the first counterparty has the securities account
Final_T2S_GFS_110.doc
Page 169
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
ATTRIBUTE
DESCRIPTION
Final Party CSD
The CSD where the final counterparty has the securities account
Final Beneficiary
The beneficiary party of the trade
Auto-Collateralisation Flag
The Individual Settlement Instruction has the possibility of coming to
NCBs lending
Linked Instructions Counter
Number of instructions that are linked to this one
Partial Indicator
When the partial settlement has occurred
Partial Settlement Indicator
When this ISI is enable to making partial settlement
Partial Flag
When the partial settlement is allowed for the T2S
Priority
The level of priority assigned by the T2S actor.
T2S First Party
The party that will deliver the securities (cash in case of a PFoD) in a
settlement instruction.
T2S Final Party
The party that will receive the securities (cash in case of a PFoD) in a
settlement instruction
CosD flag
When the ISI fulfils one CoSD rule stored in SD
CARL flag
When the ISI is identified as required for having an automated transfer of
cash proceeds to RTGS system
Common Reference
Reference to be identified when the instruction is matched.
Allowed Modification Flag
The CSD can identify an ISI as non-modifiable by its
participants{T2S.05.300}
Repo Reference
Reference for REPO Instructions {T2S.05.186} {T2S.05.190}
Reservation Flag
When the reservation/blocking information is inserted in the settlement
instruction itself
Pre-check Amendment Flag
When the individual settlement instruction data is processed only for
validation of maintenance instructions purposes.
Each Individual Settlement Instruction must be linked to the only one Settlement Related Instruction that
caused its creation.
Each Individual Settlement Instruction is linked necessarily to ISI Status entity for maintaining the last
statement of its different statuses, to its relevant Half Securities Movement and Half Cash Movement, and
it is also linked to its relevant Action.
In case it is needed, depending on the different situations, the Individual Settlement Instruction is linked
to ISI Link, CoSD Party, Hold/Release Party, Allegement and Linked restrictions.
Finally, each Individual Settlement Instruction is linked to its Settlement Transaction (once created).
Final_T2S_GFS_110.doc
Page 170
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
11 – Allegements
This entity stores information to be included in the message to advise an account owner that a
counterparty has alleged an instruction against its account and no corresponding instruction by the
account owner was found.
A list of the attributes for the Allegements entity is given hereafter:
ATTRIBUTE
DESCRIPTION
Date/Time
Data about the date and the time of the message
Status
Possible values:
- Sent: when an allegement message (either a matching allegement or a
maintenance allegement) is sent to a T2S Actor
- Removed : when a removal of an allegement message is sent to a T2S
Actor, e.g. following the matching of the instruction for which an
allegement had been initially sent
Allegement Type
Possible values:
- Hold and Release: features the maintenance allegement message sent to
a T2S Actor when a maintenance instruction for holding or releasing a
settlement instruction is processed.
- Unmatched instruction: features the matching allegement message sent
to a T2S Actor (after an unsuccessful matching attempt) for the latter to
send the missing settlement instruction.
- Cancellation allegement features the maintenance allegement message
sent to a T2S Actor when a maintenance instruction for cancelling a
settlement instruction is processed.
- Amendment allegement (partial settlement) features the maintenance
allegement message sent to a T2S Actor when a maintenance instruction
for amending the partial settlement indicator of a settlement instruction is
processed.
Each Allegement is linked to its relevant Individual Settlement Instruction and to its Receiver Party.
12 – Individual Settlement Instruction Status
This entity includes the information of each specific status that an Individual Settlement Instruction can
have in its lifecycle. The status may change in time, but only the latest value is present here at any given
point in time.
Final_T2S_GFS_110.doc
Page 171
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
A list of the attributes for the ISI status entity is given hereafter:
ATTRIBUTE
Name
DESCRIPTION
Possible value:
- Validation status
- Matching status
- Cancellation status
- Settlement status
- CoSD status
- Allegement status
- Eligibility status
- Hold/Release status
Value
Depending on the status type, it will have different values:
- Validation status: Accepted,
- Matching status: Matching not required, already matched, ready to be
matched, matched, unmatched.
- Cancellation status: cancelled, cancellation requested, no cancellation
requested.
- Settlement status: Settled, unsettled, partially settled, <empty>.
- CoSD status: <empty>, CoSD on hold, CoSD to be released, CoSD to be
cancelled.
- Allegement status: allegement sent, allegement removed, none
allegement sent
- Eligibility status: Eligible, ineligible, <empty>.
- Hold/Release status: On hold, released.
Each ISI Status is linked to its relevant Individual Settlement Instruction and to the Reason Codes entity.
13 – CoSD Administering Party
This entity includes the different commands that an Administering Party can instruct against an Individual
Settlement Instruction in relation to CoSD instructions.
The only attribute of this entity is defined as follows:
ATTRIBUTE
Command
DESCRIPTION
Possible Values:
- Cancellation
- Release
Each CoSD Party is linked to its relevant Individual Settlement Instruction and to its relevant Party.
Final_T2S_GFS_110.doc
Page 172
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
14 – Reason Codes
This entity includes the information about the reasons for the status value updates that occurred during
the life cycle of the Individual Settlement Instruction. This entity will track the different reason codes at
the same time or the reason of the same status changed from one value to another.
The attributes of this entity are defined as follows:
Reason Code Reference
Possible values:
- When value “cancelled” in Cancellation status:
-
Recycling period reached
Standard
period
for
unmatched
instructions
reached
-
Unilateral cancellation
-
Bilateral cancellation
-
Cancelled due to Static Data change
-
Cancellation triggered by Administering Party
- When value “ineligible” in Eligibility status:
-
Individual settlement instruction on hold
-
Linked individual settlement instruction missing
-
DVP cut-off reached
-
First leg/ inception not settled
-
Intended Settlement Date not reached
-
- When value “unsettled” in Settlement status:
-
Lack of cash
-
Lack of securities
-
Lack of cash and securities
-
Intraday restriction (security, currency, security
account, T2S dedicated cash account or T2S party
blocked)
Final_T2S_GFS_110.doc
-
Net buying limit reached
-
Earmarked restriction not sufficient
Page 173
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Each Reason Code is linked to its relevant Individual Settlement Instruction Status entity.
15 – Audit Trail
This entity is shared with the Static Data Model (see Static Data Management chapter for more
information)
A list of the attributes for the Audit Trail entity is given hereafter:
ATTRIBUTE
Timestamp
DESCRIPTION
Timestamp of the change.
Each audit trail record is linked to the T2S system user (or the application) responsible for the change and
to the before and after (static or dynamic) images of the records impacted by the change.
3.4.2.2. Settlement and Maintenance Instruction Status
The Settlement and Maintenance Instructions are technically implemented as Settlement Related
Instructions, Actions and Individual Settlement Instruction entities.
In order to better explain this functional description, the tables below summarise the status that Actions
and Individual Settlement Instructions (ISIs) can be set to throughout the different T2S process.
ACTION STATUS VALUES
DESCRIPTION
Incoming
Instruction Validation: When an action is technically created
Accepted
Instruction Validation: When the action derived of the Settlement Instruction
have been successfully validated
Rejected
Instruction Validation: When the action derived of the Settlement Instruction is
not successfully validated
Executed
Instruction Maintenance: For maintenance instructions, when they are
successfully processed
Cancelled
Instruction Maintenance: For maintenance instruction, when they can not be
processed
Final_T2S_GFS_110.doc
Page 174
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
The status transitions for actions are depicted in the following diagram:
Action Status
Instructions
Validation:
Successful
validation
INCOMING
ACCEPTED
Instructions
Maintenance:
Successful
execution
Instructions
Validation:
Unsuccessful
validation
REJECTED
Instructions
Maintenance:
Unsuccessful
execution
EXECUTED
CANCELLED
At any point in time individual settlement instructions have a unique business status, which is determined
by the combination of its different technical status attributes. This Life Cycle status is used by the system
for T2S Parties communication purposes.
The technical status attributes already foreseen for the individual settlement instructions are shown in the
following table:
ISI STATUS TYPE
STATUS VALUE
MODULE IN
ATTRIBUTE
ATTRIBUTE
CHARGE
CASE
Validation status
Accepted
Instruction
Validation
An ISI is created
Matching status
Matching not
required
Instruction
Validation
An ISI is identified as such because the ISO transaction
code and/or instructing party type
Matching status
Already matched
Instruction
Validation
A matching indicator is present in the ISI and it is
consistent with the instruction type
Matching status
Ready to be
matched
Instruction
Validation
An ISI is identified as not already matched but matching is
required for the instruction type
Matching status
Matched
Instruction
Matching
Two ISI instructions are found to have equal values in the
matching fields
Matching status
Unmatched
Instruction
Matching
It can not be found a different ISI instructions whose
matching fields have the same values
Final_T2S_GFS_110.doc
Page 175
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
ISI STATUS TYPE
STATUS VALUE
MODULE IN
ATTRIBUTE
ATTRIBUTE
CHARGE
CASE
Cancellation
status
Cancelled
Instruction
Maintenance
A cancellation request is received from all the T2S Actors
involved in the ISI or the ISI is cancelled by the system
Cancellation
status
Cancellation
requested
Instruction
Maintenance
Only one cancellation request is received between all the
T2S Actors involved in the ISI
Cancellation
status
No Cancellation
requested
Value by
default
----------
Settlement status
Settled
VPB
The transfer of securities and/or cash included in the ISI
has taken place
Settlement status
Unsettled
VPB
The transfer of securities and/or cash included in the ISI
could not be executed
Settlement status
Partially settled
VPB
An ISI is booked only by a partial amount
Settlement status
<Empty>
Value by
default
----------
CoSD status
CoSD Hold
VPB
The securities and/or cash are blocked in a CoSD
instruction
CoSD status
CoSD to be
released
Instruction
Maintenance
All the required releasing requests have been correctly
received for a CoSD instruction
CoSD status
CoSD to be
cancelled
Instruction
Maintenance
All the required cancellation requests have been correctly
received for a CoSD instruction
CoSD status
<empty>
Value by
default
----------
Matching
Allegement
status
Allegement sent
Instruction
Matching
When a matching allegement has been sent to the related
counterparty for the corresponding ISI
Matching
Allegement
status
None allegement
sent
Value by
default
No matching allegement has been sent
Matching
Allegement
status
Allegement
removed
Instruction
Matching
A matching allegement removal has been sent to the
related counterparty for the corresponding ISI
H/R status
Released
Instruction
Maintenance
When all the required releasing requests have been
successfully processed (i.e. when the individual
settlement instruction has been put on hold by the CSD
and the T2S Party, then it will only be released when both
release requests are received and processed)
H/R status
On Hold
Instruction
Maintenance
When the ISI has been sent on hold by the instructing
party or a hold request has been successfully processed
Eligibility status
Eligible
Settlement
Eligibility
Eligibility conditions have been successfully checked for
the ISI
Eligibility status
Ineligible
Settlement
Eligibility
Eligibility conditions have been checked for the ISI but it
has not passed them
Final_T2S_GFS_110.doc
Page 176
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
ISI STATUS TYPE
STATUS VALUE
MODULE IN
ATTRIBUTE
ATTRIBUTE
CHARGE
Eligibility status
<empty>
Value by
default /
Instruction
Maintenance
/ Settlement
Eligibility
CASE
After an ISI with Eligibility status set to eligible is
amended
The transition among values, within the same status type, for settlement instructions are depicted in the
following diagrams:
Final_T2S_GFS_110.doc
Page 177
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Final_T2S_GFS_110.doc
Page 178
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
CANCELLATION STATUS
CANCELLED
Instruction Maintenance:
Cancellation by the system
or unilateral cancellation
Instruction Maintenance:
Cancellation request
received from all T2S Parties
NO CANCELLATION
REQUESTED
Instruction Maintenance:
Cancellation request not
received from all T2S Parties
CANCELLATION
REQUESTED
Final_T2S_GFS_110.doc
Page 179
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.3. Settlement Instructions (SI) use cases
Scope
This category includes all T2S instructions that may have an impact on the cash balance and securities
position through their processing inside the LCMM and the Settlement domains, i.e.:
•
Trade settlement instructions derived from outright transactions, securities transfers and
repo transactions (comprising the new securities financing messages);
•
Non trade settlement instructions derived from settlement restrictions and settlement
transactions of corporate events.
Criteria
The criteria that characterize a SI use case comprise all the external parameters defining the instructions
that influence their processing in the LCMM and the Settlement domains.
Final_T2S_GFS_110.doc
Page 180
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
These criteria are summarised in the table below with their possible values:
CRITERIA
POSSIBLE VALUES
COMMENT
Access Type
U2A, A2A
Access to functionality starts from
User or from Application
CSD Configuration
Intra-CSD, cross-CSD, in/out T2S
Derives from the CSD of the
participants and/or the CSD Issuer
Groups of instructions
Standard, block-trade, two-legged
Instruction type
Settlement instruction: DVP, DWP, FOP, DVD,
PFOD
Settlement restriction (Blocking, reservation,
earmarking and segregation)
Settlement instruction deriving from corporate
actions *36
Settlement instructions for
corporate actions are processed
similarly to
DVP/DWP/FOP/DVD/PFOD
instructions, plus in a few case
additional rebalancing of liquidity
from T2S to the RTGS system
Linked instructions
Yes, No
The ‘Yes’ value derives from
instructions with link
AFTER,BEFORE,WITH or with a
common repo reference
Matching
Yes, Not Required or Already matched (NR/AM)
The ‘Already Matched’ value
derives from an attribute in the
instruction. Matching not required
derives from instructions for
corporate actions and intra-T2S
party FOP
Partial settlement
Yes, No
The ‘Yes’ value derives from CSD
having opted for mandatory partial
settlement or from the choice
expressed at securities account
level unless the instruction
specifies the contrary
CoSD
Yes, No
Rules in Static Data for CoSD
Auto-collateralisation
Yes, No
Parameters attached to the parties,
securities and accounts
It is to be noted that for the sake of simplification, the following parameters are taken into account as
part of the description of the use cases but not as parameters that impact their list:
•
Instructing party type with values: CSD participant, CSD, CCP, NCB; Organised market, T2S
operator;
36
•
Connectivity with values: direct connection, indirect connection;
•
ISO transaction codes: with the relevant values of the ISO 20022;
Message standardisation should ensure that ISO 20022 standards allow identifying settlement instructions of corporate actions.
Final_T2S_GFS_110.doc
Page 181
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
Settlement priority.
List of Use Cases
The criteria described above are reported in the following tree:
Settlement
Instructions
A2A
U2A
Intra-CSD
Cross-CSD
In/out T2S
Standard
Block Trade
Two-legged
Settlement
instruction(DvP,
DwP, FoP, DvD,
PFoD)
Settlement restriction(Blocking,
Reservation, earmarking,
segragation)
Settlement
instruction deriving
from corporate
event
Linked
Matching
Required
Final_T2S_GFS_110.doc
Not linked
Matching not resuired
Already matched
Partial settlement
No partial
settlement
CoSD
No CoSD
Autocollateralisation
No Autocollateralisation
Page 182
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
All the combinations of values are not relevant from a business point of view: the complete list of use
cases is presented in appendix.
3.4.4. Processing of Settlement Instructions Use Cases
3.4.4.1. Selection of representative Settlement Instructions use cases for LCMM
This selection aims at limiting the description of processing to the use cases representing a variation of
each criterion (defined as the list of representative SI use cases in the table below) and at illustrating use
cases relevant for the LCMM among a common table to LCMM and Settlement domains (see section
3.5.3). Use cases already to be presented in the Settlement domain are mentioned on grey background.
The current section therefore only deals with the remaining use cases.
CRITERIA
Intra-CSD
standard
settlement
Intra-CSD
Standard
No
Settlement
Instruction
No
Already Matched
No
No
UC-SI-1b
Intra-CSD
standard
settlement
Intra-CSD
Standard
No
Settlement
Instruction
No
Not Required
No
No
UC-SI-2
Linked
instructions
Intra-CSD
Standard
No
Settlement
Instruction
Yes Yes
No
No
UC-SI-3
Matching
Intra-CSD
Standard
No
Settlement
Instruction
No
Yes
No
No
UC-SI-4
Partial
settlement
Intra-CSD
Standard
No
Settlement
Instruction
No
Not Required/
Already Matched
Yes No
UC-SI-5
Autocollateralisatio Intra-CSD
n
Standard
No
Settlement
Instruction
No
Not Required/
Already Matched
No
Yes
UC-SI-6
Conditional
Security
Delivery
Intra-CSD
Standard
Yes
Settlement
Instruction
No
Not Required/
Already Matched
No
No
UC-SI-7
Block Trade
Intra-CSD
Block-Trade
No
Settlement
Instruction
No
Not Required/
Already Matched
No
No
UC-SI-8
Two-legged
Intra-CSD
Two-legged
No
Settlement
Instruction
No
Not Required/
Already Matched
No
No
UC-SI-9
Blocking
Intra-CSD
Standard
No
Blocking
Instruction
No
Not Required/
Already Matched
No
No
FOCUS
Final_T2S_GFS_110.doc
CSD CONFIG
GROUP OF
INSTRUCTIONS
INSTRUCTION
TYPE
LINKED
UC-SI-1a
DESCRIPTION
COSD
AUTOCOLLAT
PROCESS
PARTIAL
REPRESENTA
TIVE USE
CASE
MATCHING
Page 183
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
CRITERIA
Reservation
Intra-CSD
Standard
No
Reservation
Instruction
No
Not Required/
Already Matched
No
No
UC-SI-11
Settlement of
a corporate
action with
associated
liquidity
transfer
Intra-CSD
Standard
No
Settlement
Instruction
No
Not Required/
Already Matched
No
No
UC-SI-12a
Cross CSD
settlement
Cross-CSD
Standard
No
Settlement
Instruction
No
Not Required/
Already Matched
No
No
UC-SI-12b
In-out T2S
settlement
In-out CSD
Standard
No
Settlement
Instruction
No
Not Required/
Already Matched
No
No
FOCUS
Final_T2S_GFS_110.doc
CSD CONFIG
GROUP OF
INSTRUCTIONS
INSTRUCTION
TYPE
LINKED
UC-SI-10
DESCRIPTION
COSD
AUTOCOLLAT
PROCESS
PARTIAL
REPRESENTA
TIVE USE
CASE
MATCHING
Page 184
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.4.2. Processing of UC-SI-1a: Settlement of a standard settlement instruction- Already
matched
Business assumption
•
This description relates to the processing of individual settlement instructions where T2S
Actor A delivers securities to T2S Actor B, which receives the securities.
•
Both participants belong to the same CSD.
•
The instructions have already been matched in the corresponding CSD.
•
In this case, CSD A sends a unique communication instruction C1 to T2S, containing the data
of the two instructions from both counterparties (T2S Actors A and B), with the same and
unique common reference.
Final_T2S_GFS_110.doc
Page 185
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Processing
Once the format and syntax validations are successfully passed, the incoming instruction I1 enters the
Instruction Validation module which executes the different validation processes to I1, according to the
Processing attribute Analysis.
Alternative 1:
I1 does not pass the validations, getting the business status value “rejected”, which is communicated to
the Status Management module. T2S Actor A is informed through Interface, depending on its message
subscription preferences, about the status value of the settlement instruction, together with the reason
codes for the rejection.
Alternative 2:
I1 successfully passes the corresponding validations, getting the Validation status value “accepted” which
is communicated to the Status Management module, so it can inform through Interface T2S Actor A and B
and CSD A (via one single message) on the status of the instruction, depending on their subscription
preferences.
The individual settlement instruction I1 is split into two separate individual settlement instructions I1A and
I1B both with the same and unique T2S common reference. In addition, the Instruction Validation module
sets the Matching status value “already matched” to I1A and I1B, which is only communicated to Status
Management (and not to the relevant T2S Parties)
Once the validation procedures have been successfully passed, both individual settlement instructions are
routed together directly to the Settlement Eligibility module, not needing to be processed in the
Instruction Matching module.
On settlement day, I1A and I1B get the Eligibility status value “eligible”.
Once eligible, I1A & I1B are processed in the Settlement domain starting with Standardisation and
Preparation to Settlement module which:
•
creates a settlement transaction T1 with the relevant securities’ movements and/or the cash
movement;
•
sends T1 to the Sequencing module for submission alternatively:
-
during day-time to the Validation Provisioning and Booking (VPB) module for a real time
settlement attempt;
-
during night-time to the Recycling and Optimisation (R&O) module for optimisation
attempt before being forwarded to VPB .
Once in VPB, T1 may alternatively:
Final_T2S_GFS_110.doc
Page 186
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
settle following a successfully provision-checking, in which case:
-
the “settled” Settlement Transaction Status value added to the settlement transaction T1
is sent to R&O for information of a new incoming resource;
-
the “settled” Settlement status value of I1A & I1B is sent to the Status Management
module in order to inform the relevant parties of the settlement.
•
fail following an unsuccessfully provision-checking, in which case:
-
T1 is sent to R&O for optimisation and submitted again to VPB.
-
I1A & I1B get the Settlement status value “unsettled”, which is communicated to the
Status Management module in order to inform the T2S Actors of the fail, together with its
reason code, should it be the first occurrence of this fail. T2S Actors receive this
information depending on their message subscription preferences.
3.4.4.3. Processing of UC-SI-1b: Settlement of a standard settlement instruction – Matching not
required
Final_T2S_GFS_110.doc
Page 187
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Scenario 1 - Intra T2S Party FoP
Business assumption
This description relates to the processing of an individual settlement instruction that does not have to be
matched in T2S. In this description the assumption is that T2S Party A sends an intra T2S Party FoP
individual settlement instruction I1 to T2S.
Processing
Once the formal and syntax validations are successfully passed, the incoming instruction I1 enters the
Instruction Validation module which executes the different validation processes to I1, according to the
Processing Attribute Analysis.
Alternative 1:
I1 does not pass the validations, getting the Validation status value “rejected”, which is communicated to
the Status Management module. T2S Party A is informed through Interface depending on its message
subscription preferences, about the status value of the settlement instruction, including the reason codes
for the rejection.
Alternative 2:
I1 successfully passes the corresponding validations, getting the Validation status value “accepted” which
is communicated to the Status Management module. T2S Party A is informed about the status value of
the instruction, depending on its message subscription preference, through Interface. Additionally, the
Instruction Validation module sets its Matching Status value to “matching not required”, which is only
communicated to the Status Management module (and not to T2S Party A).
Once the validation procedures have successfully been passed, the individual settlement instruction I1 is
routed directly to the Settlement Eligibility module, not needing to be processed in the Instruction
Matching module.
On settlement day, I1 gets the Eligibility status value “eligible”. The rest of the settlement process for this
Use Case is described in UC-SI-1a Settlement of a standard settlement instruction-Already matched.
Scenario 2 - Corporate Action
Business assumption
•
This description relates to the processing of a corporate action, sent as a FoP individual
settlement instruction.
Final_T2S_GFS_110.doc
Page 188
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
The directly connected Corporate Action (CA) managing entity sends to T2S a “matching not
required” corporate action individual settlement instruction I1.
Processing
Once the formal and syntax validations are successfully passed, the incoming instruction I1 enters the
Instruction Validation module which:
•
Identifies I1 as a Corporate Action related individual settlement instruction through a specific
ISO transaction code;
•
Executes the different validation processes to I1, according to the Processing Attributes
Analysis, getting the Validation status value “accepted” which is communicated to the Status
Management module. The directly connected CA managing entity is informed of the status
value of the settlement instruction, depending on its message subscription preferences.
Additionally, the Instruction Validation module sets the individual settlement instruction’s
Matching status value to “matching not required”, which is only communicated to the Status
Management module (and not to the directly connected CA managing entity).
On settlement day, the Settlement Eligibility module selects I1, getting the Eligibility status value
“eligible”. After this point, the description of the Use Case follows the standard settlement process, taking
into account that I1A is a FoP individual settlement instruction.
Scenario 3 - Settlement Restrictions
Settlement restrictions are described in UC-SI-9 “Blocking instruction” and UC-SI-10 “Reservation
instruction”.
3.4.4.4. Processing of UC-SI-2: Intra-CSD Standard Linked DvP Instructions
Business assumption
•
This description relates to the processing of linked settlement instructions in T2S where:
•
The T2S Actor A delivers securities to the T2S Actor B and sends the settlement instruction
I1 to T2S.
•
The T2S Actor B receives securities from the T2S Actor A and sends the settlement
instruction I2 to T2S.
•
T2S Actor B delivers securities to T2S Actor C and sends the settlement instruction I3 to T2S.
•
T2S Actor C receives securities from T2S Actor B and sends the settlement instruction I4 to
T2S.
Final_T2S_GFS_110.doc
Page 189
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
T2S Actor B has linked it settlement instruction (I2) to the settlement instruction reference
(I3) with an ISO settlement link indicator (“BEFO”, “AFTE”, “WITH” or a common repo
reference).
•
T2S actors A, B and C belong to the same CSD, and send their settlement instructions
directly to T2S, without the intervention of the CSD or a CCP.
•
All the settlement instructions (I1, I2, I3 and I4) are processed in T2S according to the
corresponding standard Use Cases, depending on their processing attributes. The matching
process is not detailed in the description of this use case as it is already covered in the use
case for instructions with matching.
•
No pool reference used and no optional number included.
Final_T2S_GFS_110.doc
Page 190
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Settlement link indicator “BEFO” (before)
Intra-CSD Standard Linked DvP Instructions - Settlement link indicator “BEFO”
Interface
T2S Actor
Communication C2
T2S
Actor B
LCMM:
Instruction
Validation
LCMM:
Instruction
Matching
LCMM:
Status
Management
LCMM:
Settlement
Eligibility
SETT:
SPS
Incoming
Instruction I2
Alt 1
ISI I2 Standard process
I2 “eligible”
I2 follows
the
standard
settlement
process
ISI “accepted” I2
T2S
Actor B
“accepted” status I2
Data for “accepted” status message I2
Alt 2
Alt 2.1
ISI I2 Standard process
I2 “eligible”
I2 follows the
standard
settlement
process. I2
has to settle
before I3
ISI “accepted” I2
T2S
Actor B
“accepted” status I2
Data for “accepted” status message I2
Alt 2.2
“rejected” I2
“rejected” status I2
T2S
Actor B
Data for “rejected” status message I2
.
T2S Actor B firstly sends the communication C2 linked, with the ISO settlement link “BEFO”, to the
settlement instruction reference I3. In addition to the standard processes performed in the Instruction
Validation module and already described in the standard use cases, the Instruction Validation module
Final_T2S_GFS_110.doc
Page 191
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
identifies that I2 is linked to another individual settlement instruction by the link “BEFO”. This module
checks if the linked individual settlement instruction I3 is already present.
Alternative 1: Linked individual settlement instruction I3 is missing:
When the linked individual settlement instruction is not present, no consistency checks between both
instructions can be performed at this stage and the individual settlement instruction I2 follows the
standard processing in T2S until being processed in the Settlement Eligibility module. In this case, the
linked individual settlement instruction I3 is missing, but since I2 has the link indicator “BEFO”, I2 can be
settled. From this point, I2 continues with the relevant settlement process.
Alternative 2: Linked individual settlement instruction I3 is already present in T2S
T2S Actor B has sent the settlement instruction I3 to T2S, for which the Instruction Validation module
checks that the information contained in I2 is consistent with I3, on the basis of the information contained
in the settlement instructions (same or previous intended settlement date and same securities account
holder).
Alternative 2.1:
If I2 is consistent with I3, then I2 follows the relevant settlement process, taking into account that I2 is to
be settled before or at the same time as I3.
Alternative 2.2:
If I2 is not consistent with I3, I2 is rejected.
Final_T2S_GFS_110.doc
Page 192
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Settlement link indicator “AFTE” (after)
Intra CSD Standard Linked DvP Instructions - Settlement link indicator “AFTE”
Interface
T2S Actor
Communication C3
T2S
Actor B
LCMM:
Instruction
Validation
LCMM:
Instruction
Matching
LCMM:
Status
Management
LCMM:
Settlement
Eligibility
SETT:
SPS
Incoming
Instruction I3
ISI I3 Standard process
Alt 1
I3 “eligible”
ISI “accepted” I3
“accepted” status I3
T2S
Actor B
I3 follows the
standard
settlement
process
Data for “accepted” status message I3
Alt 1.1
Communication I2
T2S
Actor A
Settlement
instruction I2
ISI I2 Standard process
I2 “eligible”
I3 has to
settle after
I2
Alt 1.2
I3 is
considered
as failed
Alt 2
Alt 2.1
ISI I3 Standard process
I3 “eligible”
ISI “accepted” I3
“accepted” status I3
T2S
Actor B
Data for “accepted” status message I3
I3 follows the
standard
settlement
process. I3
has to settle
after I2
Alt 2.2
“rejected” I3
“rejected” status I3
T2S
Actor B
Data for “rejected” status message I3
.
T2S Actor B sends the communication C3 linked, with the ISO settlement link “AFTE”, to the settlement
instruction reference I2. In addition to the processes performed in the Instruction Validation module,
already described in the standard use cases, the Instruction Validation module firstly identifies that I3 is
Final_T2S_GFS_110.doc
Page 193
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
linked to another settlement instruction by the link “AFTE” and checks if the linked individual settlement
instruction I2 is already present in T2S.
Alternative 1: Linked individual settlement instruction I2 is missing:
In case the linked individual settlement instruction is not present, no consistency checks between both
instructions can be performed at this stage, and the individual settlement instruction I3 follows the
standard processing in T2S until being processed in the Settlement Eligibility module. Given that the link
indicator is “AFTE”, this module does not consider for settlement I3 (I3 can not be settled before I2 is
settled).
Alternative 1.1:
If I2 is received in T2S, I3 settles after or at the same time as I2
Alternative 1.2:
If I2 is still missing at the end of the intended settlement date of I3, the latter is then considered as
failed.
Alternative 2: Linked individual settlement instruction I2 is already present in T2S
T2S Actor has already sent the settlement instruction I2 to T2S. The Instruction Validation module checks
that the information contained in I3 is consistent with I2 (same or later intended settlement date and
same securities account holder).
Alternative 2.1:
If the consistency check is successful, I2 and I3 follow the relevant settlement process (I3 is settled after
or at the same time as I2).
Alternative 2.2:
If the information in I3 is not consistent with I2, I3 is rejected.
Final_T2S_GFS_110.doc
Page 194
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Settlement link indicator “WITH” (all-or-none)
Intra-CSD Standard Linked DvP Instruction - Settlement link indicator “WITH”
Interface
T2 S
Actor
Communication C2
T2S
Actor B
LCMM:
Instruction
Validation
LCMM:
Instruction
Matching
LCMM:
Status
Management
LCMM:
Settlement
Eligibility
SETT:
SPS
Incoming
Instruction I2
Alt 1
ISI I2 Standard process
I2 “eligible”
ISI “accepted” I2
“accepted” status I2
T2S
Actor B
I2 follows
the
standard
settlement
process
Data for “accepted” status message I2
Alt 2
Alt 2.1
ISI I2 Standard process
I2 “eligible”
ISI “accepted” I2
“accepted” status I2
T2S
Actor B
I2 follows the
standard
settlement
process. I2 has
to settle at the
same time than
I3
Data for “accepted” status message I2
Alt 2.2
“rejected” I2
T2S
Actor B
“rejected” status I2
Data for “rejected” status message I2
.
T2S Actor B sends the communication C2 linked with the ISO settlement link “WITH” to the settlement
instruction reference I3. In addition to the processes performed in the Instruction Validation module,
already described in the standard use cases, the Instruction Validation module first identifies that I2 is
Final_T2S_GFS_110.doc
Page 195
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
linked to another settlement instruction by the link “WITH” and checks if the linked individual settlement
instruction I3 is already present in T2S.
Alternative 1: Linked individual settlement instruction I3 is missing:
In case the linked individual settlement instruction is not present, no consistency checks between both
instructions can be performed at this stage and individual settlement instruction I2 follows the standard
processing in T2S until its processing in the Settlement Eligibility module. Given that the link indicator is
“WITH”, this module does not consider for settlement I2 (I2 and I3 are to be settled simultaneously).
If I3 is still missing at the end of the intended settlement date of I2, the latter is then considered as
failed.
Alternative 2: Linked individual settlement instruction I3 is already present in T2S
T2S Actor has already sent the settlement instruction I3 to T2S. The Instruction Validation module then
checks that the information contained in I3 is consistent with I2 (same intended settlement date and
same securities account holder).
Alternative 2.1:
If the consistency check is successful, I2 and I3 follow the relevant settlement process (both to be settled
at the same time).
Alternative 2.2:
If the information in I3 is not consistent with I2, I2 is rejected and I3 is considered as failed at the end of
settlement date because it is linked to a missing individual settlement instruction.
Final_T2S_GFS_110.doc
Page 196
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Settlement instructions linked by a common repo reference
Intra-CSD Standard Linked DvP Instruction - Settlement link indicator “REPU”
Interface
T2 S
Actor
Communication C2
T2S
Actor B
LCMM:
Instruction
Validation
LCMM:
Instruction
Matching
LCMM:
Status
Management
LCMM:
Settlement
Eligibility
SETT:
SPS
Incoming
Instruction I2
Alt 1
ISI “accepted” I2
I2 “eligible”
I2 follows
the
standard
settlement
process
I2 Standard process
T2S
Actor B
“accepted” status I2
Data for “accepted” status message I2
Alt 2
Alt 2.1
I2 Standard process
I2 “eligible”
ISI “accepted” I2
T2S
Actor B
“accepted” status I2
I2 follows the
standard
settelment
process. I2
has to settle
before I3
Data for “accepted” status message I2
Alt 2.2
“rejected” I2
“rejected” status I2
T2S
Actor B
Data for “rejected” status message I2
.
T2S Actor B firstly sends the communication C2 linked with a common repo reference to the settlement
instruction I3. It is assumed that I2 is the settlement instruction for the starting leg of a repo (ISO
Final_T2S_GFS_110.doc
Page 197
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
transaction code REPU) while I3 is the settlement instruction for the closing leg (ISO transaction code
RVPO).
The Instruction Validation module performs the standard validation processes (already described in the
standard use cases) and identifies that I2 is linked to another settlement instruction with a common repo
reference. It also identifies if the linked settlement instruction is the starting leg or the closing leg of the
repo and the link types “starting leg” or “closing leg” are assigned accordingly. As in the former cases, this
module also checks if the linked individual settlement instruction is already present.
Alternative 1: Linked individual settlement instruction I3 is missing:
In case the linked individual settlement instruction is not present, no consistency checks between both
instructions can be performed at this stage and individual settlement instruction I2 follows the standard
processing in T2S until the Settlement Eligibility module. In the Settlement Eligibility module, although I3
is missing, I2 is considered for settlement since the presence of I3 is not required for further processing.
Alternative 2: Linked individual settlement instruction I3 is already present:
T2S Actor B has already sent the settlement instruction I3 to T2S. In this case, once the module identifies
that the settlement instruction I2 is the starting leg of the repo and I3 is the closing leg of the repo
individual settlement instruction, it verifies the consistency on the basis of the information contained in
both individual settlement instructions.
Alternative 2.1:
If the information in the settlement instruction I3 is consistent with I2, both settlement instructions follow
the standard processing until the Settlement Eligibility module, where the closing leg (I3) only becomes
eligible if and only if the starting leg (I2) is settled.
Alternative 2.2:
If the information is not consistent, I2 is rejected.
Final_T2S_GFS_110.doc
Page 198
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.4.5. Processing of UC-SI-3: Intra CSD-Standard DvP with Matching
Intra CSD-Standard DvP with Matching
Interface
T2S Actor
T2S
Actor A
Communication C1
LCMM:
Instruction
Validation
LCMM:
Status
Management
LCMM:
Instruction
Matching
LCMM:
Settlement
Eligibility
Incoming
Instruction I1
Alt 1
I1 “rejected”
T2S
Actor A
“rejected” status I1
Data for “rejected” status message I1
Alt 2
ISI “accepted” I1
“ready to be matched” I1
T2S
Actor A
“accepted” status I1
Data for “accepted” status message I1
“ready to be
matched” I1
“unmatched” I1
“allegement
not sent”
T2S
Actor A
“unmatched” status I1
T2S
Actor B
Allegement Message
T2S
Actor B
Communication C2
Data for “unmatched” status message I1
Data for matching Allegement Message
Incoming
Instruction I2
After the matching
process
“allegement sent”
ISI “accepted” I2 /
“ready to be matched” I2
“ready to be
matched” I2
T2S
Actor B
“accepted” status I2
Data for “accepted” status
message I2
“matched” I1 & I2
Matching status
“matched” I1
T2S
Actor A
Matching status
“matched” I2
T2S
Actor B
Data for Matching status “matched” I1
Follows the standard
Settlement process
Data for Matching status “matched” I2
“allegement
removed”
T2S
Actor B
Allegement Message
Data for matching removal allegement
message
“matched” I1 & I2
Business assumption
This description relates to the settlement of two standard individual settlement instructions, which require
matching in T2S.
In this description, the assumptions are:
Final_T2S_GFS_110.doc
Page 199
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
T2S Actor A delivers securities to T2S Actor B, which receives the securities. Both actors
belong to the same CSD, and both send their individual settlement instructions directly to
T2S, without intervention of a CSD or CCP;
•
T2S Actor A sends its communication C1 to T2S first, and the counterparty’s communication
C2, has not been sent yet. No common reference has been agreed and mentioned in the
individual settlement instructions by the counterparties;
•
After receiving a matching allegement message, T2S Actor B sends its individual settlement
instruction and finally, both individual settlement instructions are matched, with discrepancy
in the cash amount.
Processing
Once the format and syntax validations are successfully passed, the incoming instruction I1 enters the
Instruction Validation module which validates I1, according to the Processing Attribute Analysis.
Alternative 1:
I1 does not pass the validations, getting the Validation status value “rejected”, which is communicated to
the Status Management module. T2S Party A is informed through Interface depending on its message
subscription preferences about the status value of I1, together with the reason codes for the rejection.
Alternative 2:
I1 successfully passes the corresponding validations, getting the Validation status value “accepted” which
is communicated to the Status Management Module. T2S Actor A is informed through Interface depending
on its message subscription preference on the status value of I1.
The Instruction Validation module sets the Matching Status value of the individual settlement instruction
to “ready to be matched”, which is communicated only to Status Management (and not to T2S Actor A).
Once all the validation procedures have successfully been passed, the individual settlement instruction is
routed to the Instruction Matching module.
First, the Instruction Matching module tries to match I1, but the counterparty individual settlement
instruction I2 is not found in the system (in the repository of unmatched individual settlement
instructions). Then, the individual settlement instruction I1 gets the Matching status value “unmatched”,
which is communicated to the Status Management module. T2S Actor A is informed through Interface,
depending on its message subscription preference, on the Matching status value of the settlement
instruction “unmatched”, but no reason codes are sent.
I1 is stored in the repository of unmatched individual settlement instructions. After a defined period of
time, the Instruction Matching module collects all the relevant data and forwards it to Interface, so a
Final_T2S_GFS_110.doc
Page 200
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
matching allegement message can be sent to the counterparty, depending on the message subscription
preference. Additionally, the Instruction Matching module sets the Allegement status value of the
individual settlement instruction I1 to “allegement sent” and communicates it only to the Status
Management module.
From the moment of the first unsuccessful matching attempt until the period of time stipulated to send
the matching allegement message, individual settlement instruction I1 gets the Allegement status value
“allegement not sent.”
After receiving the matching allegement message, T2S Actor B sends its communication C2 to T2S. The
incoming instruction I2 is processed in the same way as I1 until it gets the Matching status value “ready
to be matched”, which is communicated only to the Status Management module.
Once all the validation procedures have successfully been passed, the individual settlement instruction I2
is routed to the Instruction Matching module.
The Instruction Matching module searches for the counterparty’s individual settlement instruction (i.e. I1)
and verifies with all possible individual settlement instructions matching possibilities that all the mandatory
and additional matching fields match.
The result of the comparison is that both individual settlement instructions match univocally, except for
the cash amount for which the discrepancy is within the tolerance amount limit:
•
The matched amount, for which both individual settlement instructions are considered to
match, is determined by the original cash amount of the securities seller I1;
•
A “T2S common reference” with a common value is set to both individual settlement
instructions;
•
The Matching status value of I1 and I2 is set to “matched” and is communicated to the
Status Management module. T2S Actor A and T2S Actor B are informed, through Interface,
that I1 and I2 are “matched” according to their message subscription preferences.
The Instruction Matching module also collects the relevant data in order to send to the Status
Management module a removal of the previously sent matching allegement message to T2S Actor B,
informing that this message is no longer valid, according to T2S Actor B message subscription
preferences. Once this message has been sent, I1 gets the Allegement status value “allegement
removed”.
Afterwards, both matched individual settlement instructions are forwarded to the Settlement Eligibility
module.
Final_T2S_GFS_110.doc
Page 201
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
On settlement day, Settlement Eligibility module selects the individual settlement instructions I1 and I2,
getting the Eligibility status value “eligible”. After this point, the description of the Use Case follows the
standard settlement process.
3.4.4.6. Processing of UC-SI-7: Intra CSD-Standard DvP with Block Trade instruction
Intra CSD-Standard DvP with Block Trade Instruction
Interface
T2 S
Actor
Communication
C1
T2S
Actor A
LCMM:
Instruction
Validation
LCMM:
Status
Management
LCMM:
Settlement
Eligibility
SETT:
SPS
SETT:
Sequencing
SETT:
VPB
Incoming
Instruction I1
Alt 1
“rejected” I1
T2S
Actor A
“rejected” status I1
Alt 2
Data for “rejected” status message I1
“accepted” I1
“accepted” S1
...
“accepted” S2
“accepted” Sn
T2S
Actors
S1,
S2
.
.
Sn
“accepted” status S1
“accepted” status S2
...
“accepted” status Sn
Data for “accepted” status
message S1
Data for “accepted”
status
...
message S2
Data for “accepted” status
message Sn
“accepted” S1
“accepted” S2
...
“accepted” Sn
“eligible” S1
“eligible” S2
...
“eligible” Sn
“created” T1
“created” T2
...
“created” Tn
Follows the standard
Settlement process
T2S
Actors
S1,
S2
.
.
Sn
Settlement status
“settled” S1
Settlement status
“settled” S2
Settlement status
“settled” Sn
Data for Settlement status
message “settled” S1
created T1
created T2
...
created Tn
Instruction Status Information
“settled” T1
Data for Settlement status
message “settled” S2
Instruction Status Information
...
“settled”
T2
Data for Settlement status
message “settled” Sn
Instruction Status Information
“settled” Tn
This use case relates to the processing of a block-trade instruction I1.
After validation, this instruction is split into individual settlement instructions that are processed
independently following the DvP standard settlement process.
Final_T2S_GFS_110.doc
Page 202
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Business assumption
•
The block-trade instruction I1 refers only to a single ISIN code and is sent by a T2S Actor A.
•
The content of the block-trade instruction is 1-to-many relationship. T2S Actor A is the
common counterparty of all individual settlement instructions that derive from the splitting
process. T2S Actors S1, S2…Sn are T2S Actor A counterparties in each individual settlement
instruction.
Processing
When receiving the incoming instruction I1, the Instruction Validation module fulfils the validation process
in the following steps:
It identifies I1 as a block-trade instruction (checks the 1 to n relationship in the instruction) and checks
that the amounts (quantity of securities and amount of money) for T2S Actor A corresponds with the sum
of the counterparty individual settlement instructions that make up the total of the block-trade instruction.
Alternative 1:
If these checks are not successfully passed, the block-trade instruction I1 status value is set to “rejected”
and information is sent to Interface in order to inform T2S Actor A of the status of I1, including the
reason codes for the rejection.
Alternative 2:
•
In case the abovementioned checks are successfully passed, the Instruction Validation
module splits I1 (1 to n relationship) into individual settlement instructions (S1, S2…Sn)
having all of them the T2S Actor A as counterparty.
•
After successful validation, settlement instructions get the validation status value “accepted”.
The Instruction Validation module validates each individual settlement instruction resulting
from the splitting, according to the Processing Attribute Analysis.. In case any errors are
found in the individual settlement instructions, the block-trade instruction I1 is rejected, and
the set of errors is sent to T2S Actor A, including the relevant reason codes for the rejection
as described in Alternative 1
The Instruction Validation module forwards this information to the Status Management
module that sends data for a message status to Interface to inform the T2S Actor A that I1 is
accepted and each T2S Actor S1, S2, …, Sn that their instructions are accepted.
Additionally, the Instruction Validation module sets the individual settlement instructions
Matching status value to “matching not required”, which is only communicated to the Status
Management module (and not to the relevant T2S Actors).
Final_T2S_GFS_110.doc
Page 203
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
On the settlement day, the Settlement Eligibility module selects S1, S2 … Sn and moves them to the
Eligibility status value “eligible”. Then, the eligible instructions follow independently the standard
settlement process already described in the corresponding Use Cases. The settled settlement status of
each individual instruction is sent to the Status Management module in order to inform the parties and the
CSD of the settlement.
If the block trade instruction includes an all-or-none link (“WITH” link indicator), the split individual
settlement instructions (S1, S2….Sn) are settled according to the process described in UC-SI-2 Intra-CSD
Standard Linked DvP Instructions for that type of link.
Final_T2S_GFS_110.doc
Page 204
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.4.7. Processing of UC-SI-8: Intra CSD- Two-legged instruction
Two-legged Instruction
Interface
T2S Actors
Communication
C1
T2S
Actor A
“accepted”
status I1
T2S
Actor A
LCMM:
Instruction
Validation
Incoming
Instruction
I1
LCMM:
LCMM:
LCMM:
Instruction Instruction
Status
Matching Maintenance Management
LCMM:
Settlement
Eligibility
SETT:
SPS
SETT:
Sequencing
ISI “accepted” I1A & I1B
Data for “accepted” status message I1 (I1A & I1B)
Alt 1
I1A & I1B
I1A
“eligible”
I1A
“eligible”
Alt 2
I1B follows
the
standard
settelment
process
I1B
“on hold”
H/R status “on
hold” I1B
T2S
Actor A
T2S
Actor B
I1A follows
the
standard
settelment
process
I1B
“on
hold”
Data for H/R status message “on hold”
I1B
I1A
I1A
“eligible”
Communication C2
Incoming
Instruction I2
“accepted”
status I1
T2S
Actor A
I1A follows
the
standard
settelment
process
Maintenance Instruction “accepted”
M1
Data for “accepted” status message I1
M1
“executed”
“accepted” M1
I1B
“release”
M1 “executed”
Data for “executed” message M1
T2S
Actor A
H/R status
“released” I1
Data for H/R status message “released” I1B)
I1B
I1B
“eligible”
I1B follows
the
standard
settelment
process
.
Business assumption
This description relates to a two legged instruction instructed by CSD A as a single instruction I1,
containing the relevant data for the settlement of the inception and the redemption of the repo.
Final_T2S_GFS_110.doc
Page 205
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Processing
Once the format and syntax validations are successfully passed, the incoming instruction I1 enters the
Instruction Validation module which:
•
Executes the different validation processes on I1, according to the Processing Attribute
Analysis. Once the Validation status value of the settlement instruction is “accepted”, it is
communicated to the Status Management module, so CSD A is informed through Interface
on the status value of the instruction, according to its message subscription preference.
•
Splits the instructions into two separate individual settlement instructions I1A and I1B linking
them (inception and redemption) internally by a common repo reference (ISO Transaction
Code).
In the Instruction Matching module, individual settlement instructions I1A and I1B follow the standard
matching process (described in UC-SI-3) separately. Once matched, two possible alternatives arise
depending on the intended settlement date of both legs.
Alternative 1:The inception and the redemption of the two-legged instruction have different settlement
date
Settlement of the inception
On the intended settlement date of the inception instruction I1A, the Settlement Eligibility module
processes it and sets its Eligibility status value to “eligible”. The individual settlement instruction I1A
follows the relevant settlement process.
Settlement of the redemption
On the intended settlement date of the redemption instruction I1B, the Settlement Eligibility module
checks that I1A has been settled. The individual settlement instruction I1B gets the Eligibility status value
“eligible” and follows the aforementioned settlement process.
Alternative 2:The inception and the redemption of the two-legged instruction have the same settlement
date
This is the case of an intraday repo.
Once the Instruction Validation Module splits the instruction into two separate individual settlement
instructions (I1A, I1B), it identifies that the two legs are to be settled on the same intended settlement
date and sets the redemption instruction to the Hold/Release status value “on hold”, so the redemption is
not settled immediately, but after the inception instruction is settled and T2S Actor B sends a release
maintenance instruction.
In the Instruction Matching module, individual settlement instructions I1A and I1B follow the standard
matching process separately.
Final_T2S_GFS_110.doc
Page 206
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Settlement of the inception
On the intended settlement date of the inception instruction I1A, the Settlement Eligibility module sets its
Eligibility status value to “eligible”, and follows the standard settlement process.
Settlement of the redemption
T2S Actor B sends a maintenance instruction to release the redemption instruction (I1B). The Settlement
Eligibility module sets the redemption instruction to the Hold/Release status value “release” and checks
that I1A has already been settled. The individual settlement instruction I1B gets the Eligibility status value
“eligible” and follows the standard settlement process.
Final_T2S_GFS_110.doc
Page 207
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.5. Instruction Validation
3.4.5.1. Diagram of the module
INTF: Flow
Management
Static Data
<<Data Store>>
[Instructions]
Instruction Validation
Request
LCMM: Instruction
Maintenance
Static Data Maintenance
Notification
Settlement / Maintenance
Instruction
Selection of Instructions
to be Revalidated
Duplicate Check
Time Event
(SoD)
Answer
Instructions to be
Revalidated
Instruction
Settlement Instruction
Settlement Instruction
Validation
Maintenance
Instruction Validation
<<Data Store>>
[Static Data]
Check Result
<<Data Store>>
[Validation Error]
Validation Flow
Management
Check Result
Maintenance Instruction
Duplicated Instruction
[rejected]
Validated Actions
[accepted/rejected] /
Revalidated
Instructions
Validated Grouped
Instruction
[accepted/rejected]
LCMM: Status
Management
Partially Settled
Instruction info
Instruction
Management
New Instruction
(from partially settled)
Settlement instructions
<<Data Store>>
[Instructions]
Validation Status
Management
Instruction Status
Information /
Maintenance Instruction
Status Information
LCMM: Status
Management
Accepted Individual Settlement
Instruction / Accepted Maintenance
Instruction
Routing
Final_T2S_GFS_110.doc
ISI
[Ready to be matched]
[Accepted] [On hold/Released]
[None Cancellation Requested]
ISI
[Already matched / Matching not
required]
Maintenance Instruction
[Accepted ]
LCMM: Instruction
Matching
LCMM: Settlement
Eligibility
LCMM: Instruction
Maintenance
Page 208
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.5.2. Description of the module
Validation is the process of checking the consistency of settlement related instructions sent to T2S by a
CSD or directly connected T2S Actor with the information stored in the T2S Static Data. This service is
continuously available during settlement days, except during the maintenance window.
This module validates the following T2S instructions:
•
Settlement instructions:
For settlement instructions, different validation processes are executed depending on the
processing attributes, understood as the set of criteria for the specific processing in T2S.
These validation processes are performed on:
-
All the incoming instructions received during the current processing day
-
Individual settlement instructions already validated, that have been affected by a change
in Static Data.
•
-
Individual settlement instructions affected by an amendment instruction.
-
Individual settlement instructions at the Start of Day procedures.
Maintenance instructions.
For maintenance instructions, general validation rules are applied in the validation module.
Further status checks are performed in the Maintenance Instruction Module for the
maintenance instruction.
The validation of maintenance instructions is done in two steps:
-
First, general validation rules are applied
-
Secondly, validations for amendment maintenance instructions are performed.
T2S never validates non-settlement-related information added to instruction by T2S Actors for their own
ends. {T2S.05.230}
When data of an incoming instruction is received from the Flow Management module, this function stores
all information received in the following entities:
•
Settlement related instruction. It stores both settlement and maintenance instruction basic
data common to the actions associated to this entity.
•
Action. This entity stores the type of action that the T2S Actors want T2S to execute (i.e. a
new settlement instruction, an amendment of an existing one, a cancellation …).
Final_T2S_GFS_110.doc
Page 209
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
Actions parameter. The aim of this entity is to store all the remaining data received from the
Flow Management module contained in the message sent by the T2S Actor and that have to
be validated.
For both settlement instructions and maintenance instructions, at the end of the validation process, the
Action status can be set to any of the following values:
•
“Accepted”, whenever the maintenance or settlement instruction has passed successfully all
validations,
•
“Rejected”, whenever any error has been found.
Once the data of an incoming instruction are successfully validated:
•
If the data refer to a new settlement instruction, a new occurrence is stored in the Individual
Settlement Instruction entity and in its related entities (see Validation Status Management
function)
•
If the data refer to a maintenance instruction, no new occurrence is recorded in the
Individual Settlement Instruction entity but the data are forwarded to the Instruction
Maintenance module in order to modify an already existing individual settlement instruction.
•
For settlement instructions affected by a Static Data update that makes them no longer valid,
the Cancellation status is set to “cancelled” and the T2S Actor is informed.
The Status Management module is informed on the status of the instruction to be reported to the relevant
parties, including the reason codes for unsuccessful validations.
All the validations performed by this module are carried out through the following eight functions:
•
Duplicate Check
•
Validation Flow Management
•
Settlement Instruction Validation
•
Maintenance Instruction Validation
•
Instruction Management
•
Selection of Instruction To Be Revalidated
•
Validation Status Management
•
Routing
Final_T2S_GFS_110.doc
Page 210
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.5.3. Description of the functions of the module
1 – Duplicate Check
This function carries out a duplicate-submission control for incoming new instructions. It applies to both
settlement and maintenance instructions.
The function rejects duplicate or multiple submissions of incoming new instructions based on a
combination of the T2S Actor identifier and the instruction reference assigned by the instructing party
{T2S.05.030}. This check is done vis-à-vis the same category of T2S instructions (settlement or
maintenance instructions) and non-settled individual settlement instructions. It will also be checked vis-àvis individual settlement instructions that have been settled in a standard number of days in the past. This
standard number of days will be a parameter to be set in T2S. This function also checks that the
instruction reference included by a T2S Party is not identical to the T2S individual settlement instruction
reference set by T2S to another instruction of this same Party.
If a duplicate is found, the instruction is rejected by the Duplicate Check function which informs the
Validation Status Management function.
If no duplicate is found, the function sends the instruction to the Validation Flow Management function.
2 – Validation Flow Management
Type of instruction identification
This sub-function receives both settlement and maintenance instructions as an input from the Duplicate
Check Function and forwards them, according to their type, to the Settlement Instruction Validation
function or the Maintenance Instruction Validation function respectively. This sub-function also receives
individual settlement instructions to be revalidated which are sent by the Selection of Instructions to be
Revalidated function.
Checks Flow Control
Both the validations of settlement instructions and maintenance instructions follow a pre-defined order to
ensure that all possible errors are detected. This sub-function performs the following tasks:
•
It ensures that instructions (either settlement or maintenance) are routed to the appropriate
sub-functions of the Settlement Instruction Validation function or of the Maintenance
Instruction Validation function, by determining according to the type of error identified
whether further logical validation checks can be performed or not. In case further logical
validation checks can be performed, the Check Flow Control sub-function sends the
instructions to the other relevant sub-functions of the Settlement Instruction Validation
function or of the Maintenance Instruction Validation function;
Final_T2S_GFS_110.doc
Page 211
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
It ensures that after all validations are performed those instructions with the pre-check
amendment flag on, are sent back to the Maintenance Instruction Validation function, with
their respective positive / negative validation results.
•
It also ensures that the relevant validations are performed on those settlement instructions
affected by a Static Data update;
•
It stores the nature and the outcome of the different validations sent by the relevant subfunctions on an instruction;
•
It reports all errors registered and sends them to the Validation Status Management function.
Only after having performed all logically possible validations, if there are errors, the
instruction is rejected {T2S.05.020}.
•
When the Settlement Instruction Validation function and the Maintenance Instruction
function communicates the result to the Validation Flow Management function, the following
differentiation is considered according to instructions for which:
-
an error has been identified;
-
no error has been identified;
-
no further logical checking can be performed.
Splitting Flow control
Once the two-legged instructions, matched instructions and block-trade instructions {T2S.05.183} have
passed successfully all the relevant validation steps performed by the Settlement Instruction Validation
function and have been sent back to the Validation Flow Management function, the Splitting Flow control
sub-function forwards them to the Instruction Management function for their splitting.
3 –Settlement Instruction Validation
All settlement instructions are routed from the Validation Flow Management function, with the purpose of
passing a completed validation checking. The result of the process is communicated again to the
Validation Flow Management function with the related reason code registered, if it is the case.
This function encompasses the following sub-functions:
•
Consistency Validation
•
Processing Attributes Analysis
•
Matching Status Assignment
•
Validations According to the Processing Attributes
Final_T2S_GFS_110.doc
Page 212
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Consistency validation
This sub-function has two purposes:
•
Checking whether the relevant information available in the instruction enables the system to
perform a processing attribute analysis {T2S.05.010}.
•
Checking the set of harmonised mandatory fields in the instruction. This means checking the
existence of the following fields depending on the instruction type {T2S.05.035}.
DVP/DWP/RVP/RWP
FOP
DVD
Intended settlement date
Trade date
Currency
Cash amount
Share quantity (for equities) or nominal amount (for fixed income securities)
Final_T2S_GFS_110.doc
To deliver: share quantity (for
equities) or nominal amount (for
fixed income securities)
Page 213
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
DVP/DWP/RVP/RWP
FOP
DVD
To receive: share quantity (for
equities) or nominal amount (for
fixed income securities)
Buy/sell
Deliver/Receiver
ISIN code
ISIN code to deliver
ISIN code to Receive
BIC code of the counterparty who delivers the securities
BIC code of the counterparty who receives the securities.
CSD of the counterpart37
Deliverer’s securities account (to be included by the delivering party)
Receiver's securities account (to be included only by the receiving party)
Processing Attributes Analysis
This sub-function performs, for each settlement instruction, an analysis of the criteria as they are
described in the non-exhaustive table shown below.
In case the specific values for the set of criteria cannot be taken from the information included in the
settlement instruction, they are taken from Static Data. All these values are attached to the settlement
instruction for the processing across the different modules in T2S.
The processing attributes are needed in order to:
•
Determine which processes an individual settlement instruction should go through ( i.e.
Instruction type: Reservation, in this case the individual settlement instruction has the
Matching status “matching not required” and matching processes are not performed).
•
Determine the criteria to be applied in the different rules followed when executing a
function/process. (i.e. Instruction Type FOP: Currency field is not checked in the validation
process).
After deriving all the missing values from the settlement instruction’s information and/or Static Data if
needed, this sub-function:
•
Checks if the value attributed to each criteria is consistent;
•
Determines the value of processing attributes for the settlement instruction according to the
combination of all criteria and values.
37
After further investigation, this field could be removed as a mandatory matching field
Final_T2S_GFS_110.doc
Page 214
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
The outcome of these checks (positive or negative) and the reason codes associated are communicated to
the Validation Flow Management function.
CRITERIA
POSSIBLE VALUES
Groups of instructions
Standard, already matched, two-legged, block trade
Instruction type
DVP, DWP, FOP, DVD, PFOD, Block, Reservation,
Earmarking, Segregation
Instructing party type
CSD, DCP (Direct Connected Participant), CCP, Stock
Exchange, Trading platform, NCB
Cross-CSD
Intra-CSD, cross-CSD, in/out T2S, in/out T2S
conditional
CoSD
Yes, No (1)
Currency
T2S recognised, T2S Settlement
Linked instruction
Yes, No
Partial settlement allowed
Yes, No
Auto-collateralisation
Yes, No
Reservation Flag
Yes, No
ISO Transaction Code
REPU/RVPO, BSBO/BSBC, etc.
To identify CoSD criteria, the following parameters are to be taken into account: ISIN, Settlement
Currency, CSD, Securities Account, Country of Issuance, Place of Settlement, Transaction Type, Issuer
CSD Location, Deliverer Location and Receiver Location {T2S.11.740}.
The combination of the values of the above mentioned criteria determines the processing characteristics
of the validation process.
Matching Status Assignment:
This function is responsible of identifying and assigning one of the following Matching status values:
•
Matching not required:
This Matching status value is set if the ISO Transaction code of the individual settlement
instructions indicates that it refers to a corporate action, or if the individual settlement
instruction type refers to a settlement restriction.
It is also set when the process checks that Instruction type is FoP and a movement is
requested between securities accounts of the same T2S party within the same CSD specified
via the static data. Apart from this specificity, FoP instructions between securities accounts
belonging to the same T2S party within the same CSD are validated as any other FoP
instruction.
Final_T2S_GFS_110.doc
Page 215
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
Already matched:
Whenever the instruction is already matched outside T2S identified if the instruction has a
common reference specified. (CSD, monetary policy operations…)
•
Ready to be matched:
In case none of the above mentioned occurs.
Validations According to the Process Attributes Analysis
This sub-function checks for each settlement instruction the validity of its fields according to a pre-defined
logical order. This pre-defined order depends on the processing attributes and will have to be determined
in the detailed functional specification phase.
The following paragraphs identify a non exhaustive list of validations to be performed.
Non-exhaustive list of validations to be performed:
ISIN Code Validation
•
The ISIN code(s) exists in T2S Static Data and that it is eligible for settlement in the
corresponding CSD for the intended settlement date. Nevertheless, CSDs can send
instructions for non-settlement eligible ISIN(s) as long as they are still active (not logically
deleted) {T2S.05.080}.
Intended Settlement Date Validation
•
The intended settlement date is a T2S settlement day for the settlement currency as defined
in T2S Static Data {T2S.05.120}.
•
The trade date is equal to or earlier than the intended settlement day {T2S.05.110}.
•
In case of securities traded on grey markets, the intended settlement date is equal to or later
than the intended issuing date. For technical house-keeping instructions of the issuer CSD
(e.g. to prepare the issuance), this check does not apply {T2S.05.150}.
•
The Intended Settlement Date is valid for the ISIN code(s) in the instruction.
Amount Validation
•
The minimum settlement unit or nominal for each ISIN code is as defined in T2S Static Data.
•
It also checks against the multiple or deviating settlement unit or nominal. This check is not
performed on instructions related to corporate events {T2S.05.090} {T2S.05.100}.
•
In case a block trade instruction is identified, it is checked that the amounts (quantity of
securities and amount of money) correspond with the sum of the counterparty individual
settlement instructions that make up the total of the block-trade instruction {T2S.05.183}.
Final_T2S_GFS_110.doc
Page 216
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
T2S Dedicated Cash Account Validation
•
This check is performed on the authorisations related to the T2S dedicated cash accounts for
cash settlements in T2S as defined in T2S Static Data.
•
In case of securities related settlement, it checks that the T2S dedicated cash account for the
cash leg of the securities settlement has a link with the securities account or with T2S Actor,
holding the securities account {T2S.05.060}.38
•
Counterparties’ T2S dedicated cash accounts are both defined in the same currency.
•
The currency of the cash leg is the same as the currency of the T2S dedicated cash accounts.
•
If the owner of the T2S dedicated cash account is not the instructing party, it checks that it is
authorised to send instructions on behalf of the account owner as defined in T2S Static Data
and has a link with the securities account {T2S.05.040} {T2S.05.060}.
•
It is checked that the T2S dedicated cash account is present in the instruction. In case a T2S
dedicated cash account is included in the instruction, it prevails over the default choice. If
there is no T2S dedicated cash account included in the instruction, it is considered the
default cash account specified by the T2S Actor in static data {T2S.05.400}. If not
possible, the instruction will be rejected. {T2S.05.060}.
•
If the settlement instruction is identified as a corporate action instruction (though ISO
transaction code) and the owner of the T2S dedicated cash account where the cash proceeds
are going to be credited has opted for an automatic retransfer to the RTGS system, the CARL
flag in the individual settlement instruction is set to “YES”. {T2S.16.660}
Linked Instruction Validation
•
When a settlement instruction with a settlement-related link indicator is received, this
process searches in the system for the linked instruction. In case this linked instruction is
found it checks if the links included in both instructions are coherent. It is also checked that
the intended settlement date of the latter is consistent with the links included.
{T2S.05.148}
•
When a settlement instruction with a settlement-related link indicator is received, this
process searches in the system for the linked instruction. In case this linked instruction is
found, it is checked if the newly processed linked instruction credits or debits the same
securities account than the instruction it is linked to.
38 These first two checks are not relevant when the T2S dedicated cash account field is enriched by T2S on the basis of the information available in
the instruction (i.e. securities account) and information available in Static data (i.e. cash account linked to the securities account referred to in the
instruction).
Final_T2S_GFS_110.doc
Page 217
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
Checks that the value of the Linked Instruction counter attribute is consistent with the
number of linked references included in the instruction.
•
Whenever a settlement instruction is related to a pool reference it is checked that this pool
reference is correct {T2S.14.310}.
•
Settlement Restriction Validation
•
Whenever an instruction is referring to a settlement restriction previously sent, it is checked
that initial settlement restriction is still active (i.e. the restriction is still in place)
{T2S.05.148}.
Securities Account Validation
•
Checks that the T2S Actor involved has the securities account in the corresponding CSD in
T2S.
•
The party is authorised to use the Securities Account as defined in T2S Static Data
{T2S.05.050}.
•
If the owner of the securities account is not the instructing party, it checks that it is
authorised to send instructions on behalf of the account owner as defined in T2S Static Data
{T2S.05.040}.
•
Validates that the instructing party is allowed to send an already matched instruction or a
matching not required instruction for the counterparty accounts included in the settlement
instruction
Instructing Party Validation
•
Identifies the instructing party of the settlement instruction to verify if it is authorised to send
the instruction according to the instruction types and transaction codes defined in Static Data
{T2S.11.750}.
•
Validates the deviating instructing party, if it is the case, to check that the respective power
of attorney is stored in Static Data {T2S.16.670}.
Process Indicator Validation
•
The settlement process indicators are valid considering the type of instruction and the
instructing party, as defined in T2S Static Data. {T2S.05.140}.
•
Only CSD and central banks can assign a “reserved priority” for specific instructions.
{T2S.07.160}.
Final_T2S_GFS_110.doc
Page 218
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Currency validation
•
The currency of the cash leg of an instruction is either a T2S settlement currency or a T2S
recognised currency as defined in T2S Static Data {T2S.02.050}. This validation is not
performed for FOP instructions.
•
The currency of the cash leg of an instruction has to be the same as the currency of the cash
account {T2S.05.070}
Cross-CSD Rules Validation
For instructions involving participants of more than one CSD, the function checks that the corresponding
CSD links are set to active.
Specific validations apply to the two following types of cross-CSD instructions:
•
Cross-CSD Settlement (when all the involved CSDs are in T2S): Specific validations require
validating the settlement instructions to be in accordance with the specific links agreed
between CSDs. These validations require checking the compliance with authorised instruction
types, CSD participants and ISIN codes.
•
External-CSD Settlement (when External CSDs are involved): In the case of instructions
involving at least one external CSD, information regarding the CSD participants of the CSD
outside T2S is not checked although instructions contain such information. In case the Issuer
CSD for the ISIN code included in the instruction is an external CSD, it will be checked the
CSD responsible for the ISIN code. {T2S.05.160}.
Specific validations, depending on the relations between the involved CSDs and the Issuer CSD, are
performed.
Standard DVP Instruction Validation
•
The cash amount contains a value (this value can be zero).
•
The currency is a recognised settlement currency.
Regulatory/Supervisory Requirements Validation
•
Validations required by authorities (i.e. for anti-money laundering, anti terrorist financing,
etc.), in accordance with T2S Principle 5. {T2S.05.260}.
These validations shall be defined in a later stage.
CSD Rules Validation
Validates the instruction against the whole set of rules defined in T2S for the involved CSD.
Final_T2S_GFS_110.doc
Page 219
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
The list of validations to be performed is not already defined and therefore cannot be covered in this
document. It will be defined during the detailed functional specification phase.
Common Reference Validation
•
Checks how many instructions are in the system with the same matching reference received
from the same counterparty.
•
If there is already one instruction from the same counterparty with this matching reference,
the incoming instruction is rejected.
Two-legged Instruction Validation
For two-legged instructions:
•
Checks that the intended settlement date of the redemption is latter than the intended
settlement date of the inception.
•
Checks that the intended settlement date of the redemption is also valid for the ISIN(s)
code(s) included in the instruction.
4 – Maintenance Instruction Validation
This function performs all the validations on maintenance instructions, implemented through the following
entities:
•
Settlement Related Instruction entity
•
Actions entity of the type maintenance instruction
•
Action Parameter entity
The Maintenance Instruction Validation function follows the next steps:
•
General Maintenance Instruction validation: Common validation to maintenance instructions.
•
Validation defined for the maintenance instructions type amendment.
Final_T2S_GFS_110.doc
Page 220
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
At the end of each validation performed by the sub-functions, the outcome is communicated to the
Validation Flow Management function.
General Maintenance Instruction Validation
This sub-function performs general validations for maintenance instructions. The following checks are
applied:
Referred Instruction Check
•
Checks that the related reference is present in the message {T2S.05.210}.
•
Checks that the individual settlement instruction with that reference exists {T2S.05.210}.
•
Checks that the maintenance instruction is valid and consistent with the previous instruction
{T2S.05.210}.
Instructing Party Check
•
All the checks below have the aim to identify the instructing party of any maintenance
instruction and verify if it is authorised to hold, release, cancel or amend the instruction
{T2S.05.220}.
•
Checks that CCPs, Stock Exchanges and Trading platforms are allowed to hold, release,
amend and cancel instructions generated by them for their participants, provided that they
have a power of attorney from their participants {T2S.05.310}.
Final_T2S_GFS_110.doc
Page 221
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
Checks that CSD participants are not allowed to hold, release, amend or cancel CSD
settlement instructions identified by CSDs as non-modifiable by their participants (i.e. checks
if there is a flag which enables the participant to modify the instruction sent by the CSD)
{T2S.05.300}.
•
Checks that CSD participants are not allowed to hold, release, amend or cancel instructions
generated by CCPs {T2S.05.300}.
•
Checks that CSD participants are not allowed amending or cancelling instructions generated
by stock exchanges or trading platforms {T2S.05.300}.
Amendment Instruction Validation
In case a maintenance instruction was sent by a CSD participant to deactivate the partial settlement
indicator, this process checks that the indicator was not defined by CSDs, CCPs or Stock Exchange under
their power of attorney.
T2S parties are allowed to opt in and out of partial settlement freely during the day until each settlement
attempt. When a CCP or a CSD opts for partial settlement of all its instructions, this sub-function checks
that any modification of the partial settlement indicator sent by other T2S parties involved in the
settlement of the relevant instruction does not modify the CCP or CSD choice recorded in static data
{T2S.05.141} {T2S.08.270}.
This function performs several procedures to validate the amendment to avoid that once the amendment
instruction is executed, the affected individual settlement instruction is not valid anymore, and is to be
rejected from the system.
For this purpose the function takes the data of the affected individual settlement instruction such as it
would be once the amendment instruction is executed, assigning a Pre-check Amendment flag to this
instruction. This instruction is forwarded to the Validation Flow Management function, with the purpose of
going through all the validation procedures. The flag previously assigned is recognised and the result is
sent back to the Maintenance Instruction Validation function. We can have the following two scenarios:
•
When the check has been positive; the validation result of the amendment instruction is
positive and it is forwarded to the Validation Flow Management function so it continues to be
processed.
•
When the check has been negative; the validation result of the amendment instruction is
negative and it is forwarded to the Validation Flow Management function with the
corresponding reason code(s).
The flagged settlement instruction for pre-check purposes can not continue to be processed because its
functionality has finished once the check result of the amendment instruction has been sent to the
Validation Flow Management function.
Final_T2S_GFS_110.doc
Page 222
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
5 – Instruction Management
This function has two roles:
•
Splitting “groups of instructions”:
-
Already matched instructions entered as a single instruction containing both legs of the
two counterparties. The Instructions Management module creates two separate
instructions with the same unique T2S common reference (matching reference)
{T2S.05.170};
-
Two legged instructions;
-
Block-trade instructions {T2S.05.183}.
This kind of instructions is received from the Splitting Flow Control sub-function in the
Validation Flow Management function once they have passed the settlement instruction
validation. In case the split settlement instruction is a two-legged instruction, once they are
split, the link types “Starting leg” or “Closing leg” are identified and assigned accordingly.
When both legs have the same Intended Settlement date, the “second leg” Hold/Release
status is set to “on hold” and an occurrence is stored in the Hold/Release Party entity linked
to the relevant instructing party {T2S.05.190}.
•
Generation of a settlement instruction for the remaining amount to settle after the partial
settlement of an instruction, all other fields equal. This settlement instruction is assigned a
new T2S reference, including also the initial instruction reference given by the T2S Actor
{T2S.08.240}. In case the partially settled instruction was a linked instruction by T2S
Actors, all the unsettled legs of the linked instructions are linked {T2S.08.420}.
The Eligibility status value of these individual settlement instructions is set to “<empty>” and
they are routed to the Validation Status Management function.
6 – Selection of Instruction to be revalidated
After a Static Data change, this function is responsible for the selection of individual settlement
instructions already validated.
The Static Data Management domain informs the Validation Module about the different updates in static
data for being able to identify and revalidate the affected instructions.
This function selects the individual settlement instructions to be revalidated in the following two cases:
•
Intraday Settlement-related static data change:
In this case the function selects those instructions affected by static data changes.
Final_T2S_GFS_110.doc
Page 223
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
All individual settlement instructions are selected, except those with the Settlement status
“settled” or “partially settled”, or with the Cancellation status “cancelled”.
In case of individual settlement instructions with Eligibility status “eligible” or with Settlement
status “unsettled”, the Process Settlement Status function in the Instruction Maintenance
module is notified to ask the Settlement domain to cancel the relevant transaction. These
instructions will not be routed for revalidation until a positive answer is received from Process
Settlement Status function
In case of instructions that have entered T2S with their Matching status “already matched”,
the revalidation is always done on both individual settlement instructions.
•
Start of Day (SoD) Process:
This function selects all the individual settlement instructions during de Start of Day (SoD)
Process, which Settlement status is not “settled” or “partially settled” or those which
Cancellation status is different from “cancelled”. The Eligibility status of all these individual
settlement instructions is set to “<empty>”.
These instructions are forwarded to Validation Flow Management to be revalidated against
the new data.
7 – Validation Status Management
This function gathers the information sent by the Validation Flow Management function in order to identify
the validation processes already achieved by each instruction according to their processing attributes. It
assigns a new status to the instruction taking into consideration the result of each validation process.
Also this function is responsible for the creation of individual settlement instructions, once the action
related to a settlement instruction is accepted in several cases, apart from maintenance instructions.
Validation Status Identification
This sub-function identifies the validation processes achieved by each instruction in order to assign the
status after validation.
Instruction Status Allocation
This sub-function assigns to each implemented action and/or individual settlement instruction one of the
following validation status {T2S.05.270}.
•
Action status gets the value “accepted” or “rejected” {T2S.05.240}.
•
Individual settlement instructions get the Validation status “accepted” or the Cancellation
status “cancelled” with the reason code “Cancelled due to Static Data change” associated,
after an unsuccessful revalidation process triggered by a Static Data update.
Final_T2S_GFS_110.doc
Page 224
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
The result of the validation process is reported to the Status Management module. In case an instruction
is rejected, the reason is included {T2S.05.250}.
In case of maintenance instructions with the implemented Action status “accepted”, the relevant data for
reporting purposes is not forwarded yet to the Status Management module. The Instruction Maintenance
module is informed on the result of the validation of the maintenance instruction if it is accepted.
Once the Action and the Settlement Related Instruction entity referring to a new settlement instruction
have successfully passed all validations, the Action status is set to “accepted”, an individual settlement
instruction is created with the validation status set to “accepted”, then the individual settlement
instruction continues the whole process of settlement.
The update in the Action status value is forwarded to Status Management module. All maintenance
instructions with the Action status value equal to “accepted” are forwarded to the Instructions
Maintenance module.
For this purpose the existing attributes of the action and settlement instruction will be recorded in the
following entities:
•
Individual Settlement Instruction
•
Hold/Release Party
•
CoSD Administering Party
•
ISI status
•
ISI link set
•
ISI link
•
Half cash Movement
•
Half securities Movement
•
In case a settlement instruction has been sent “on hold” by the instructing party
Hold/Release status is set to “on hold” and an occurrence is stored in the Hold/Release Party
entity linked to the relevant instructing party.
This process assigns a unique reference to the Individual Settlement Instruction recorded; assuring that it
will not be the same as the reference sent by Instructing Party.
8 – Routing
This function receives as input accepted instructions that have already successfully achieved all the above
mentioned checks, and routes them to one of the modules mentioned below, according to their
processing attributes:
Final_T2S_GFS_110.doc
Page 225
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
Settlement instructions with Matching status value “ready to be matched” or “unmatched”
are routed to the Instruction Matching module.
•
Settlement instructions with Matching status value “already matched” or “matching not
required” are routed to the Settlement Eligibility module.
•
Maintenance instructions are routed to the Instruction Maintenance module.
3.4.5.4. Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Incoming
(Settlement /
Maintenance)
Instruction
IN
Flow Management
Static Data
Maintenance
Notifications
IN
Static Data Modules
(SDMG)
Time Event
IN
Scheduler
Partially settled
instruction info
IN
Generation of a settlement Status Management
instruction for the
remaining amount
Answer
IN
When positive answer is
received, ISI is routed for
revalidation
Request
OUT
ISI with Eligibility status
“eligible” or with
Settlement status
“unsettled” that needs to
be revalidated
Instruction Maintenance
Instruction
Status
Information
OUT
Update of the individual
settlement instruction
status value. Includes
reason code.
Status Management
Maintenance
Instruction
Status
Information
OUT
Update of the
maintenance instruction
status value. Includes
reason code.
Status Management
Individual
settlement
instructions
<already
matched /
matching not
required>
OUT
Final_T2S_GFS_110.doc
Instruction Maintenance
Settlement Eligibility
Page 226
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Individual
Settlement
Instruction
<ready to be
matched>
<accepted>
<on Hold /
Released>
<none
cancellation
requested>
OUT
Instruction Matching
Maintenance
instruction
<Accepted>
OUT
Instruction Maintenance
3.4.5.5. Data accessed by the module
DATA
ACCESS MODE
STATUS
COMMENTS
STATIC DATA
Allowed Instruction
Party
Read
Allowed Instruction
Profile
Read
T2S Dedicated Cash
Account
Read
Conditional Securities
Delivery Rule
Read
Closing day
Read
CSD Account Link
Read
Currency
Read
Deviating Instructing
Account
Read
Deviating Instructing
Party
Read
Deviating Security
Nominal
Read
Error Code
Read
Market-Specific
Restriction Type
Read
Matching Fields
Read
On-Behalf Authorised
Party
Read
Final_T2S_GFS_110.doc
Page 227
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
DATA
ACCESS MODE
Party
Read
Party CALS
Read
Party Code
Read
Party Restriction
Read
Securities Account
Read
Securities Account
Restriction
Read
Security
Read
Security Code
Read
Security CSD Link
Read
System Entity
Read
Tolerance Amount
Read
STATUS
COMMENTS
DYNAMIC DATA
Action
Create
Action type
Status
Action Parameter
Create
Parameter name
Parameter value
Final_T2S_GFS_110.doc
Page 228
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
DATA
Individual Settlement
Instruction
ACCESS MODE
Create
STATUS
COMMENTS
Individual Instruction Type
Instructing Party
Trade Date
Intended Settlement Date
ISO Transaction Code
First Party CSD
Final Party CSD
Final Beneficiary
Auto-Collateralisation Flag
Linked Instructions Counter
Partial Indicator
Partial Settlement Indicator
Partial Flag
Priority
T2S First Party
T2S Final Party
CosD flag
CARL flag
Common Reference
Allowed Modification Flag
Repo Reference
Reservation Flag
Pre-check Amendment Flag
Half Cash movement
Create
Operation
Original Amount
Matched Amount
Settled Amount
Settlement Date/Time
Default account
Half Security
movement
Create
Operation
Original Quantity
Settled Quantity
Settlement Date/Time
Final_T2S_GFS_110.doc
Page 229
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
DATA
ACCESS MODE
STATUS
COMMENTS
Individual Settlement
Instruction Status
Create
Name
Hold/Release Party
Create
Command
Reason codes
Create
Reason code reference
Action error
Create
Error code
CoSD Administering
Party
Create
Command
Individual Settlement
Instruction Link
Create
Link Type
Individual Settlement
Instruction Link Set
Create
Settlement Related
Instruction
Create
Value
3.4.6. Maintenance Instruction (MI) Use Case
Scope
This category of use cases includes all T2S instructions that aim to amend, cancel, hold or release
Settlement Instructions (SI).
Criteria
The criteria comprise all the external parameters defining the maintenance instructions that influence the
processing of these instructions in the LCMM and the Settlement domains. These criteria are summarized
in the table below:
Criteria
possible values
Comment
Access Type
U2A, A2A
Access to functionality starts from
User or from Application
Maintenance Instruction
type
Amend, Hold, Release, Cancel
Fields to be amended39
Non applicable, Matching fields, Non Matching
Fields/Process Indicators
Group of instructions
Standard, block trade, two-legged
39
Derives from parameters in Static
Data and parameter attached to
the instruction
In case of Hold, Release or Cancel instruction, the specific value to be assigned for the criteria “fields to be amended” is “non applicable”
Final_T2S_GFS_110.doc
Page 230
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Criteria
possible values
Comment
Access Type
U2A, A2A
Access to functionality starts from
User or from Application
Status of the original
settlement instruction
Accepted, rejected, matched, unmatched,
cancelled, eligible, ineligible, empty, settled,
unsettled, partially settled, CoSD hold..
Business status is, at a certain
point in time, a combination of
different attributes of the Status
List of Use Cases
The criteria described above are reported in the following tree:
A2A
U2A
All the combinations of values are not relevant from a business point of view: the complete list of use
cases is presented in appendix.
Final_T2S_GFS_110.doc
Page 231
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.7. Processing of Maintenance Instructions Use Cases
3.4.7.1. Selection of representative Maintenance Instructions Use Cases
The following representative use cases are described:
•
UC-MI-1: Amend Maintenance Instruction;
•
UC-MI-2: Hold / Release Maintenance Instructions;
•
UC-MI-3: Cancellation Maintenance Instruction;
•
UC-MI-4: Maintenance of two legged instructions and block-trade instructions.
3.4.7.2. Processing of UC-MI-1: Amend Maintenance Instruction
Amend Maintenance Instruction
Interface
T2 S
Actor
T2S
Actor A
Communication
C1
LCMM:
Instruction
Validation
LCMM:
Instruction
Maintenance
Incoming
Instruction I1
LCMM:
Instruction
Matching
LCMM:
Status
Management
LCMM:
Settlement
Eligibility
SETT: SPS
M1 “accepted”
M1 “accepted”
T2S
Actor A
“accepted”
message M1
Data for “accepted” message M1
Request for cancellation T1
Alt 1
Positive answer from SPS
T1 positive answer (associated transaction T1 cancelled)
M1 “executed”
I1 Eligibility status “ empty”
I1
T2S
Actor A
Alt 2
“executed” message M1
Data for “executed“ message M1
Negative answer from SPS
T1 negative answer (associated transaction T1 not cancelled)
M1 “cancelled”
T2S
Actor A
“cancelled” message M1
Final_T2S_GFS_110.doc
Data for “cancelled” message M1
Page 232
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Business assumption
•
This description relates to a maintenance instruction M1, which amends a previously sent
individual settlement instruction I1.
•
T2S Actor A sends communication C1.
•
The amendment refers to a matching field.
•
The settlement transaction T1 associated to the individual settlement instruction I1 has
already been created.
•
The Eligibility status value of the Individual settlement instruction I1 is “eligible”, the
Matching status value is “matching not required”, “ready to be matched” or “unmatched”, the
Settlement status is not “settled” or “partially settled” and the Cancellation status is not
“cancelled”.
Processing
Once the format and syntax validations are successfully passed, the incoming instruction I1 enters the
Instruction Validation module which validates M1, according to the Processing Attribute Analysis. When
the maintenance instruction is accepted, the Status Management module is informed on the status of the
M1 to be reported to T2S Actor A, through Interface, depending on its message subscription preferences.
Once all validation procedures have been successfully passed, the maintenance instruction is routed to the
Instruction Maintenance module.
First, the Instruction Maintenance module checks the status values of the affected individual settlement
instruction I1, in order to verify if the amendment instruction can be executed or not:
•
As I1 Matching status value is “matching not required”, “ready to be matched” or
“unmatched”, the amendment can be processed;
•
As I1 Eligibility status value is “eligible”, the Instruction Amendment function sends a request
for cancellation of the settlement transaction T1 associated with the individual settlement
instruction to the Process Settlement Status function, in order to process the amendment.
Alternative 1: Positive answer from the Standardisation and Preparation to Settlement module
•
The amendment maintenance instruction M1 status is set to “executed”;
•
The affected individual settlement instruction I1 is modified and its Eligibility status is set to
”empty”, in order to allow the Settlement Eligibility module checking the eligibility criteria and
being aware of the need of creating a new settlement transaction(s);
Final_T2S_GFS_110.doc
Page 233
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
The Status Management module collects the relevant data and forwards it to Interface, so
T2S Actor A is informed about the execution of M1, depending on its message subscription
preferences.
Alternative 2: Negative answer from the Standardisation and Preparation to Settlement module
•
The amendment maintenance instruction status M1 is set to “cancelled”, and the reason code
for the cancellation is “affected ISI already settled”;
•
The affected individual settlement instruction I1 is not amended;
•
The Status Management is informed about the cancellation of M1. Also, the Status
Management collects data and forwards it to Interface, so T2S Actor A is informed about the
cancellation of M1, depending on its message subscription preferences.
Final_T2S_GFS_110.doc
Page 234
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.7.3. Processing of UC-MI-2: Hold / Release Maintenance Instructions
a) Hold Maintenance Instruction from a T2S Actor
Business assumption
•
This description relates to a hold maintenance instruction sent by a T2S Actor A, which
relates to a previously sent individual settlement instruction.
•
T2S Actor A sends a hold maintenance instruction M1 to hold the individual settlement
instruction I1. T2S Actor B is the counterparty to I1.
Final_T2S_GFS_110.doc
Page 235
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
Depending on the Settlement status of the affected individual settlement instruction I1, the
hold maintenance instruction M1 can be either executed or cancelled in the Instruction
Maintenance module.
Processing
Once the format and syntax validations are successfully passed, the maintenance instruction M1 enters
the Instruction Validation module which validates M1, according to the Processing Attribute Analysis.
When the maintenance instruction gets the status “accepted”, the Status Management module is informed
on the status of M1 to be reported to the relevant parties according to their message subscription
preferences.
The Instruction Maintenance module checks the different status of the affected individual settlement
instruction I1 in order to verify if the hold maintenance instruction can be executed or not.
Alternative 1: I1 Eligibility status values are « empty » or « ineligible»
•
The Hold/Release status of the individual settlement instruction is updated and set to “on
hold”;
•
In addition, Hold/Release Mechanism function sets the status of the hold maintenance
instruction to “executed”;
•
T2S Actor A is informed not only about the execution of the hold amendment on the I1 but
also, about the update on Hold/Release Status of the individual settlement instruction;
•
Finally, the maintenance allegement function collects the relevant data, so Interface can send
an allegement message to the counterparty to inform that the individual settlement
instruction I1 is “on hold”.
Alternative 2:I1 Eligibility status value is «eligible»
Then, the Hold/Release Mechanism sends a request to Actions on the Transactions and Limits function (in
SPS module) to cancel any settlement transaction (i.e. T1) related to the individual settlement instruction
I1. If one of the related settlement transaction status value is “settlement in process”, the requested
cancellation is rejected; otherwise it is accepted.
Alternative 2.1: Positive answer from the SPS module
•
The hold maintenance instruction M1 status is set to “executed” and I1 is updated and set to
“on hold”;
•
Then, the Hold/Release status value of the individual settlement instruction is set to “on
hold”;
•
T2S Actor A is informed about the execution of M1 and on the relevant status;
Final_T2S_GFS_110.doc
Page 236
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
The Instruction Maintenance module collects the relevant data and sends the maintenance
allegement, through Interface, to the counterparty T2S Actor B, informing that the
Hold/Release status value of the I1 is “on hold”.
Alternative 2.2: Negative answer from the SPS module
•
The hold maintenance instruction M1 status is set to “Cancelled”.
•
T2S Actor A is informed about the cancellation of the maintenance instruction.
b) Release Maintenance Instruction from a T2S Actor
Business assumption
•
This description relates to a release maintenance instruction M2 sent by a T2S Actor A, to
release the individual settlement instruction I1. T2S Actor B is the counterparty to I1.
•
Depending on the Settlement status of the related individual settlement instruction I1, the
release maintenance instruction M2 can be either executed or cancelled in the Instruction
Maintenance module.
Processing
Once the format and syntax validations are successfully passed, the maintenance instruction M2 enters
the Instruction Validation module. This module validates M2, according to the Processing Attribute
Analysis, getting the status value “accepted”, which is communicated to the Status Management module,
Final_T2S_GFS_110.doc
Page 237
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
so T2S Actor A can be informed of the status of the maintenance instruction through Interface, depending
on its message subscription preferences.
The Instruction Maintenance module checks the different status of the affected individual settlement
instruction I1 in order to verify if the release maintenance instruction can be executed or not. The
Eligibility status value of the I1 has to be « empty », or « ineligible ». Then:
•
The Hold/Release Mechanism function sets the release maintenance instruction to “executed”
status and the release individual settlement instruction is updated;
•
Then, the Hold/Release status of the individual settlement instruction I1 is set to “released”;
•
T2S Actor A is informed about the execution of M2, and the Hold / Release status update of
the related individual settlement instruction I1.
•
The Hold/Release Mechanism function collects the relevant data, so Interface can send an
allegement message to the counterparty of the individual settlement instruction I1 (T2S Actor
B), informing that the Hold/Release status of I1 is set to “released”;
•
Once the individual settlement instruction I1, has been released, it is sent to Settlement
Eligibility module, which checks whether it is eligible or not and follows the standard
settlement process.
Final_T2S_GFS_110.doc
Page 238
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.7.4. Processing of UC-MI-3: Cancellation Maintenance Instruction
Cancellation Maintenance Instruction
Interface
T2 S
Actor
Communication C1
T2S
Actor A
LCMM:
Instruction
Validation
Incoming
Instruction I1
LCMM:
Instruction
Maintenance
LCMM:
Status
Management
“accepted” M1
“accepted” M1
“accepted” status
M1
T2S
Actor A
Alt 1
Data for “accepted” status message M1
Affected individual settlement instruction Matching status different from
“matched” or “already matched”
M1 “executed”
I1 “cancelled”
Data for “executed” message M1
T2S
Actor A
“executed” message M1
“cancelled” message I1
Alt 2
Alt 2.1
Data for “cancelled” message I1
Affected individual settlement instruction Matching status “matched” or
“already matched”
The counterparty’s cancellation maintenance instruction (M2) has already
been received in T2S
M1 “executed”
T2S
Actor A “executed” message M1
Data for “executed” message M1
I1&I2 “cancelled”
T2S
Actor B
T2S
Actor A
Alt 2.2
Settlement status
“cancelled” I1
Data for Settlement status
message “cancelled” I1&I2
Settlement status
“cancelled” I2
The counterparty’s cancellation maintenance instruction (M2) has not been received
in T2S yet
M1 “executed”
I1 “cancellation
requested”
T2S
“executed” message M1
Actor A
Cancellation
T2S
allegement message
Actor B
Final_T2S_GFS_110.doc
Data for “executed” message M1
Cancellation allegement Data
Page 239
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Business assumption
•
This description relates to a cancellation maintenance instruction M1, initially communication
C1 sent by a T2S Actor A, to cancel the individual settlement instruction I1.
•
In this description the corresponding affected settlement transaction has not yet been
created. (Eligibility Status of I1 is “empty”).
Processing
Once the format and syntax validation are successfully passed, the Instruction Validation module validates
I1, according to the Processing Attribute Analysis. When the maintenance instruction is accepted, the
Status Management module is informed on the status of M1, which is reported to T2S Actor A through
Interface, depending on its message subscription preferences.
Once the validation procedures have successfully been passed, the cancellation maintenance instruction
M1 is routed to the Instruction Maintenance module for its processing. This module checks if the
individual settlement instruction I1 has already been matched (Matching status values: “matched” or
“already matched”), in order to follow consequently different cancellation processes.
As the corresponding settlement transaction related to the individual settlement instruction I1 has not yet
been created, the Eligibility status value of I1 is different from “eligible” and the Maintenance instruction
is ready for its processing.
The processing of the cancellation instruction can be one of the following:
Alternative 1: Matching status value equal to “unmatched”, “matching not required” or “ready to be
matched”:
•
The status value of the cancellation maintenance instruction M1 is set to “executed”.
•
The Cancellation status value of the individual settlement instruction I1 is set to “cancelled”.
•
T2S Actor A is informed about the execution of M1 and the cancellation of I1.
Alternative 2: Matching status value equal to “matched” or “already matched”:
In this case, when one cancellation instruction from each counterparty is required, the Instruction
Maintenance function verifies in the Instruction Maintenance module if the Cancellation status value of the
counterparty’s instructions I2 is “cancellation requested”.
Alternative 2.1: The counterparty’s cancellation maintenance instruction M2 has already been received in
T2S, and the Cancellation status of the instruction I2 is “cancellation requested”.
•
The Cancellation status of the individual settlement instructions I1 & I2 are set to
“cancelled”.
Final_T2S_GFS_110.doc
Page 240
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
The status of the cancellation maintenance instruction M1 is set to “executed”.
•
Both T2S Actors are informed accordingly.
Alternative 2.2: The counterparty’s cancellation instruction I2 has not been received in T2S yet, and the
Cancellation status of the instruction I2 is “no cancellation requested”
•
The status of the cancellation maintenance instruction is set to “executed”. Also the Status
Management module collects this data and forwards it to Interface in order to inform T2S
Actors accordingly.
•
The Cancellation status of the individual settlement instruction I1 is set to “cancellation
requested”.
•
A cancellation allegement message is sent to T2S Actor B.
3.4.7.5. Processing of UC-MI-4: Maintenance of two legged instructions and block-trade
instructions
Scenario a) Maintenance of two legged instructions
This use case relates the processing of a maintenance instruction on a two-legged instruction.
Final_T2S_GFS_110.doc
Page 241
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Business assumption
•
A T2S Actor A sends a communication C1 on a two-legged instruction I1 already sent to T2S.
•
I1 had already been split into two individual settlement instructions: I1A for the inception
and I1B for the redemption.
•
In this description, T2S Actor A provides the initial settlement instruction reference I1 of its
two-legged instruction.
•
The maintenance instruction M1 is split into two separate maintenance instructions and they
are processed independently following the settlement processes described in the relevant
Use Cases.
Processing
Once the formal and syntax validation are successfully passed, the incoming instruction I1 enters the
Instruction Validation module which:
•
Identifies I1 as a maintenance instruction M1 for a two-legged instruction.
•
Executes the different validation processes to M1, according to the Processing Attribute
Analysis.
•
M1 is accepted in the Instruction Validation module, and the Status Management module is
informed on the status of the maintenance instruction “accepted” to be reported to the
relevant parties, depending on their message subscription preferences.
•
Splits the maintenance instruction M1 into two separate maintenance instructions M1A and
M1B.
Once the validation procedures are successfully passed, maintenance instructions are routed to the
Instruction Maintenance module. This module checks the status on the original split settlement
instructions I1A & I1B. Maintenance instructions are only applicable to those split settlement instructions
that are not settled yet.
Final_T2S_GFS_110.doc
Page 242
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Scenario b) Maintenance of block-trade instructions
This use case relates to the processing of a maintenance instruction on a block-trade instruction
containing 1-to-many relationship.
Business assumption
•
A T2S Actor A sends a communication C1 on a block trade instruction (M1).
•
The maintenance instruction M1 is split into separate maintenance instructions and these
instructions are processed independently following the standard process according to the UCMI-1 (Amend maintenance instruction), UC-MI-2 (Hold/Release maintenance instruction) or
UC-MI-3 (Cancellation maintenance instruction).
Processing
Once the format and syntax validation are successfully passed, I1 enters the Instruction Validation module
which:
•
Identifies I1 as a block-trade maintenance instruction M1;
•
Executes the different validation processes to M1, according to the Processing Attribute
Analysis;
Final_T2S_GFS_110.doc
Page 243
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
M1 status value is set to “accepted” which is reported to the relevant parties, depending on
its message subscription preferences;
•
Splits the maintenance instructions M1 into “n” separate maintenance instructions (M1A,
M1B, ….., M1n).
Once the validation procedures are successfully passed, maintenance instructions are routed to the
Instruction Maintenance Module and follow the standard process for these instructions.
3.4.8. Instruction Maintenance
3.4.8.1. Diagram of the module
LCMM:Instruction
Validation
Maintenance Instruction
[Accepted]
Instruction Maintenance
Maintenance
Instruction Routing
Maintenance Instruction
[Amendment]
Maintenance Instruction
[Cancellation]
Maintenance Instruction
[Hold/Release]
Maintenance Instruction
[CoSD Release/Cancel]
Instruction
Amendment
Instruction
Cancellation
Hold/Release
Mechanism
CoSD Maintenance Instruction:
Release/Cancel
Request
(A)
LCMM: Instruction
Validation
Answer
(B)
Answer
Request
Answer
Request
Answer
Request
Answer
Request
Process
Settlement
Status
Request
(C)
SETT: SPS
Answer
(D)
Maintenance
Instruction
[Cancelled]
Amended ISI
[Unmatched]
[Accepted] [On
Hold/Released]
[None
Cancellation
Requested]
<<Data Store>>
[Static Data]
Maintenance
Instruction Status
Information /
ISI Amended
Maintenance
Instruction
Status
Information
Instruction
Status
Information
Maintenance
Instruction
Status
Information
Instruction
Status
Information
Maintenance
Instruction
Status Information
Instruction
Status
Information
ISI
[CoSD to be Cancelled]
[CoSD to be Released]
Maintenance Status
Management
Time Event
(EoD)
<<Data Store>>
[Individual
Settlement
Instruction]
Instruction Cancellation
by the System
<<Data Store>>
[Action]
Individual Settlement
Instruction
[Cancelled]
<<Data Store>>
[History Log]
Maintenance
Allegements
Allegement
Data
LCMM:Instruction
Matching
INTF:Flow
Management
Final_T2S_GFS_110.doc
Maintenance Instruction
Status Information /
Instruction Status
Information
ISI Amended /
Reason code
LCMM:Status Management
LCMM:Settlement Eligibility
Page 244
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.8.2. Description of the module
The Instruction Maintenance module processes accepted maintenance instructions, i.e. those instructions
sent by T2S Actors with the intent of changing previously existing individual settlement instructions.
Maintenance instructions can be classified in the following categories:
•
Amend: those intended to modify the business data an individual settlement instruction.
•
Cancel: those intended to cause the cancellation of an individual settlement instruction.
•
Hold / Release: those intended to hold or release individual settlement instructions.
•
CoSD Release/Cancel: those sent by the Administering Party in a CoSD individual settlement
instruction with the intention of cancelling or releasing it.
Maintenance instructions sent by T2S Actors to hold, release, amend or cancel individual settlement
instructions can be processed by the Instruction Maintenance module until the actual settlement of the
affected settlement instruction. {T2S.05.310}. If the affected individual settlement instruction has
already been settled at the time of processing, the maintenance instruction is not executed.
The inputs for this module are:
•
An accepted maintenance instruction coming from the Instruction Validation module,
associated to an action, understood as the command received by the counterparty to
perform a cancellation, amendment, hold or release, on the individual settlement instruction
(see also data status description) and affecting at least one individual settlement instruction.
•
The End-of-Day time event to trigger the cancellation of instructions by the system under the
conditions defined in Static Data.
The Instruction Maintenance Module is available at all times during the settlement day, except during the
maintenance window {T2S.03.210}. T2S Actors may send maintenance instructions for individual
settlement instructions, regardless of the matching location of these settlement instructions
{T2S.05.290}.
Any maintenance instruction can refer to its affected settlement instruction as follows:
•
For settlement instructions which validation results in a single individual settlement
instruction, the T2S Actor may provide in the maintenance instruction either the T2S
individual settlement instruction reference or the initial settlement instruction reference
originally assigned by the T2S Actor.
•
For two-legged instructions for which validation leads to a split into two individual settlement
instructions, the T2S Actor may provide in the maintenance instruction:
Final_T2S_GFS_110.doc
Page 245
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
-
The T2S individual settlement instruction reference. In this case, the maintenance
instruction affects only the referenced split individual settlement instruction and T2S
would ignore any information related to the other split individual settlement instruction.
-
The initial settlement instruction single reference provided by the T2S Actor. In this case,
the maintenance instruction affects both split individual settlement instructions unless one
of them has already been settled or cancelled in which case T2S would ignore any
information related to the settled or cancelled split settlement instruction and the
maintenance instruction affects the split individual settlement instruction which is not
cancelled nor settled. {T2S.05.320}.
•
For already matched instructions for which validation leads to a split into two individual
settlement instructions, the T2S Actor may provide
-
The T2S individual settlement instruction reference. In this case, a maintenance
instruction (excluding cancellation that is not possible, and allowing amendment only to a
limited extent) affects only the referenced split individual settlement instruction
-
The initial settlement instruction single reference provided by the T2S Actor. In the latter
case, the maintenance instruction affects both split individual settlement instructions
3.4.8.3. Description of the functions of the module
1 – Maintenance Instruction Routing
This function identifies the maintenance instruction category and routes it to the relevant Instruction
Maintenance function: Instruction Amendment, Instruction Cancellation, Hold/Release Mechanism or CoSD
Maintenance Instruction Release / Cancel (when related to a CoSD Individual Settlement Instruction and
received from the Administering Party(ies)).
2 – Instruction Amendment
This function processes accepted maintenance instructions intended to amend business data of existing
individual settlement instructions. The Instruction Amendment function follows different processes
depending on the following conditions, which are checked in the specified order:
•
When the Settlement status value equals “settled” or “partially settled”, or Cancellation status
value equals “cancelled”, or CoSD status value equals “CoSD on hold”: In any of these cases,
the maintenance instruction is not considered valid for processing in the Instruction
Amendment function, and the status of the action associated to the maintenance instruction
is therefore set to “cancelled”.
Final_T2S_GFS_110.doc
Page 246
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
When the Matching status value equals to “matched” or “already matched”: The
maintenance instruction is only valid in case of an amendment of process indicators or nonmatching fields {T2S.05.390}. Matching fields can be amended only in case of instruction
with Matching status “matching not required”, “ready to be matched” or “unmatched”.
-
When the Eligibility status is “empty” the function changes the required data on the
individual settlement instruction.
-
When the Eligibility status is “eligible”, the function sends a request for cancellation of the
settlement transaction(s) associated with the individual settlement instruction to the
Process Settlement status function.
In case of a negative answer from the Process Settlement status function, the
status of the action associated to the maintenance instruction is set to “cancelled”
with reason code “affected ISI already settled” and the affected individual
settlement instruction is not amended.
In case of a positive answer to the request, the status of the action associated to
the maintenance instruction is set to “executed”, the affected individual settlement
instruction is modified and its Eligibility status is set to “<empty>”.
The function then forwards all the status updates to the Maintenance Status Management function as
Maintenance Instruction Status Information.
If the action associated to the maintenance instruction has been set to “executed” and if the amended
field of the affected individual settlement instruction was the “partial settlement” indicator, the
Maintenance Allegement function is triggered.
After the amendment, the Instruction Maintenance module forwards individual settlement instructions to
the Matching module, if:
•
The status of action associated to the maintenance instruction has been set to “executed”
•
The amended field of the affected individual settlement instruction was a matching field
•
The Matching status value of the affected individual settlement instruction is “unmatched”
3– Instruction Cancellation
This function processes an accepted maintenance instruction of the category “Instruction Cancellation”
sent by a T2S Actor, trying to cancel the affected individual settlement instruction. Cancellation of
individual settlement instructions is allowed until their settlement. Cancellation can be requested before or
after matching.
Final_T2S_GFS_110.doc
Page 247
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
This function checks if the different possible values of the cancellation and Settlement status of the
affected individual settlement instruction enable to validate the cancellation instruction:
•
If the Settlement status value is equal to “settled”, “partially settled”, or the Cancellation
status value is equal to “cancelled”, then the cancellation instruction is not valid, and the
status of the action associated to the maintenance instruction is set to “cancelled” reason
code “affected ISI already settled”.
•
For the rest of the cases, the cancellation instruction is applicable. {T2S.05.420}
{T2S.05.450}.
In case of a cancellation instruction with the reference of an “already matched” settlement instruction or
an “already matched” two-legged instruction that was split in T2S, the maintenance instruction is
executed only if it can be applied on the individual settlement instructions of both counterparties. In case
the T2S Actor makes use of the reference of the T2S individual settlement instruction split, only the
referring leg will be cancelled.
In case the Matching status of the affected individual settlement instruction is “unmatched” or “ready to
be matched” the cancellation instruction is executed, and the affected individual settlement instruction is
set to “cancelled” with the reason code “unilateral cancellation”. Further checks are needed when the
Matching status of the affected individual instruction equals “matching not required”, in this case the
function checks the Eligibility status of the affected individual settlement instruction:
•
When the Eligibility status is different from “eligible” the Cancellation status of the affected
individual settlement instruction is set to “cancelled” with the reason code “unilateral
cancellation” and the status of the action associated to the cancellation instruction is set to
“executed”
•
When the Eligibility status is equal to “eligible”, the Instruction Cancellation function sends to
the Process Settlement status function a request for cancellation of the settlement
transaction related to the individual settlement instruction.
-
In case of a negative answer from the Process Settlement status function, the status of
the action associated to the cancellation instruction is set to “cancelled” reason code
“affected ISI already settled” and the affected individual settlement instruction is not
cancelled.
-
In case of a positive answer to the request, status of the action associated to the
cancellation instruction status is set to “executed” and the Cancellation status of the
affected individual settlement instruction is set to “cancelled” with the reason code
“unilateral cancellation”.
Final_T2S_GFS_110.doc
Page 248
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
When the CoSD status is “CoSD on hold”, the Cancellation status of the individual settlement
instruction is set to “cancellation requested” and the Administering Party is informed.
In case the Matching status of the affected individual settlement instruction is equal to “matched” or
“already matched” {T2S.05.560}:
•
When the Eligibility status of the affected individual instruction is different from “eligible”, the
function firstly checks that the counterparty cancellation instruction exists and has been
executed (i.e. the value of the Cancellation status of the counterparty individual settlement
instruction is equal to “cancellation requested” and the System sends a maintenance
allegement through the Maintenance Allegement function)..
-
If the result is positive, then the Cancellation status of the individual settlement
instruction and that of the counterparty individual settlement instruction are both set to
“cancelled” with the reason code “bilateral cancellation”.
-
If the result is negative, the Cancellation status of the individual settlement instruction is
set to “cancellation requested”.
In both cases the status of the action associated to the cancellation instruction is set to
“executed”.
•
When the Eligibility status is “eligible”, the function firstly checks that the counterparty
cancellation instruction exists and is executed (i.e. the value of the Cancellation status of the
counterparty individual settlement instruction is equal to “cancellation requested”).
-
If the result is negative, the Cancellation status of the individual settlement instruction is
set to “cancellation requested” and the status of the action associated to the cancellation
instruction is set to “executed”.
-
If the result is positive, the function sends to the Process Settlement Status function a
request for cancellation of the settlement transaction(s) related to the individual
settlement instruction. In case of a negative answer from the Process Settlement Status
function, the cancellation instruction is not executed and the affected individual
settlement instruction Cancellation status is not modified. In case of a positive answer to
the request, the cancellation instruction is executed and the Cancellation status of the
affected individual settlement instruction and that of the counterparty individual
settlement instruction are both set to “cancelled” with the reason code “bilateral
cancellation”.
•
When the CoSD status of the affected individual settlement instruction is “CoSD on hold”,
independently of the value of the Eligibility status, the Cancellation status of the affected
individual settlement instruction can not be set to “cancelled” even if both cancellation
Final_T2S_GFS_110.doc
Page 249
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
requests have come from the two counterparties, since the Administering Party cancellation
is needed. In this case, the Cancellation status for both individual settlement instructions is
set to “cancellation requested” and Administering Party is informed. T2S system sends a
maintenance allegement to the counterparty informing about the request for cancellation of
the affected individual settlement instruction, through the Maintenance Allegement function.
The function then informs the Maintenance Status Management function about the execution or non
execution of the cancellation instruction for reporting purposes.
4 – Instruction cancellation by the system
This function cancels individual settlement instructions after a standard period of time as defined in Static
Data according to the following cases:
Expiration after the Recycling Period
When an End-of-Day time event is received, the function selects all individual settlement instructions with
Settlement status “unsettled”. For each of them, it checks if the duration of the defined recycling period
defined by the CSD or CCP has been reached. If so, the Cancellation status of the individual settlement
instruction is set to “cancelled” with the reason code “recycling period reached”.
For cross-CSD instructions where a CCP is involved, the shorter recycling period defined in Static Data is
applied {T2S.05.460}.
Cancellation of Unmatched Instructions:
When an End-of-Day time event is received, the function selects all individual settlement instructions with
Matching status “unmatched”. For each of them, the function checks if the standard period of working
days after the intended settlement day has been reached. If so, the Cancellation status of the individual
settlement instruction is set to “cancelled” with the reason code “standard period for unmatched
instructions reached”. {T2S.05.430}
The function forwards Cancellation status changes to the Status Management function with the reason
codes associated and action associated status update as Instruction Status Information and Maintenance
Status Information respectively {T2S.05.480}
5 – Hold/Release mechanism
Hold/Release mechanism allows T2S Actors to hold or release individual settlement instruction. Only the
T2S Actor which has put an instruction on hold is allowed to release it.
The Hold/Release Mechanism function allows putting on hold or release individual settlement instruction
until actual settlement occurs, even beyond the intended settlement date {T2S.05.370}.This function
checks if the different status values of the affected individual settlement instruction enables to process the
hold or release maintenance instruction.
Final_T2S_GFS_110.doc
Page 250
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
As regards the checking performed on the basis of the values of the different statuses, the hold/release
instruction is not valid if the affected individual settlement instruction is already with the Settlement status
value equal to “settled”, “partially settled” or with the Cancellation status value “cancelled” .
The function performs in two sub-functions:
•
Recording of the Hold or Release Actions,
•
Hold/Release Status Management {T2S.05.360}
Recording of the Hold/Release Action:
This sub-function records only the last hold and release actions performed on an individual settlement
instruction for each specific T2S Actor that is able to do so, having at any point in time, one unique
hold/release record for each T2S Actor. This information is used to determine the value of the individual
settlement instruction Hold / Release status every time a hold/release action is executed.
Depending on the Eligibility status of the affected individual settlement instruction, the Hold/Release
Mechanism processes as it follows:
•
When the Eligibility status of the affected individual settlement instruction is equal to
“<empty>”, or “ineligible”, a new record (hold/release) is created, the status of the action
associated to the maintenance instruction is set to “executed” and the Hold/Release Status
Management sub-function is activated.
•
When the Eligibility status of the affected individual settlement instruction is equal to
“eligible”, a hold request is received and the individual settlement instruction Hold / Release
status is equal to “released”, the function sends a request to the Process Settlement Status
function in order to ask Standardisation, Provisioning and Booking function to cancel the
settlement transactions related to the individual settlement instruction:
-
In case of a negative answer from the Process Settlement Status function, no new record
is created and the status of the action associated to the maintenance instruction is set to
“cancelled” reason code “affected ISI already settled”.
-
In case of a positive answer to the request, a new hold record is created, the status of
the action associated to the maintenance instruction is set to “executed” and the
Hold/Release Status Management sub-function is triggered.
•
When the Eligibility status of the affected individual settlement instruction is “eligible” and it
is a release instruction, a new release record is created, the action status is set to “executed”
and the Hold/Release Status Management sub-function is activated.
Final_T2S_GFS_110.doc
Page 251
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Hold/Release Status Management:
Each time a hold/release action is executed, this sub-function search for all the records of hold and
release actions of different T2S Actors associated to the hold and release instructions performed on the
individual settlement instruction:
•
When the first hold action record is found, the individual settlement instruction Hold /
Release status is set to “on hold”. The individual settlement instruction will remain “on hold”
until each T2S Actor (i.e. instructing party and CSD) that sent a maintenance instruction for
holding the individual settlement instruction sends the correspondent release instruction.
{T2S.05.360}
•
When a release instruction is received, the function checks all the hold records associated to
the relevant individual settlement instruction. If this release action completes all the release
actions required to free the individual settlement instruction, the Hold / Release status of the
individual settlement instruction is set to “released”. If not, the Hold / Release status of the
individual settlement instruction is not changed.
•
In case the affected individual settlement instruction has the CoSD status value equal to
“CoSD on hold”, and the individual settlement instruction has a unique Administering Party,
this Administering Party is allowed to send a release instruction unilaterally assuming the
parties do fulfil the external condition for settlement. A hold maintenance instruction is not
accepted if the affected settlement instruction CoSD status value is “CoSD on hold”.
All status updates in the affected settlement instruction and the action status updates are then forwarded
to the Maintenance Status Management function as Instruction Status Information and Maintenance
Instruction Status information respectively.
In case the Hold/Release status is set to “on hold” and the Eligibility status is “eligible” then the Eligibility
status is set to “<empty>”.
6 – Maintenance Allegements
Allegement messages are sent to the involved T2S Actors when the counterpart sends any of the
following maintenance instructions {T2S.05.340}:
•
Cancellation
•
Amendment (partial settlement allowed)
•
Hold
•
Release
Final_T2S_GFS_110.doc
Page 252
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
The function receives information on all the aforementioned actions from the functions of the
Maintenance Module.
Maintenance Allegement Messages
When processing a maintenance action (for amendment actions, only in case of a change of the partial
settlement indicator), and if the Matching status of the affected individual settlement instruction is
“matched” or “already matched”, the function informs the Flow Management module to send an
allegement message to the involved T2S Actors, informing about the counterpart’s individual settlement
instruction amendment.
7 – Conditional Securities Delivery (CoSD) Instruction maintenance: Release/Cancel
This function handles administering party(ies)’ maintenance instructions to release or cancel individual
settlement instructions which were flagged by T2S as CoSD instructions.
The function is performed in three steps:
•
Checking of the CoSD status of the individual settlement instruction;
•
Recording of the CoSD cancellation or release requests;
•
CoSD status Management.
Checking of the CoSD status of the individual settlement instruction
•
If the CoSD status of the individual settlement instruction differs from “CoSD on hold”, the
release received from the Administering Party can not be executed {T2S.05.470}. In this
case the release maintenance instruction status will be set to “cancelled”.
Recording of the CoSD maintenance actions:
At this step, the function records all the CoSD cancellation or release requests received from the
Administering Party(ies). This recording implies that the CoSD release or cancellation action status is set
to “executed”.
All CoSD release or cancellation action updates are forwarded to the Maintenance Status Management
function as Maintenance Instruction Status Information.
CoSD status Management:
Each time a CoSD release or cancellation maintenance instruction received from an Administering Party is
executed, this function looks for all the records of CoSD release or cancellation request actions performed
on the affected individual settlement instruction.
After finding a CoSD release action record, the function checks the Administering Party(ies) associated to
the affected individual settlement instruction.
Final_T2S_GFS_110.doc
Page 253
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
In case the individual settlement instruction has only one Administering Party the CoSD
status of the individual settlement instruction is set to “CoSD to be released”.
•
When more than one Administering Party is assigned to the individual settlement instruction,
the sub-function checks if all the actions associated to the expected CoSD release
instructions have been recorded, since Administering Party releases are expected to be
received one by one, even if the same Administering Party administers more than one CoSD
rule applicable to the same individual settlement instruction. Only in that case the CoSD
status of the individual settlement instruction is set to “CoSD to be released”. Otherwise, no
change on the CoSD status of the individual settlement instruction is made.
In case a CoSD cancel action record is found, the CoSD status of the individual settlement instruction is
set to “CoSD to be cancelled”..
The above mentioned updates of the CoSD status are performed on one individual settlement instruction
if the Matching status is “matching not required”, and on individual settlement instructions from both
counterparties if the Matching status is “already matched” or “matched”.
When the CoSD instruction is finally cancelled by the Validation Provisioning and Booking module, the
Cancellation status of the individual settlement instruction is set to “cancelled” reason code “cancellation
triggered by the Administering Party”.
All status updates of the affected individual settlement instruction are then forwarded to the Maintenance
Status Management function as Instruction Status Information.
8 – Maintenance Status Management
This function forwards all status updates of the individual settlement instruction and of the actions to the
Status Management module as Instruction Status Information and Maintenance Instruction Information
respectively.
9 – Process Settlement Status
This function receives requests from the functions of the Instruction Maintenance module (“Request”) and
the Instruction Validation module (“Request (A)”) in order to ask the Settlement domain for the
cancellation of the settlement transactions associated to the affected individual settlement instruction.
These requests are sent to the Settlement domain (“Request (C)”), and the answer from the Settlement
domain (“Answer (D)”) is forwarded back to the requesting function (“Answer” for functions of the
Instruction Maintenance module and “Answer (B)” for the Instruction Validation module). {T2S.05.310}
{T2S.05.370} {T2S.05.390} {T2S.05.450}.
Final_T2S_GFS_110.doc
Page 254
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.8.4. Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Maintenance
Instruction
[Accepted]
IN
Maintenance on an
individual settlement
instruction
Instruction Validation
Request (A)
IN
Request to cancel all the
settlement transactions
related to an individual
settlement instruction that
needs to be revalidated
Instruction Validation
Answer (B)
OUT
Answer to the request for
cancellation (A)
Instruction Validation
Request (C)
OUT
Request to cancel all the
settlement transactions
related to an individual
settlement instruction due
to a maintenance action on
it
Standardisation and
Preparation to
Settlement
Answer (D)
IN
Answer to the request for
cancellation (C)
Standardisation and
Preparation to Settlement
Time Event (EoD) IN
End of Day
Scheduling
Allegement data
OUT
Information for allegement
message
Flow Management
Amended ISI
[Unmatched]
[Accepted] [on
Hold/Released]
[No Cancellation
Requested]
OUT
ISI amended that triggers
new matching attempt
Instruction Matching
ISI [CoSD to be
released] [CoSD
to be cancelled]
OUT
Update of the individual
settlement instruction CoSD
status value.
Settlement Eligibility
Maintenance
Instruction
status
information
OUT
Update of the maintenance
instruction status value.
Includes reason code.
Status Management
Update of the individual
settlement instruction
status value. Includes
reason code
Status Management
Instruction Status OUT
Information
Final_T2S_GFS_110.doc
Page 255
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.8.5. Data accessed by the module
DATA
ACCESS MODE
STATUS
COMMENTS
STATIC DATA
Conditional Securities
Delivery Rule
Read
Cash Reservation
Cosd administering party
COSD Rule Name
Country
Country2
CSD system entity
ISIN code
Party
Securities account
Security Reservation
settlement currency
Transaction Type
On-Behalf Authorised
Party
Read
Party
Party
Read
Party restriction
Party status
Recycling period
Reference Value
Read
Reference value description
Reference value
DYNAMIC DATA
Action
Action Parameter
Final_T2S_GFS_110.doc
Modify
Action type
Read
Action status
Modify
Parameter name
Read
Parameter value
Page 256
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
DATA
ACCESS MODE
Individual Settlement
Instruction
STATUS
COMMENTS
Individual Instruction Type
Instructing Party
Trade date
Intended Settlement Date
Allowed modification flag
Common Reference
Trade Date
T2S First Party
T2S Final Party
First Party CSD
Final Party CSD
Partial flag
Partial indicator
Partial settlement indicator
Priority
Repo reference
Reservation flag
Half Cash movement
Original Amount
Matched Amount
Operation
Half Security
movement
Security Account
Security Identifier
Original Quantity
Operation
Individual Settlement
Instruction Link
Modify
Link Type
Individual Settlement
Instruction Link Set
Modify
Individual Settlement
Instruction Status
Modify
Name
Read
Value
Hold/Release Party
Modify
Command
Read
Final_T2S_GFS_110.doc
Page 257
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
DATA
Allegements
ACCESS MODE
STATUS
COMMENTS
Create
Date / Time
Read
Allegement type
Status
Receiver Party
Action Error
Read
Error Code
CoSD Administering
Party
Read
Command
3.4.9. Instruction Matching
3.4.9.1. Diagram of the module
Final_T2S_GFS_110.doc
Page 258
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.9.2. Description of the module
Matching is the process of comparing the individual settlement instruction fields provided by the buyer
and the seller of securities in order to ensure that they agree on the settlement terms of their respective
trade-related instructions.
It is a real-time process which is available continuously during the whole day T2S operating hours
{T2S.03.210}, with the exception of the Maintenance Window {T2S.05.490}.
The Instruction Matching module is responsible for matching individual settlement instructions that have
to be matched in T2S. It never receives individual settlement instructions which Matching status has been
set to “already matched” (instructions that have been already matched outside, e.g. at CSD level) or
“matching not required” (e.g. those related to corporate events) by the Instruction Validation Module
{T2S.05.500}.
Blocking and Reservation Instructions are settlement restriction instructions for which matching is not
required and therefore they are not processed in the matching module.
In the case of two-legged instructions split in the validation module (inception and redemption), the
Instruction Matching module matches the inception and redemption independently {T2S.05.550}.
3.4.9.3. Description of the functions of the module
This module is composed of three different functions dealing with individual settlement instructions.
1 – Matching Algorithm
The Matching Algorithm function manages the matching of individual settlement instructions that have to
be matched in T2S, by contrast with instructions with a Matching status value “matching not required” or
“already matched” that do not need to be matched in T2S.
The function deals with:
•
Validated individual settlement instructions which, after passing through the Instruction
Validation module, always have the following status at this point:
•
-
Validation status value “accepted”;
-
Matching status value “ready to be matched”;
-
Hold / Release status “on hold” or “released”;
-
Cancellation status “none cancellation requested”.
Amended individual settlement instructions, which are received from the Instruction
Maintenance module, always have the following status:
Final_T2S_GFS_110.doc
Page 259
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
-
Validation status value “accepted”;
-
Matching status value “unmatched”;
-
Hold / Release status “on hold” or “released”;
-
Cancellation status “none cancellation requested”.
Validated individual settlement instructions can be matched regardless of their Hold / Release status
(value is “on hold” or “released”). Individual settlement instructions that require matching may include a
Common Reference (if agreed by the counterparties) in order to facilitate matching.
In case a mandatory or additional matching field of an “unmatched” individual settlement instruction is
amended, this instruction will be reprocessed by the function in order to match it according to its new
matching fields.
The Matching Algorithm performs a detailed and structured comparison between individual settlement
instructions, in order to obtain pairs of possible matched individual settlement instructions.
The function is made of two main sub-functions, “Matching Fields Algorithm” and “Cash Amount Tolerance
and Optimisation Algorithm” described below:
Matching Fields Algorithm sub-function
The Matching Fields Algorithm sub-function searches in the unmatched instructions repository (i.e. the
data store of validated individual settlement instructions which are not yet matched), for another
instruction to be matched against the incoming individual settlement instruction, by comparing that all the
corresponding mandatory and additional matching fields are the same except the cash amount field. This
sub-function processes those instructions identified in the Instruction Validation module which matching
location is T2S.
For each given individual settlement instruction coming from the Instruction Validation module or from the
Instruction Maintenance module, the Matching Fields Algorithm performs a matching comparison process,
that will be specified according to future optimisation studies and testing.
During this matching comparison the sub-function searches in the repository of “unmatched” instructions
those instructions that have the same matching fields values as the processed instruction, except the cash
amount field. When comparing the BIC of the counterparties, the algorithm makes a cross-check between
the BIC Code of the Party who delivers the securities, and the BIC Code of the Counterpart who receives
the securities. So the BIC Code of the selling instruction party is matched against the BIC of the
counterpart who receives the securities. {T2S.05.570};
Through this process all unmatched instructions which have at least one matching field compared
different, are excluded.
At the end of the process either:
Final_T2S_GFS_110.doc
Page 260
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
One or several “unmatched” individual settlement instructions are found with the same matching fields
except the cash amount. In this case the individual settlement instruction(s) are forwarded to the Cash
Amount Tolerance and Optimisation Algorithm Sub-function for their further processing;
No matching Individual Settlement Instruction is found. If the process fails to find at least one unmatched
instruction with the same matching fields, then the matching process is stopped and the individual
settlement instruction Matching status is “unmatched” is forwarded to the Matching Status Management
function.
Repository of “Unmatched”
Instructions
ISI (2)
ISI (n-1)
ISI (3)
ISI (n)
ISI (1)
Mandatory
Matching
Fields
Enters the
process
Matching Fields
Algorithm*
Additional
Matching
Fields
Subset of x ISI’s found with the same
Mandatory / additional Matching
Fields except Cash Amount
ISI (x)
ISI (x-x)
* Does not consider Cash Account
The following table identifies the mandatory matching fields per instruction type that are checked by this
sub-function:
DVP / DWP
FOP
DVD40
BIC code of the counterpart who delivers the securities
BIC code of the counterpart who receives the securities
Instruction type code
40
DVD instructions are structured as two free payment instructions linked.
Final_T2S_GFS_110.doc
Page 261
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
DVP / DWP
DVD40
FOP
Intended settlement date
Trade date
Receiving Party CSD
Delivery Party CSD
Currency
N.A.
Share quantity (for equities) or nominal amount (for fixed income securities)
To deliver: share quantity (for
equities) or nominal amount (for
fixed income securities)
N.A.
To Receive: share quantity (for
equities) or nominal amount (for
fixed income securities)
Buy/sell
Deliver/Receive
ISIN code
ISIN code to deliver
N.A.
ISIN code to Receive
Cash amount
N.A.
This sub-function also verifies additional matching fields that are not mandatory matching fields, but
become such if they are included in at least one of the two counterparties settlement instructions
{T2S.05.590}.
In case the additional matching fields referred to the Client of the delivering / receiving CSD participant,
they may match to blank. These fields become mandatory matching fields only if both individual
settlement instructions have included data for these fields in their settlement instructions.
A non-exhaustive list of additional matching fields per transaction type can be:
DVP
FOP
DVD
Common reference 41
N.A.
Cash amount if it is not a blank
field 42
N.A.
Client of delivering CSD participant 43 (if a defined standard code, e.g. BIC, exists, it should be
used). This field may match to blank.
Client of receiving CSD participant 44 (if a defined standard code, e.g. BIC, exists, it should be
used). This field may match to blank.
41 It is voluntarily introduced by both counterparties in order to facilitate the matching.
42 It is blank for FoP instructions. Therefore, the cash is not settled in T2S.
43 The ESF/ECSDA standards refer to “second layer market participant (sub-account/customer of counterparty)”.
44 The ESF/ECSDA standards refer to “second layer market participant (sub-account/customer of counterparty)”.
Final_T2S_GFS_110.doc
Page 262
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Cash Amount Tolerance and Optimisation Algorithm sub-function
At the end of the process described before, the individual settlement instruction can still be potentially
matched with more than one instruction from its counterparty, due to the fact that matching rules allow
for a certain tolerance level in the cash amount. The tolerance amount has two different bands per
currency, depending on cash countervalue and currency (in line with ECSDA rules45) {T2S.05.580}.
Subset of x ISI’s found with the same
Mandatory / additional Matching
Fields except Cash Amount
ISI (x)
MATCHING FIELDS ALGORITHM
ISI (x-x)
Subset of ISIs
found with the
same Mandatory
Matching Fields
except the
ISI 1
Cash Amount
Cash Amount Tolerance and
Optimisation Algorithm:
Min ∆ (Cash Amounts)
Cash Amount
Check if ∆ (Cash Amounts)
Tolerable
ISI 1
matched
ISI x
matched
ISI 1
unmatched
Repository of
“unmatched
instructions
T2S Common Reference
This sub-function processes the result of the Matching Fields Algorithm, which is a subset of “unmatched”
individual settlement instructions with the same values for mandatory / optional fields (but the cash
amount field) that can be matched with the individual settlement instruction being processed.
This sub-function is responsible for comparing the cash amount field that has not already taken into
consideration until this moment.
The sub-function chooses the most suitable instruction to match with (i.e. the one with the smallest cash
amount difference) through an optimisation procedure. When individual settlement instructions are
matched with discrepancy in the cash amount, they must be submitted for settlement with the cash
amount specified by the securities seller {T2S.05.580}.
45 The general tolerance amount for matching the cash amount field as suggested by ECSDA is 25€ when the countervalue is above 100.000€ or 2€
when it is less or equal to 100.000€
Final_T2S_GFS_110.doc
Page 263
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
When there is more than one instruction with the same cash difference tolerance, the FIFO logic applies.
Once the Cash Amount Tolerance and Optimisation Algorithm sub-function have compared the data of the
individual settlement instruction being processed with that of the possible matching instructions coming
from the Matching Fields Algorithm sub-function, there are two possibilities:
•
One matching instruction is found:
-
Both “matched” individual settlement instructions are forwarded to the Matching Status
Management function;
-
The sub-function informs the Matching Allegement Removal sub-function that these two
instructions have been matched.
•
No matching instruction is found:
-
The individual settlement instruction being processed is forwarded to the Matching Status
Management Function;
-
The sub-function informs the Matching Allegement Sending sub-function that there is a
new unmatched individual settlement instruction in the repository.
2 – Matching Status Management
The Matching Status Management function updates the Matching status value of the individual settlement
instruction(s) depending on the result of the previous function.
For this purpose, it checks the incoming individual settlement instructions setting their Matching status
accordingly:
•
“Matched” (In case two instructions are received)
When the individual settlement instruction matches univocally with one of the instructions
selected in the matching algorithm process and the comparison of mandatory and additional
matching is successful (including cash amount):
-
the Matching status of both instructions is set to the value “matched”;
-
their “T2S common reference” is set to a common value;
-
when instructions are matched with discrepancy in the cash amounts, this matched cash
amount is recorded in both individual settlement instructions.
•
“Unmatched”
If the individual settlement instruction does not match with any of the instructions of the
repository, the status of the individual settlement instruction being processed is set to the
value “unmatched” {T2S.05.520}.
Final_T2S_GFS_110.doc
Page 264
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Instruction Status Information is communicated to the Status Management module in charge of collecting
data for sending the information to the T2S Actors {T2S.05.530}. These data are also communicated to
the Matching Allegement function that deals with the matching allegement messages.
The function forwards to the Settlement Eligibility Module the individual settlement instructions with
Matching status value “matched”.
3 – Matching Allegement
This function deals with the matching allegement messages issued to inform the counterparty after the
first unsuccessful matching attempt, because of a missing counterpart instruction {T2S.05.540}. This
function deals also with the removal of matching allegement messages when unmatched instructions, with
Allegement status value “allegement sent”, are matched {T2S.05.540}. Accordingly, two main subfunctions deal with matching allegement messages:
Matching Allegement Sending sub-function
Matching allegement messages are sent once per unmatched instruction and per counterparty.
To avoid the unnecessary (i.e. too early) transmission of matching allegements, they are sent a predetermined period of time after the unsuccessful matching attempt, depending on the date of receipt and
the intended settlement date of the instruction, in accordance to the allegement parameterization features
specified.
For this purpose, a time event is received in predefined time intervals from the Scheduling module. On
reception of this time event, the sub-function selects in the repository the “unmatched instructions” with
the matching Allegement status “allegement not sent” that remained unmatched during a pre-determined
period of time in order to send a matching allegement to the respective counterparty. The sub-function
collects the instructing data of these individual settlement instructions and forwards it to the Flow
Management module.
When the matching allegement is sent, the Allegement status of the individual settlement instruction is
set to the value “allegement sent”.
Matching Allegement Removal sub-function
When an individual settlement instruction A is matched with an individual settlement instruction B, this
sub-function checks if a matching allegement message was previously sent for the individual settlement
instruction B (i.e. the Allegement status value equals to “allegement sent”). Should it be the case, the
sub-function sends the relevant data to the Flow Management module, in charge of sending a real-time
removal of matching allegement message to the party that sent individual settlement instruction B
{T2S.05.540}. In this case, the Allegement status value of individual settlement instruction B is set to
“allegement removed”.
Final_T2S_GFS_110.doc
Page 265
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.9.4. Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Individual
Settlement
Instruction
<ready to be
matched>
<accepted>
<on Hold /
Released>
<none
cancellation
requested>
IN
Once the Individual
Settlement Instruction is
generated and its
Matching status is “ready
to be matched”
Instruction Validation
Amended
Individual
Settlement
Instruction
<unmatched
>
<accepted>
<on Hold /
Released>
<none
cancellation
requested>
IN
Once the Individual
Settlement Instruction is
amended by the
Instruction maintenance
module.
Instruction Maintenance
Allegement
data
OUT
Data for composing a
matching allegement
message, when the
counterparty’s instruction
is not found in the
repository.
Flow Management
Instruction
Status
Information
OUT
Individual settlement
instruction data for
history log.
Status Management
Individual
Settlement
Instruction
<matched>
OUT
After all the matching
procedures have finished.
Settlement Eligibility
3.4.9.5. Data accessed by the module
DATA
ACCESS MODE
STATUS
COMMENTS
STATIC DATA
Tolerance Amount
Read
Allegement
Parameterization
Features
Read
Final_T2S_GFS_110.doc
Page 266
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
DATA
Currency
ACCESS MODE
STATUS
COMMENTS
Read
DYNAMIC DATA
Individual Settlement
Instruction
Individual Instruction Type
Common Reference
ISO Transaction Code
Instruction Type Code
Intended Settlement Date
Trade Date
T2S First Party
T2S Final Party
First Party CSD
Final Party CSD
Final Beneficiary
Half Cash movement
Operation
Original Amount
Matched Amount
Half Security
movement
Security Account
Security Identifier
Original Quantity
Operation
Individual Settlement
Instruction Status
Read
Name
Modify
Value
Allegements
Create
Date/Time
Read
Allegement Type
Delete
Status
Receiver Party
Final_T2S_GFS_110.doc
Page 267
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.10. Status Management
3.4.10.1. Diagram of the module
LCMM: Instruction
Validation
LCMM: Instruction
Matching
Instruction Status Information /
Maintenance Instruction Status
Information
Instruction Status
Information
<<Data Store>>
Audit Trail
Life Cycle Track
Status Management
LCMM: Instruction
Maintenance
Instruction Status Information /
Maintenance Instruction Status
Information
ISI Amended /
reason code
Instruction Status
Information
SETT: VPB
Restriction Status
Information
Collateral Settlement
Information
Collateral Instruction
Settlement Management
Instruction Status Information /
Maintenance Instruction Status
Information
Instruction Status
Information
Instruction Status
Information
LCMM: Settlement
Eligibility
ISI Amendments
End of Cycle
information
Data Collection for Messages
SETT: Sequencing
<<Data Store>>
Instructions
Instruction Status Information
[settled /partially settled]
<<Data Store>>
Securties Account
Further Processing
Identification
Message data
Partially settled
instruction info
Liquidity Event
INTF: Flow
Management
LCMM: Instruction
Validation
LQMG: Liquidity
Control
3.4.10.2. Description of the module
The Status Management module manages the updates from Instruction Maintenance, Instruction
Validation, Instruction Matching, Settlement Eligibility and Validation Provisioning and Booking modules of
the following dynamic data entities:
•
Individual Settlement Instruction (ISI), ISI status,
Final_T2S_GFS_110.doc
Page 268
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
Action status. This status can take the values “accepted”, “rejected”, “executed” or
“cancelled” as it is described in the introductory part of this domain,
•
Reason Code Entity.
This module receives the updates and collects the data related to these updates, and forwards them to
the Interface domain (Flow Management function) for their transmission to the T2S Actors, according to
the message subscription preferences.
This module keeps record of all the data needed for audit trail purposes which are stored in the Audit Trail
entity, at any time a field of the individual settlement instruction is changed.
Furthermore, regarding Individual Settlement Instructions Statuses, it is worthwhile highlighting that
some statuses are business-oriented and hence are communicated to T2S Actors when relevant, whereas
other statuses (e.g. “eligible”) are only for T2S internal technical purposes and hence are not
communicated to T2S Actors.
3.4.10.3. Description of the functions of the module
1 – Life Cycle Track
This function stores the attribute value updates occurred during the entire life cycle of individual
settlement instructions and changes in the Action status. Each record includes the date and time of each
update and a unique identifier of the system user performing the change {T2S.05.270}. The Life Cycle
Track function registers the updated information, the associated time stamp and the reference of the
message that originates the changes, if that is the case. All this information is recorded in the Audit Trail
entity.
The Life Cycle Track function also saves all the reason codes related to the correspondent status value in
order to provide the counterparties with the information about failures, recycling attempts, rejections,
ineligible instructions and cancellations {T2S.13.120} {T2S.05.020} {T2S.05.330} {T2S.05.625}
{T2S.05.480}
This function forwards all data to the Data Collection for Messages function. In case the Settlement status
value is “partially settled” or “settled”, this function forwards the information to the Identification of
Further Processing function.
2 – Data Collection for Messages
This function receives from Life Cycle Track function all updates performed and collects the data to be
sent as a message to the corresponding T2S Actor(s) {T2S.13.060}. These data include T2S Actor
instruction reference and the T2S reference in case of split instructions. It will also include any other
information required to compose the correspondent message including reason codes, if that is the case
Final_T2S_GFS_110.doc
Page 269
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
(see table below in the individual settlement instruction status management description) {T2S.05.330}.
These data are forwarded to the Flow Management module in the Interface domain.
Action status values updates
When the System receives a settlement or a maintenance instruction, first of all, it stores the main
information in the Settlement Related Instruction, Action and Action Parameter entities. Each settlement
or maintenance instruction is processed one by one.
Every update in the Action status value has to be communicated to the T2S actors, which are informed
according to the following table:
ACTION
STATUS
TYPE OF INSTRUCTION DATA
RECEIVED
POSIBLE ISI
STATUS
ACTION STATUS
COMUNICATED
Rejected
Any
N.A.
Rejected
Accepted
New for settlement purposes
Accepted
None (ISI status
communicated instead)
Accepted
For maintenance purposes
Any
Accepted
Executed
For maintenance purposes
Any
Executed
Cancelled
For maintenance purposes
Any
Cancelled
When a validated maintenance instruction is not executed, its status is set to “cancelled” and the function
provides a message informing the T2S party about this cancellation with the proper reason code.
Restriction Status Information updates
When a Restriction Status Information is received from the Validation, Provisioning and Booking module in
the Status Management module, the previously partially settled reservation instruction is searched in
order to report the T2S Actor that additional cash/securities have been used to fill in the reservation.
Validation Error Entity updates
This sub-function collects the validation errors associated to the rejection of the action in addition to the
data sent to the Flow Management module.
Individual settlement instruction status value updates
If a change in the status value of an Individual Settlement Instruction is to be sent to the T2S Actor, this
sub-function collects data required to compose a status advise message (except from Settlement status
set to “settled” during any night-time cycle) and forwards it to the Flow Management module. The
business status value that is reported, at any point in time, to the T2S Actor is the business status value
obtained from the combination of values as it is shown in the table below.
All these data related to business status value updates are immediately forwarded to the Flow
Management module, except when the business status to be communicated is “settled” due to the fact
Final_T2S_GFS_110.doc
Page 270
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
that the Settlement status value has been set to “settled” during a night-time cycle {T2S.13.070}. Hold
and Release status value updates are also communicated immediately to the T2S Actor.
Although already matched instructions are split into two different individual settlement instructions in T2S,
this function will collect data for sending only one status message to the CSD or the CCP.
VALIDATION &
ACTION STATUS
MATCHING STATUS COSD STATUS ELIGIBILIT
Y STATUS
CANCELLATION
STATUS
SETTLEMENT
STATUS
LIFE
CYCLEBUSINESS
STATUS
Accepted
Ready to be
matched /
Matching not
required
Accepted
Unmatched
Accepted
Already matched
/ Matched
Accepted
Matching not
required /
Matched /
Already matched
Accepted
Any
No cancellation
requested /
Cancellation
requested
<empty>
Accepted
<empty>
Any
No cancellation
requested /
Cancellation
requested
<empty>
Unmatched
<empty>
Any
No cancellation
requested /
Cancellation
requested
<empty>
Matched
CoSD on
Eligible
hold / CoSD
to be
released /
CoSD to be
cancelled
No cancellation
requested /
Cancellation
requested
<empty>
CoSD hold
Any
Any
Any
Cancelled
Unsettled /
<empty>
Cancelled
Accepted
Any
Any
Ineligible
No cancellation
requested /
Cancellation
requested
<empty>
Ineligible
Accepted
Matching not
required /
Matched /
Already matched
Any
Eligible
No cancellation
requested /
Cancellation
requested
Settled
Settled
Accepted
Matching not
required /
Matched /
Already matched
Any
Eligible
No cancellation
requested /
Cancellation
requested
Partially settled Partially settled
Accepted
Matching not
required/Matche
d / Already
matched
Any
Eligible
No cancellation
requested /
Cancellation
requested
Unsettled
Final_T2S_GFS_110.doc
<empty>
Unsettled
Page 271
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
Cancellation Status Values Updates
Also when both Individual Settlement instructions have the Cancellation status “cancellation requested”
and its CoSD status remains “CoSD on Hold”, although the business status has not been changed, a
message is sent to the Administering Party in order to inform that both actors have requested the
cancellation of their instructions.
Reason Codes Entity Values Updates
This sub-function also collects the reason codes associated with the corresponding status value, in
addition to the data sent to the Flow Management Module, according to the following list:
•
For Settlement status value ”unsettled”: {T2S.13.130}
-
Lack of cash
-
Lack of securities
-
Lack of cash and securities
-
Intraday restriction (security, currency, security account, T2S dedicated cash account or
T2S party blocked)
•
•
-
Net buying limit reached
-
Earmarked restriction not sufficient
For Eligibility status value “ineligible”:
-
Individual settlement instruction on hold
-
Linked individual settlement instruction missing
-
DVP cut-off reached
-
First leg/ inception not settled
-
Intended Settlement Date not reached
For Cancellation status value “cancelled”:
-
Recycling period reached
-
Standard period for unmatched instructions reached
-
Unilateral cancellation
-
Bilateral cancellation
-
Cancelled due to Static Data change
-
Affected ISI already settled
Final_T2S_GFS_110.doc
Page 272
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
-
Cancellation triggered by Administering Party
During day-time settlement this T2S communicates to the T2S Actor, each attempt of settlement, even if
only the reason code changes. This sub-function collects data to build the message.
If the reason code changes during any night-time cycle, T2S communicates the last attempt and its
corresponding reason code only at the end of that cycle.
Additional information requirements depending on the individual instruction type
This sub-function performs two different processes:
Settlement restriction instructions
When the individual settlement instruction is a settlement restriction (or a release of a settlement
restriction) process checks if the Settlement status value has been set to “settled” or “partially settled”. If
that is the case, it then collects the data required to compose a message in order to send a status advise
on the individual settlement instruction to the connected central bank collateral management system (e.g.
CCBM2), CSDs and directly connected T2S Actors involved {T2S.06.440}
Auto-collateralisation procedures
This process receives from Settlement Collateral Instruction Management function a status update when
the collateral settlement instruction has been created, so the relevant data can be forwarded to the
involved parties (including the connected collateral management system of the central bank).
Event driven processes
Two different processes are foreseen in this sub-function
End of night-time cycle event driven process
This process is triggered by an End Of Cycle Information sent by the Sequencing Module indicating the
end of each night-time cycle. For any given instruction, this process collects all the data to inform a T2S
Actor about the Settlement status value update of the individual settlement instruction {T2S.13.070}.
Recycling attempt event driven process
This process is triggered by the VPB Module which informs the Status Management module whether the
individual settlement instruction is settled or unsettled through the provision of Instruction Status
Information after each recycling attempt. For any given instruction, this process collects all the data to
inform T2S Actor about the changes of Settlement status value of the individual settlement instruction
{T2S.13.110}.
Final_T2S_GFS_110.doc
Page 273
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3 – Further processing Identification
Two sub-functions are included in this function:
The management of the remaining amount of an individual settlement instruction
This sub-function checks if the Settlement status value has been set to “partially settled”. In case, it sends
to the Instruction Validation module (Instructions Management function) a request with all the relevant
information to generate a new individual settlement instruction for the remaining amount to be settled
{T2S.08.240}.
Associated liquidity transfers
This sub-function selects the individual settlement instruction related to a corporate action (ISO
transaction code), which status has been set to “partially settled” or “settled”, and checks in cash account
entity in SD if the T2S Actor has opted for automated liquidity transfer of the cash proceeds to the RTGS
System. In that case, this sub-function sends a request to Liquidity Management module, together with
the cash reservation reference provided by the Validation Provisioning and Booking module.
4 – Collateral Instruction Settlement management
This function receives from Validation Provisioning and Booking module the information about the
settlement of a transaction of the two following categories:
•
“Collateral” for the settlement transaction created by the Auto-collateralisation Manager
function.
•
“Intraday Credit Reimbursement” or “EOD Intraday Credit Reimbursement” for the settled
settlement transaction created by the Intraday Credit Reimbursement Manager function.
This process complements the data received to store an individual settlement instruction with the
Settlement status set to “settled” and forwards this status update to the Data Collection for Messages
function.
3.4.10.4. Description of the Input/Output of the module
FLOW
Instruction
Status
Information
IN/OUT
IN
DESCRIPTION
Update of the individual
settlement instruction
status value. Includes
reason code.
FROM
TO
Instruction Validation
Instruction Matching
Instruction Maintenance
Settlement Eligibility
Validation Provisioning
and Booking
Final_T2S_GFS_110.doc
Page 274
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Collateral
Settlement
Information
IN
Transaction created by the
Auto-collateralisation
Manager function
End of Cycle
Information
IN
Indicates the end of cycle of Sequencing
settlement
Restriction
Status
Information
IN
Information after a preemption for a partially filled
reservation
Validation Provisioning
and Booking
Maintenance
Instruction
Status
Information
IN
Update of the maintenance
instruction status value.
Includes reason code.
Instruction Validation
Instruction Maintenance
ISI Amended/ IN
Reason Code
Amendment of the
individual settlement
instruction.
Instruction Maintenance
Partially
settled
instruction
info
OUT
It sends a request with all
the relevant information of
a partially settled
instruction
Instruction Validation
Liquidity
Event
OUT
Sends a request , together
with the cash reservation
reference
Liquidity Control
Data for composing a
status message
Flow Management
Message Data OUT
Final_T2S_GFS_110.doc
Validation Provisioning
and Booking
Page 275
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.10.5. Data accessed by the module
DATA
ACCESS MODE
STATUS
COMMENTS
DYNAMIC DATA
Individual Settlement
Instruction
Read
Individual Instruction Type
Modify
Instructing Party
Trade Date
Intended Settlement Date
ISO Transaction Code
First Party CSD
Final Party CSD
Final Beneficiary
Auto-Collateralisation Flag
Linked Instructions Counter
Partial Indicator
Partial Settlement Indicator
Partial Flag
Priority
T2S First Party
T2S Final Party
CosD flag
CARL flag
Common Reference
Allowed Modification Flag
Repo Reference
Reservation Flag
Pre-check Amendment Flag
Half Cash movement
Read
Operation
Original Amount
Matched Amount
Settled Amount
Settlement Date/Time
Default account
Final_T2S_GFS_110.doc
Page 276
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
DATA
Half Security
movement
ACCESS MODE
Read
STATUS
COMMENTS
Operation
Original Quantity
Settled Quantity
Security Identifier
Security Account
Settlement Date/Time
Action error
Create
Error code
Individual Settlement
Instruction Status
Read
Name
Hold/ Release Party
Read
Command
CoSD Administering
Party
Read
Command
Action
Read
Action type
Read
Status
Reason Codes
Read
Reason codes reference
ISI link
Read
Link Type
ISI link set
Read
Final_T2S_GFS_110.doc
Page 277
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
3.4.11. Settlement Eligibility
3.4.11.1. Diagram of the module
LCMM:
Instruction Validation
LCMM:
Instruction Matching
LCMM:
Instruction Maintenance
ISI
[Matching Not
Required / Already
Matched] (A)
ISI
[Matched]
(B)
ISI
[CoSD To Be Released]
[CoSD To Be Cancelled]
(C)
Settlement Eligibility
OPSR:
Scheduling
Time Event
[Start of Day]
(F)
Time Event
(G)
Time Event
[End of Day]
(H)
Start Of Day Eligibility Check
« data store »
[Static Data]
Continuous Eligibility Check
Periodic Check For
Ineligible Linked Instructions
« data store »
[ISI]
ISI
[-]
ISI
[-]
« data store »
[ISI]
ISI
[Ineligible]
Linked Eligibility Check
Linked Settlement
Instructions
[-]
Fail Management
Updating Instruction Status
ISI
[Eligible] (D)
Instruction
Status
Information (E)
SETT: Standardisation and
Preparation to Settlement
LCMM: Status
Management
[-] : same values as in
imput of the function
3.4.11.2. Description of the module
The Settlement Eligibility module checks the eligibility of the individual settlement instructions based on a
set of settlement eligibility criteria (individual settlement instruction statuses, intended settlement date,
and individual settlement instruction links) and forwards those which meet these criteria to the Settlement
Domain {T2S.05.600}.
This check applies according to the settlement day period as follows:
•
At the Start of Day period, the module selects from the data store the individual settlement
instructions that meet the eligibility criteria;
Final_T2S_GFS_110.doc
Page 278
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
During the settlement day, out of the Start of Day period, the module checks on a
continuous basis the eligibility of the received46 individual settlement instructions,
disregarding of individual settlement instructions with an entry time later than their
applicable cut-off time.
In case of “Matching Not Required” Matching Status, only one individual settlement instruction is handled.
In the other cases it is a pair of matched individual settlement instructions. The module handles both
situations, and, in the case of a pair of matched individual settlement instructions, manages and forwards
both individual settlement instructions.
3.4.11.3. Description of the functions of the module
1 – Start Of Day Eligibility Check
At the Start of Day period, this function selects from the data store the individual settlement instructions
having the following properties {T2S.03.030} {T2S.03.040} {T2S.05.620}:
•
An Intended settlement date equal or earlier to the current settlement date;
•
A “No Cancellation Requested” or “Cancellation Requested” Cancellation Status;
•
An “Ineligible” or “<empty>47” Eligibility Status;
•
An “Accepted” Validation Status;
•
An “Already Matched”, “Matching Not Required” or “Matched” Matching Status;
•
A “CoSD To Be Released”48, “CoSD To Be Cancelled”49 or “<empty>” CoSD Status;
•
A “Released” Hold And Release Status;
•
An “Unsettled” or “<empty>” Settlement Status.
The function then submits each instruction that meets the above criteria for a complementary check to
the Linked Eligibility Check function.
46 The Individual Settlement Instructions are submitted continuously for a first analysis of their eligibility or following an update that can make them
eligible.
47 “<empty>” is the value at the creation or at the revalidation of the Individual settlement instruction (c.f. §.4.3.2.2 Settlement and Maintenance
Instruction Status)
48 “CoSD To Be Released” is a CoSD status used for the release of the original instruction (c.f. Use Case UC-SRI-6 Conditional Securities Delivery
Instruction, c.f. value of ISI Status entity in the Instruction & Validation module)
49 “CoSD To Be Cancelled” is a CoSD status used for the cancellation of the original instruction (c.f. Use Case UC-SRI-6 Conditional Securities Delivery
Instruction, c.f. value of ISI Status entity in the Instruction & Validation module)
Final_T2S_GFS_110.doc
Page 279
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
2 – Continuous Eligibility Check
During the settlement day, and out of the Start of Day period, this function applies on each individual
settlement instructions received the successive checks below.
Intended settlement date check
Individual settlement instruction with an intended settlement date equal to the current settlement date or
earlier {T2S.05.610} {T2S.05.625} are submitted to the Cut-off time check.
Otherwise they are sent to the Updating Instruction Status function as ineligible50.
Cut-off time check
The function checks that the individual settlement instructions are received in T2S (Entry Date/Time)
before a pre-defined time associated to each of the following individual settlement instructions
{T2S.05.610} {T2S.05.625}:
•
“DVP” individual settlement instructions {T2S.03.250} {T2S.07.100};
•
Bilaterally agreed treasury management individual settlement instructions {T2S.03.270}
{T2S.07.110};
•
“FOP” individual settlement instructions {T2S.03.280} {T2S.07.110};
•
Central bank operations {T2S.03.290} {T2S.07.110}.
Individual settlement instructions that comply with the Cut-off time check are submitted to the Status
check.
Otherwise they are sent to the Updating Instruction Status function as ineligible.
Status check
The function checks that the individual settlement instructions meet the following statuses and values
{T2S.05.620}:
•
An “<empty>” Eligibility Status;
•
An “Accepted” Validation Status;
•
An “Already Matched”, “Matching Not Required” or “Matched” Matching Status;
•
A “CoSD To Be Released” or “CoSD To Be Cancelled” or “<empty>” CoSD Status;
{T2S.09.220}
•
50
A “No Cancellation Requested” or “Cancellation Requested” Cancellation Status;
Ie with the eligibility status to be updated with an “Ineligible” value
Final_T2S_GFS_110.doc
Page 280
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
A “Released” Hold And Release Status51. {T2S.05.625}
Individual settlement instructions that comply with the Status check are sent to the Linked Eligibility
Check function.
Otherwise they are sent to the Updating Instruction Status function as ineligible.
3 – Linked Eligibility Check52
Linked individual settlement instructions check
This function applies complementary checks to the individual settlement instruction received from the
functions above according to its Link Type (hereafter referred as link: “With”, “After”, “Before”, “Info”,
“Starting leg”, “Closing leg”).
The received individual settlement instructions with no link, with a link “Info” or “starting leg”
{T2S.09.100} are sent to the Updating Instruction Status function as eligible53.
Otherwise the function searches in the data store, the instructions that are linked to the received
individual settlement instruction (hereafter referred as linked instructions) and checks the eligibility
through the following steps depending on the value of the link. {T2S.05.147} {T2S.05.148}
Eligibility for linked instructions with a link “With”
For the received individual settlement instruction having a link “With”: {T2S.05.147}
•
When linked instructions are found, and should they comply with the eligibility criteria listed
above, all the linked instructions are sent to the Updating Instruction Status function as
eligible;
•
Otherwise the received individual settlement instruction is sent to the Updating Instruction
Status function as ineligible.
Eligibility for linked instructions with a link “Before”
For the received individual settlement instruction with a link “Before”: {T2S.09.100} {T2S.09.110}
{T2S.05.147}
•
When the linked instruction with a link “After” is found, and should this latter comply with the
eligibility criteria listed above, both linked instructions are sent to the Updating Instruction
Status function as eligible;
51
Split into party hold, CoSD hold, Deviating instructing party hold under consideration for the following version. C.f. § Settlement and Maintenance
Instruction Status.
52
Individual settlement instructions are submitted to this function both following a check in Start Of Day Eligibility Check and in Continuous Eligibility
Check.
53
I.e. with the eligibility status to be updated with an “Eligible” value.
Final_T2S_GFS_110.doc
Page 281
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
•
Otherwise only the received settlement instruction with the link “Before” is sent to the
Updating Instruction Status function as eligible.
Eligibility for linked instructions with a link “After”
For the received individual settlement instruction with a link “After”: {T2S.09.100} {T2S.09.110}
{T2S.05.147}
•
When the linked instruction with a link “Before” is found:
-
with a status eligibility “Eligible”, the received instruction is sent to the Updating
Instruction Status function as eligible,
-
with a status eligibility “<empty>”, and should this latter comply with the eligibility
criteria listed above, both linked instructions are sent to the Updating Instruction Status
function as eligible;
•
Otherwise the received settlement instruction is sent to the Updating Instruction Status
function as ineligible.
Eligibility for linked instructions as repos
For the received individual settlement instruction with an Instruction Type “DVP” and a link “Closing Leg”:
{T2S.05.186}
•
When the linked instruction with a link “Starting Leg” is found and has a settlement status
“Settled” the received instruction is sent to the Updating Instruction Status function as
eligible;
•
Otherwise the received settlement instruction is sent to the Updating Instruction Status
function as ineligible.
4 – Updating Instruction Status
This function updates their eligibility status:
•
With the value “Eligible” for individual settlement instructions received as eligible from the
functions upfront;
•
With the value “Ineligible” for individual settlement instructions received as ineligible from
the functions upfront.
The individual settlement instructions with an eligibility status “Eligible” are then sent to the
Standardisation and Preparation to Settlement module {T2S.05.600}.
Final_T2S_GFS_110.doc
Page 282
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
5 – Fail Management
At the reception of an “End Of Day” time event, the function updates the Settlement Status to “Unsettled”
for individual settlement instructions that are ineligible:
•
Since they have an Hold and Release status value equal to "On Hold" at the end of their
intended settlement date; {T2S.05.370}{T2S.05.625}
•
Since they are linked to a missing linked instruction; {T2S.05.625}
•
Since they have been received by the Settlement Eligibility module after their cut-off time.
{T2S.05.625}
Then, the function sends an “Instruction Status” information to the Status Management module giving the
reason of this failure.
These individual settlement instructions with an “Unsettled” settlement status are recycled within their
recycling period, or cancelled at the end of this period, by the Instruction Maintenance module
{T2S.05.460}.
6 - Periodic check for ineligible linked instructions
Individual settlement instructions with a link “After”, “With” or “Closing Leg” that enter in the system
before (older Entry Date/Time) their respective linked individual settlement instruction are set to an
eligibility status “Ineligible”.
Therefore, the Settlement Eligibility module has to submit again these former ineligible individual
settlement instructions to an eligibility check, once their respective linked settlement instruction have
entered the system and become eligible.
To do so, this function achieves the following actions, on a periodic timeframe:
•
Selects “Ineligible” individual settlement instructions with a link “After”, “With” or “Closing
Leg”;
•
Submits the selected individual settlement instructions to the Continuous Eligibility check
function.
3.4.11.4. Description of the Input/Output of the module
FLOW
IN/OUT
Matching Not Required In
or Already Matched
individual settlement
instructions (A)
Final_T2S_GFS_110.doc
DESCRIPTION
Matching Status
FROM
TO
Instruction
Validation
Page 283
T2S General Functional Specifications
Functional Description
Lifecycle Management and Matching
FLOW
IN/OUT
DESCRIPTION
FROM
Matched individual
In
settlement instructions
(B)
Matching Status
Instruction
Matching
CoSD To Be Releases
In
or CoSD To Be
Cancelled individual
settlement instructions
(C)
CoSD Status
Instruction
Maintenance
Eligible individual
Out
settlement instructions
(D)
Eligibility Status
TO
Standardisation
and
Preparation to
Settlement
Instruction Status
Information (E)
Out
Status
Management
Time Event – SoD (F)
In
Start of Day
Scheduling
Time Event (G)
In
End of Day
Scheduling
Time Event – EoD (H)
In
End of Day
Scheduling
3.4.11.5. Data accessed by the module
DATA
ACCESS MODE
COMMENT
STATIC DATA
Operating day
Read
Status of the settlement day:
cut-off for intraday DVP (1 or 2 global
deadlines depending on the chosen
option - see open issue in T2S.03.260)
cut-off for bilaterally agreed treasury
management intraday individual
settlement instructions
cut-off for intraday FOP
cut-off for NCB operations
deadline for 1st night-time settlement
cycle
DYNAMIC DATA
Individual Settlement Instruction
Read
Intended settlement date
Instruction type (DVP, FOP)
Individual Settlement Instruction Status
Modify
Eligible Status updated to “Eligible” or
“Ineligible”
Individual Settlement Instruction Link
Read
Link type and link indicator
Final_T2S_GFS_110.doc
Page 284
T2S General Functional Specifications
Functional Description
Settlement
3.5. Settlement
3.5.1. General Introduction
The modules belonging to the Settlement domain are in charge of the settlement both on a continuous
basis during the day-time and in cycles and sequences54 during the night-time. Their objectives are to
maximise the volume and value of settlement with the available securities and cash resources, and to
minimise the time for settlement.
Once the instructions are set as eligible, they are prepared for settlement: transactions are created in a
standard format, taking notably into account specific use-cases such as cross-CSD settlements (module
“Standardisation and Preparation to Settlement”). Transactions are routed for settlement, either one after
the other in the day-time or grouped in sequences for the night-time (module “Sequencing”). Since
priorities are affected ahead of the Sequencing module, and used only after, during the optimisation
process {T2S.07.130}, no prioritisation function remains in the module itself.
During the day-time, transactions are submitted systematically to a first settlement attempt (module
“Validation, Provisioning and Booking”). If not successful, recycling through optimisation processes tries to
identify sets of transactions to be settled together, in order to resolve gridlocks (module “Recycling and
Optimisation”). During the night-time, sequenced Settlement transactions are submitted together at once
to the optimisation process, through the module “Recycling and Optimisation”. Lastly, at the end of the
last night cycle and during the last 15 minutes of day-time, partial settlement procedures are used if
requested.
Both for day-time and night-time, auto-collateralisation procedures are used in order to reduce the
number of lacks of cash (module “Auto-collateralisation”).
54
Gathering of settlement transactions according to the type of settlement transaction managed within a cycle
Final_T2S_GFS_110.doc
Page 285
T2S General Functional Specifications
Functional Description
Settlement
LIQUIDITY MANAGEMENT
Liquidity
Blocking
Request
Liquidity
Transaction
OPERATIONAL
SERVICES
LCMM
Individual
Settlement Instruction
[Eligible]
Request
End of
Process Event
Time Event
Answer
SETTLEMENT
Standardisation
and Preparation
To Settlement
Actions on
Transactions
& Limits
Analyser
EoD Cash
Restrict Release
Information
Manager
Harmonised Transaction
Generator
End of Last
Cycle
Information
End of Cycle
Information
Settlement Transaction
[Created]
Sequencing
Routing
Cut-off Processing
Night-time Sequencing
Collection
[Collection
Queued]
Validation
Provisioning &
Booking
End of Day Release
End of
Sequence
Event
Sequence
Ready Event
Recycling & Optimisation
Intraday Restriction
Check
Optimisation Algorithm Manager
Earmarking
Restriction
Manager
Optimisation
Algorithms
EoD
Intraday
Credit Rbt
Event
Limits Check
Decreased
NCB Limits
Event
Simulated Provision-Checking
Provision Checking
Pre-empted
Liquidity
Information
Simulated
Auto-collateralisation
Request
Pre-empting
Intraday Credit
Reimbursement
Request
Auto-collateralisation
Request
Simulated
Auto-collateralisation
Answer
Booking
Pending
Intraday Credit
Auto-collateralisation
Settlement Status
Transaction
Status
Information
Auto-collateralisation
Manager
LIQUIDITY
MANAGEMENT
Forced RTGS
Transfer
Intraday Credit Provider
Autocollateralisation
Answer
Rebuilding
securities positions
or cash balances
Intraday Credit
Reimbursement
Manager
Eligibility and AC Limits Check
Collateral Transaction
Generator
Collateral Selection
Dynamic Reimbursement
Rebuilding of
cash balances
Rebuilding of
security
positions
Rebuilding
report
Liquidity Transfer
Booking
Information
Liquidity Blocking
Status Information
Floor/Ceiling
Information
Instruction
Status
Information
Collateral
Settlement
Information
Restriction
Status
Information
Legend:
Group of functions
OPERATIONAL SERVICES
Final_T2S_GFS_110.doc
LIQUIDITY MANAGEMENT
LCMM
Page 286
T2S General Functional Specifications
Functional Description
Settlement
3.5.2. Dynamic data managed by the domain
3.5.2.1. Diagram of the dynamic data related to settlement
3.5.2.2. List of dynamic data managed by the settlement domain
Dynamic data are shared with Life Cycle Management and Matching and Liquidity Management domains.
The settlement domain is managing data related to:
•
Settlement transactions, Movements Net Flows, Collection of Settlement transactions;
•
Securities Positions and Cash Balances, including the management of restrictions
(Earmarking, Segregation, Blocking, Reservation and CoSD Blocking);
•
Limits utilisation and their journaling.
3.5.2.3. Description of the data related to settlement transactions
Settlement transaction Definition
The Settlement transaction is designed in the Data Model as an entity optimised for the settlement
process, i.e.:
•
It contains the main data requested for the settlement (debited and credited accounts,
quantity or amount, priority, ISO transaction code…);
Final_T2S_GFS_110.doc
Page 287
T2S General Functional Specifications
Functional Description
Settlement
•
It is the single and common entity that contains these data for their processing in the
Settlement domain should they relate to settlement instructions, restriction set-up, liquidity
transfer orders, auto-collateralisation.
On the basis of eligible Individual Settlement Instructions managed by the LCMM domain, Settlement
transactions are created within the Settlement domain by the Standardisation and Preparation to
Settlement (SPS) module.
In addition, Settlement transactions are also created in case of validation of liquidity transfer orders and
of set-up of an auto-collateralisation.
Settlement transactions are then updated and cancelled only in the Settlement domain at the end of each
settlement day or upon a request for cancellation due to an action occurring on the associated Individual
Settlement Instruction or liquidity transfer orders.
The Settlement transaction entity contains:
•
General information: Sender and Receiver Parties, Individual Settlement Instructions, Entry
date/time;
•
Settlement information: Settlement date/time, Settlement transaction Type (DVP, FOP,
PFOD, DWP, DVD), ISO Transaction Code (TRAD, MKUP, MKDN, SUBS, REDM, OWNE, OWNI,
SETR, NETT, POOL, REPU, RVPO, CNCB, COLL, SECL, SECB, PLAC), Transaction Category,
Settlement transaction Status, Priority (Reserved, Top, High, Normal);
•
Optimisation information: Partial Settlement Indicator, Receiver Auto-collateralisation Flow
Agreement, Reason for Settlement Failure;
•
Restriction references: Restriction references given by the T2S parties for the execution of
their Individual Settlement Instructions and stored in the entity Linked Restrictions;
•
And a pool of movements on securities (0,n) and/or cash (0,1) accounts between two
participants recorded in the Security Movement and in the Cash Movement entities
associated to the Settlement transaction.
The Securities Movement Entity contains:
•
A First Account attribute storing the reference of the Securities Account from which the
securities are transferred and a Final Account attribute storing the reference of the Securities
Account to which the securities are transferred. These accounts, that always belong to the
same CSD, can be identified as Participant, Mirror, Omnibus or Inter CSD accounts according
to the stored data in Entity CSD Account Link;
•
A Security reference to the Security (ISIN);
•
The Quantity of securities to transfer from the First Account to the Final account;
Final_T2S_GFS_110.doc
Page 288
T2S General Functional Specifications
Functional Description
Settlement
•
The Partial Quantity of securities, to transfer from the First Account to the Final account filled
by the module Recycling & Optimisation in case of a partial settlement;
•
The First Position which stores the reference of the Securities Position which is debited for
the First Account;
•
The Final Position which stores the reference of the Securities Position which is credited for
the Final Account.
The Cash Movement Entity contains:
•
A First Account attribute storing the reference of the T2S dedicated cash account from which
the cash is transferred and a Final Account storing the reference of the T2S dedicated cash
account to which the cash is transferred;
•
A Currency reference to the Currency Entity;
•
The Amount to transfer from the First Account to the Final account;
•
The First Balance which stores the reference of the Cash Balance that is debited for the First
Account;
•
The Final Balance which stores the reference of the Cash Balance that is credited for the
Final Account.
All the account references within the movements are linked to specific securities positions or cash
balances of the accounts (see the description of the restrictions for details regarding the management of
restricted positions within the accounts).
Final_T2S_GFS_110.doc
Page 289
T2S General Functional Specifications
Functional Description
Settlement
Settlement transaction lifecycle
STATUS
FROM MODULE
(SET BY)
DEFINITION
TO MODULE
(USED BY)
CREATED
First status
SPS
Sequencing
SEQUENCED
Selected for the next sequence
Sequencing
R&O
SETTLEMENT
IN PROCESS
Blocked by VPB for booking
VPB
VPB
UNSETTLED
Provisioning not successful, needs
to be recycled by R&O55
VPB
R&O
PARTIALLY
SETTLED
End status, in case of partial
settlement (when and if possible)
VPB
Status Management
SETTLED
End status
VPB
Status Management
55
Status Management
Transactions related to Restrictions and Liquidity Transfers are not recycled.
Final_T2S_GFS_110.doc
Page 290
T2S General Functional Specifications
Functional Description
Settlement
STATUS
FROM MODULE
(SET BY)
DEFINITION
CANCELLED
End status
TO MODULE
(USED BY)
SPS
Sequencing
These statuses are only internal statuses managed within the Settlement domain. Information delivered to
the parties only covers the statuses of the Individual Settlement Instruction, which reflects the status of
the Settlement transaction in the following cases: “Unsettled”, “Partially Settled” and “Settled”.
Relations between Individual Settlement Instructions and Settlement transactions
In most of the cases, two matched Individual Settlement Instructions lead to the creation of one
Settlement transaction.
For Conditional Securities Deliveries (CoSD), the two Individual Settlement Instructions lead to more than
one Settlement transaction: one Settlement transaction is created for the CoSD Blocking on the basis of
the two initial Individual Settlement Instructions, and a second Settlement transaction for the CoSD to be
Released (or CoSD to be Cancelled) upon the release (or the cancellation) of Individual Settlement
Instructions subject to a CoSD. The release or cancellation is handled through a maintenance instruction
which does not become eligible, leaving the relationship as two eligible Individual Settlement Instructions
for two Settlement transactions.
For Cross-CSD, only one Settlement transaction is created, containing as many movements as needed for
the realignment.
Rules for updating the statuses of Individual Settlement Instructions and Settlement transactions
The update of the statuses of an Individual Settlement Instruction within the Settlement Domain can only
occur in the following cases:
•
In case of settlement: within the module Validation, Provisioning and Booking (VPB), the
status value of the Settlement transaction is moved to “Unsettled”, “Settled” or “Partially
Settled”, and the settlement status of the Individual Settlement Instructions is moved
accordingly to “Unsettled”, “Settled” or “Partially Settled”;
•
In case of settlement of a CoSD blocking Settlement transaction, the status of the Settlement
transaction is set to “Settled”, and the CoSD Status of the associated Individual Settlement
Instructions is set to “CoSD on Hold” and the Eligibility Status of the associated Individual
Settlement Instructions to “empty”;
•
In case of settlement of a CoSD release Settlement transaction, the status of the Settlement
transaction is set to “Settled” and the CoSD Status is set back to “empty”;
Final_T2S_GFS_110.doc
Page 291
T2S General Functional Specifications
Functional Description
Settlement
•
In case of settlement of a CoSD cancellation Settlement transaction,
-
if CoSD blocking has not taken place, the status of the Settlement transaction is set to
“Cancelled”, and the Cancellation status of the associated Individual Settlement
Instructions is set to “Cancelled”;
-
if CoSD blocking has taken place, the Eligibility Statuses of the initial Individual
Settlement Instructions are set to “Eligible”, and following the settlement of the CoSD
cancellation Settlement transaction, the Cancellation status of the initial CoSD Individual
Settlement Instructions is set to “Cancelled”, and the CoSD Status of these Individual
Settlement Instructions is set back to “empty”.
As a result, only the statuses of the Individual Settlement Instructions that are linked to a settlement
attempt are updated in the Settlement domain. This choice has been made to ensure that these statuses
are managed through a single and consistent update by the Domain in charge of the settlement actions
leading to these statuses.
Links between Settlement transactions
Settlement transactions can be linked according to:
•
The link between the underlying Individual Settlement Instructions, set by T2S parties
(external link: “With”, “After”, “Before”);
•
The internal link generated in T2S in case of CoSD, cross-CSD, restriction and autocollateralisation (internal link: “Auto-collateralisation”, “Pre-emption For Restriction” , “Use of
Restriction”).
These links are taken into account when building the Collection of Settlement transactions to be submitted
to the module Validation, Provisioning and Booking which settles the Collection on an “all or none” basis
(or in due sequence for “After”/”Before” links).
The links between Settlement transactions are managed with two entities:
•
“Settlement Transaction Link” which specifies the links associated to a Settlement
transaction;
•
“Settlement Transaction Link Set” which stores a set of Settlement transaction links56.
Collection Definition
A Collection of Settlement transactions is a set of (linked) Settlement transactions, as defined above,
submitted together for a settlement attempt in the Validation Provisioning and Booking module.
56
A set of settlement transaction links is a group of settlement transaction links.
Final_T2S_GFS_110.doc
Page 292
T2S General Functional Specifications
Functional Description
Settlement
A Collection of Settlement transactions can contain from 057 to many Settlement transactions
A Settlement transaction may belong to 058 or many collections; however, a Settlement transaction can
only belong to one and only one collection with a status "Collection Queued" at a given time.
The Collection entity contains one attribute, the Collection Status. The Collection entity is linked to the
Provisioning Net Flows entities in order to store the sum, per securities position or cash balance, of credit
and debit resulting from the Settlement transactions that are part of a Collection of Settlement
transactions.
Collection lifecycle59
57
During the optimisation process a collection can be empty as a result of a de-selection of settlement transactions.
58
Because a collection is an internal temporary object deleted at the end of the Validation Provisioning and Booking module, at a given time a
settlement transaction can belong to none collection.
59 a Collection is an internal temporary object deleted in any case, settlement or not of the settlement transactions contained in the collection, at the
end of the Validation Provisioning and Booking module.
Final_T2S_GFS_110.doc
Page 293
T2S General Functional Specifications
Functional Description
Settlement
STATUS
Collection Created
Collection Queued
DEFINITION
First status
Queued for real-time settlement
FROM MODULE
(SET BY)
TO MODULE
(USED BY)
Sequencing
Sequencing
Auto-collateralisation
Auto-collateralisation
R&O
R&O
Sequencing
VPB
Auto-collateralisation
VPB
R&O
VPB
Collection Selected
Submitted to one optimisation algorithm
R&O
R&O
Collection Settlable
Ready for booking
R&O
R&O
Collection Being Processed
Blocked by VPB for booking
VPB
VPB
Collection Deleted
Final status
VPB
SPS
Sequencing
R&O
3.5.2.4. Diagram of the dynamic data related to limits and restrictions
Final_T2S_GFS_110.doc
Page 294
T2S General Functional Specifications
Functional Description
Settlement
3.5.2.5. Description of the data related to limits
Limits data can be divided in two categories of entities:
•
Limits and Limits Groups which are defined and maintained by NCBs and settlement/payment
banks via static data updates;
•
Limits utilisation and their journaling which are managed by the Settlement domain.
Limits and Limits Groups
In T2S, three types of limits can be set up:
•
The net buying Limits set by a settlement/payment bank on security account(s) of a T2S
Party with one or more CSDs. It limits the cash available for the settlement on these
securities accounts when using the T2S Dedicated Cash Account of this settlement/payment
bank;
•
The auto-collateralisation limit set by a settlement/payment bank on securities account(s) of
a T2S Party (referred as the “Settlement-bank Auto-collateralisation Limit” in the domain). It
limits the amount of intraday credit that can be obtained through auto-collateralisation for
the settlement of instructions pertaining to these securities accounts when using the T2S
Dedicated Cash Account of this settlement/payment bank;
•
The auto-collateralisation limit set by an NCB to a T2S Party (referred as “Autocollateralisation NCB Limit” in the domain). It limits the net amount of intraday credit
provided by the NCB to a T2S Party for all its T2S dedicated cash accounts owned with this
NCB. This limit overrides other limits.
A Limit can apply to one or several securities accounts or T2S Dedicated Cash Accounts of a T2S party.
The Link between the limit and the accounts to which a limit applies is stored in the Limit Groups entity.
The Limit entity contains:
•
A Limit Type which specifies a classification for the limit. Possible values are (Net buying,
Auto-collateralisation or NCB);
•
A Limit Amount which specifies the limit amount for the credit consumer for the relevant T2S
Dedicated cash account;
•
A Valid From Timestamp attribute which specifies the date from which the credit limit is valid.
The following table summarises how the limits are expressed, which accounts are concerned and which
Settlement transactions are involved:
Final_T2S_GFS_110.doc
Page 295
T2S General Functional Specifications
Functional Description
Settlement
TYPE OF LIMITS
RELATED ACCOUNT
NCB Limits
T2S dedicated Cash accounts
Auto-Collateralisation Limits
Security accounts
Net Buying Limits
Security accounts
INVOLVED SETTLEMENT TRANSACTIONS
Auto-collateralisation Settlement transactions
All Settlement transactions except the Autocollateralisation Settlement transactions
Limits Utilisation and journaling
The Limit Utilisation aims at checking the compliance with the remaining amount at each settlement
attempt that may impact these limits.
The Limit Utilisation entity contains:
•
The Currency of the Limit amounts;
•
The Limit Utilisation which specifies the current amount of liquidity drawn down by the T2S
Party;
•
The Remaining Limit which specifies the current amount of liquidity available to the T2S
Party;
•
A Date which specifies the T2S settlement day to which the Limit Utilisation applies.
The Journaling of Limit Utilisation tracks, for audit trail purposes, each change in a T2S Party Limit
utilisation induced by a Settlement transaction.
The Journaling of Limit Utilisation entity contains:
•
A Transaction Reference of the Settlement transaction, which updates the Limit Utilisation;
•
The Currency of the Limit amounts;
•
A Debit Credit attribute which specifies the increasing or the decreasing of the Limit
Utilisation;
•
The Amount which specifies the amount of liquidity drawn down by the T2S Party;
•
The Remaining Limit After which specifies the amount of liquidity available to the T2S Party;
•
The Date to which T2S the Limit Utilisation applies.
Final_T2S_GFS_110.doc
Page 296
T2S General Functional Specifications
Functional Description
Settlement
3.5.2.6. Description of the data related to restrictions (reservation, blocking, CoSD blocking,
segregation or earmarking)
Restriction types
In T2S, several restrictions types can be set up on:
•
A T2S Party, a Security, a Currency or a T2S Dedicated Cash Account (blocking);
•
A Securities Account (blocking, segregation or earmarking);
•
A Securities Position (reservation, blocking, CoSD blocking, segregation or earmarking)
•
A Cash Balance (reservation or blocking).
Each of those restrictions types has its own characteristics which result in a specific settlement processing
for its set-up, use or cancellation.
A restrictions type is specified within T2S by a Static data update in the Market specific restriction type
entity. It can be specified by:
•
The T2S Operator for common purpose and applies to every T2S Party whatever their CSD
(e.g. restrictions such as blocking, reservation or earmarking for each auto-collateralisation
services in T2S);
•
A CSD for specific purpose and applies only to the T2S Party of this CSD (e.g. segregations,
earmarking, etc.).
Final_T2S_GFS_110.doc
Page 297
T2S General Functional Specifications
Functional Description
Settlement
The characteristics of each restriction type are summarised in the following table:
EARMARKING
SEGREGATION
BLOCKING*
Position Blocking Instruction
Instruction
with the "earmarking"
with the "earmarking"
restiction type and
restiction type and
applicable "Market specific applicable "Market specific
restriction type"
restriction type"
SET UP
Restriction
classification
Market specific
restriction type
Securities Position or Securities Account
"earmarking"
Settlement Instruction
with a reservation flag
{T2S.09.180}
with the "CoSD blocking"
restriction type
T2S based on
the CoSD rules specified in
Static Data
Securities Position or Cash Balance
"segregation"
Allowed
"blocking"
"reservation"
Allowed
Not allowed
"blocking"
Not allowed
Yes, with the available quantity or amount in the main securities position or cash balance
{T2S.07.350}
{T2S.07.351}
Partial execution
Additional
pre-emption in
case of partial
execution
No, partially filled blocking instruction are not completed
{T2S.07.350}
No
Recycling
Blocking Status or Settlement Status
Confirmation
USE
No reference to any
Restriction Reference
No partial execution
Yes of any incoming
securities or cash which
can completement a
partially filled reservation
{T2S.07.351}
No
No
Reservation Status or
Settlement Status
Yes
Blocking Status
{T2S.09.230}
No automatic detection
No release (apply only to securities)
{T2S.07.380}
End of day
release
Not allowed
Settlement Instruction
Settlement Instruction
COSD Release by the
No reference to initial
referring to the Restriction referring to the Restriction
administering party(ies)
blocking instruction but
Reference sent in the
Reference sent in the
resulting in the release of
Only reference to position
"Blocking status"
"Blocking status"
the intial Settlement
and to attributes of
{T2S.09.190}
{T2S.09.190}
Instruction with the
position earmarketd or
{T2S.07.340}
{T2S.07.340}
reference
segregated
{T2S.07.360}
{T2S.07.360}
{T2S.09.220}
{T2S.07.370}
{T2S.07.370}
Automatic detection during
the provisioning of a
Automatic
Settlement Instruction
detection by T2S depending of the Marketspecific restriction type
specification
RELEASE / CANCELLATION
COSD BLOCKING
Position Blocking
Instruction
Previously specified by the T2S operator or by CSDs
Subordinate
position
restriction
{T2S.11.650}
Instruction
with the "blocking"
restriction type
T2S Party which owns of the account
Instructing actor
Apply to
{T2S.11.650}
RESERVATION
Reservation Instruction
Cash: automatic Ed of Day release and Start of Day regeneration {T2S.07.380}
Securities: No release {T2S.07.380} {T2S.09.240}
Date > Valid timestamp {T2S.10.030}
End validity
Cancellation
pre-use
Position unblocking instruction
Cancellation
post-use
Automated deletion following entire use
except for some type of earmarking which are automaticly reconstituted
(e.g. for auto-collateralisation purpose)
No
Future un-reserve
instruction UR §13.4
(footnote p39)
COSD cancellation
{T2S.09.250}
Automated deletion following entire use
{T2S.09.200}
* The blocking as Intraday settlement restriction on a T2S Party, a Security, a Currency or an Account is not described in this table since it results as a
prohibition of the entire settlement and not as a specific settlement processing.
Intraday settlement restriction
An intraday settlement restriction is a blocking of a T2S Party, a Security, a Currency, a Securities Account
or a T2S Dedicated Cash Account which can be set up at any time of the settlement day.
Final_T2S_GFS_110.doc
Page 298
T2S General Functional Specifications
Functional Description
Settlement
It is handled within T2S as Static Data updates and specified in the following entities: Party Restriction,
Security Restriction, Securities Account Restriction or T2S Dedicated Cash Account Restriction.
Once an intraday settlement restriction is set-up through a Static Data update, no booking is allowed on
the Settlement transaction impacted by this restriction (i.e. using the intraday restricted T2S Party,
Security, currency or accounts). This is achieved with a check of the intraday settlement restriction before
any settlement attempt at the entry of the Validation, Provisioning and Booking module.
Restrictions at the securities account level (segregation or earmarking for auto-collateralisation)
A T2S Party can set up a restriction at the securities account level to limit the use of all securities
positions for a specific purpose. As for the intraday settlement restriction, such restriction is handled
within T2S as Static Data updates and specified in the Securities Account Restriction.
Except the check on intraday settlement restriction, only the earmarking restriction for an autocollateralisation purpose is handled as restriction at the securities account level by the Settlement domain.
This check is performed within the Auto-collateralisation module before every auto-collateralisation to
check the T2S Party’s agreement to use the considered securities account as collateral on stock.
Restrictions at the securities position or cash balance level (excepted earmarking)
A T2S Party can restrict the use of a securities position in a securities account or the use of a cash
balance in a T2S Dedicated Cash Account. Those restrictions are managed through specific occurrences of
the entity Securities position or of the entity Cash balances of the same account, as described below:
For cash, the T2S Dedicated Cash Account can be linked to several Cash Balances (all held in the same
currency):
•
One (and only one) Cash Balance with no indicator in the Restriction Type attribute that is
the main Cash Balance for this T2S Dedicated Cash Account;
•
A restricted Cash Balance for each reservation with an indicator in the Restriction Type
attribute which is linked to the “Reservation” restriction type in the Market Specific
Restriction type;
•
A restricted Cash Balance for each blocking with an indicator in the Restriction Type attribute
which is linked to the “Blocking” restriction type in the Market Specific Restriction type;
For securities, the Securities Account can be linked to several Securities Positions for each considered
ISIN:
•
One (and only one) Securities Positions with no indicator in the Restriction Type attribute,
that is the main Securities Positions for this ISIN in the Securities Account;
Final_T2S_GFS_110.doc
Page 299
T2S General Functional Specifications
Functional Description
Settlement
•
A restricted Securities Positions for each reservation with an indicator in the Restriction Type
attribute which is linked to the “Reservation” restriction type in the Market Specific
Restriction type;
•
A restricted Securities Positions for each blocking with an indicator in the Restriction Type
attribute which is linked to the “Blocking” restriction type in the Market Specific Restriction
type;
•
One (and only one) restricted Securities Positions for a segregation purpose with an indicator
in the Restriction Type attribute which is linked to the “Segregation” restriction type
corresponding to this purpose in the Market Specific Restriction type.
There is one single restricted Cash Balance or Securities Positions per reservation or blocking instruction.
Each one is linked to a unique “Restriction Reference” generated during its set-up. This reference is sent
to the T2S Party for use in a future settlement instruction. A restricted Cash Balance or Securities Position
is deleted following its use or upon a cancellation instruction before its use.
A restricted “Securities Positions” for segregation can be increased, decreased or cancelled after its setup. It is linked to a “Restriction Reference” generated during the set-up and sent back to the T2S Party
after every update to the T2S Party for use in future settlement instructions.
To set up those restrictions, T2S receives a blocking instruction (with “blocking” or the relevant
“segregation” restriction type) or a reservation instruction. The settlements of the related Settlement
transactions follow the standard settlement process with a provisioning and a booking in the Validation,
Provisioning and Booking module. The booking results in the debit of the main Cash Balance or the main
Securities Positions to a restricted one in the same account.
The use of those restrictions depends of the indication of the relevant “Restriction Reference” in the
settlement instruction and result in a booking which debits the restricted Cash Balance or the restricted
Securities Positions and credits the main one in the same account.
Except in case of intraday settlement restriction, if both are set up, the restriction at the securities
position level overrides the restriction at the securities account level.
Earmarking Restriction at the securities position level
A T2S Party can flag a Securities Position as eligible for a specific purpose. This is achieved by setting up
an Earmarking Limit Restriction associated to the main Securities Position for the considered ISIN in the
Securities Account.
To set up an earmarking, T2S receives a blocking instruction (with the relevant “earmarking” restriction
type). The settlements of the related Settlement transactions follow a specific settlement process (close to
Final_T2S_GFS_110.doc
Page 300
T2S General Functional Specifications
Functional Description
Settlement
a limit management process) in the Validation, Provisioning and Booking module according to the fact
that:
•
An earmarking can be set up:
-
Without specified quantity (i.e. all the available amount is always eligible for the
earmarking purpose);
•
For a quantity higher than the available;
Several earmarking can be set up on the available quantity of a securities position.
Their settlement does not result in any debit in the considered main Securities Position.
If specified, the quantity of an Earmarking Limit Restriction can be updated or cancelled after its set-up.
In this case, every use results in an update of the remaining amount in the earmarking. This use is not
submitted to a reference (which is not generated) but is automatically checked by the Validation,
Provisioning and Booking module upon every settlement attempt in the considered Securities Position.
3.5.3. Processing of Settlement Instructions Use Cases
3.5.3.1. Selection of representative Settlement Instructions and Liquidity Transfers use cases for
Settlement
This selection aims at limiting the description of processing to the use cases representing a variation of
each criterion (defined as the list of representative SI use cases in the table below) and at illustrating use
cases relevant for the Settlement domain selected within the table presented in the LCMM domain (see
section 3.4.3 and 3.4.4). Use cases already presented in the LCMM domain are recalled on grey
background. The current section therefore only deals with the remaining use cases.
CRITERIA
Intra-CSD
standard
settlement
Intra-CSD
Standard
No
Settlement
Instruction
No
Already Matched
No
No
UC-SI-1b
Intra-CSD
standard
settlement
Intra-CSD
Standard
No
Settlement
Instruction
No
Not Required
No
No
UC-SI-2
Linked
instructions
Intra-CSD
Standard
No
Settlement
Instruction
Yes Yes
No
No
FOCUS
Final_T2S_GFS_110.doc
CSD CONFIG
GROUP OF
INSTRUCTIONS
INSTRUCTION
TYPE
LINKED
UC-SI-1a
DESCRIPTION
COSD
AUTOCOLLAT
PROCESS
PARTIAL
REPRESENTA
TIVE USE
CASE
MATCHING
Page 301
T2S General Functional Specifications
Functional Description
Settlement
CRITERIA
Matching
Intra-CSD
Standard
No
Settlement
Instruction
No
Yes
No
No
UC-SI-4
Partial
settlement
Intra-CSD
Standard
No
Settlement
Instruction
No
Not Required/
Already Matched
Yes No
UC-SI-5
Autocollateralisatio Intra-CSD
n
Standard
No
Settlement
Instruction
No
Not Required/
Already Matched
No
Yes
UC-SI-6
Conditional
Security
Delivery
Intra-CSD
Standard
Yes
Settlement
Instruction
No
Not Required/
Already Matched
No
No
UC-SI-7
Block Trade
Intra-CSD
Block-Trade
No
Settlement
Instruction
No
Not Required/
Already Matched
No
No
UC-SI-8
Two-legged
Intra-CSD
Two-legged
No
Settlement
Instruction
No
Not Required/
Already Matched
No
No
UC-SI-9
Blocking
Intra-CSD
Standard
No
Blocking
Instruction
No
Not Required/
Already Matched
No
No
UC-SI-10
Reservation
Intra-CSD
Standard
No
Reservation
Instruction
No
Not Required/
Already Matched
No
No
UC-SI-11
Settlement of
a corporate
action with
associated
liquidity
transfer
Intra-CSD
Standard
No
Settlement
Instruction
No
Not Required/
Already Matched
No
No
UC-SI-12a
Cross CSD
settlement
Cross-CSD
Standard
No
Settlement
Instruction
No
Not Required/
Already Matched
No
No
UC-SI-12b
In-out T2S
settlement
In-out CSD
Standard
No
Settlement
Instruction
No
Not Required/
Already Matched
No
No
FOCUS
CSD CONFIG
GROUP OF
INSTRUCTIONS
INSTRUCTION
TYPE
LINKED
UC-SI-3
DESCRIPTION
COSD
AUTOCOLLAT
PROCESS
PARTIAL
REPRESENTA
TIVE USE
CASE
MATCHING
In addition, this section also integrates one additional Liquidity transfers use case due to its very
transversal nature to the Liquidity Management and Settlement domains (see section 3.5.3.10).
Final_T2S_GFS_110.doc
Page 302
T2S General Functional Specifications
Functional Description
Settlement
3.5.3.2. Processing of UC-SI-4 Intra CSD-Standard DvP with Partial Settlement
Settlement process with partial settlement
Interface
T2S
Parties
LCMM:
Instructions
Validation
Communication C1
Incoming
Instruction II1
Communication C2
Incoming
Instruction II2
LCMM:
Status
Management
LCMM:
Instructions
Matching
LCMM:
Settlement
Eligibility
SETT:
SPS
SETT:
Sequencing
SETT: VPB
SETT: R&O
Following the standard process
ISI
Accepted I1
ISI
Accepted I2
Matched I1|I2
Eligible I1|I2
Created T1
Created T1
Settlement status
Unsettled I1
Settlement status
Unsettled I2
Transaction Status
Information
(Unsettled
T1)
Instruction Status Information (Unsettled I1|I2)
Data for Settlement status
message Unsettled I1|I2
Unsettled T1
with partial amount
Alt 1
[Failure]
Transaction Status
Information
(Unsettled T1)
without
partial amount
Unsettled T1
with new partial amount
Settled T1
[Settlement]
Alt 2
Instruction Status Information (Partially settled I1|I2)
Settlement status
Partially settled I1
Settlement status
Partially settled I2
Transaction
Status Information
(Settled T1)
Data for Settlement status message
Partially settled I1|I2
Data for generation
of splitted instructions I1b|I2b
Accepted I1b|I2b
(new matching is not required)
Eligible I1b|I2b
The standard settlement process is followed
(with partiallisation if necessary)
Business assumption
Upon their entry in the Interface domain, the Communications C1 and C2 follow the standard process as
described in UC-SI-1 & 3 to their entry in the SPS module.
Processing
The Standardisation and Preparation to Settlement module generates a settlement transaction T1 from
the original individual settlement instructions I1 & I2 with all attributes requested for a potential partial
settlement:
• a Partial Settlement Indicator, confirming the applicability of partial settlement by taking into
account:
-
The agreement of T2S Parties, or partial settlement in Static Data and/or on involved
accounts level;
Final_T2S_GFS_110.doc
Page 303
T2S General Functional Specifications
Functional Description
Settlement
-
The Partial Flag of each original individual settlement instruction I1 & I2 as well as the
Partial Flag of each original individual settlement instruction linked to I1 and/or I2;
-
The mandatory partial settlement based on a CSD or CCP decision;
• the Partial applicable threshold, expressed in percentage or in absolute value:
-
Threshold defined by the relevant CSD if the settlement involves only one CSD;
-
A harmonised threshold if several CSDs are involved in the settlement or if no threshold is
defined by the CSD;
-
Threshold defined by a CCP regardless of whether the securities accounts are held with
the same CSD or with different CSDs.
The Validation Provisioning and Booking module applies a first settlement attempt on T1. Upon a fail:
• The Settlement status value of I1 & I2 is set to “Unsettled”. Information statuses are sent to the
Status Management module to be directed to the respective parties, through the Interface;
• T1 is sent to the Recycling & Optimisation module.
When the Recycling & Optimisation module selects T1 in a collection of settlement transactions during a
window where partial settlement is applicable, the module:
• Checks in the attributes of T1 if the partial settlement is allowed (i.e. attribute partial flag set to
“Yes”);
• Calculates the partial settlement ratio possible with the real position on all the considered
participant’s accounts;
• Compares if this ratio respects the applicable threshold.
If the collection is settlable with the application of partial settlement:
• the attribute partial amount/quantity of T1 is filled with the settlable identified quantity in the
Recycling & Optimisation module;
• the settlable collection including T1 is sent to the Validation Provisioning and Booking module for
a settlement attempt on the partial amount/quantity.
Alternative 1 – T1 does not settle (due to change in balance/positions since the last provisioning): T1
status is set to «unsettled », sent again to R&O, and no message is sent to Status Management.
Alternative 2 – T1 is settled for the partial amount:
• T1 status is set to “Partially Settled” in the Validation Provisioning and Booking module;
Final_T2S_GFS_110.doc
Page 304
T2S General Functional Specifications
Functional Description
Settlement
• a message is sent to the Status Management module to inform that the original individual
settlement instructions (I1&I2) set their Settlement Status value to “Partially Settled”, along with
the amount settled;
• Data is sent to the Instruction Validation module for the generation of split individual settlement
instructions I1b & I2b (for the remaining amount/quantity) getting the Validation status value
“Accepted”;
• I1b&I2b are sent to the Settlement Eligibility module;
• I1b & I2b then follow the standard settlement process, including the partial settlement process,
when applicable.
3.5.3.3. Processing of UC-SI-5 Intra CSD-Standard DvP with Auto-collateralisation
The Auto-collateralisation module is called in case of lack of:
• Cash (to establish a new intraday credit operation);
• Securities (to do a dynamic reimbursement or an automated substitution if possible).
This request can be done during both booking and optimisation processes.
Auto-collateralisation during the booking process
Final_T2S_GFS_110.doc
Page 305
T2S General Functional Specifications
Functional Description
Settlement
This option relates to a situation where the lack (on cash or on securities) is detected in the Provision
checking function in VPB module during a settlement process.
Business assumption
The description of the process from the entry of the Communications C1 and C2 till the settlement
attempt in the SPS module can be referred into the relevant UC descriptions.
This focus starts with the point where:
• the Provision checking function in the Validation Provisioning and Booking (VPB) module detects a
lack;
• a request for auto-collateralisation is sent to the Auto-collateralisation module for the identified
lack.
Processing
The processing in the Auto-collateralisation module is different for each type of lack (on cash or on
securities) mentioned in the Auto-collateralisation Request.
Lack on cash
In this case, the Auto-collateralisation module:
• Checks the eligibility of the T2S Party to collateralisation by its NCB;
• Values the requested collateral amount, resorting preferably to auto-collateralisation on flow –
when allowed by default at the securities account or at the individual settlement instruction level complemented if necessary with auto-collateralisation on stock;
• Checks the collateral value against the Auto-collateralisation limits (set by the relevant NCB or the
payment/settlement bank) applicable to the relevant securities account or T2S dedicated cash
account.
Lack on securities
In this case, the Auto-collateralisation module:
• Checks if the collateralised securities can fill in the considered lack if released;
• Attempts a dynamic reimbursement with the cash available on the T2S Dedicated cash account
complemented, if necessary, with the incoming positive cash flow.
If the available cash is insufficient to perform the dynamic reimbursement, the module attempts an
automatic substitution with available collateral.
After this processing, the module then alternatively:
Final_T2S_GFS_110.doc
Page 306
T2S General Functional Specifications
Functional Description
Settlement
• Either returns a failure message to the Provision Checking function in VPB module, if the autocollateralisation is not achievable, resulting in the individual settlement instruction being
unsettled;
• Or returns an improved collection of settlement transactions including the original settlement
transactions with the linked collateral settlement transactions, resulting in the individual
settlement instruction being settled (or not, should the balance be updated since the last
provisioning).
In case of settlement:
• The user is informed, via the Instruction Status Information sent to the Status Management
module, of the settlement of its individual settlement instruction (with use of autocollateralisation);
• The collateral management system (CMS) is informed of the settlement of the collateral
settlement transaction, via Collateral Settlement Information sent to the Status Management
module.
Otherwise, the user is informed of the fail, and all collateral settlement transactions are cancelled.
Auto-collateralisation during the optimisation process
This option relates to a situation where the lack is detected in the Simulated Provision Checking function
during a Recycling & Optimisation process:
• A Simulated Auto-collateralisation Request is sent to the Auto-collateralisation module only for
assessment of the collateralisation feasibility;
• The collateral settlement transactions are ultimately created inside VPB module, following the
process described above when the settlement transaction is sent to VPB and processed for actual
settlement.
Final_T2S_GFS_110.doc
Page 307
T2S General Functional Specifications
Functional Description
Settlement
3.5.3.4. Processing of UC-SI-6: Conditional Securities Delivery instruction
This use case covers the description of the processing of a CoSD individual settlement instruction, where
final securities and/or cash booking is dependent on the successful completion of an additional action or
event outside T2S. Three steps are described here below: the CoSD activation (a), the CoSD release (b)
and the CoSD cancellation (c).
a) CoSD Activation
This use case relates to the processing of a CoSD individual settlement instruction according to CoSD
parameters in the Static Data (“CoSD instructions”).
Business assumption
The description of the process from the entry of the CoSD Communications C1 and C2 until its processing
in the SPS module is included in the relevant UC descriptions, except for the detection of the CoSD by the
analysis of the “CoSD flag” of the incoming instruction achieved in the Instruction validation module on
the basis of CoSD Processing Analysis and CSD rules.
Processing
When CoSD individual settlement instructions I1 & I2 enter the SPS module, this module checks in the
attributes of I1 and I2 if CoSD functionality shall be activated (i.e. if the attribute CoSD flag is set to “Yes”
and the restriction reference is empty). Individual settlement instructions setting up a CoSD activation
generate a CoSD Blocking settlement transaction T1 to block the securities or cash needed to settle I1 &
I2 when they are released by the Administering Parties (cf § b – CoSD Release).
Final_T2S_GFS_110.doc
Page 308
T2S General Functional Specifications
Functional Description
Settlement
After being generated in SPS, T1 is sent to the Sequencing module which then sends it to VPB for
settlement.
After the settlement attempt, T1 is:
• either unsettled, in which case each T2S Party is informed via Interface of the Settlement status
value “Unsettled” concerning its respective CoSD individual settlement instructions I1 & I2;
• or settled, in which case the individual settlement instructions are set on hold (i.e. CoSD status
“CoSD on Hold”) and their Eligibility Status is set to “empty”. In order to ensure that the blocked
securities/cash are used for the settlement of the individual settlement instruction, the restriction
reference of the individual settlement instruction is filled with the Restriction Reference of the
CoSD blocking resulting from the settlement of T1.
Then, both the T2S Actors and the Administering Parties are informed accordingly.
b) CoSD Release
This use case relates to the processing of the maintenance instructions sent by the Administering Parties
to release I1 & I2, previously blocked during the CoSD activation.
Business assumption
One by one C1, …, Cn (release maintenance instructions submitted as Communications by the
Administering Parties for the CoSD individual settlement instructions I1 & I2) are sent from the Interface,
as Incoming Instructions II1, …, IIn, to the Instruction validation module in order to be validated and
forwarded to the Instruction maintenance module.
Final_T2S_GFS_110.doc
Page 309
T2S General Functional Specifications
Functional Description
Settlement
Processing
The Instruction maintenance module records the reception of the respective release maintenance
instructions MI1, …, MIn from the relevant Administering Parties. When all the required release individual
settlement instructions are received:
• The CoSD status values of the CoSD individual settlement instructions I1 & I2 are set to “CoSD to
be released”. I1 & I2 are then sent to the Settlement Eligibility module for getting their Eligible
status to “Eligible” before being sent to SPS;
• MI1, …, MIn release maintenance instructions are set to “Executed” since the execution of the
CoSD release maintenance instructions has been taken into account.
The status value updates of the individual settlement instructions are forwarded to the Status
management module for information purposes. I1 & I2 follow the standard settlement process:
Once the individual settlement instructions are received in the SPS module, the corresponding CoSD
release settlement transaction T2 is created with:
• as many movements as needed (securities and/or cash) between the two participants’ accounts
involved in the eligible CoSD individual settlement instructions;
• the settlement transaction’s restriction reference equals to the individual settlement instruction's
restriction reference.
T2 is then forwarded – directly in day-time or through the Recycling & Optimisation module in night-time to the VPB module in order to be settled with the use of blocked securities/cash corresponding to the
CoSD blocking.
Once the CoSD release settlement transaction T2 is settled, the Settlement status values of I1 & I2 are
set to “Settled”, and an Instruction Status Information is sent to the Status Management module for the
information of Administering Parties and T2S Parties.
Final_T2S_GFS_110.doc
Page 310
T2S General Functional Specifications
Functional Description
Settlement
c) CoSD Cancellation
Settlement process for CoSD Cancellation
Interface
Administering T2S
Parties
Parties
opt1
opt2
LCMM:
Instruction
Validation
LCMM:
Instruction
Maintenance
Communication C1
Incoming
Instruction II1
Accepted MI1
Communication C2
Incoming
Instruction II2
Accepted MI2
Communication C3
Communication C4
Incoming
Instruction II3
Incoming
Instruction II4
Accepted MI3
LCMM:
Instruction
Matching
LCMM:
Settlement
Eligibility
LCMM:
Status
Management
SETT:
Sequencing
SETT: SPS
SETT: VPB
SETT: R&O
If necessary {T2S.05.470}, all the
CoSD Release maintenance instruction
Accepted MI4
Alt a)
Loop
Request Cancel Blocking Settlement Transaction T1 related to I1|I2
[I1|I2's restriction reference is empty]
Agreement message
alt
Cancels
[Related transactions’ status are different of « Settlement in process »]
Instruction Maintenance message
Executed
Data for Instruction
Maintenance message
Executed MI1|MI2
Executed CMI1|CMI2
Status executed MI1/MI2
[Related transactions’ status is « Settlement in process »]
existing T1
Rejection message with reason
The following steps are similar than fo
r the first request Drop Blocking Settlement Transaction T1
related to I1|I2
[I1|I2's restriction reference is filled]
Alt b)
The transaction’s category is set to
« CoSD Cancellation »
CoSD to be cancelled I1|I2
CoSD Eligible I1|I2
Settlement
Transaction
Created T2
alt
[day-time]
[night-time]
Created T2
Sequenced T2
Sequenced T2
Settled T2
Settlement status message
Cancelled I1|I2
Data for Settlement status message Cancelled I1|I2
due to CoSD Cancellation
due to CoSD Cancellation
Instruction Maintenance message
Executed
due to CoSD Cancellation
Cancelled I1|I2
Data for Instruction Maintenance message
Executed MI1|MI2
Settlement status message Unsettled I1|I2
due to CoSD Cancellation
Instruction Status Information (Cancelled I1|I2)
Data for Instruction
Maintenance message
Executed MI1|MI2
This use case relates to the processing of a “CoSD to be Cancelled” communications C1 and C2 sent by
the T2S Parties or Administering Parties.
Business assumption
The process differs depending on whether the CoSD blocking related to the individual settlement
instructions has already taken place or not, i.e. whether the restriction reference of the CoSD individual
settlement instruction is filled or not (c.f. CoSD Activation use case).
Final_T2S_GFS_110.doc
Page 311
T2S General Functional Specifications
Functional Description
Settlement
Processing
The Instruction maintenance module records the reception of the respective cancel maintenance request
from the relevant Administering Parties, or from T2S Parties until all the required incoming cancel
instructions are received. In this case:
• Individual settlement instructions I1 & I2 have their CoSD status values set to “CoSD to be
cancelled” (only for alternative b);
• MI1…MIn cancellation maintenance instructions are set to “Executed”, since the execution of the
CoSD cancellation maintenance instruction has been taken into account.
The status updates of the individual settlement instructions are forwarded to the Status Management
module for information purposes.
Alternative a: If the CoSD blocking has not taken place (i.e. the Restriction Reference of I1 & I2 is empty,
T1 is not yet settled), the Instruction Maintenance module:
• asks the SPS module to cancel T1;
• and:
-
either receives an agreement message from SPS, i.e. an answer which accepts the
request, if the settlement status value of T1 is not “Settlement in Process”. In this case,
the status of T1 is switched to “Cancelled”, and the Cancellation Status of I1 & 12 is set
to “Cancelled”. The maintenance instructions are set to “Executed”, and both the
Administering Parties and Instructing Parties are informed with an “executed” message
for the maintenance instructions;
-
or receives a rejection message due to a T1 settlement status value “Settlement in
Process”. In this case, the Instruction maintenance module re-sends its request until the
receipt of an agreement message.
Alternative b: If the CoSD blocking has already taken place (i.e. the Restriction Reference of the CoSD
individual settlement instruction is filled, T1 is settled), the processing follows the next steps:
• On the reception of their cancellation maintenance instructions by all Administering Parties and
T2S Parties, the Instruction maintenance module updates the CoSD Status of the CoSD individual
settlement instructions into “CoSD To Be Cancelled”. The individual settlement instructions are
then sent to the Settlement Eligibility module;
• The CoSD individual settlement instructions (from both T2S Parties) are selected by the
Settlement Eligibility module, their Eligibility Status value is updated into “Eligible” and they are
then sent to the SPS module;
Final_T2S_GFS_110.doc
Page 312
T2S General Functional Specifications
Functional Description
Settlement
• The SPS module generates a “CoSD Cancellation” settlement transaction T2 to unblock the CoSD
blocking and sends it to the VPB module for settlement;
• Upon the settlement of T2, the CoSD individual settlement instruction is updated with a
Cancellation Status “Cancelled” and the user is informed of the cancellation of the CoSD individual
settlement instruction;
• A data is sent to Instruction maintenance module in order to update the maintenance instruction
status into “Executed” and to inform the user with the Action Status of the maintenance
instruction for CoSD cancellation.
3.5.3.5. Processing of UC-SI-9: Blocking instruction
Settlement process of Blocking Instruction
(including blocking, segregation and earmarking restriction types as specified in the Blocking instruction)
Interface
T2S
Parties
LCMM:
Instruction
Validation
LCMM:
Instruction
Matching
LCMM:
Status
Management
Communication C1
LCMM:
Settlement
Eligibility
SETT:
SPS
SETT:
Sequencing
SETT: VPB
Following the standard process
I1
Eligible I1
Created T1
Created T1
alt
[Settlement]
Blocking Confirmation
Settled I1
Data for Blocking confirmation
message Settled I1
Instruction Status Information (Settled I1)
with Restriction Reference*
Settled T1
including Restriction Reference*
including Restriction Reference*
[Failure]
Blocking status
Unsettled I1
Data for Blocking status
message Unsettled I1
Instruction Status Information (Unsettled I1)
Unsettled T1
[Partial Execution]
Blocking confirmation
Partially Settled I1
including Partial amount
and Restriction Reference*
Instruction Status Information (Partially Settled I1)
Data for Blocking confirmation message
Partially Settled I1
with Partial amount and Restriction Reference*
Partially
Settled T1
including Partial amount and Restriction Reference*
* The Restriction Reference is not sent in case of earmarking restriction type. For the segregation restriction type, a new Restriction Reference is sent only after the settlement of the first blocking instruction for a considered segregation
resriction type. If a segregated securities position already exists with this segregation resriction type, the quantity segregated in is updated and the same restriction reference is re-sent for the additional blocking instruction.
Business assumption
The description of the process from the entry of the Blocking Communication C1 (with a blocking,
segregation or earmarking restriction type) to the settlement attempt in the Validation Provisioning and
Booking (VPB) module can be referred into the relevant UC descriptions.
This focus starts with the point where the blocking settlement transaction T1 created for the Blocking
individual settlement instruction enters the VPB module for a settlement attempt.
Processing
Once in the VPB module, the settlement processing followed by T1 depends of the restriction type:
Final_T2S_GFS_110.doc
Page 313
T2S General Functional Specifications
Functional Description
Settlement
• For the blocking60 or the segregation restriction type, the standard settlement is followed (i.e. with
the provisioning and booking process);
• For the earmarking restriction type, due to its specific characteristics with respect to other
restrictions, a specific settlement processing (without provisioning and booking) is done by the
function which specifically manages the earmarking (cf. description below).
For the T2S Parties which sent the initial blocking Communications, these different settlement processes
have no impact on the message received and the status of their individual settlement instructions.
Blocking restriction type
If T1 is a blocking settlement transaction with a blocking restriction type61, the standard settlement
process in the VPB module is done.
Before the booking, a provision-checking is done to check if the available quantity in the considered
securities position allows the settlement of T1. If this provision-checking is:
• (Partly) satisfactory:
-
T1 is (partially) settled with the available quantity of securities moved in a new blocked
securities position;
-
The original I1 blocking individual settlement instruction Settlement status value is set to
“(Partially) Settled”, and the T2S Parties are informed with a Blocking Confirmation which
includes the new created restriction reference (and the quantity blocked in case of partial
execution);
• Not satisfactory:
-
T1 is unsettled;
-
I1 Settlement status value is set to “Unsettled”, and the T2S Parties are informed with a
Blocking status message “Unsettled”.
After this settlement attempt, if I1 has been partially settled or unsettled, the unsettled part is not
attempted another time (i.e. no recycling), even if the necessary quantity of securities credits the
considered securities position.
60
Contrary to earmarking and segregation which apply only to securities, the blocking restriction type also applies to cash. For clarity reason, the
present use-case only quotes about securities position. In the case of the blocking restriction type, the processing described is similar in case of
blocking on cash balance.
61
The use-case only applies to blocking instructions. The CoSD blocking, for which no partial settlement is possible, is not covered here.
Final_T2S_GFS_110.doc
Page 314
T2S General Functional Specifications
Functional Description
Settlement
Segregation restriction type
If T1 is a blocking settlement transaction with a segregation restriction type, the standard settlement
process in the VPB module is done as well, with a slight difference if a segregated securities position
already exists for the same segregation type.
In this case, the new quantity segregated is moved on the existing securities position instead of on a new
segregated securities position for the same segregation type.
In addition, the restriction reference sent in the Blocking confirmation is the restriction reference already
associated to the existing segregated securities position (i.e. only one restriction reference is associated to
a considered segregation restriction type for an ISIN in a securities account).
Earmarking restriction type
The earmarking restriction type has some specific characteristics with respect to other restriction types
(the earmarked quantity can be greater than the available quantity of the main securities position, or a
security can be earmarked for several purposes, or no quantity is indicated in a way to earmark the
securities position regardless of its quantity…)
As a consequence, if T1 is a blocking settlement transaction with an earmarking restriction type, T1
follows a specific processing in the VPB module instead of the standard provisioning and booking process.
Whatever the available quantity in the considered securities position (no provision-checking), T1 is settled,
and an earmarking is set up for the quantity indicated in the securities movement, or without a quantity
when no quantity has been indicated in I1. If an earmarking already exists for the same earmarking
purpose, the amount earmarked in the existing earmarking is updated. The earmarked securities are not
actually moved from the considered main securities position and no restriction reference is created.
This specific processing for the earmarking restriction type has no impact for the T2S Party considering
that the I1 Settlement status value is set to “Settled” and a Blocking Confirmation is sent after the
settlement of T1.
Final_T2S_GFS_110.doc
Page 315
T2S General Functional Specifications
Functional Description
Settlement
3.5.3.6. Processing of UC-SI-10: Reservation instruction
Business assumption
The description of the process from the entry of the Reservation Communication C1 to the settlement
attempt in the Validation Provisioning and Booking (VPB) module can be referred into the relevant UC
descriptions.
This focus starts at the point where the reservation settlement transaction T1 enters the VPB module for a
settlement attempt.
Processing
Setting up of the reservation
T1 follows the standard settlement process (i.e. with the provisioning and booking process) in the VPB
module.
Final_T2S_GFS_110.doc
Page 316
T2S General Functional Specifications
Functional Description
Settlement
Before the booking, a provision-checking is done to check if the available quantity in the considered
securities position62 allows the settlement of T1. If this provision-checking is:
• Satisfactory:
-
T1 is settled with the available quantity of securities moved in a new reserved securities
position;
-
The original I1 reservation individual settlement instruction Settlement status value is set
to “Settled”, and the T2S Parties are informed with a Reservation Status message
“Settled” which includes the new created restriction reference;
• Partly63 or not64 satisfactory:
-
T1 is partially settled with the available quantity of securities moved in a new reserved
securities position;
-
The unfilled part of T1 (i.e. difference between the requested quantity to be reserved and
the actual reserved amount) is stored in a specific attribute in the created reserved
securities position to allow the pre-emption of all new incoming securities in the
considered securities position immediately after the settlement of T1;
-
The original I1 blocking individual settlement instruction Settlement status value is set to
“(Partially) Settled”, and the T2S Parties are informed with a Reservation Status message
which includes the new created restriction reference for this reservation and the quantity
actually reserved.
Pre-emption for a partially filled reservation
In case of partially filled reservation on a securities account, all new incoming securities (T2) are preempted until the reservation is entirely filled.
After the provision-checking of the involved securities position, a check is done on all the restricted
securities position associated to the credited securities position. This check searches if one or several of
these restricted positions have a “To be filled” attribute with a specified quantity.
In this case, a new settlement transaction is created and linked to the settlement transaction which brings
the incoming securities. This settlement transaction transfers the securities necessary to complement the
partially filled reservation.
62 The reservation restriction type applies to securities and cash. For clarity reason, the present use-case only quotes about securities position but the
processing described is similar in case of reservation on cash balance.
63 The use-case only applies to blocking instructions. The CoSD blocking, for which no partial settlement is possible, is not covered here.
64 Even if the actual quantity of securities moved on the new restricted securities position is equal to zero, the settlement transaction and the initial
reservation individual settlement instruction gets the Settlement status value “Partially Settled” instead of the value “Unsettled”. The partially settled
status value indicates to the T2S Party that his reservation instruction is taken into account and a pre-emption has been set up on the considered
securities position.
Final_T2S_GFS_110.doc
Page 317
T2S General Functional Specifications
Functional Description
Settlement
After this pre-emption, the T2S Parties are informed with the settlement of the new incoming individual
settlement instruction and with the additional quantity increasing the filled quantity in this reservation,
depending of its messages subscription. In addition, if some resource remains available after the preemption, R&O is informed of this additional resource (minus the pre-empted amount) via a Transaction
Status Information (settled T2).
Once all the reservation has been filled, the “To be filled” attribute of the relevant reserved securities
position is empty.
3.5.3.7. Processing of UC-SI-11: Settlement of a corporate action with associated liquidity
transfer
Settlement of a Corporate Action with associated liquidity transfer
LCMM:
Instruction
Validation
Interface
T2 S
Actor
T2S
Actor A
(CSD)
Communication
I1
Incoming
Instruction I1
LCMM:
Status
Management
LCMM:
Instruction
Maintenance
LCMM:
Settlement
Eligibility
SETT:
SPS
SETT:
Sequencing
SETT:
VPB
LQMG:
Liquidity
Control
SETT:
R&O
ISI Accepted/ matching not required I1
ISI Accepted/ matching
not required I1
T2S
Actor A
(CSD)
I1 Eligible
Data for Validation status mesage
accepted I1
Validation Status
Accepted I1
T1 “created”
I1 Eligible
T2 “created”
T1 “created”
T2 “created”
Alt 1
T2S
Actor A
(CSD)
T2S
Actor B
Cancellation status
cancelled I1
Data for Cancellation status message
cancelled I1
Instruction Status Information
(Unsettled I1)
Cancellation status
cancelled I1
Alt 2
Instruction Status Information
(Settled I1 + reservation reference)
T2S
Actor A
(CSD)
T2S
Actor B
Settlement status
settled I1
Data for settlement status message
settled I1/Reservation reference
Liquidity Event I1 (reservation reference)
Settlement status
settled I1
Liquidity order 1 created
Liquidity order 1
queued
T2S
Actor A
(CSD)
Liquidity order
1 executed
“Executed” Message
Data for “liquidity order executed” message
Business assumption
This description relates to the processing of a corporate action related settlement instruction (I1) initiated
by T2S Actor A (CSD A):
Final_T2S_GFS_110.doc
Page 318
T2S General Functional Specifications
Functional Description
Settlement
• that results in a credit in the T2S dedicated cash account of another T2S Actor (T2S Actor B);
• and is credited afterwards on the RTGS account linked to the T2S dedicated cash account
according to an option chosen by T2S Actor B defined in Static Data on account level (T2S Actor
can opt for an automatic and immediate retransfer of cash proceeds from any corporate action(s).
Settlement instructions received for Corporate Action imply only one debit and one credit of cash (i.e. only
two T2S Actors are implied, i.e. CSD A and T2S Actor B).
Processing
Once the format and syntax validations are successfully passed, the corporate action related settlement
instruction I1 enters the Instruction validation module which:
• Executes the different validation processes to I1, according to the Processing attribute analysis,
getting the Validation Status value “Accepted”, which is communicated to Status Management
module. CSD A is informed about the status value of the settlement instruction through the
Interface, depending on its message subscription preference. Additionally, the Instruction
validation module identifies that the ISO Transaction code of the individual settlement instructions
refers to a corporate action, setting the Matching Status value “Matching not required”, which is
communicated to Status Management module;
• Checks if the T2S Actor B has chosen (at a dedicate cash account level) an automated and
immediate retransfer to the RTGS account of the cash proceeds from the corporate action, if this
is the case, it attaches an indicator to the corporate action settlement instruction.
On the settlement day, Settlement Eligibility module selects I1, which gets the eligibility status value
“Eligible” and sends it to SPS module in order to generate:
• A settlement transaction T1 for CA settlement purpose (with only one movement on securities or
cash accounts);
• A settlement transaction T2 for the reservation of the cash proceeds (only if the T2S Actor has
opted for an automatic retransfer of cash proceeds from any corporate action to the RTGS
account). T2 is linked to T1 with the link “WITH”.
The settlement transactions are then completed and updated, and submitted to the Sequencing module
which determines the mode of submission of incoming settlement transactions to a settlement attempt:
• In day-time settlement period, the settlement transactions T1 and T2 are sent to VPB module for
a real-time settlement attempt;
• In night-time settlement period, the settlement transactions are sent to R&O module for an
optimisation attempt.
Final_T2S_GFS_110.doc
Page 319
T2S General Functional Specifications
Functional Description
Settlement
In VPB module:
• In case T1 (and therefore T2) fail to settle, VPB informs the Status Management module and
sends data for a message status to the Interface to inform CSD A and T2S Actor B that I1 is
unsettled. T1 and T2 are recycled, and if settlement is not possible in the following days during
the recycling period, I1 is cancelled by the Instruction Maintenance module that informs the
Status Management module about this modification (I1 gets the Cancellation status value
“Cancelled” reason code “Recycling period reached”, that sends data for a message status to
Interface Flow Management to inform CSD A and T2S Actor B);
• In case T1 and T2 are successfully settled, the Settlement status value of I1 is set to “Settled”.
Then, VPB sends a message to the Status Management module about the successful settlement.
When Status Management module is informed that I1 is settled, it:
• Sends data for a message status to Interface to inform CSD A and T2S Actor B that I1 is settled;
• Reports the reservation reference of the cash proceeds to T2S Actor B;
• Informs Liquidity Management domain about the settlement of I1 and the cash reservation
reference, where T2S Actor B has opted for an automated transfer of the cash proceeds to the
RTGS account (Liquidity event).
After being alerted by Status Management module, Liquidity Management module:
• Checks in Static Data about the terms of the Liquidity transfer (i.e. RTGS account linked);
• Generates a liquidity transfer (L1) from the T2S dedicated cash account to the RTGS account to
which the T2S dedicated cash account is linked on the basis of the reservation reference provided
by Status Management, for the same amount of reserved cash;
• Forwards L1 to the Sequencing module.
Sequencing module selects L1 and sends it to VPB which directly settles L1 and sets the Settlement status
value of L1 to “Settled”. VPB sends relevant data to Liquidity Management in order to inform T2S Actor B
that L1 is “Settled”. With this data received, Liquidity Management module composes and sends a
message to inform T2S Actor B that the cash transfer was performed.
Final_T2S_GFS_110.doc
Page 320
T2S General Functional Specifications
Functional Description
Settlement
3.5.3.8. Processing of UC-SI-12a: Cross CSD Standard DvP
Business assumption
The description of the process from the entry of the Communications C1 and C2 till the SPS module can
be referred into the relevant UC descriptions.
Processing
The Instruction validation module identifies the incoming instruction as cross-CSD instruction and
validates that the links are set to active (i.e. that the chain of intermediate accounts exist in the CSDs
involved). It is also validates that the incoming instruction is suitable to be processed through the link (i.e.
dependant on ISIN code, Instruction Type and CSD participant).
The SPS module:
• On reception of “Eligible” individual settlement instructions sent by the Settlement Eligibility
module, analyses them and the involved CSDs to determine the ones which correspond to a
“Cross CSD” settlement. These CSDs can be:
-
Investor CSD, i.e. the CSD of each party of the settlement transaction;
-
Issuer CSD, i.e. the CSD in which the security has been issued and distributed on behalf
of the issuer;
Final_T2S_GFS_110.doc
Page 321
T2S General Functional Specifications
Functional Description
Settlement
For a “Cross-CSD” settlement, all involved CSDs are in T2S.
• Creates one settlement transaction constituted of:
-
Securities movements, as many as necessary, to insure the realignment between the
involved CSDs;
-
One cash movement in case of a DVP settlement.
• Sends the “Created” settlement transaction to the Sequencing module.
Then the settlement transactions are handled by the Sequencing module during the settlement day and
sent to VPB or R&O modules (according to the settlement period of the settlement day) following the
standard settlement process.
3.5.3.9. Processing of UC-SI-12b: In-out T2S Standard DvP
The same Business assumptions and processing up to SPS module are utilised in this UC.
The SPS module:
Final_T2S_GFS_110.doc
Page 322
T2S General Functional Specifications
Functional Description
Settlement
• On reception of “Eligible” individual settlement instructions sent by the Settlement Eligibility
module, analyses them and the involved CSDs to determine the ones which correspond to a
“Conditional in/Out CSD” and “Unconditional In/Out CSD” settlement;
-
For a “Conditional In/Out” settlement, the Issuer CSD is outside T2S, and at least one
Investor CSD is inside. The final securities delivery within T2S is dependent on actions
outside T2S;
-
For an “Unconditional In/Out” settlement, the Issuer CSD is inside T2S and at least one
Investor CSD is outside. No actions outside T2S are required prior to settlement.
• For “Conditional In/Out” individual settlement instruction, analyses it to determine if it is a
“Conditional In/Out - CoSD Blocking” or a “Conditional In/Out - CoSD Release”;
• Creates one settlement transaction constituted of:
-
One securities movement (DVP) to set the position restriction for a “Conditional In/Out” CoSD Blocking” settlement. Then the process is the same as for a “CoSD blocking”
settlement transaction;
-
Securities movements, as many as necessary, to insure the realignment between the
involved CSDs, and one cash movement (DVP) for a “Conditional In/Out - CoSD Release”
settlement. The settlement is released by the Investor inside T2S after the confirmation
of the settlement within the External Issuer CSD. Then the process is the same as for a
“CoSD Release” settlement transaction;
-
Securities movements, as many as necessary, to insure the realignment between the
involved CSDs and one cash movement (DVP) for an “Unconditional In/Out” settlement.
• Sends the “Created” settlement transaction to the Sequencing module.
Then the settlement transactions are handled by the Sequencing module during the settlement day and
sent to VPB or R&O modules (according to the settlement period of the settlement day) following the
standard settlement process.
Final_T2S_GFS_110.doc
Page 323
T2S General Functional Specifications
Functional Description
Settlement
3.5.3.10. Processing of UC-LT-4: Execution of a single standing and predefined liquidity transfer
orders from T2S to RTGS
Execution of standing and predefined LTOs from T2S to RTGS
Interface
RTGS
T2S
System User
LQMG: Liquidity
Control
OPSR: Scheduling
SETT:
Sequencing
SETT: Validation,
Provisioning and
Booking
LQMG: Notification and
Information
Management
Time/ business
event
Liquidity transaction
Settlement
transaction
Alt
(Full execution)
Liquidity transfer booking
information
Notification
Response
(Confirmation message)
Outgoing notification
Confirmation data
Alt
(Partial execution)
Liquidity transfer booking
information
Notification
Response
(Alert message)
Outgoing notification
Confirmation data
Alt
(No execution)
Liquidity transfer booking
information
Response
(Alert message)
Alert data
The
T2S dedicated cash account holder or another T2S Actor acting on behalf of the cash account holder is
able to define standing and predefined liquidity transfer orders to be executed during the business day of
T2S. Standing and predefined liquidity transfer orders are stored in Static Data and are initiated when the
defined time or business event occurs.
Business assumption
A predefined or a single standing liquidity transfer order stored in T2S Static Data is activated by the
defined time and/or business event.
Processing
Standing and predefined liquidity transfer orders are stored in Static Data. After receiving a time and/or a
business event from the Scheduling Module the Liquidity Control module reads from the Static Data data
store the liquidity transfer order data foreseen for this point in time and / or business event.
Final_T2S_GFS_110.doc
Page 324
T2S General Functional Specifications
Functional Description
Settlement
Afterwards Liquidity Control Module creates a liquidity transaction (debit T2S dedicated cash account credit RTGS dedicated transit account) and forwards it to the Sequencing Module. The Sequencing Module
puts the transaction into a queue available for the VPB Module, which checks whether the booking is
feasible. There are three different possible scenarios:
• The available cash on the T2S dedicated cash account to be debited is sufficient to execute the
transfer:
-
In case the provision-checking is successful the transaction is sent via the “Pre-empting”
function to the “Booking” function;
-
Then the “Booking” function updates on a gross basis the balances of the T2S dedicated
cash accounts involved. The requested T2S dedicated cash account is debited and the
RTGS dedicated transit account of the responsible NCB is credited;
-
After the successful booking a liquidity transfer booking information is sent to the
Notification and Information Management Module. On this basis, the Notification and
Information Management Module updates the liquidity transfer data store accordingly;
-
Afterwards the Notification and Information Management Module sends the Outgoing
notification and the Confirmation data to the Flow Management within the Interface. A
notification is sent to the involved RTGS system to initiate the booking there. A Response
(Confirmation message) is sent to the holder of the debited T2S dedicated cash account
(depending on the subscription preferences);
-
A confirmation of the booking from the RTGS system (RTGS answer) is required to ensure
the liquidity transfer has reached its destination. If T2S receives:
an acknowledgement (ACK) from the RTGS system, the liquidity transfer has
completed successfully;
A negative acknowledgement (NAK) from the RTGS system, the liquidity transfer
is not unwound, but an alert is sent to the T2S Operator for further
investigations;
No message from the RTGS system, an alert is sent to the T2S Operator for
further investigations.
• The available cash on the T2S dedicated cash account of the payment bank is only partly
sufficient to execute the transfer.
-
The first steps are similar to the 3 first steps in scenario 1 above;
-
Afterwards the Notification and Information Management Module sends the Outgoing
notification and the Alert data to the Flow Management within the Interface. The
Final_T2S_GFS_110.doc
Page 325
T2S General Functional Specifications
Functional Description
Settlement
Interface sends a Response (Alert message) to the account holder of the debited T2S
dedicated cash account (depending on the subscription preferences), the Notification is
sent to the involved RTGS system to initiate the booking there;
-
A confirmation of the booking from the RTGS system (RTGS answer) is required to ensure
the liquidity transfer has reached its destination. If T2S receives:
an acknowledgement (ACK) from the RTGS system the liquidity transfer has
completed successfully;
A negative acknowledgement (NAK) from the RTGS system the liquidity transfer
is not unwound, but an alert is sent to the T2S Operator for further
investigations;
No message from the RTGS system an alert is sent to the T2S Operator for
further investigations.
• There is no cash available (zero balance) on the T2S dedicated cash account to be debited The
liquidity transaction could not be settled due to insufficient liquidity on the T2S dedicated cash
account. No liquidity is transferred at all. In this case, a liquidity transfer booking information is
sent to the Notification and Information Management Module.
Afterwards the Notification and Information Management Module sends the Alert data to the Flow
Management within the Interface. The Interface sends a response (Alert message) to the account holder
of the T2S dedicated cash account for which the standing or predefined liquidity transfer order had failed
(depending on the subscription preferences).
Final_T2S_GFS_110.doc
Page 326
T2S General Functional Specifications
Functional Description
Settlement
3.5.4. Standardisation and Preparation to Settlement
3.5.4.1. Diagram of the module
SPS
LQMG:
Liquidity Control
SETT:
Sequencing
LCMM: Settlement
Eligibility
LCMM:
Instruction
Maintenance
Static
Data
Liquidity
Blocking
Request (D)
EoD Cash
Restrict Release
Information (B)
ISI
[Eligible] (A)
Request
(E)
Request
(H)
Analyser
« data store »
[Static Data]
Actions on
Transactions and Limits
Restriction
Instruction Analyser
« data store »
[ISI]
Is a
restriction ?
No
ISI
[Eligible]
Action on
Transactions and Limits
Cross and In/Out CSD
Instruction Analyser
« data store »
[STrx]
Yes
Is a Cond In/Out ?
No
Yes
ISI
(Cond In/Out)
Reser./
Unereser.
CoSD
To Be Cancelled
CoSD
Blocking
Blocking/
Unblocking
ISI
(Reservation
/Unreservation)
ISI
(CoSD
Cancellation)
Conditional In/Out
Instruction Analyser
Uncond In/Out
CoSD
Activ.
ISI
(CoSD
Blocking)
ISI
(Blocking
/Unblocking)
Intra
Cross
CSD
CoSD
Release
ISI
(Uncond In/Out)
ISI
(Cond In/Out
CoSD Blocking)
ISI
(Cond In/Out
CoSD Release)
ISI
(Intra)
ISI
(Cross CSD)
« data store »
[ISI]
« data store »
[STrx]
Manager
Position Restriction
Transaction Manager
Standard
Transaction Manager
« data store »
[Security
Movement]
« data store »
[Cash
Movement]
STrx
Harmonised
Transaction Generator
« data store »
[STrx]
STrx
[Created] (C)
Answer
(F)
Decreased
NCB Limits
Event
(G)
SETT:Sequencing
LCMM: Instruction
Maintenance
SETT:AutoCollateralisation
3.5.4.2. Description of the module
The Standardisation and Preparation to Settlement (SPS) is the entry module in the Settlement domain for
“Eligible” individual settlement instructions. They are analysed by the Restriction Instruction Analyser, the
Cross and In/Out CSD Instruction Analyser and the Conditional In/Out Instruction Analyser (functions 1 to
3) which set a SPS Codification in order to internally route the individual settlement instructions to the
Final_T2S_GFS_110.doc
Page 327
T2S General Functional Specifications
Functional Description
Settlement
appropriate manager function. The SPS codification can either store the Instruction Type (notably to
identify the restrictions) or a value resulting from the cross CSD analysis.
The Position Restriction Transaction Manager and the Standard Transaction Manager (functions 4 and 5)
create the settlement transactions – one or two settlement transactions per incoming individual
settlement instruction – containing all the movements on securities and cash needed for settlement. The
Position Restriction Transaction Manager also receives “EoD Cash Restriction Release” information from
the Sequencing module to release restrictions on cash unused at the end of the settlement day, and
incoming “Liquidity Blocking” requests sent by the Liquidity Management domain to create settlement
transactions to set up a restriction for liquidity management purpose.
The settlement transactions are then complemented and updated by the Harmonised Transaction
Generator (function 6) and submitted to the Sequencing module. In particular, this function stores the
final SPS codification value in the Transaction Category attribute of the Settlement Transaction, and
creates the settlement transaction links and link sets.
The Action on Transactions and Limits (function 7) receives requests sent by the Instruction Maintenance
module to perform some actions on the settlement transactions in relation with maintenance on the
associated individual settlement instructions, as well as requests from the Static Data module to update
remaining limits, and sends back answers to the calling module.
3.5.4.3. Description of the functions of the module
1 – Restriction Instruction Analyser
This function analyses all the incoming “Eligible” individual settlement instructions sent by the Settlement
Eligibility module and sets the SPS Codification if related to a restriction on a securities position or a cash
balances or redirects them to other analyser.
For individual settlement instructions which:
•
Set up or cancel a reservation on a securities position or a cash balances (i.e. the Instruction
Type value is “Reservation” or “Unreservation”), the function sets the SPS Codification with
the corresponding Instruction Type;
•
Set up or cancel a blocking, a segregation or an earmarking on a securities position or a cash
balances (i.e. the Instruction Type value is “Blocking” or “Unblocking” and the Restriction
Classification of the Restriction Type is “Blocking”, “Segregation” or “Earmarking”), the
function sets the SPS Codification according to the Instruction Type and the related
Restriction Classification as follows:
Final_T2S_GFS_110.doc
Page 328
T2S General Functional Specifications
Functional Description
Settlement
ISI INSTRUCTION TYPE
RESTRICTION
CLASSIFICATION RELATED TO
ASSIGNED SPS
CODIFICATION
ISI RESTRICTION TYPE
•
Blocking
Empty
Blocking
Blocking
Blocking
Blocking
Blocking
Earmarking
Earmarking
Blocking
Segregation
Segregation
Unblocking
Empty
Unblocking
Unblocking
Blocking
Unblocking
Unblocking
Earmarking
Un-earmarking
Unblocking
Segregation
Un-segregation
Set up a CoSD activation (i.e. the CoSD flag value is “Yes” and the Restriction Reference is
empty), the function sets the SPS Codification to “CoSD Blocking” {T2S.09.210}
{T2S.11.740} {T2S.02.090};
•
Cancel a CoSD blocking (i.e. CoSD Status value is “To Be Cancelled”), the function sets the
SPS Codification to “CoSD Cancellation” {T2S.11.740};
All individual settlement instructions related to a restriction, for which a SPS Codification has been
assigned, are directed to the Position Restriction Transaction Manager function.
Other remaining “Eligible” individual settlement instructions are sent to the Cross and In/Out CSD
Instruction Analyser for other SPS Codification assignments.
2 – Cross and In/Out CSD Instruction Analyser
This function analyses the “Eligible” individual settlement instructions sent by the Restriction Instruction
Analyser and sets their SPS Codification. This codification depends on the role (Investor or Technical
Issuer CSD) and the participation to T2S (internal or external) of the CSDs involved in the settlement.
These CSDs are identified on the basis of information stored in the individual settlement instruction and in
the static data.
An Investor CSD manages the buyer or the seller participant security accounts. In case several CSDs are
involved in the settlement, each Investor CSD shall have at least one mirror account in its own set of
accounts in T2S, representing its holdings on the omnibus account in its Technical Issuer CSD, and an
Inter CSD account65 linked to each mirror account.
The Issuer CSD is its own Technical Issuer for the securities issued on its books. {T2S.09.300}
{T2S.09.310} {T2S.09.340}
65
Used in case the Issuer CSD is external to T2S
Final_T2S_GFS_110.doc
Page 329
T2S General Functional Specifications
Functional Description
Settlement
The table below summarizes the assignment of SPS codification for all the potential cases involving two
participants and one or three CSDs internal (IN) or external (OUT) to T2S.
In the first case, both participants belong to the same Issuer CSD. For all the remaining cases, each
participant belongs to a different Investor CSD.
The scenarios mentioned in the table refer to scenarios that are further detailed in the Standard
Transaction Manager function.
ISSUER
INVESTOR
INVESTOR
CSD
CSD1
CSD2
SCENARIOS
IN
-
-
Intra
IN
IN
IN
Cross 1
IN
OUT
OUT
Ext. 1
IN
IN
OUT
Ext. 2
IN
OUT
IN
OUT
IN
OUT
Ext. 3
OUT
OUT
IN
OUT
IN
IN
Ext. 4
OUT
OUT
OUT
X
UR REF
ASSIGNED SPS CODIFICATION
Intra
{T2S.09.350}
{T2S.09.360}
{T2S.02.100}
{T2S.09.390}
{T2S.02.110}
{T2S.09.400}
{T2S.02.120}
{T2S.09.410}
{T2S.02.130}
{T2S.09.420}
Cross-CSD
Unconditional In/Out (Intra CSD
like)
Unconditional In/Out (Cross CSD
like)
Conditional In/Out (CoSD like)
Unconditional In/Out (Cross CSD
like)
Out of scope
Once having assigned the SPS codification above the function sends:
•
The “Intra”, “Cross-CSD” and “Unconditional In/Out” individual settlement instructions to the
Standard Transaction Manager;
•
The “Conditional In/Out” individual settlement instructions to the Conditional In/Out
Instruction Analyser.
3 – Conditional In/Out Instruction Analyser
This function analyses the Restriction Reference of the incoming individual settlement instructions with a
SPS Codification set to “Conditional In/Out”, to identify if they have to follow the blocking or the release
processing. Then the function redirects them to the relevant function Manager {T2S.09.120}.
If the individual settlement instruction has:
•
No Restriction Reference corresponding to a CoSD Blocking reference (i.e. it is a CoSD
activation), the function updates the SPS Codification to “Conditional In/Out - CoSD Blocking”
Final_T2S_GFS_110.doc
Page 330
T2S General Functional Specifications
Functional Description
Settlement
and sends the individual settlement instruction to the Position Restriction Transaction
Manager. {T2S.09.220} {T2S.09.410}
•
A Restriction Reference corresponding to a CoSD Blocking reference (i.e. it is a CoSD
release), the function updates the SPS Codification to “Conditional In/Out - CoSD Release”
and sends the individual settlement instruction to the Standard Transaction Manager.
{T2S.09.220} {T2S.09.410}
4 – Position Restriction Transaction Manager
This function creates the settlement transactions that set up or cancel a restriction on a securities position
or a cash balance66. The function is triggered by:
•
Incoming individual settlement instructions from the Restriction Instruction Analyser function
to set-up or cancel a restriction;
•
Incoming individual settlement instructions from the Conditional In/Out Instruction Analyser
function to set-up a restriction for CoSD Activation purpose;
•
“Liquidity Blocking” requests from the Liquidity Control module to set up a blocking on a cash
balance;
•
“EoD Cash Restriction Release” information from the Sequencing module to release unused
restrictions on cash balances during the end-of-Day processing.
On a triggering by individual settlement instructions to set-up a restriction on a securities position or a
cash balance (i.e. SPS Codification set to “Reservation”, “Blocking”, “Earmarking”, “Segregation”
{T2S.09.280}
{T2S.09.290},
“CoSD
Blocking”
and
“Conditional
In/Out
CoSD
Blocking”
{T2S.09.220}), the function creates one settlement transaction, with one securities or cash movement
corresponding to the quantity or amount indicated in the individual settlement instruction, and which
{T2S.09.180} {T2S.11.740}:
•
Debits the main securities position or cash balance of the considered participant account;
•
Credit a restricted securities position or cash balance in the same participant account
On a triggering by individual settlement instructions to cancel a restriction on a securities position or a
cash balance (i.e. SPS Codification set to “Unreservation”, “Unblocking”, “Un-earmarking” or “Unsegregation” {T2S.09.280} {T2S.09.290}, “CoSD Cancellation” {T2S.09.220} {T2S.09.250}) the
function creates one settlement transaction, with one securities or cash movement corresponding to the
quantity or amount indicated in the individual settlement instruction, and which:
66 The restriction at the account level is not managed by this function but by the Static Data Management. Consequently, the individual settlement
instructions which credit or debit an account with a restriction at the account level are handled by the Standard Transaction Manager function without
specific processing.
Final_T2S_GFS_110.doc
Page 331
T2S General Functional Specifications
Functional Description
Settlement
•
Debits the considered restricted Securities Position or Cash Balance;
•
Credits the main securities position or cash balance in the same participant account.
On a triggering by “Liquidity Blocking” requests from the Liquidity Control module, the function sets the
related SPS Codification to “Blocking Liquidity Transfer Order” and creates one settlement transaction with
one cash movement corresponding to the requested amount as described above for the set up of a
restriction on a cash balance. {T2S.08.890}
On a triggering by “EoD Cash Restriction Release” information from the Sequencing module to release
unused restrictions on cash balances during the End-of-Day processing, the function reads the data and
creates one settlement transaction, with one cash movement corresponding to the unused amount
previously restricted, and which:
•
Debits the considered restricted cash balance;
•
Credits the main cash account balance in the same T2S Dedicated Cash Account
All the settlement transactions created by this function are then sent to the Harmonised Transaction
Generator function.
5 – Standard Transaction Manager
This function creates settlement transactions for individual settlement instructions received from the Cross
and In/Out CSD Instruction Analyser function (i.e. SPS Codification set to “Intra”, “Cross-CSD” or
“Unconditional In/Out”) or from the Conditional In/Out Instruction Analyser function (i.e. SPS Codification
set to “Conditional In/Out - CoSD Release”).
The securities movements to be described in those settlement transactions depend on the type of the
involved CSDs, their number and their participation to T2S or not. The different cases are described in the
scenarios below in relation with the SPS Codifications set upfront by the Cross and In/Out CSD Instruction
Analyser or by the Conditional In/Out Instruction Analyser.
It is to be noted that the movements described in these scenarios cover the case of a Delivery Versus
Payment (one cash movement and one or several securities movements according to the applicable
scenario). For other instruction types, the movements within the settlement transaction are to be adapted
as follows:
•
For a Delivery Versus Delivery (DVD), there is no cash movement but extra securities
movement(s);
•
For a Free Of Payment (FOP), there is no cash movement;
•
For a Deliver With Payment (DWP), there are both cash and securities movements from one
participant to another;
Final_T2S_GFS_110.doc
Page 332
T2S General Functional Specifications
Functional Description
Settlement
•
For a Payment Free Of Delivery (PFOD), there is only one cash movement and no securities
movement.
Scenario Intra (SPS Codification “Intra”)
This scenario covers the intra-CSD settlement defined as a settlement between two participants belonging
to the same CSD in T2S.
Since both participants belong to the same CSD in T2S, there is no securities movement derivation.
Consequently, the function creates one settlement transaction with:
•
One securities movement (1) corresponding to the quantity indicated in the underlying
individual settlement instructions which:
Final_T2S_GFS_110.doc
Page 333
T2S General Functional Specifications
Functional Description
Settlement
•
-
Debits the participant A securities account;
-
Credits the participant B securities account.
One cash movement (2) corresponding to the amount indicated in the seller’s individual
settlement instruction67 {T2S.05.580} which:
-
Debits the participant B T2S Dedicated cash account;
-
Credits the participant A T2S Dedicated cash account.
Even if both participants have their T2S Dedicated cash account68 {T2S.07.280} {T2S.06.070} in the
same NCB or in two different NCB, the cash delivery is settled directly without derivation.
Remark: in all the described scenarios, the function always handles the cash delivery in the same way.
Consequently, the cash movement is not mentioned again in the next scenarios.
Scenarios Cross (SPS Codification “Cross-CSD”)
The following scenarios cover the cross-CSD settlement defined as a settlement between participants not
belonging to the same CSD with all the involved CSDs (Investors and Issuers) being in T2S.
Scenario Cross 1: the Investor CSDs and the Issuer CSD are in T2S
This scenario describes the settlement of a trade between participant A from Investor CSD A selling
securities to participant B from Investor CSD B. It implies:
•
Two Investor CSDs (A and B) in T2S in relationship with the Issuer CSD as Technical Issuer;
•
The Issuer CSD (I) in T2S.
T2S
Investor
CSD
Issuer
CSD
Investor
CSD
67 The cash amounts coming from the seller’s and the buyer’s Cash Movement entities of the underlying individual settlement instruction can be
identical or different. In both cases, the Amount of the cash movement is filled in from the cash amount indicated in the seller’s individual settlement
instruction.
68 This T2S Dedicated cash account can be either the T2S Dedicated Cash Account of the Half Movement or the default T2S Dedicated Cash Account
in static data.
Final_T2S_GFS_110.doc
Page 334
T2S General Functional Specifications
Functional Description
Settlement
The function creates one settlement transaction with three securities movements corresponding to the
quantity indicated in the underlying individual settlement instructions:
•
•
•
A securities movement (1) between securities accounts in the Investor CSD A which:
-
Debits the participant A securities account;
-
Credits the mirror account A/I representing its Technical Issuer CSD I;
A securities movement (2) between securities accounts in the Technical Issuer CSD I which:
-
Debits the CSD A omnibus account;
-
Credits the CSD B omnibus account;
A securities movement (3) between securities accounts in the Investor CSD B which:
-
Debits the mirror account B/I representing the Technical Issuer CSD I
-
Credits the participant B securities account.
{T2S.09.350} {T2S.09.360}
Scenario Cross 2: Two Investor CSDs and two Issuers CSD all in T2S
Final_T2S_GFS_110.doc
Page 335
T2S General Functional Specifications
Functional Description
Settlement
This scenario describes the settlement of a trade between participant A from Investor CSD A selling
securities to participant B from Investor CSD B. It implies:
•
Two Investor CSDs (A and B) in T2S in relationship with different Issuer CSD as Technical
Issuer CSD;
•
Two Issuer CSDs (I and II) in T2S.
The scenario is equivalent to scenario Cross 1 with additional securities movements to update the
issuance accounts (in each Issuer CSD) which have the nature of the position (mark up, mark down)
indicating the decrease or the increase of the securities respectively depending of the direction of the
transfer (receive or delivery).
Scenario Cross 3: Four Investor CSDs and one Issuer CSD all in T2S
This scenario describes the settlement of a trade between participant A from Investor CSD A selling
securities to participant C from Investor CSD D. It implies:
•
Two Investor CSDs (C and D) in T2S in relationship with two different Investor CSDs as
Technical Issuer CSD;
•
Two Investor CSDs (A and B) in T2S in relationship with the Issuer CSD as Technical Issuer
CSD;
•
The Issuer CSD (I) in T2S.
The scenario is equivalent to scenario Cross 1 with two additional securities movements between
securities accounts of each additional Investor CSD involved in the derivation. {T2S.09.370}
Final_T2S_GFS_110.doc
Page 336
T2S General Functional Specifications
Functional Description
Settlement
Scenario Cross 4: Common Investor CSD in T2S
This scenario describes the settlement of a trade between participant A from Investor CSD C selling
securities to participant B from Investor CSD D. It implies:
•
Two Investor CSDs (C and D) in T2S in relationship with the same Investor CSD as Technical
Issuer CSD;
•
An Investor CSD (A) in T2S in relationship with the Issuer CSD as Technical Issuer CSD;
•
The Issuer CSD (I) in T2S.
The scenario is equivalent to scenario Cross 1 with two additional securities movements within the
Investor CSD A involved in the derivation.
In case CSD A uses two different omnibus accounts in the Issuer CSD I, an extra movement is created to
insure the realignment between these two omnibus accounts. If the CSD A uses the same omnibus
account, no extra movement is created.
{T2S.09.380}
Scenarios External (SPS Codification “Unconditional In/Out T2S or “Conditional In/Out T2S”)
The following scenarios cover the In/Out T2S settlement defined as a settlement between two
participants not belonging to the same CSD with at least one involved CSDs (Investors and Issuers) being
external to T2S.
Final_T2S_GFS_110.doc
Page 337
T2S General Functional Specifications
Functional Description
Settlement
Scenario External 1: both Investor CSDs are external to T2S and the Issuer CSD is in T2S (SPS
Codification “Unconditional In/Out T2S”)
This scenario describes the case of an external trade between participant A of Investor CSD A selling
securities to participant B of Investor CSD B. It implies:
•
Two Investor CSDs (A and B) external to T2S in relationship with the Issuer CSD (I) as
Technical Issuer CSD;
•
The Issuer CSD (I) in T2S.
From the perspective of T2S, this scenario appears as a domestic settlement in CSD I: both Investors CSD
A and CSD B are participants of the Issuer CSD I in T2S where they own their omnibus account.
On individual settlement instructions received from Investor CSDs, the function creates one settlement
transaction with one securities movement 1 corresponding to the quantity indicated in the underlying
individual settlement instructions between securities accounts in Issuer CSD I which:
•
Debits the CSD A omnibus account;
•
Credits the CSD B omnibus account.
Since CSD A and CSD B as participants of the CSD I belong to T2S, there is no security movement
derivation.
{T2S.02.100} {T2S.09.390}
Final_T2S_GFS_110.doc
Page 338
T2S General Functional Specifications
Functional Description
Settlement
Scenario External 2: One Investor CSD is external to T2S with one Investor CSD and the Issuer CSD in
T2S (SPS Codification “Unconditional In/Out T2S”)
This scenario describes the case of a trade between participant A from Investor CSD A in T2S selling
securities to participant B from Investor CSD B external to T2S. It implies:
•
An Investor CSD (A) in T2S in relationship with the Issuer CSD (I) as Technical Issuer CSD;
•
An Investor CSD (B) external to T2S in relationship with the same Issuer CSD (I) as
Technical Issuer CSD;
•
The Issuer CSD (I) in T2S.
From the perspective of T2S, this scenario appears as a settlement between:
•
Participant A which belongs to Investor CSD in T2S;
•
The external CSD B as participant of the Issuer CSD I in T2S where it owns an omnibus
account.
Consequently, the function creates one settlement transaction with two securities movements
corresponding to the quantity indicated in the underlying individual settlement instructions:
•
•
A securities movement (1) between securities accounts in the Investor CSD A which:
-
Debits the participant A securities account;
-
Credits the mirror account A/I.
A securities movement (2) between securities accounts in the Issuer CSD I which:
Final_T2S_GFS_110.doc
Page 339
T2S General Functional Specifications
Functional Description
Settlement
-
Debits the CSD A omnibus account;
-
Credits the CSD B omnibus account B.
{T2S.02.110} {T2S.09.400}
Scenario External 3: One Investor CSD and the Issuer CSD are external to T2S with one Investor CSD in
T2S (SPS Codification “Conditional In/Out T2S – CoSD Release)”
This scenario is described here for the sake of a full coverage of all cases, although the “Conditional
In/Out T2S” SPS codification is not handled by the Standard Manager functions for the creation of
settlement transaction, as explained below.
This scenario describes the case of a trade between a participant A of the Investor CSD A in T2S selling
securities to a participant B of the Investor CSD B external to T2S. It implies:
•
An Investor CSD (A) in T2S in relationship with the Issuer CSD (I) as Technical Issuer CSD;
Final_T2S_GFS_110.doc
Page 340
T2S General Functional Specifications
Functional Description
Settlement
•
An Investor CSD (B) external to T2S in relationship with the same Issuer CSD (I) as
Technical Issuer CSD;
•
The Issuer CSD (I) external to T2S.
From the perspective of T2S, this appears as a conditional settlement between participant A of CSD A and
the CSD A (as its own participant) since a simultaneous real-time settlement cannot be achieved. Its full
settlement process is done in three steps:
•
Firstly, the quantity of securities indicated in the individual settlement instruction is blocked
in the participant account;
•
Secondly, once released by CSD A after the confirmation of the settlement within the
external Issuer CSD I, the individual settlement instruction is processed for the actual debit
of the participant A securities account (securities movement -1- in diagram);
•
Thirdly, at a later stage, the CSD A proceeds to the realignment in its accounts with another
FOP instruction (securities movement -2- in diagram);
For this scenario the Standard Transaction Manager creates settlement transactions only at the second
and the third steps.
Actually, in the first step, a SPS codification “Conditional In/Out–CoSD Blocking” is assigned to the
individual settlement instruction between participant A and CSD I,, upon its reception in the SPS module.
It is thus processed by the Position Restriction Manager function which creates the relevant settlement
transactions for the blocking (as described in this function).
At the second step, a SPS codification “Conditional In/Out – CoSD Release” is assigned to the individual
settlement instruction between participant A and CSD I,, upon its reception again in the SPS module
following the release by CSD A.
The Standard Transaction Manager creates at this step one settlement transaction with the securities
movement (1) corresponding to the quantity indicated in the underlying individual settlement instructions
between securities accounts in CSD A, and which:
•
Debits the participant A securities account;
•
Credits the inter CSD account A/I.
The third step is handled later upon reception of a FOP instruction sent by CSD A. An “Intra-CSD” SPS
codification is assigned to this instruction, upon its reception in the SPS module, for a settlement between
the inter CSD account A/I and the mirror account A/I. It results in the creation by the Standard
Transaction Manager function of a settlement transaction with the securities movement (2) which debits
the inter CSD account A/I and credits the mirror account A/I (as described in Scenario Intra).
{T2S.02.120} {T2S.09.410}
Final_T2S_GFS_110.doc
Page 341
T2S General Functional Specifications
Functional Description
Settlement
Scenario External 4: The Issuer CSD is external to T2S and both Investor CSDs are in T2S “Unconditional In/Out T2S” SPS Codification
This scenario describes the case of a trade between participant A from Investor CSD A selling securities to
participant B from Investor CSD B. It implies:
•
Both Investor CSDs (A and B) in T2S in relationship with the same Issuer CSD (I) as
Technical Issuer CSD;
•
The Issuer CSD (I) external to T2S.
Even if Issuer CSD I is external to T2S, the settlement of this scenario in T2S is not conditional: an
unsynchronised realignment is sent by Investor CSDs to the external Issuer CSD I for the realignment.
Consequently, the function creates one settlement transaction with:
•
•
A securities movement (1) between securities account in Investor CSD A which:
-
Debits the participant A securities account;
-
Credits the inter CSD account A/I;
A securities movement (4) between securities account in Investor CSD B which:
-
Debits the inter CSD account B/I
-
Credits the participant B securities account;
Final_T2S_GFS_110.doc
Page 342
T2S General Functional Specifications
Functional Description
Settlement
The securities movements (2) and (3) between the inter CSD accounts and the mirror accounts in
Investor CSDs A and B are created at a later stage in two settlement transactions on instructions (with a
FOP) by CSD A and B.
{T2S.02.130} {T2S.09.420}
Additional settlement transactions depending on individual settlement instruction attributes
For all the scenarios described above, the function creates additional settlement transactions depending
on the individual settlement instruction attributes.
If the individual settlement instruction contains a:
•
Corporate Action Rebalancing Liquidity (CARL) flag set to “Yes”69, the function creates an
additional settlement transaction with one cash movement to reserve the incoming cash in
the T2S Dedicated cash account to make sure that the incoming cash is available for liquidity
rebalancing handled by the Liquidity Management domain. {T2S.06.110} {T2S.06.260}
•
Reservation Flag set to “Yes”, the function creates an additional settlement transaction with
one movement to reserve the incoming resource in the account for a future use by the
account owner with the generated Restriction Reference {T2S.09.180};
Those settlement transactions are associated to the initial individual settlement instruction and linked to
its associated settlement transaction with a Settlement Transaction Link “With” (See function 6 Harmonise
Transaction Generator).
Specific categories of securities
For the following specific categories the function creates the related settlement transactions in the
standard way described above as well:
•
Fund shares (instructed by FOP, DVP or DVD), increases/decreases securities positions via
securities issuances and redemptions with possible settlement of decimals of holdings;
{T2S.09.010} {T2S.09.020} {T2S.09.320} {T2S.09.330}
•
Coupon (instructed by FOP), stripping and reattachment; {T2S.09.030} {T2S.09.040}
{T2S.09.050}
•
Basket of collateral, (instructed by several FOP deliveries from different securities accounts
and a DVP which debits the securities account linked to a required T2S dedicated cash
account with a link "With" for a settlement on an all-or-none basis. {T2S.09.140}
{T2S.09.150} {T2S.09.160} {T2S.09.170}
69 The CARL flag is set by LCMM when the individual settlement instruction is a corporate action, an intraday repo with NCBs or a monetary policy
operation, and the “Automated Cash Rebalancing” in entity T2S dedicated Cash Account Liquidity Transfer Order is set to “Yes”.
Final_T2S_GFS_110.doc
Page 343
T2S General Functional Specifications
Functional Description
Settlement
•
Multilateral individual settlement instructions without CCP intervention {T2S.09.260}
Once created the settlement transactions are sent to the Harmonised Transaction Generator function.
6 – Harmonised Transaction Generator (HTG)
This function receives all the created settlement transactions sent by the Position Restriction Transaction
Manager function or the Standard Transaction Manager. The function complements the Settlement
Transaction entity by all the data necessary for settlement70 {T2S.09.060} and creates the associated
Settlement Transaction Link and Settlement Transaction Link Set entities.
Settlement Transaction
The function complements the settlement transactions created upfront with all the data necessary for
settlement. Those data are retrieved from the underlying individual settlement instruction or from the
static data.
Partial settlement
The Partial Settlement Indicator attribute of the created settlement transactions is determined by
considering:
•
The potential mandatory partial settlement based on a CSD or CCP decision {T2S.09.120}
{T2S.08.400};
•
The T2S Parties agreements for partial settlement in static data {T2S.08.250}
{T2S.08.260}:
-
At the instruction level (i.e. individual settlement instruction Partial Settlement Indicator
set to “Yes”) {T2S.05.141} {T2S.08.270}
•
At the involved accounts level {T2S.08.265} {T2S.08.280},
The potential applicability of additional settlement windows during the settlement day
{T2S.08.220}
The Applicable Threshold of the created settlement transactions is expressed in percentage and in
absolute value {T2S.08.300}. It is determined by considering {T2S.08.290} {T2S.11.730}:
•
The threshold defined by a possible involved CCP (which supersedes all CSDs thresholds)
{T2S.08.370};
•
The threshold defined by the CSD involved in the settlement {T2S.08.340};
•
A cross-CSD harmonised threshold if several CSDs are involved in the settlement or if no
threshold is defined by the CSD {T2S.08.350} {T2S.08.360}.
70
This attributes list may be complemented later
Final_T2S_GFS_110.doc
Page 344
T2S General Functional Specifications
Functional Description
Settlement
Priority
The priority of the created settlement transactions is based on the priority indicated in the Priority
attribute of individual settlement instructions {T2S.05.145} {T2S.11.340}.
The four different levels of priority are {T2S.07.150} (from the highest to the lowest):
•
“Reserved priority” {T2S.07.160};
•
“Top priority” {T2S.07.170}
•
“High priority” {T2S.07.180} {T2S.07.200};
•
“Normal priority” {T2S.07.190} {T2S.07.200}
In case of linked individual settlement instructions, the priority of the related linked settlement
transactions is set with the highest level among the underlying individual settlement instructions
{T2S.07.130} {T2S.09.130}.
Other attributes
•
Transaction Category: is filled with the SPS Codification allocated upfront to the settlement
transaction. It is analysed by the VPB module in order to perform specific treatments or
specific message sending;
•
Restriction Reference: is filled with the Restriction Reference related to the underlying
individual settlement instructions (i.e. it is a restriction use {T2S.09.190}, a CoSD Release
or a Conditional In/Out CoSD Release {T2S.09.220});
•
First Party : contains the reference to the first Party sending the securities;
•
Final Party: contains the reference to the final Party receiving the securities;
•
Auto-Collateralisation flag: stores the Auto-Collateralisation flag value of the individual
settlement instruction; {T2S.05.143} {T2S.08.660}
•
ISO Transaction Code : is taken from the individual settlement instruction;
•
Creation date: is set with the settlement day;
•
Settlement Transaction Status: is set to “Created”.
Settlement Transaction Link and Settlement Transaction Link Set:
The Link Indicator of the Settlement Transaction Link related to the created settlement transactions stores
the Link Type value of the Individual Settlement Instruction Link attribute.
If the Link Type value is set to “Starting Leg” or “Closing Leg” (i.e. this is a Repo), the Link Indicator is
respectively set to “Before” or “After”.
Final_T2S_GFS_110.doc
Page 345
T2S General Functional Specifications
Functional Description
Settlement
In case of a “CARL” individual settlement instruction, the two created settlement transactions are linked to
each other with a settlement transaction link “With”.
The Settlement Transaction Link Set contains the Settlement Transaction Link references to reflect the
Individual Settlement Links Set references to the Individual Settlement Instructions Link.
{T2S.05.147}
{T2S.09.060}
{T2S.09.070}
{T2S.09.080}
{T2S.09.090}
{T2S.09.100}
{T2S.09.110} {T2S.09.270} {T2S.09.290};
Once complemented, the Harmonised Transaction Generator function sends the created settlement
transactions to the Sequencing module.
7 - Actions on Transactions and Limits
This function is in charge of ensuring the consistency between changes on individual settlement
instructions performed in the LCMM domain and changes performed on settlement transactions.
{T2S.05.280}. It is also in charge of updating the remaining amount of updated limits.
The function is triggered by requests received from:
•
The Instruction Maintenance module following the reception of an Instruction Maintenance;
•
The Static Data Management domain following a Static Data Update on a limit.
On a triggering by a request from the Instruction Maintenance module for an authorisation to change an
individual settlement instruction with an “Eligible” Eligibility Status, or an “Unsettled” Settlement Status
{T2S.05.370}, the function:
•
Checks the status of all the settlement transactions related to the relevant individual
settlement instruction;
•
Sends an answer to the Instruction Maintenance module:
-
If none of the related settlement transaction statuses have a value “Settlement In
Process”, the requested change on an “Eligible” individual settlement instruction is
accepted. All the related settlement transactions are dropped (their status is moved to
“Cancelled”), and the references to Settlement Transaction Link, Settlement Transaction
Link Set are removed. If a dropped settlement transaction belonged to a collection with a
Collection Status “Collection Queued”, all the remaining settlement transactions in the
collection are dropped in the same way, and the collection is deleted (Collection Status
set to “Collection Deleted”);
{T2S.05.380}
Otherwise, the change request is rejected giving the reason for rejection.
{T2S.05.390}
{T2S.05.410}
{T2S.05.420}
{T2S.05.450}
{T2S.05.460}
{T2S.05.470}
Final_T2S_GFS_110.doc
Page 346
T2S General Functional Specifications
Functional Description
Settlement
On a triggering by a request from the Static Data Management domain {T2S.08.800} {T2S.08.810},
the function:
•
Updates the Remaining Limit amount and the Requested reimbursement amount with the
information stored into the request;
•
Sends “Reporting” information to the static data;
•
Sends a “Decreased NCB Limits” event to the Auto-collateralisation module if the following
conditions are combined {T2S.08.800}:
-
The updated limit is an Auto-collateralisation limit set by a NCB;
-
The update results in a negative Remaining Amount.
3.5.4.4. Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Eligible individual
settlement instruction
(A)
In
Individual settlement instructions
eligible for settlement in the new
settlement day.
Settlement
Eligibility
EoD Cash Restriction
Release Information
(B)
In
Event to release the restrictions on
cash at the end of day
Sequencing
Created settlement
transaction (C)
Out
Settlement Transaction Status set by
the Harmonised Transaction Generator
Liquidity Blocking
Request (D)
In
To create a restriction transaction
Liquidity Control
Request (E)
In
Contains the maintenance instruction
Instruction
Maintenance
Answer (F)
Out
Contains the answer to this
maintenance instruction
Instruction
Maintenance
Decreased NCB Limits
Event (G)
Out
Request sent in case of a negative
remaining limit amount
Autocollateralisati
on
Request (H)
In
Request received for limit update
Sequencing
Static Data
3.5.4.5. Data accessed by the module
DATA
ACCESS MODE
COMMENT
STATIC DATA
Security CSD Link
Read
Identification of the Investor and
Technical Issuer CSDs
CSD Account Link
Read
Identification of the Mirror, Omnibus and
Inter CSD accounts
Final_T2S_GFS_110.doc
Page 347
T2S General Functional Specifications
Functional Description
Settlement
DATA
ACCESS MODE
COMMENT
Party
Read
Cash Balance
Read
T2S Dedicated Cash Account
Read
Link to the Cash Movement
Currency
Read
Link to the Cash Movement
Securities Account
Read
Link to the Security Movement
DYNAMIC DATA
Security Movement
Create/Modify/Read
Cash Movement
Create/Modify/Read
Individual Settlement Instruction
Read
Individual Settlement Instruction Link
Read
Individual Settlement Instruction Link Set
Read
Individual Settlement Instruction Status
Read
Analysis of the statuses
Restriction Reference
Read
Existence of a Restriction Reference and
analysis of the Restriction Type
Linked Restrictions
Read
Analysis of the restriction reference
given by the T2S Parties
Securities Position
Read
Settlement Transaction
Create/Modify
Copy of the Individual Settlement
Instruction data plus extra information
for settlement purpose
Settlement Transaction Link
Create/Modify
Copy of the Individual Settlement
Instruction Link data
Settlement Transaction Link Set
Create/Modify
Copy of the Individual Settlement
Instruction Link Set data
Collection
Modify
Can be deleted by Action on
Transactions and Limits
3.5.5. Sequencing
3.5.5.1. Diagram of the module
Below is the Activity Diagram modelling the interactions between the functions within the module,
organised from left to right according to the different periods of the settlement day that the module is in
charge of sequencing: night-time, day-time and end-of-day
Final_T2S_GFS_110.doc
Page 348
T2S General Functional Specifications
Functional Description
Settlement
3.5.5.2. Description of the module
The Sequencing module determines, during the settlement day, the mode of submission of incoming
settlement transactions to a settlement attempt either to the Validation Provisioning & Booking (VPB)
module during the day-time settlement period for a real-time settlement attempt, or to the Recycling &
Optimisation (R&O) module during the night-time settlement period for an optimisation attempt.
This module also updates the Settlement Transaction Status of unsettled transactions at the cut-off time
events and handles the end-of-day procedures aimed at launching the release of the cash restrictions and
the intraday credit reimbursement process.
The functions in this module are:
•
The
Routing
function,
receiving
the
“Created”
settlement
transactions
from
the
Standardisation and Preparation to Settlement (SPS) module, as well as the liquidity
transactions from the Liquidity Control module and sending them:
-
To the Night-time Sequencing function during the night-time settlement period;
-
To the VPB module, in a collection of settlement transactions, for a real-time settlement
attempt during all the day-time settlement period and during the end-of-day period (only
for settlement transactions coming from Liquidity Control).
Final_T2S_GFS_110.doc
Page 349
T2S General Functional Specifications
Functional Description
Settlement
•
The Night-time Sequencing function, operating during the night-time settlement period,
which gathers the settlement transactions through a pre-defined number of cycles and
sequences to be treated by the R&O module;
•
•
The Cut-off Processing function, updating the Settlement Transaction Status to “Cancelled”:
-
At the “DVP Cut-off” time event for the unsettled “DVP” settlement transactions;
-
At the “Cut-off” time event for all the remaining unsettled settlement transactions.
The End of Day Release function, performed at the end-of-day period, sending:
-
Information to the SPS module for cash restriction release purposes;
-
An event to the Auto-collateralisation module, triggering intraday credit reimbursement;
-
An “End of Process” event to the Scheduling module which then sends a Business event
to the NCB Business Procedures module, triggering end-of-day liquidity transfers.
3.5.5.3. Description of the functions of the module
1 – Routing
This function receives “Created” settlement transactions sent by the SPS module, as well as liquidity
transactions sent by the Liquidity Control module. The function then transforms the liquidity transactions
into settlement transactions (with a Transaction Category “Liquidity Transfer Order”) and redirects them,
along with the other settlement transactions, to the relevant function according to the settlement period
of the settlement day {T2S.03.010} {T2S.03.240}:
•
During the night-time period, after the reception of a “Beginning of Night-time” time event
{T2S.03.030} the Routing sends the settlement transactions to the Night-time Sequencing
function;
•
During the day-time period, after the reception of a “Beginning of Day-time” time
event{T2S.03.160} {T2S.08.030}
-
For transactions continuously received after this “Beginning of Day-time” event the
function:
Creates a collection of settlement transactions with a Collection Status value to
“Collection Created”;
Final_T2S_GFS_110.doc
Page 350
T2S General Functional Specifications
Functional Description
Settlement
Retrieves
(linked)
settlement
transactions71
and
groups
them
into
the
aforementioned collection; {T2S.05.147} {T2S.09.110} {T2S.09.070}
Sends continuously {T2S.07.090} {T2S.08.080} the collections of (linked)
settlement
transactions
to
the
VPB
module
for
a
settlement
attempt
{T2S.07.120}, after having switched the Collection Status value to “Collection
Queued”; the settlement transactions in the collection have a Settlement
Transaction Status value “Created”.
-
For settlement transactions previously sent to the Night-time Sequencing function (i.e.
after the start of the last cycle, but that have not been included in this cycle), the
function:
Retrieves them and selects all the “Created” settlement transactions;
Sends them according to their entry order and to settlement transactions link sets
to
VPB
in
“Collection
Queued”
collections
of
settlement
transactions.
{T2S.03.090} {T2S.03.110}
•
During the end-of-day period, only settlement transactions coming from the Liquidity Control
module (with Transaction Category “Liquidity Transfer Order”) are sent in a collection of
settlement transactions to the VPB module.
2 – Night-time Sequencing
This function receives the “Created” settlement transactions sent by the Routing function during the
night-time, {T2S.08.020} {T2S.08.080} and regroups them according to their attributes and the Entry
Date/Time of their associated settlement instructions. These settlement transactions are sequenced and
managed within at least two night-time cycles of settlement.72 {T2S.03.100} {T2S.07.010}.
Once a sequence is ready in the data store, the function sends a “Sequence Ready Event” to R&O module
to start the processing of the settlement transactions sequenced and waits for an “End of Sequence
Event” from R&O module prior to creating the next sequence.
Determination of the Cycles and Sequences
This function:
71
An incoming settlement transaction can be linked to other settlement transactions by the T2S Parties (e.g “With”, “After”, “Before”, “Starting leg”,
“Closing leg” links) or by a T2S processing (e.g. set of settlement transactions identified by an optimisation algorithm). To ensure their simultaneous
settlement, the function retrieves, for each settlement transaction in the queue, all the settlement transactions that are linked together,
72
Presently, the exact number of cycles remains to be defined and will be parameterised in the system
Final_T2S_GFS_110.doc
Page 351
T2S General Functional Specifications
Functional Description
Settlement
•
Selects all the “Created” settlement transactions for which the associated individual
settlement instructions have an Entry Date/Time entity value earlier than the beginning of
the cycle;
•
Creates a sequence of settlement transactions on the basis of the criteria mentioned below;
•
Switches the status of the settlement transactions to “Sequenced” once they are sequenced.
For the first night-time cycle, the sequences are created, according in particular to the settlement
transactions’ ISO Transaction Code, in the following fixed order {T2S.07.020}:
•
Sequence 1 handles:
-
All settlement transactions (having a Transaction Category “Liquidity Transfer Order”);
-
All Corporate actions settlement transactions with the current intended settlement date
having an allocated value to their attribute ISO Settlement Transaction Code;
{T2S.07.030} {T2S.09.270}
•
Sequence 2 handles all FOP rebalancing of securities settlement transactions with the current
intended settlement date between the securities accounts of a same Party either in the same
or in different CSDs, having a Transaction Type set to “FOP”. Only FOP settlement
transactions between the securities accounts of a same Party either in the same or in
different CSDs are taken into account by this sequence; {T2S.07.040}
•
Sequence 3 handles all NCBs specific settlement transactions (e.g. collateralisation operations
such as substitution of collateral or calls of additional collateral) with the current intended
settlement date; {T2S.07.050}
•
Sequence 4 handles all Trading-related settlement transactions for the settlement date
considered or for an older intended settlement date. {T2S.07.060}
For the second night-time cycle {T2S.07.070} and all additional ones, the function builds only one
single sequence, to handle all the new “Created” settlement transactions {T2S.03.300}.
Remark: Settlement transactions with a Settlement Transaction Status value “Unsettled” are not
sequenced by this function but directly recycled by R&O from one sequence to the next one.
{T2S.07.040} {T2S.07.050} {T2S.07.060} {T2S.03.110}
Processing of Cycles and Sequences
For each sequence of the cycle, the function:
•
Sends a “Sequence Ready Event” to R&O module to inform it that a sequence of settlement
transactions is ready to be executed;
Final_T2S_GFS_110.doc
Page 352
T2S General Functional Specifications
Functional Description
Settlement
•
At the reception of an “End of Sequence Event” sent by R&O module, indicating that it has
finished the processing of its previous sequence, the function creates the next sequence (of
the same cycle or of the following cycle) before sending the next “Sequence Ready Event” to
R&O.
At the end of each cycle, an “End of Cycle Information” is delivered to the Status Management module.
The latter has received continuously the settlement statuses of the individual settlement instructions from
VPB during the cycle. Nevertheless, those statuses (for each instruction only the last valid status) are sent
together to the T2S parties only at the end of the cycle. {T2S.03.120} {T2S.13.070}
At the end of the last cycle, an “End of Last Cycle Information” is sent to the Liquidity Control module to
inform it that the last cycle has ended.
3 – Cut-off Processing
The Cut-off Processing function aims at preventing the settlement transactions’ recycling within the
Settlement domain. It is triggered at the reception of a “DVP Cut-off” time event and at the reception of a
“Cut-off” time event:
•
At the reception of a “DVP Cut-off” time event, the function updates the status of unsettled
settlement transactions associated to individual settlement instructions with “DVP” Instruction
Type to “Cancelled” {T2S.07.100};
•
At the reception of a “Cut-off” time event, the function updates the status of all the
remaining unsettled settlement transactions to “Cancelled”. {T2S.07.110}
In both cases, if there is a “Collection Queued” collection to which the “Cancelled” settlement transaction
belongs, the Collection Status value of the collection will be set to “Collection Deleted”.
However, at the expiration of a deadline (cut-off), the function only updates the status of settlement
transactions with an “Unsettled” settlement transaction status value. Consequently, the function waits for
a first settlement attempt by VPB module before updating the status of the settlement transactions to
“Cancelled” (as well as the collection with a Collection Status “Collection Queued” to which the settlement
transaction belongs). The purpose is to avoid setting a “Cancelled” status to settlement transactions that
have not been submitted to a settlement attempt whereas their corresponding settlement instructions
have been received
before the cut-off
time. {T2S.03.250} {T2S.03.270} {T2S.03.280}
{T2S.03.290}.
For each Settlement Transaction Status updated to “Cancelled”, the Eligibility Status of the associated
individual settlement instructions is then set to “empty”.
Final_T2S_GFS_110.doc
Page 353
T2S General Functional Specifications
Functional Description
Settlement
4 – End of Day Release
At the reception of an “End of Day” time event, this function handles the release of any reserved/blocked
liquidity that has not been used during the settlement day {T2S.07.380} {T2S.09.240}. In this case,
the function constitutes an “EoD Cash Restriction Release Information” with the following data to allow
SPS creating a settlement transaction:
•
The debited Cash Account Balance (restricted);
•
The credited Cash Account Balance (main);
•
The amount (unused in the restricted Cash Account Balance).
Then, the “EoD Cash Restriction Release Information” is sent to the Restriction Transaction Manager
function in the SPS module.
Sequencing receives a “Transaction Status Information” from VPB when the cash restriction release
settlement transaction has been settled. The End of Day Release function then checks that one
“Transaction Status Information” has been received per “EoD Cash Restriction Release Information” sent
to SPS.
Once this checking is completed, the function sends an “EoD Intraday Credit Reimbursement Event” to
the Auto-collateralisation module which creates the necessary settlement transactions to reimburse
intraday credits. The Transaction Category is set to “EoD intraday credit reimbursement” if created by the
Auto-collateralisation module, or “Forced RTGS Transfer” if created by the Auto-Collateralisation module
after having received forced RTGS transfers from the Liquidity Control module. The Auto-collateralisation
module then sends an answer with a collection of settlement transactions to VPB for a settlement
attempt.
Once a “Transaction Status Information” has been received by the End of Day Release function from the
VPB module for all the settlement transactions generated by the Auto-collateralisation module, the End of
Day Release function sends an “End-of-Process Event” to the Scheduling module. The Scheduling module
then sends a Business event to the NCB Business Procedures module, triggering end-of-day liquidity
transfers.
3.5.5.4. Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
Created settlement
transactions (A)
In
Status allocated to the settlement
transaction by SPS module
SPS
Liquidity Transaction
(B)
In
Coming from Liquidity Control module,
and related to liquidity transfers
Liquidity Control
Final_T2S_GFS_110.doc
TO
Page 354
T2S General Functional Specifications
Functional Description
Settlement
FLOW
IN/OUT
DESCRIPTION
FROM
TO
”Collection Queued”
collection (C)
Out
Collection Status allocated to the
collection of settlement transactions
by Routing function within Sequencing
module
Beginning of Nighttime Time Event (D)
In
Launches the start of day night-time
process
Beginning of Day-time
Time Event (E)
In
Launches the start of day time process Scheduling
DVP Cut-off Time
Event (F)
In
Launches the DVP cut-off process
Scheduling
Cut-off Time Event (G) In
Launches the cut-off processes.
Scheduling
End of Day Time Event In
(H)
Launches the End of Day process
Scheduling
End of Sequence Event In
(I)
Indicates that the sequence previously
sent to R&O has been treated
R&O
Sequence Ready Event Out
(J)
A collection of settlement transactions
is ready for treatment
R&O
End of Cycle
Information (K)
Out
Indicates the end of cycle of
settlement
Status
Management
Transaction Status
Information (L, M)
In
To confirm the cash restriction release
EoD Cash Restriction
Release information
(N)
Out
Information to release the restrictions
on cash at the end of day
SPS
EoD Intraday Credit
Reimbursement Event
(O)
Out
Sent to Auto-collateralisation module
Autocollateralisati
on
End of Last Cycle
Information (P)
Out
Sent to Liquidity Control to inform it
that the last cycle has ended.
Liquidity
Control
Sent to Scheduling module, after
which Scheduling sends a Business
event to NCB Business Procedures
module in order to trigger end-of-day
liquidity transfers (from T2S to T2)
Scheduling
End-of-Process Event
(Q)
Final_T2S_GFS_110.doc
VPB
Scheduling
VPB
To confirm intraday credit
reimbursement
Page 355
T2S General Functional Specifications
Functional Description
Settlement
3.5.5.5. Data accessed by the module
DATA
ACCESS MODE
COMMENT
STATIC DATA
DYNAMIC DATA
Settlement Transaction
Read
Settlement Transaction Link
Read
Settlement Transaction Link Set
Read
Settlement Transaction Status
Modify
Change to “Cancelled”
Collection
Create/Modify
Group of (linked) settlement
transactions
Eligibility Status of Individual Settlement
Instruction
Modify
Change to “empty”
Final_T2S_GFS_110.doc
Determination of the linked settlement
transaction
Page 356
T2S General Functional Specifications
Functional Description
Settlement
3.5.6. Validation, Provisioning and Booking
3.5.6.1. Diagram of the module
SETT:
Sequencing
SETT:
Auto-Collateralisation
SETT:
R&O
T2S
Operator
Collection (A)
[Collection Queued]
VPB
Data Store
[Party Restriction]
[Securities Account Restriction]
[Security Restriction]
[T2S Dedicated Cash Account Restriction]
[Market-Specific Restriction Type]
[T2S Dedicated Cash Account]
[Securities Account]
Rebuilding of Cash
Balances (L)
Rebuilding of Securities
Positions (K)
Intraday Restriction Check
Not
validated
Validated
Earmarking
Transactions
Rebuilding
securities positions
or cash balances
Collection
[Collection being processed]
Data Store
[Limit]
[Limit Utilisation]
[Earmarking Restriction Utilisation]
Rebuilding report (M)
Limits check
Failure
Collection
[Collection being processed]
Auto-collateralisation Answer (B)
Data Store
[Security Position]
[Cash Balance]
SETT:
Auto-Collateralisation
Provision checking
Failure
Data Store
[Securities Movement]
[Cash Movement]
Lack
Auto-collateralisation request (C)
Incoming Cash
Resources
Success
Pre-empted liquidity information (O)
User
Reimbursement Request
Collection
[Collection being processed]
Data Store
[Securities Movement]
[Cash Movement]
Collection
[Collection being processed]
Data Store
[Earmarking Restriction Utilisation]
[Earmarking Restriction]
Pre-empting
Collection
[Collection being processed]
2nd attempt
With "after"
Links removed
Data Store
[Collection]
[Settlement Transaction]
[Cash Movement]
[Individual Settlement Instruction]
[Liquidity Transfer]
Earmarking
Restriction Manager
Data Store
[Cash Balance]
[Security Position]
[Limit Utilisation]
[Journaling of Limit Utilisation]
[Earmarking Restriction Utilisation]
[Settlement Transaction]
[Individual Settlement Instruction]
[Liquidity Transfer]
Booking
Settl. Transaction
[Settlement in
process]
Floor / Ceiling
Information
Settl. Transaction
[Settled] or
[Partially Settled]
Settlement Status
Transaction
Status
Information (D)
Transaction
Status
Information (E)
SETT:
R&O
SETT:
Sequencing
Final_T2S_GFS_110.doc
Intraday credit reimbursement request (P)
Collateral
Settlement
Information (F)
Instruction
Status
Information (G)
LCMM: Status
Management
Restriction
Status
Information (H)
Floor / Ceiling
Information (I)
Liquidity
Transfer
Booking
Information (J)
LQMG: Notification &
Information
Management
Liquidity
Blocking
Status
Information (N)
LQMG: Liquidity
Control
Page 357
T2S General Functional Specifications
Functional Description
Settlement
3.5.6.2. Description of the module
The core purpose of the Validation, Provisioning and Booking module is to update the securities position
and cash balances with the cash and securities movements of the incoming settlement transactions, in a
centralised process {T2S.07.240}. This module behaves similarly in the day-time and the night-time
settlement periods.
For that purpose, the module receives in its entry queue collections containing:
•
(Linked) settlement transactions from the Sequencing module for a real-time settlement
attempt during the day-time settlement period;
•
Optimised settlement transactions from the Recycling & Optimisation module during both the
day-time and the night-time settlement periods;
•
Auto-Collateralisation Forced Reimbursement settlement transactions from the AutoCollateralisation module and issued following a decrease of NCB limit during the day-time
settlement period {T2S.08.800}.
The module handles the collections received in the sense that it tries to settle all the settlement
transactions of a collection in an “all or none” basis {T2S.09.080} and does not attempt any selection or
de-selection inside a collection. The unique exception to this principle relates to a collection of settlement
transactions having an “After” and “Before” link. In that case the settlement transactions with an “After”
link {T2S.09.110} are deleted from the collection following a first failure during the provisioning, in
order to achieve a new settlement attempt of the settlement transactions with the “Before” link only
{T2S.09.100}.
The module performs on each collection {T2S.07.260}:
•
Validation, with the Intraday Restriction Check function which checks that no intraday
restrictions is applicable on any of the traded ISIN, currency, accounts or T2S Party involved
in the collection;
•
Provisioning, with the Limits check function and the Provision checking function which:
-
Checks the compliance with the net buying limits or earmarking limit restrictions;
-
Adds settlement transactions to use restricted resources indicated by the T2S Parties;
-
Checks if the net flows (i.e. the sum using technical netting of debits and credits
movements on a considered securities position or cash balance) can be settled with the
resources available on the securities positions or cash balances;
73
Calls the Auto-collateralisation module in case of lacks of cash or securities73;
In case of securities already collateralised.
Final_T2S_GFS_110.doc
Page 358
T2S General Functional Specifications
Functional Description
Settlement
•
Booking, with the Pre-emption function which pre-empts the incoming resources in case of
reservation partially filled, and the Booking function which updates the securities positions
and cash balances with the cash and securities movements described in the settlement
transactions, and which updates the journaling limits;
•
Lastly, the Settlement Status function provides the other modules with the result of the
settlement process.
At the end of the Validation, Provisioning and Booking module, the status of each settlement transaction
in the collection is updated to the following values:
•
“Settled”, in case of successful settlement, or “Partially Settled” in case of partial settlement;
•
“Unsettled” in case of failure.
The “unsettled” settlement transactions are sent to the Recycling & Optimisation module for their
optimisation.
Management of securities positions and cash balances restrictions
The settlement process may involve settlement transactions that aim at setting up new restriction or
settlement transactions that use an existing restriction.
The setting up of a new reservation (securities or cash), blocking (securities or cash), or segregation
(securities only) is achieved with the booking of the relevant movements, that have been identified
upfront in the SPS module. The module transfers with these movements the corresponding quantity or
amount to a new restricted securities position or cash balance within the account and generates the
corresponding restriction reference (see the Booking function and the Pre-empting function).
The use of reserved, blocked or segregated positions is achieved when the settlement transaction
contains a Restriction reference. With this reference, the module adds a settlement transaction to transfer
the quantity or amount necessary from the restricted position to the main74 securities position or cash
balance before checking its provision (see the Provision Checking function, and notably the use of
restricted position).
The management of the earmarking limit restriction (securities only) differs from the management of the
other restrictions. As such the setting up of an earmarking is achieved by a dedicated Earmarking
Restriction Manager function and not by the provision-checking and booking functions. This function
creates or updates earmarking restriction on the securities account involved in the earmarking settlement
transaction (see the Earmarking Restriction Manager function and the dedicated processing of these
instructions outside of the booking, since positions are not involved).
74
The main security position or cash balance on an account is its non-restricted security position or cash balance.
Final_T2S_GFS_110.doc
Page 359
T2S General Functional Specifications
Functional Description
Settlement
The use of earmarked securities to settle a settlement transaction is not submitted to the indication of a
restriction reference but is automatically detected by the Limit Check function within the management of
the limits (see the Limits Check function, and notably the Earmarking Limit Restrictions Check).
Management of the partial settlement
The partial settlement of a settlement transaction is handled and described in the Recycling &
Optimisation module since it applies on unsettled settlement transactions {T2S.08.210} and depends
on specific windows and several other criteria.
In such a partial settlement, the Validation, Provisioning and Booking module only checks if a partial
quantity or amount has been filled upfront in the movements by the Recycling & Optimisation module. If
any, the partial quantity or amount is taken into account for the provision checking instead of the initial
quantity or amount.
In case of failure, this partial quantity or amount is not changed within the module. The considered
settlement transactions are sent to R&O in order to perform again the partial settlement during an
optimisation process.
In case of settlement, the booking function updates the securities positions and cash balances with this
partial quantity or amount and not with the initial quantity or amount. During the consecutive split of the
individual settlement instruction in the LCMM domain, the new individual settlement instruction created
with the remaining quantity or amount keeps track of the initial individual settlement instruction
{T2S.08.240}. In case of linked individual settlement instructions, the links are maintained in the new
split individual settlement instructions {T2S.08.420}.
Management of the partial execution during the settlement process (restrictions or liquidity transfers)
Complementary to the partial settlement process described above, a few settlement transactions are
subject to a partial execution during their settlement (“Immediate Liquidity Transfer” with the partial
indicator set to “yes”, “Segregation”, “Blocking”, “Reservation”). These partial executions are not
submitted to a specific window, threshold or T2S Party agreement.
When applying to settlement transaction subject to partial execution, the Provision Checking function can
fill the partial quantity or amount of the considered movements with the available quantity or amount.
The booking function updates the securities positions and cash balances with this partial quantity or
amount instead of the initial quantity or amount.
Final_T2S_GFS_110.doc
Page 360
T2S General Functional Specifications
Functional Description
Settlement
3.5.6.3. Description of the functions of the module
1 – Intraday Restriction Check
This function checks if no intraday settlement restriction is posted on any settlement transactions of the
collection. The function does not check securities positions or cash balances restrictions which are
managed by other functions in the module.
For this check, the function:
•
Checks the intraday restrictions;
•
Checks the securities eligibility for the auto-collateralisation earmarking;
•
Locks the entities to be updated with the booking function.
This function reads the entry queue in a FIFO mode, retrieves all settlement transactions that are
contained in the read collection in order to handle them in an “all or none” basis {T2S.07.330}.
If the status of the collection referenced in the queue is “Deleted”75 or if the status of any settlement
transaction in the collection is “Cancelled”, the function does not handle it and reads the following in the
queue.
Intraday settlement restrictions check
The function checks on the settlement transactions of the collection that no intraday settlement restriction
applies on the following entities:
•
Security {T2S.07.260} {T2S.16.510} {T2S.16.385};
•
Currency {T2S.07.260};
•
Security account {T2S.07.260} {T2S.16.680};
•
T2S dedicated cash account {T2S.07.260};
•
T2S Party (set by a CSD or a NCB) {T2S.16.680}.
•
If at least one intraday settlement restriction is detected, the collection is sent to the
Settlement Status function with the reason for failure.
•
Otherwise, the function switches the status of the collection to “Collection being processed”
and the status of each settlement transaction in the collection to “Settlement In Process”.
75 A collection can have been deleted after posting the collection in the queue by the Action on Transaction function in order to execute a
maintenance instruction.
Final_T2S_GFS_110.doc
Page 361
T2S General Functional Specifications
Functional Description
Settlement
Security eligibility to the auto-collateralisation checking
•
When the function detects a movement in a settlement transaction of the collection, which
credits or debits an earmarked position for auto-collateralisation, it checks if the security is
eligible to auto-collateralisation {T2S.08.590} {T2S.08.610} {T2S.08.620}.
•
If at least one of these settlement transactions uses a security that is not eligible to autocollateralisation, the collection is sent to the Settlement Status function with the reason for
failure.
Data locks
The locking of the involved data aims at forbidding competing updates (e.g. due to parallelisation of
booking process) or any static data updates that would modify the validity of the checks (e.g. limits).
The function locks in exclusive access for writing the following entities involved in the collection:
•
Securities Positions;
•
Cash balances;
•
Limits;
•
Earmarking Limit Restriction.
•
When the collection contains a settlement transaction whose category is either “Earmarking”
or “Unearmarking”76, the function sends it to the Earmarking Restriction Manager function.
•
Otherwise, the function sends the collection to the Limits Check function.
2 – Limits Check
This function checks that the booking of the collection does not lead to exceed the remaining quantity or
amount of the applicable:
•
Net Buying Limits {T2S.10.070};
•
Earmarking Limit Restrictions {T2S.10.030}.
Net Buying Limit check
In order to check the applicable Net Buying Limits, the function:
•
Searches if a net buying limit exists for each securities account involved in the collection
{T2S.10.080} {T2S.10.083} {T2S.10.086};
76
In this case, the collection contains only one settlement transaction.
Final_T2S_GFS_110.doc
Page 362
T2S General Functional Specifications
Functional Description
Settlement
•
Selects the settlement transactions which debits or credits a securities position of a securities
account with a Net Buying Limit;
•
Calculates the Cash Net Flows for each currency used in the cash movements of the selected
settlement transactions {T2S.07.390} {T2S.08.450} {T2S.08.460};
•
If the Net Buying Limit applies to several securities accounts, nets all the calculated Cash Net
Flows associated to those securities accounts {T2S.07.400} {T2S.10.060};
•
Checks if each calculated Cash Net Flows complies with the remaining amount in the
applicable Net Buying Limit.
If at least one cash net flows does not respect the applicable limit, the collection is sent for processing to
the Settlement Status function with the reason for failure {T2S.07.390}.
Otherwise, the collection is submitted to the Earmarking Limit Restrictions Check.
Earmarking Limit Restrictions Check
The function checks if the settlement transactions in the collection are subject to earmarked restrictions
{T2S.10.030}.
This detection is automatic77 by comparing the earmarking purpose to the characteristics of all settlement
transactions in the collection. The indication of a restriction reference by the T2S Party is not necessary.
For the settlement transactions that are subject to earmarked restrictions, the function:
•
Searches if an earmarking limit restriction exists, associated to the main securities position
for the considered ISIN and securities account, in the collection and if the earmarking
without limit is not set to “true”;
•
Calculates the Securities Net Flow of the selected settlement transactions;
•
When the calculated Securities Net Flow is in debit, checks if it complies with the remaining
amount in the applicable Earmarking Utilisation associated to the Earmarking Limit
Restriction.
If at least one Securities Net Flow does not respect the applicable remaining amount, the collection is sent
to the Settlement Status function with the reason for failure.
Otherwise, the Limits Check is successful and the collection is sent to the Provision Checking function.
3 – Provision Checking
This function checks if the securities positions and cash balances allow the settlement of the collection by:
77
The way to trigger off the automatic detection has still to be defined
Final_T2S_GFS_110.doc
Page 363
T2S General Functional Specifications
Functional Description
Settlement
•
Preparing the use of restricted resources (restricted security positions or/and restricted cash
balances);
•
Sending a request to the Auto-Collateralisation for an Intraday Credit Reimbursement
settlement transaction;
•
Calculating the Provisioning Net Flows (sum of debits and credits for each involved securities
position or cash balance);
•
Executing the provision-checking (from the Provisioning Net Flows);
•
In case of lack on an immediate liquidity transfer or on the set up of a restriction, partialising
the settlement transactions which can be partially executed during their settlement;
•
Sending a request for auto-collateralisation in case of remaining lack of cash or securities.
Moreover, the function checks the incoming cash resources with regards the negative NCB limit remaining
amounts in order to trigger auto-collateralisation reimbursements.
Use of restricted resources preparation
For each settlement transaction, the function prepares the use of restricted resources {T2S.07.360}
{T2S.07.370}
{T2S.09.190}
{T2S.09.220}
{T2S.10.030}
{T2S.10.040}
{T2S.10.050}
{T2S.10.130} by:
•
Checking if one or several restriction reference(s) are indicated;
•
Searching the restricted securities position or cash balance associated to each restriction
reference indicated;
•
For the available quantity or amount78, creating a new settlement transaction with a
movement which:
•
-
Debits the restricted securities position or cash balance;
-
Credits the main securities position or cash balance used in the trade;
Linking it with the corresponding original settlement transaction (the link type is Use of
Restriction);
•
Adding this settlement transaction to the collection.
Once the quantity/amount in the trade is covered, the function stops searching restricted resources even
if other restriction references are indicated in the settlement transaction. Otherwise, if the amount or
78
Limited by the quantity/amount necessary for the trade.
Final_T2S_GFS_110.doc
Page 364
T2S General Functional Specifications
Functional Description
Settlement
quantity is not covered, the function seeks for additional restricted resource if indicated in the settlement
transaction79.
Auto-collateralisation request for Intraday Credit Reimbursement
When the collection contains settlement transactions related to Intraday Credit reimbursement requests
(with the relevant ISO Transaction code), the function sends it to the Auto-Collateralisation module.
The settlement transactions contain Cash Movements as follows:
•
Debits of the main cash balance of a T2S Dedicated cash account owned by the considered
T2S Party;
•
Credits of the main balance of the NCB cash account;
If the “Auto-collateralisation” answer is:
•
positive (with the reimbursement settlement transactions already added in the collection),
the function:
-
locks the additional securities positions or cash balances involved in the collateral
settlement transactions added;
•
calculates the Provisioning Net Flows for the collection;
negative (no reimbursement settlement transaction added in the collection), the provision
checking of the collection fails and the collection is sent to the Settlement Status function
with the reason for failure {T2S.07.260}.
Provisioning Net flows calculation
Before performing the provision checking, the function calculates the Provisioning Net Flows of all
involved main80 securities positions or cash balances {T2S.07.270} {T2S.07.290} {T2S.07.340}
{T2S.08.090}.
To that purpose, for each securities position or cash balance, the function:
•
Selects all movements which debit or credit this securities position or cash balance (including
the movements prepared upfront to use restricted resources);
•
Sums all debits and credits movements (for their partial quantity or amount if filled, or if not,
their initial quantity or amount);
79
At the end, if the trade is not fully covered by the restricted resources, the missing resource is implicitly debited from the available main position or
balance.
80 Because the Provisioning Check function has added only the available amount of the restricted securities positions/cash balances, the provisioning
net flows are not calculated for those securities positions/cash balances.
Final_T2S_GFS_110.doc
Page 365
T2S General Functional Specifications
Functional Description
Settlement
The Provisioning Net Flows can be:
•
Positive, the main securities positions or cash balances receives more resources than sent;
•
Negative, the main securities positions/cash balances sends more resources than received.
Within a collection, the positive Provisioning Net Flows are compensated by the negative Provisioning Net
Flows. As a result when the booking of negative Provisioning Net Flows is ensured, the booking of positive
Provisioning Net Flows is also ensured. Consequently, the provision checking is performed only on the
negative Provisioning Net Flows (see the diagram in Table below).
Execution of the provision checking
For each involved main securities positions or cash balances with a negative Provisioning Net Flows, the
function checks whether this Provisioning Net Flows can be settled with the available quantity or amount.
This provision checking does not apply to accounts which are allowed to have a negative balance (i.e. T2S
NCB cash account, RTGS transit accounts, Issuer CSD balance accounts) {T2S.07.410}.
In case of successful provision checking, the function:
•
Sends the collection to the Pre-empting function.
Otherwise:
•
Switches the status of the auto-collateralisation settlement transactions of the collection to
Cancelled and subtracts them from the collection;
•
Re-calculates
the
collection
Provisioning
Net
Flows
without
the
Cancelled
auto-
collateralisation settlement transactions;
•
Submits the collection to the Partial execution or auto-collateralisation functions.
Partial execution of allowed settlement transaction categories
In case of failure, the function checks if the calculation of the relevant Provisioning Net Flows involves
settlement transactions that can be partially executed in the Validation Provisioning and Booking module
(i.e. “Segregation”, “Blocking”, “Reservation”, “Immediate Liquidity Transfer” with the partial indicator to
yes” {T2S.06.260} {T2S.07.350} {T2S.07.351} {T2S.10.030} {T2S.10.130}. The “CoSD
blocking” are not concerned {T2S.07.352}).
In such case, the function:
•
checks if a partial execution of those settlement transactions allows a successful provisioning
check;
•
fills the partial quantity/amount of the relevant movement with the calculated quantity or
amount;
Final_T2S_GFS_110.doc
Page 366
T2S General Functional Specifications
Functional Description
Settlement
Auto-collateralisation request for lacks of cash or securities
Except for the liquidity transfers {T2S.06.260} and for the restriction setup {T2S.08.570}, if at least
one failed provision checking remains, (on securities, due to collateralised securities {T2S.08.910}, or
on cash {T2S.07.320} {T2S.08.140} {T2S.08.200} {T2S.08.480}), the function sends an “Autocollateralisation” request to the Auto-collateralisation module. This request contains:
•
the collection with “Collection being processed” status (its settlement transactions remaining
with “Settlement in Process” status);
•
the calculated net balances and net quantities of the Provisioning Net Flows;
•
the corresponding Provision Checking Quantities and Provision Checking Balances81.
If the “Auto-collateralisation” answer is:
•
Positive, the collection is enriched with the auto-collateralisation settlement transactions. The
function:
-
locks the additional securities positions or cash balances involved in these new settlement
transactions {T2S.09.090};
-
re-calculates all the Provisioning Net Flows and re-performs the provision checking to
ensure that the collection with the auto-collateralisation settlement transactions can be
settled;
•
Negative, the provision checking of the collection fails and the collection is sent to the
Settlement Status function with the reason for failure {T2S.07.260}.
Checking the incoming cash resources regarding the negative NCB limit remaining amounts
Resulting from the decrease of NCB limits, some remaining amounts can be negative. The incoming cash
resources can be used to reimburse the auto-collateralisation in order to return the remaining limit
amount to zero {T2S.08.800}.
The function checks the cash net flows:
•
If one or several credited cash flows are related to negative Remaining Amounts (corrected
by the corresponding requested reimbursement amount) of NCB Utilisation Limits, the
function sends a Pre-Empted Liquidity Information to the Auto-Collateralisation module for
auto-collateralisation reimbursements;
•
If the “Auto-collateralisation” answer is positive (with the collateral reimbursement
settlement transactions already added in the collection), the function:
81
The negative values correspond to the lacks.
Final_T2S_GFS_110.doc
Page 367
T2S General Functional Specifications
Functional Description
Settlement
-
locks the additional securities positions or cash balances involved in the collateral
settlement transactions added;
•
re-calculates all the Provisioning Net Flows and re-performs the provision checking;
If there is no new reimbursement settlement transaction in the collection (negative answer or
no cash usable for auto-collateralisation reimbursement), the function sends the collection to
the Pre-empting function.
Illustration of the provision-checking concepts and processing
The following table presents an illustration of the provision-checking concepts and processing:
Securities Positions & Cash Balances
involved in the collection
Securities Positions
SP1
Collection
of Settlement
Transactions
Settlement Transactions
ST1
SP2
+10
ST3
-30
ST4
-18
Provisioning Net Flows to settle*
-30
(-) Available**
+12
(=) Provision Checking result
-18
LACK
CB2
-22
+22
-30
+18
+50
+8
CB1
-14
+30
ST5
ST6
Cash Balances
SP4
-10
+14
ST2
SP3
+43
+30
-50
CB3
+30
-43
-30
+64
-64
+26
-77
List of
Debits
& Credits
-8
+14
+44
-28
+51
+50
N/A
N/A
+22
OK
+0
N/A
N/A
-77
LACK
* Sum of Debits & Credits for a securities position or cash balance
** Available quantity or amount in the a securities position or cash balance before the settlement of the collection
Based on a collection of six settlement transactions, the function calculates the Provisioning Net Flows of
each securities positions (SP1 to SP4) and cash balances (CB1 to CB3) involved in the collection.
For each negative one (here for SP1, SP4 and CB3), the function executes the provision-checking by
subtracting to the Provisioning Net Flows the available quantity or amount available in the relevant
securities positions and cash balances.
If the provision-checking is positive (here SP4), the Provisioning Net Flows can be settled during the
booking.
If the provision-checking is negative (here SP1 and CB3), the Provisioning Net Flows cannot be settled
during the booking. Then the function tries to fill in the lacks by:
•
searching involved settlement transactions which can be partially executed;
Final_T2S_GFS_110.doc
Page 368
T2S General Functional Specifications
Functional Description
Settlement
•
sending a request for auto-collateralisation.
The collection can be sent to the Pre-empting function, only if both lacks on SP1 and CB3 can be filled in.
4 – Pre-empting
This function handles the pre-emption of incoming resource (securities or cash) on a main securities
position or cash balance with an associated reservation partially filled due to the following cases:
•
A settlement transaction reserving a cash or security is partially executed. An incoming cash
or security resource is pre-empted in order to complement the previous reservation
{T2S.07.351};
•
A restricted cash balance is automatically released during the end of the previous settlement
day. An incoming cash resource is pre-empted in order to re-generate the restriction for the
new settlement day.
The function pre-empts an incoming resource for a partially filled restriction only if the relevant
Provisioning Net Flow calculated by the Provision Checking function is positive (i.e. the main securities
positions or cash balances receives more resources than sent). This Provisioning Net Flow quantity or
amount is the maximum quantity or amount which can be pre-empted.
For each pre-empting restricted position, the function:
•
selects the settlement transactions crediting the relevant resource;
•
inserts as many settlement transactions as necessary to complement the reservation partially
executed (from the oldest to the most recent one). Each settlement transaction contains a
movement from the main securities position or cash balance to the relevant restricted
securities position or cash balance.
The pre-empting settlement transactions are added to the collection and linked to the pre-empted
settlement transactions with a Pre-emption for Restriction link.
Once all possible resources have been pre-empted, the function sends the collection to the Booking
function.
5 – Booking
This function aims at:
•
Updating the security positions and the cash balances;
•
Updating the Earmarking Limit Restrictions and the Journaling of Auto-collateralisation;
•
Updating the limit utilisations and the Journaling of Limit Utilisations;
•
Checking the Floor and Ceiling;
Final_T2S_GFS_110.doc
Page 369
T2S General Functional Specifications
Functional Description
Settlement
•
Updating the statuses;
•
Unlocking the entities.
Security positions and cash balances update
{T2S.07.220}
The function updates the securities positions and cash balances with the movements of all settlement
transactions of the collection {T2S.07.230}. Within the collection, the processing order of the settlement
transactions is not relevant. During this process an account structurally in credit might be temporary in
debit but must be in credit at the end of the booking of the collection {T2S.07.300} except for the
accounts which are authorised to be in debit.
As a result:
•
The securities positions or the restricted securities positions are updated from the quantity or
partial quantity (if it is filled {T2S.08.210}) of each securities movement;
•
The cash balance or the restricted balance are updated from the amount or partial amount (if
it is filled {T2S.08.210}) of each cash movement.
This function then updates the data related to reservation as follows:
•
In case of partial execution of a settlement transaction with the “Reservation” category, the
function fills the missing quantity or amount on the relevant restricted securities position or
restricted cash balance {T2S.07.351};
•
In case of pre-empting to fill a restriction, the function decreases the missing quantity or
amount on the relevant restricted securities position or restricted cash balance;
•
If a reserved position (cash or securities) is entirely used, the corresponding restricted
securities position or cash balance is deleted {T2S.09.200}.
Once the securities positions and the cash balances are updated, the settlement transactions are
irrevocable {T2S.07.250} {T2S.07.310} {T2S.10.010} {T2S.10.110}.
Updating the Earmarking Limit Restrictions and the Journaling of Auto-collateralisation;
From the settlement transactions eligible to an earmarking restriction, the function:
•
Creates the Journaling of Earmarking with its attributes Earmarking Utilisation Quantity After
and Remaining Earmarked Quantity After calculated from the securities movements;
•
If the earmarking has not been used since the start of the settlement day, a new Journaling
of Earmarking is created first with the same attributes above respectively set to zero and to
the value of the Earmarking Limit of the Earmarking Limit Restriction;
Final_T2S_GFS_110.doc
Page 370
T2S General Functional Specifications
Functional Description
Settlement
•
Updates (or creates for the settlement day) the Earmarking Utilisation of the relevant
Earmarking Limit Restrictions with its attributes Remaining Earmarked Quantity and
Earmarking Utilisation Quantity calculated from the last Journaling of Earmarking;
•
In case of an Auto-collateralisation settlement transaction, creates a Journaling of Autocollateralisation from the cash movement;
•
In case of an Auto-collateralisation reimbursement, updates the Remaining Autocollateralisation Amount of the relevant Journaling of Auto-collateralisation.
In the particular case of the earmarking restriction without specified limit (i.e. with infinite earmarking
limit), the function updates neither the Earmarking Utilisation nor the Journaling of Earmarking.
Journaling of Limit Utilisations
The function updates the net flows of the settled settlement transactions for each of the following limit
types:
•
The NCB Limits;
•
The Auto-Collateralisation Limits;
•
The Net Buying Limits;
The following table summarises how the limits are expressed, which accounts are concerned and which
settlement transactions are involved:
LIMIT TYPE
NCB Limits
EXPRESSED IN
Cash amount
RELATED ACCOUNT
INVOLVED SETTLEMENT TRANSACTIONS
T2S dedicated
Cash accounts
{T2S.10.083}
Auto-Collateralisation Limits
Cash amount
Security accounts
{T2S.10.086}
Net Buying Limits
Cash amount
Security accounts
{T2S.10.086}
Auto-collateralisation settlement
transactions
All settlement transactions except the
Auto-collateralisation settlement
transactions
Each debit or credit of the settled settlement transactions relevant for the limit can impact one or several
limits.
For each defined limit, the function creates a new occurrence in Journaling of Limit Utilisation for each
involved transaction and updates the attributes of Limit Utilisation from the total amount of the involved
settlement transactions.
To do this, for each account of each settlement transaction:
•
The function identifies the limits linked to each account;
Final_T2S_GFS_110.doc
Page 371
T2S General Functional Specifications
Functional Description
Settlement
•
For each limit to be respected, the function;
-
Searches the last Journaling of Limit Utilisation. If the limit has not been used since the
start of the settlement day, the Remaining Limit After is initialised with the Limit and the
Limit Utilisation After is set to zero;
-
Calculates the new Remaining Limit After, the Requested Reimbursement Amount (for the
NCB limits only) and Limit Utilisation After of Journaling of Limit Utilisation using the cash
amount or security quantity debited or credited regarding the related account
{T2S.10.100};
-
Creates a new Journaling of Limit Utilisation with this data.
When all the Journaling of Limit Utilisations is created, for each limit, the function updates the relevant
Limit Utilisation from the last Journaling of Limit Utilisation. In case of first utilisation of the limit since the
start of the settlement day, the limit is created only if the limit utilisation is not equal to zero (sum of the
debits equal to the sum of the credits {T2S.10.090}).
Checking the Floor and Ceiling
For each updated cash balance:
•
If a floor is defined on the corresponding T2S dedicated cash account (static data) and if the
cash balance is less than the floor amount, the function sends floor information to the
Settlement Status function {T2S.06.400};
•
If a ceiling is defined on the corresponding T2S dedicated cash account (static data) and if
the cash balance is greater than the ceiling amount, the function sends ceiling information to
the Settlement Status function {T2S.06.420}.
Updating the statuses
The function updates every settlement transaction in the collection {T2S.07.210}:
•
With a “Partially Settled” status when the partial quantity in the Securities Movement or/and
the partial cash amount in the cash movement are filled; or
•
With a “Settled” status82.
The function updates in the same way the status of the underlying individual settlement instruction or
liquidity transfer order, except for the following particular individual settlement instructions, which are
updated as follows:
•
82
In case of a CoSD Blocking {T2S.09.230},
The status of the settlement transactions for which a check has previously failed is updated by the Settlement Status function.
Final_T2S_GFS_110.doc
Page 372
T2S General Functional Specifications
Functional Description
Settlement
•
•
-
the Settlement Status is switched to “Settled”,
-
the CoSD Status is switched to “CoSD on Hold”,
-
the Eligibility Status is switched to “Empty”;
In case of a CoSD Cancel {T2S.09.250},
-
the CoSD Status is switched to “Empty”,
-
the Cancellation Status is switched to “Cancelled”;
In the case of a the CoSD Release,
-
the CoSD Status is switched to “Empty”,
-
the Settlement Status is switched to “Settled”.
Unlocking the data
The function unlocks the locked entities:
•
The security positions and restricted positions regarding the security accounts used on the
settlement transactions;
•
The cash balances and restricted positions regarding the cash accounts used on the
settlement transactions;
•
The corresponding limits, limit utilisations and journaling of limit utilisations.
The function sends the collection of the settlement transactions to the Settlement Status function.
6 – Earmarking Restriction Manager
This function handles the earmarking and unearmarking settlement transactions to set up or to delete
earmarked restrictions {T2S.10.030}.
If the received collection contains an earmarking settlement transaction, the function checks if an
Earmarking Limit Restriction associated to the main securities position for the considered ISIN in the
securities account exists for the same earmarking purpose83:
•
if no existing earmarking is found, the function creates a new Earmarking Limit Restriction
for the quantity indicated in the securities movement of the underlying settlement
transaction84.
83
This purpose is referred in the data model as “Market specific restriction type” and is associated to the earmarking limit restriction. The detailed
characteristics still to be specified during the next specification phase.
84 If the movement quantity is not filled, it means that all the securities of the relevant positions are earmarked and can be used for the earmarking
purpose (attribute Earmarking Without Limit is set to “True”).
Final_T2S_GFS_110.doc
Page 373
T2S General Functional Specifications
Functional Description
Settlement
•
Otherwise, the function:
-
Increases the Earmarking Limit of the Earmarking Limit Restriction with the quantity
indicated in the securities movement of the underlying settlement transaction;
-
Updates accordingly the Remaining Earmarked Quantity of the Earmarking Utilisation if
the Earmarking Limit Restriction has already been used during the settlement day.
If the received collection contains an unearmarking settlement transaction, the function:
•
Decreases the Earmarking Limit of the concerned Earmarking Limit Restriction for quantity
indicated in the securities movement of the settlement transaction;
•
Updates accordingly the Remaining Earmarked Quantity of the Earmarking Utilisation if the
Earmarking Limit Restriction has already been used during the settlement day.
The function then unlocks the data previously locked, updates the settlement transaction status to
“Settled” and sends the collection to the Settlement Status function.
7 – Settlement Status
This function provides the other domains with the result of the settlement process.
In case of failure, the function checks if there is at least one settlement transaction with an “After” link
type in the collection:
•
if any, the function:
-
Subtracts those settlement transactions and the transactions previously created for the
use of the restricted positions from the collection;
-
Switches the status of the settlement transactions with an “After” link type to Unsettled;
-
Switches the status of the transactions previously created for the use of the restricted
positions to Cancelled;
-
Re-sends the collection to the Limits Check function for a new settlement attempt
{T2S.09.100} {T2S.09.110}.
•
If no, the function:
-
Deletes the possible value in the partial quantity or amount in movements;
-
Switches the status of the transactions previously created for the use of the restricted
positions to Cancelled;
-
Switches the other settlement transactions status to “Unsettled” with the reason for
failure received from the function;
Final_T2S_GFS_110.doc
Page 374
T2S General Functional Specifications
Functional Description
Settlement
-
Unlocks the involved securities positions or cash balances previously locked.
In every case, settlement (or partial settlement) or failure, the function provides the other domains with
information allowing them to launch other process or to inform the involved T2S Party {T2S.06.400}
{T2S.06.420} {T2S.13.090} {T2S.13.130}. Depending on the settlement transaction category this
information can be:
•
“Transaction Status Information” sent to R&O or Sequencing;
•
“Instruction Status Information” (containing the reference of the blocked or reserved position
or balance when created) sent to the LCMM domain;
•
“Collateral
Settlement
Information”
sent
to
the
LCMM
domain
{T2S.06.440}
{T2S.06.450};
•
“Restriction Status Information” for the pre-emption of incoming resources sent to the LCMM
domain ;
•
“Liquidity Transfer Booking Information” (containing the reference of the blocked balance if
created) sent to Liquidity Management domain;
•
•
“Floor/Ceiling Information” sent to Liquidity Management domain;
“Liquidity Blocking Status Information” sent to the Liquidity Management domain.
The contents of this information are described in the table “Input/Output of the module” below.
At the end of the treatment of all settlement transactions of the collection, the function switches the
status of the collection to “Collection deleted”.
8 – Rebuilding securities positions or cash balances
The function is triggered by the reception of a Rebuilding Securities Positions or a Rebuilding Cash
Balances event from the Operational Monitoring module. {T2S.10.020} {T2S.10.120}
The function aims at rebuilding securities positions or cash balances from the parameters filled in the
event in real time. A Rebuilding Securities Positions event contains the following parameters:
•
A starting date (mandatory),
•
Parameters related to securities accounts:
•
-
No parameter: the rebuilding covers all the securities accounts in T2S;
-
CSD: the rebuilding covers all the securities accounts held by the related CSD;
-
Security account: the rebuilding covers the specified securities account;
Parameters related to securities:
Final_T2S_GFS_110.doc
Page 375
T2S General Functional Specifications
Functional Description
Settlement
-
No parameter: the rebuilding covers all the securities;
-
Security code: the rebuilding covers the specified security
A Rebuilding Cash Balances event contains the following parameters:
•
A starting date (mandatory);
•
Parameters related to cash balances:
-
No parameter: the rebuilding covers all the cash accounts in T2S;
-
‘NCB’: the rebuilding covers all the cash accounts of the related NCB;
-
‘Cash account’: the rebuilding covers the specified cash account
From the parameters sent, the function identifies the relevant securities or T2S dedicated cash accounts,
then for each one, it:
•
Locks it;
•
Deletes the securities positions or the T2S dedicated cash balances for the relevant period;
•
Selects the settlement transactions settled during this period and impacting the security
positions or the T2S dedicated cash balances;
•
Rebuilds the security positions or the T2S dedicated cash balances following the order of the
settlement date/time of the settlement transactions.
•
Unlocks the account.
At the end, the function performs a validation to ensure that any earmarking restrictions pertaining to the
rebuilt positions are consistent {T2S.10.022}. The function sends the rebuilding report to the
Operational Monitoring module.
3.5.6.4. Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
Collection (A)
In
Queued Collections
Sequencing,
R&O or AutoCollateralisation
modules
Auto-collateralisation
Answer (B)
In
Collection of settlement transactions
after Auto-collateralisation
AutoCollateralisation
module
Auto-collateralisation
request (C)
Out
Provisioning Net Flows (with the
missing quantity or amount) and the
collection of settlement transactions
Final_T2S_GFS_110.doc
TO
AutoCollateralisation
module
Page 376
T2S General Functional Specifications
Functional Description
Settlement
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Pre-Empted Liquidity
Information (O)
Out
In case of negative NCB remaining
amount and incoming cash resources
AutoCollateralisation
module
Intraday Credit
Reimbursement
Request (P)
Out
In case of the user reimbursement
request
AutoCollateralisation
module
Transaction Status
information (D)
Out
In case of settlement (new resources
available) or failed (new unsettled
transaction
Recycling &
Optimisation
module
Transaction status
information (E)
Out
In case of settlement transaction
category set to “EoD Cash Restriction
Release”, “EoD intraday credit
reimbursement” or “Forced liquidity
transfer”
Sequencing
module
Collateral Settlement
Information (F)
Out
In case of settlement transaction
category set to “Collateral”
Status
Management
module
Instruction Status
Information (G)
Out
In case of failure, settlement or partial
settlement (with the partial quantity or
amount)
Status
Management
module
Restriction Status
Information (H)
Out
In case of settlement transaction
category related to “Reservation”,
“Unreservation”, “Blocking”,
“Unblocking” or “CoSD Blocking”
Status
Management
module
Floor/Ceiling
Information (I)
Out
Floor or Ceiling reached
Notification
Management
module
Liquidity Transfer
Booking Information
(J)
Out
In case of settlement transaction
category set to “Liquidity Transfer”
Notification
Management
module
Rebuilding of
Securities Positions
(K)
In
Rebuilding of securities positions asked Operational
by a system administrator of the T2S
Monitoring
Operator
Rebuilding of Cash
Balances (L)
In
Rebuilding of T2S Dedicated cash
balances asked by a system
administrator of the T2S Operator
Rebuilding report (M)
Out
Reporting of the rebuilding of
securities positions or T2S Dedicated
cash balances
Operational
Monitoring
In case of settlement transaction
category set to “Blocking Liquidity
Transfer Order”
Liquidity Control
module
Liquidity Blocking
Out
Status Information (N)
Final_T2S_GFS_110.doc
Operational
Monitoring
Page 377
T2S General Functional Specifications
Functional Description
Settlement
3.5.6.5. Data accessed by the module
DATA
ACCESS MODE
COMMENT
STATIC DATA
Market-Specific Restriction Type
For the intraday settlement restrictions
Securities Account
For restriction on acct, party identifier…
T2S Dedicated Cash Account
For acct status, closing date etc…
Limit
For Net Buying Limit
Limit Group
For Net Buying Limit
Party Restriction
For the intraday settlement restrictions
Security Restriction
For the intraday settlement restrictions
T2S Dedicated Cash Account Restriction
For the intraday settlement restrictions
Securities Account Restriction
For the intraday settlement restrictions
DYNAMIC DATA
Collection
Settlement Transactions
For transaction type, status…
Securities Movement
Cash Movement
Individual Settlement Instruction
For the status
Liquidity transfer
For the status
Securities Position
Sec. acct balance to be updated
Cash Balance
Cash balance to be updated
Limit
To manage the limits
Earmarking Limit Restriction
To manage and update the Earmarking
Limit Restriction
Earmarking Utilisation
Earmarking Utilisation to be updated
Journaling of Earmarking
Journaling of Earmarking to be updated
Journaling of Auto-collateralisation
Remaining Auto-collateralisation Amount
to be updated
Limit Utilisation
Limit Utilisation to be updated
Journaling of Limit Utilisation
Journaling of Limit Utilisation to be
update
Final_T2S_GFS_110.doc
Page 378
T2S General Functional Specifications
Functional Description
Settlement
3.5.7. Recycling and Optimisation
3.5.7.1. Diagram of the module
3.5.7.2. Description of the module
This module runs optimisation procedures aiming at identifying collections of settlement transactions that
can be submitted together to a settlement attempt, with an expected success:
•
Out of sequenced settlement transactions that have been selected by the Sequencing module
during the night-time settlement period {T2S.07.010} {T2S.08.080};
•
Out of all unsettled settlement transactions that failed to settle in a first settlement attempt
during the day-time settlement period {T2S.07.090} {T2S.08.080}, except for the ones
related to blocking individual settlement instructions85.
A collection of settlement transactions can include settlement transactions linked by T2S parties
{T2S.05.147} {T2S.09.110}. In this case, the potential updates applied to the composition of the
collection in the next optimisation steps have imperatively to be achieved in accordance with these links.
85 Blocking individual settlement instructions can be either settled, partially settled or unsettled (in case of empty position or balance). In this last
case, no recycling is to be done.
Final_T2S_GFS_110.doc
Page 379
T2S General Functional Specifications
Functional Description
Settlement
Optimisation procedures are designed in order to obtain the optimum balance86 between volume and
value of settlement with the available securities and cash resources {T2S.08.010} (cash received from
RTGS Systems, cash proceeds of selling settlement transactions, cash transfers from other T2S dedicated
cash
accounts,
cash
stemming
from
intraday
credit
provision
through
auto-collateralisation)
{T2S.06.150}.
These procedures resort on series of optimisation algorithms launched upon reception of:
•
events from the Scheduling and the Sequencing modules;
•
or “launch events” (launching procedure to be defined);
•
or Transaction Status Information (new resources or unsettled settlement transaction) from
the Validation Provisioning and Booking (VPB) module.
The series of optimisation algorithms are launched by the Optimisation Algorithm Manager which is in
charge of calling the most efficient one. They are launched according to a strategy that depends on the
triggering event and the settlement period.
Each launched Optimisation Algorithm tries to identify settlable collections of transactions, i.e. collections
with a successful simulated provision-checking as computed by the Simulated Provision Checking (SPC)
function. When needed to build the settlable collection, the SPC function, resorts to partial settlement
during the partial settlement windows87.
Once identified, the settlable collections of settlement transactions are sent to VPB for their actual
settlement, with a collection status value set to “Collection Queued”.
The Optimisation Algorithms can be categorised in two families:
•
The “De-selection based” algorithms work on the full set of unsettled settlement transactions.
They are multi-Currency, mono or multi-ISIN, and bilateral or multi-participants. They
progressively deselect the settlement transactions causing failures until the settlement of
remaining settlement transactions is possible;
•
The “Build up based” algorithms build settlable chains by searching for market situations,
such as simple circles and back-to-back or more complex circles with a new unsettled
settlement transaction or incoming resources.
Launch strategies implemented by the Optimisation Algorithm Manager can be summarised as follows:
86 The URD defines the optimum balance between the maximisation of volume and value as aiming to avoid situations where only volume
optimisation would be sought (that could lead to favour settlement of low value retail transactions at the detriment of transactions with higher value)
or situations where only value optimisation would be sought (what could lead to favour the settlement of high value transactions at the detriment of
many retail transactions with lower value).
87 The partial settlement windows take place at the end of the night-time settlement cycle, before the DVP cut-off time, or in additional settlement
periods during the settlement day if required by specific T2S Actors.
Final_T2S_GFS_110.doc
Page 380
T2S General Functional Specifications
Functional Description
Settlement
•
During the night-time period88, the series of optimisation algorithms:
-
Starts with “De-selection based” Optimisation Algorithms efficient on a large number of
transactions;
-
Is followed by a “Gross Settlement Attempt” for all remaining settlement transactions
efficient to reduce the stock;
-
Ends with “Build up based” Optimisation Algorithms efficient on the remaining reduced
stock;
•
During the day-time period, series are composed of “Build up based” Optimisation
Algorithms. They are launched after each new unsettled settlement transaction or upon the
arrival of new resources or on a regular basis with a high frequency;
•
During the day-time and the night-time period, additional series with “De-selection based”
Optimisation Algorithms are launched on demand and apply to the whole unsettled
settlement transactions.
The efficiency of the launch strategies depends on the Optimisation Algorithms actually called per
settlement period and triggering event as well as on the characteristics of the settlement transactions
being submitted to optimisation.
In that respect, the Algorithm manager includes a set of parameters that allows the launch of different
series of Optimisation Algorithms per event and settlement period.
These series of Optimisation Algorithms vary from standard ones that meet known market practices, to
new series aiming at a higher performance. The optimal series between market practices and dedicated
Optimisation algorithms will be established along the testing and acceptance of the module on the basis
of real data as they are expected in the T2S go-live configuration.
3.5.7.3. Description of the functions of the module
1 – Optimisation Algorithm Manager
Series of Optimisation Algorithms
The Optimisation Algorithm Manager function launches series of Optimisation Algorithms {T2S.08.040}
{T2S.08.050} and/or Gross settlement attempts {T2S.08.020} according to the settlement period and
the triggering event.
88 It is to be considered for Sequence 1 (corporate actions related settlement), Sequence 2 (FOP rebalancing between accounts of the same T2S
Party) and Sequence 3 (NCBs specific settlement transactions) of the first night-time cycle to submit the related settlement transactions (and
unsettled settlement transactions of the previous sequence) only to a gross settlement out of any other optimisation algorithm. In this case, the
described night-time optimisation series will be used only for the sequence 4 (Trading-related settlement transactions) of the first night-time cycle as
well as for the following night-time cycles.
Final_T2S_GFS_110.doc
Page 381
T2S General Functional Specifications
Functional Description
Settlement
The following tables summarise the series of Optimisation Algorithms launched by the Optimisation
Algorithm Manager and the related parameters defined below:
TRIGGERING EVENT
APPLICABLE TO
PARAMETERS
LAUNCHED OPTIMISATION ALGORITHMS OR
GROSS SETTLEMENT ATTEMPTS
Night-time Optimisation Series
“Sequence Ready”
event sent by
Sequencing
module
All sequenced
settlement
transactions and
unsettled settlement
transactions from
previous sequences
and cycles
Duration
Greedy Smart Multilateral Mono Isin
Maximum size of a
build-up chain
Greedy Smart Bilateral Multi Isin
Launch Activated for
each of optimisation
algorithm or gross
settlement attempt
Depth of simulated
provision-checking
OnebyOne Smart Multilateral Mono Isin
OnebyOne Smart Multilateral Multi Isin
Gross settlement of all pending
transactions
Bilateral-Mono-Isin-Simple Circle
Trilateral-Mono-Isin-Back to Back
Multilateral-Build up
Day-time Unsettlement Event Series (*)
“Transaction Status All unsettled
Information” for
settlement
failure sent by VPB transactions that can
module
be linked to the
incoming unsettled
one
Duration
Maximum size of a
build-up chain
Launch Activated for
each of optimisation
algorithm
Bilateral-Mono-Isin-Simple Circle
Trilateral-Mono-Isin- Back to Back
Multilateral-Build up
Depth of simulated
provision-checking
Day-time Settlement Event Series (*)
“Transaction Status All unsettled
Information” for
settlement
successful booking transactions impacted
sent by VPB
with incoming
module
resources
Duration
Recycling89
Launch Activated
Depth of simulated
provision-checking
New Resources Time Event Optimisation Series (*)
89
See below the description of the “Recycling” Optimisation Algorithm, at the end of the paragraph “Optimisation Algorithm functions”
Final_T2S_GFS_110.doc
Page 382
T2S General Functional Specifications
Functional Description
Settlement
“New Resources
All unsettled
Day-time
settlement
Optimisation
transactions (i)
Event” sent by
impacted with
Scheduling module incoming resources of
the period or (ii) that
can be linked to
incoming unsettled of
the period
Duration
Bilateral-Mono-Isin-Simple Circle
Maximum size of a
build-up chain
Trilateral-Mono-Isin- Back to Back
Launch Activated for
each of optimisation
algorithm
Multilateral-Build up
Or
Recycling
Depth of simulated
provision-checking
Frequency
Optional Day-time Optimisation Series
“Launch Event”
All unsettled
settlement
transactions
Duration
Greedy Smart Multilateral Mono Isin
Maximum size of a
build-up chain
Greedy Smart Bilateral Multi Isin
Launch Activated for
each of optimisation
algorithm or gross
settlement attempt
OneByOne Smart Multilateral Mono Isin
OneByOne Smart Multilateral MultiIsin
Multilateral-Build up
Depth of simulated
provision-checking
All the algorithms listed above are described in the Optimisation Algorithms functions.
(*) The launch of “Day-time Unsettlement Event Series” and “Day-time Settlement Event Series” on the
one hand and “New Resources Day-time Optimisation Series” on the other hand, must be activated
alternately using the “Launch activated” parameter.
Parameters of the series
Technical parameters are used to adapt the series of Optimisation Algorithms, in order to allow the fine
tuning and/or the adaptation of the optimisation process to the market needs:
•
The “Duration” parameter is the total time given for the execution of the successive calls of
optimisation algorithms by the Optimisation algorithm manager function;
•
The “Maximum size of a build-up chain” parameter is used by “Build up based” optimisation
algorithms as the maximum number of unsettled settlement transactions which settle when
associated together;
•
The “Launch activated” parameter gives the possibility, in a series, to activate or not the
launch of an Optimisation algorithm by the Optimisation algorithm manager function;
•
The “Frequency” parameter is the number of minutes between two executions of a series.
The Scheduling module uses this parameter to send the corresponding event;
Final_T2S_GFS_110.doc
Page 383
T2S General Functional Specifications
Functional Description
Settlement
•
The “Depth of simulated provision-checking” parameter allows defining the different
parameters applying to the execution of the SPC function (e.g. the possibility to use the
virtual positions and balances or the possibility to resort to auto-collateralisation90)..
For each series, before launching an Optimisation Algorithm or a Gross settlement attempt, the function
systematically checks:
•
If the Launch Activated parameter is set to “Yes” (otherwise the function goes to the next
Optimisation Algorithm or a Gross settlement attempt);
•
If the elapsed time doesn’t exceed the duration. When the duration is reached, the series
stops. In the particular case of Night-time Optimisation Series, the series directly sends an
“End of Sequence” event to the Sequencing module.
Note that these parameters are used by the Optimisation Algorithm Manager function, the Optimisation
Algorithms functions, the SPC function or the Scheduling module.
Night-time Optimisation Series
This series is launched when the function is triggered by a “Sequence Ready” event sent by the
Sequencing module for each night-time sequence.
For the sequenced settlement transactions and the unsettled settlement transactions from previous
sequences and cycles {T2S.07.020} {T2S.07.070}, and based on the parameters of the series, the
function sequentially:
•
Prepares the launch of the “Greedy Smart Multilateral Mono Isin” optimisation algorithm by
creating and browsing a candidate list of Isin to be submitted from the remaining sequenced
and unsettled settlement transactions;
•
Launches the “Greedy Smart Multilateral Mono Isin” optimisation algorithm for each of the
browsed Isin;
•
Prepares the launch of the “Greedy Smart Bilateral Multi Isin” optimisation algorithm by
creating and browsing a candidate list of couple of T2S parties to be submitted from the
remaining sequenced and unsettled settlement transactions;
•
Launches the “Greedy Smart Bilateral Multi Isin” optimisation algorithm for each of the
browsed couple of T2S parties;
•
Prepares the launch of the “OnebyOne Smart Multilateral Mono Isin” optimisation algorithm
by creating and browsing a candidate list of Isin to be submitted from the remaining
sequenced and unsettled settlement transactions;
90
The full list of parameters and their respective aim are given further in the description of the SPC function.
Final_T2S_GFS_110.doc
Page 384
T2S General Functional Specifications
Functional Description
Settlement
•
Launches the “OnebyOne Smart Multilateral Mono Isin” optimisation algorithm for each of the
browsed Isin;
•
Launches the “OnebyOne Smart Multilateral Multi Isin” Optimisation Algorithm which applies
on all remaining sequenced and unsettled settlement transactions;
•
Launches the “Gross Settlement Attempt” to send all the sequenced settlement transactions
to VPB for a settlement attempt {T2S.08.020};
•
For each optimisation algorithms, “Bilateral-Mono-Isin-Simple Circle”, “Trilateral-Mono-IsinBack to Back” and “Multilateral-Build up” the function:
-
Prepares the launch of the optimisation algorithm by creating and browsing a candidate
list of sequenced and unsettled settlement transactions to be submitted;
-
Launches the optimisation algorithm for each of the browsed sequenced and unsettled
settlement transaction;
•
Sends an “End of Sequence” event to the Sequencing module after the execution of the last
Optimisation Algorithm.
Final_T2S_GFS_110.doc
Page 385
T2S General Functional Specifications
Functional Description
Settlement
Final_T2S_GFS_110.doc
Page 386
T2S General Functional Specifications
Functional Description
Settlement
Day-time Unsettlement Event Series
During the daytime settlement period, new incoming settlement transactions are submitted to a first
settlement attempt by the VPB module. The Day-time Unsettlement Event Series is launched when the
function is triggered by a “Transaction Status Information” after a failure in VPB {T2S.08.140}
{T2S.08.150} {T2S.08.180}. Based on the new unsettled settlement transaction referenced by the
“Transaction Status Information”, the function:
•
Launches the “Bilateral-Mono-Isin-Simple Circle” Optimisation Algorithm which seeks other
unsettled settlement transactions becoming potentially settable if associated with the new
submitted one;
•
If no settlable collection of settlement transactions is found, launches the “Trilateral-MonoIsin- Back to Back” Optimisation Algorithm which works according to the same principle;
•
If no settlable collection of settlement transactions is found, launches the “Multilateral-Build
up” Optimisation Algorithm which works according to the same principle.
Final_T2S_GFS_110.doc
Page 387
T2S General Functional Specifications
Functional Description
Settlement
Unsettled
Transaction
Status Information
(A)
« Data Store »
Cash Provisioning Net Flow
Securities Provisioning Net Flow
Settlement Transaction
Cash Movement
Securities Movement
Day-time Unsettlement Event Series
Optimisation algorithm
Bilateral-Mono-Isin-Simple Circle
Elapsed time < Duration
No
Yes
Optimisation algorithm
Trilateral-Mono-Isin- Back to Back
Elapsed time < Duration
No
Yes
Optimisation algorithm
Multilateral-Build up
Collection
[Collection Queued]
(C)
Day-time Settlement Event Series
This series is launched when the function is triggered by a “Transaction Status Information” after a
successful booking in VPB {T2S.08.140} {T2S.08.150} {T2S.08.160} {T2S.08.170}. Based on the
new resource description, the function:
•
Prepares the launch of the “Recycling” Optimisation Algorithm by creating and browsing a
candidate list of unsettled settlement transactions that may potentially benefit from the
incoming resources;
•
Launches the “Recycling” Optimisation Algorithm by submitting the candidate list to select
unsettled settlement transactions which can be potentially settle with the additional resource.
Final_T2S_GFS_110.doc
Page 388
T2S General Functional Specifications
Functional Description
Settlement
Settled
Transaction
Status Information
(A)
Day-time Settlement Event Series
Create candidate list of transactions for
incoming resource
Elapsed time < Duration
No
Yes
« Data Store »
Cash Provisioning Net Flow
Securities Provisioning Net Flow
Settlement Transaction
Cash Movement
Securities Movement
Optimisation algorithm
Recycling
Collection
[Collection Queued]
(C)
New Resources Time Event Optimisation Series
This series is launched when the function is triggered by a “New Resources Day-time Optimisation Event”
sent by the Scheduling module {T2S.08.140} {T2S.08.150}. Based on the list of “Transaction Status
Information” received from VPB in the meantime, the function:
•
Browses the list of “Transaction Status Information” in a way to optimise their
management91;
•
Launches, for each element of the list,:
-
The “Day-time Unsettlement Event Series”, if it is a “Transaction Status Information” for
failure;
-
the “Day-time Settlement Event Series” , if it is a “Transaction Status Information” for
new resource.
91 The detailed rules to sort the « Settlement Status Event » are still to be specified. They will be compliant with the optimisation objectives to obtain
the optimum balance between volume and value of settlement with the available securities and cash resources {T2S.08.010}
Final_T2S_GFS_110.doc
Page 389
T2S General Functional Specifications
Functional Description
Settlement
Optional Day-time Optimisation Series
This series is launched when the function is triggered by a “Launch Event”. Based on all the unsettled
settlement transactions, the function sequentially:
•
Prepares the launch of the “Greedy Smart Multilateral Mono Isin” optimisation algorithm by
creating and browsing a candidate list of Isin to be submitted from the unsettled settlement
transactions;
•
Launches the “Greedy Smart Multilateral Mono Isin” optimisation algorithm for each of the
browsed Isin;
•
Prepares the launch of the “Greedy Smart Bilateral Multi Isin” optimisation algorithm by
creating and browsing a candidate list of couple of T2S parties to be submitted from the
remaining unsettled settlement transactions;
•
Launches the “Greedy Smart Bilateral Multi Isin” optimisation algorithm for each of the
browsed couple of T2S parties;
•
Prepares the launch of the “OnebyOne Smart Multilateral Mono Isin” optimisation algorithm
by creating and browsing a candidate list of Isin to be submitted from the remaining
unsettled settlement transactions;
•
Launches the “OnebyOne Smart Multilateral Mono Isin” optimisation algorithm for each of the
browsed Isin;
•
Launches the “OnebyOne Smart Multilateral Multi Isin” Optimisation Algorithm which applies
on all remaining unsettled settlement transactions;
•
Prepares the launch of the “Multilateral-Build up” optimisation algorithm by creating and
browsing a candidate list of unsettled settlement transactions to be submitted;
•
Launches the “Multilateral-Build up” optimisation algorithm for each of the browsed unsettled
settlement transaction.
Final_T2S_GFS_110.doc
Page 390
T2S General Functional Specifications
Functional Description
Settlement
« Data Store »
Cash Provisioning Net Flow
Securities Provisioning Net Flow
Settlement Transaction
Cash Movement
Securities Movement
« Launch
Event » (H)
Optional Day-time
Optimisation Series
Elapsed time < Duration
Yes
No
Create candidate list of Isin for
Greedy Smart Multilateral Mono Isin
Browse List
New Element?
Elapsed time
< Duration
Yes
No
Yes
Optimisation algorithm
Greedy Smart Multilateral Mono Isin
Yes
Optimisation algorithm
Greedy Smart Bilateral Multi Isin
Yes
Optimisation algorithm
OnebyOne Smart Multilateral Mono Isin
Yes
Optimisation algorithm
Multilateral-Build up
No
Create candidate list of couple of T2S parties
For Greedy Smart Bilateral Multi Isin
Browse List
Elapsed time < Duration
No
Yes
New Element?
No
Elapsed time
< Duration
No
Yes
Create candidate list of Isin for
OnebyOne Smart Multilateral Mono Isin
Browse List
Elapsed time < Duration
No
Yes
New Element?
Elapsed time
< Duration
Yes
No
No
Optimisation algorithm
OnebyOne Smart Multilateral Multi Isin
Elapsed time < Duration
Yes
No
Create candidate list of transactions for
Multilateral-Build up
Browse List
Elapsed time < Duration
No
Yes
New Element?
No
Collection
[Collection Queued]
(C)
2 – Optimisation Algorithms functions
The optimisation algorithms listed above aim at identifying a collection of settlement transactions that can
be settled together successfully. These algorithms have common features and dedicated features in order
to reach this common objective through dedicated approaches.
Final_T2S_GFS_110.doc
Page 391
T2S General Functional Specifications
Functional Description
Settlement
Common features
Framework
All the optimisation algorithms share a similar framework with the following steps:
•
Selection among the settlement transactions to be optimised of collections of settlement
transactions that may potentially settle together (“Collection Selected” status), and sorting
according to the considered optimisation algorithm;
•
Constitution of one or several collections of settlement transactions that can settle together;
•
Submission of the collection of settlement transactions to Simulated Provision-Checking (SPC)
function for detection of potential lacks;
•
If lacks are detected, the algorithm builds a new collection of settlement transactions aiming
at filling in these lacks and submits it again to SPC function;
•
Otherwise, the settlable collection of settlement transactions is sent to the VPB module for a
settlement attempt, with the collection status value updated to “Collection Queued”.
All the algorithms chosen for the different optimisation series operate on a linear mode (execution time
increasing proportionally with the number of processed transactions). No exponential algorithm (execution
time increasing exponentially with the number of processed transactions) including recursive mechanisms
is selected for performance considerations.
Call for Simulation of provision-checking
As far as the Simulated Provision-Checking (SPC) is concerned, this function is called by the Optimisation
Algorithms in order to verify whether the settlement of a collection of settlement transactions is possible.
The objective is to simulate the provision checking, similarly to the way it is achieved in the VPB module,
within the following context of the optimisation process:
•
At the beginning of each algorithm, the function is called for a first Simulated Provision
Checking on the selected collection of settlement transactions. This check allows the
detection of potential lacks that are then analysed by the algorithm.
•
Each time the algorithm has built a new collection of settlement transactions aiming at filling
in these lacks, the function is called for update of the Simulated Provision Checking. In case
of failure, the algorithm built a new collection of settlement transactions aiming at filling in
these lacks. In case of success, the collection is selected for settlement in VPB module.
During the day-time settlement period, the settlable collection of settlement transactions is sent to VPB
for a settlement attempt, with the collection status value set to “Collection Queued”. Since the positions
might have been changed by real-time settlement attempts on the same accounts, VPB needs to process
Final_T2S_GFS_110.doc
Page 392
T2S General Functional Specifications
Functional Description
Settlement
a full new Provision Checking after having blocked the accounts, in order to confirm the actual booking for
this collection.
During the night-time settlement period, the same process is applied to the settlable collection of
settlement transactions, with a confirmation of the provisioning by VPB, in order to take into account
possible change in the positions and/or balances due to the settlement of other collections of settlement
transactions sent by parallel optimisation algorithms.
When calling the SPC function, the Optimisation Algorithms can rely on parameters to define the depth of
the functionality. These parameters relate to level of limits checks, real or virtual cash balances and
securities positions, resort to auto-collateralisation and partial settlement.
The use of these parameters globally would aim at performing simpler processes for the provisioning in
the Optimisation Algorithms and should improve the efficiency of the Optimisation Algorithms.
Moreover, the parameters related to securities positions and cash balances offer the possibility to find
collections of settlement transactions independently of any change that may occur on the real balances
and positions.
Priority management
Each time an optimisation algorithm needs to sort unsettled settlement transactions before a selection or
de-selection, either during the day-time {T2S.08.190}, or during the night-time {T2S.08.130}, the
following criteria are used, in decreasing weight order:
•
Level of priority {T2S.07.130} {T2S.07.140} {T2S.07.150} with the following order:
-
Reserved priority {T2S.07.160},
-
Top priority {T2S.07.170},
-
High priority {T2S.07.180},
-
Normal priority {T2S.07.190};
•
Oldest intended settlement date {T2S.08.060} {T2S.08.070};
•
Additional criteria (i.e. specific security and/or participant)
needed by the considered
Optimisation algorithm in the way to maximise the volume and value of settlement with the
available securities or cash resources {T2S.08.010} {T2S.08.060};
•
In case of partial settlement, a dedicated additional criterion permitting to limit the number
of redeliveries split (maximum number of redeliveries split parameter) {T2S.08.390}.
The level of priority of the collection of settlement transactions is the highest one among all the
settlement transactions of the collection {T2S.09.130}.
Final_T2S_GFS_110.doc
Page 393
T2S General Functional Specifications
Functional Description
Settlement
Multi-currency management
The multi-currency capability is handled in the optimisation process with the management of every
currency as a separately missing resource to be solved (as opposed to considering only lacks of securities
and lacks of cash in Euro) {T2S.08.440} {T2S.08.450} {T2S.08.460}.
As a result, no technical cross-currency cash netting is done: the optimisation processes consider net
position on securities and on each currency {T2S.08.470}.
Dedicated features per Family of Optimisation algorithms
“De-selection based” optimisation algorithms
This family of algorithms uses the following de-selective strategy {T2S.08.120}:
•
Global netting is done by the Simulated Provision-Checking function on all the settlement
transactions to be optimised to identify potential lacks (cash per currency or ISIN). The
composition of this collection depends on the considered optimisation algorithm;
•
Two approaches are then possible for identifying the settlable collection of settlement
transactions:
-
Settlement transactions potentially responsible for the lack identified are de-selected one
by one till the collection becomes settlable;
-
All the settlement transactions potentially responsible for the main lack identified are deselected and the de-selected settlement transactions are re-selected one by one as the
collection stays settlable (this type of de-selection algorithms is also called “Greedy”
algorithms);
•
As soon as a settlable collection of settlement transactions is identified («Collection Settlable”
status), the collection status value is set to “Collection Queued” and the collection is sent to
VPB for a settlement attempt.
The “De-selection based” optimisation algorithms that are described in the module include the following:
•
Greedy Smart Multilateral Mono Isin: deselects from a collection of pending settlement
transactions on the same security, the ones potentially responsible for the lack identified. The
de-selected settlement transactions are re-selected one by one, without creating a new lack
or increasing an existing one, as the collection stays settlable;
•
Greedy Smart Bilateral Multi Isin: deselects from a collection of pending settlement
transactions between two parties, the ones potentially responsible for the lack identified. The
de-selected settlement transactions are re-selected one by one, without creating a new lack
or increasing an existing one, as the collection stays settlable;
Final_T2S_GFS_110.doc
Page 394
T2S General Functional Specifications
Functional Description
Settlement
•
OnebyOne Smart Multilateral Mono Isin: identifies from a collection of pending settlement
transactions on the same security, the ones to be de-selected, for resolving the detected
lacks without creating a new lack or increasing an existing one, until the remaining collection
of settlement transactions is able to settle together;
•
OnebyOne Smart Multilateral Multi Isin: identifies from a collection of pending settlement
transactions the ones to be de-selected, for resolving the detected lacks without creating a
new lack or increasing an existing one, until the remaining collection of settlement
transactions is able to settle together.
“Build up based” optimisation algorithms
This family of algorithms uses a selective strategy to resolve gridlocks situations by looking for chains
(empty circles, back-to-back, more complex chains):
•
Selection of unsettled settlement transactions:
-
From a new unsettled or settled settlement transaction event, these algorithms select and
sort (by the criteria explained in common features) other unsettled settlement
transactions which can potentially settle: (i) with the new unsettled settlement transaction
{T2S.08.180} or (ii) with the new resources in case of a new settled settlement
transaction {T2S.08.160} {T2S.08.170};
-
From a time event, these algorithms are associated with two functions Create Candidate
List and Read element that create and browse a list of unsettled settlement transactions
to be submitted to these algorithms. Then these algorithms select other unsettled
settlement transactions which can potentially settle if associated with the browsed
unsettled settlement transaction.
•
For the first selected transaction associated to the new “unsettled” settlement transaction or
to the new resources, a technical netting is done by the Simulated Provision-checking
function
to
check
if
this
collection
is
settlable
{T2S.08.090}
{T2S.08.100}
{T2S.08.110};
•
In case of fail, the same calculation is done for the next selected settlement transaction;
•
In case of success the settlable collection of settlement transactions (“Collection Settlable”
status) is sent to VPB module for a settlement attempt, moving simultaneously the collection
status value to “Collection Queued” {T2S.08.180}.
The “Build up based” optimisation algorithms implemented in the module include the following:
•
Bilateral Mono Isin Simple Circle: for an unsettled settlement transaction, searches, among
unsettled settlement transactions, an opposite settlement transaction (same resource missing
Final_T2S_GFS_110.doc
Page 395
T2S General Functional Specifications
Functional Description
Settlement
–ISIN or cash-, same participants, opposite direction) that can settle together with the
original transaction. It aims at covering common market situation called “Simple circle”;
•
Trilateral Mono Isin Back to Back: for an unsettled settlement transaction, searches among
unsettled settlement transactions, a settlement transaction sharing the same resources and
sharing one counterpart, which is able to settle when combined with the initial settlement
transaction. It aims at covering common market situation called “Back-to-back”;
•
Multilateral Build-up: for an unsettled settlement transaction or for additional resource
available searches among unsettled settlement transactions, multiple settlement transactions
sharing the same resources and sharing one counterpart, that are able to settle when
combined with the initial settlement transaction;
•
Recycling: for additional resource available searches among unsettled settlement transactions
the ones which can benefit from this new resource to settle.
3 – Simulated Provision Checking
The Simulated Provision Checking function includes all the features of the limits check and provision
checking functions of VPB. In addition, the partial settlement is part of this function, since it applies on
unsettled settlement transactions following an earlier settlement attempt {T2S.08.210}, with the aim to
minimise the number of settlement transactions submitted to partial settlement {T2S.08.040}
{T2S.08.050}.
Framework
This function aims at verifying whether the settlement of a collection of settlement transactions is possible
through the following process:
•
The limits are checked to ensure that the settlement of the collection does not exceed the
remaining quantity or amount of the applicable Net Buying Limits and/or Earmarking limit
restrictions;
•
The Provisioning Net Flows are calculated : Sum of debits and credits on securities position
and cash balance of every securities and cash movement, for each settlement transaction
involved in the collection;
•
The Provisioning Net Flows are compared to the available quantity or amount in the
securities position or cash balance before the settlement of the collection;
•
The resulting lacks on securities positions or cash balances are determined;
Final_T2S_GFS_110.doc
Page 396
T2S General Functional Specifications
Functional Description
Settlement
•
If one or more lacks on securities positions or cash balances are detected, the function calls
the Auto-Collateralisation module in a simulation mode, i.e. no collateral settlement
transactions are actually created by this module92 {T2S.08.120} {T2S.08.200};
•
If one or more lacks on securities positions or cash balances still remain during a partial
settlement window, the function attempts to resort to partial settlement, as described below;
•
Then the function returns a status (settlable or un-settable) and the list of the Provisioning
Net Flows (with potential lacks on securities positions or cash balances) of the involved
securities positions and cash balances for the collection to the calling Optimisation algorithm.
Technical parameters
The following technical parameters allow defining the behaviour of the function:
•
The “Initialisation or Update” parameter calculates the Provisioning Net Flows of a dedicated
collection of settlement transactions or updates it after the modification of this collection by
an optimisation algorithm;
•
The “Limits Check” parameter specifies if the function checks or not the limits (Net Buying
Limits and/or Earmarking limit restrictions);
•
The “Comparison with Available” parameter gives the possibility to process with:
-
The real positions and balances;
-
The virtual positions and balances93;
-
No extra positions and balances, in order to verify the collection of settlement
transactions can be settable by itself without using any resources in account.
•
The “Resort to Auto-collateralisation” parameter allows resorting or not to a simulated autocollateralisation;
•
The “Partial Settlement” parameters permits to authorise or not the partial settlement.
Partial settlement
During the partial settlement windows (i.e. at the end of the night-time settlement cycle, before the DVP
cut-off time, or in additional settlement periods during the settlement day if required by specific T2S
Actors {T2S.07.080} {T2S.07.100} {T2S.08.220}), the function takes into account the partial
amount available with the following actions:
92 The collateral settlement transactions are created only during the actual settlement attempt in VPB, once the accounts are locked, in order to
prevent any other settlement transactions to use the same collateral and to prevent any change in the possibility to resort to auto-collateralisation.
93 The virtual positions and balances, set up by the Optimisation Algorithm Manager function, are defined as the positions and balances: (i) initialised
at the beginning of the current optimisation series with the real position and balances and (ii) updated with the impact of each collection of settlement
transactions sent to VPB. Their management is to be detailed in the following specification phase.
Final_T2S_GFS_110.doc
Page 397
T2S General Functional Specifications
Functional Description
Settlement
•
To check the participants agreement and the applicable threshold related to the settlement
transaction {T2S.08.250} {T2S.08.260} {T2S.08.265} {T2S.08.270} {T2S.08.280}
{T2S.08.290} {T2S.08.420} {T2S.08.430} {T2S.07.352};
•
To compute the ratio to be used by considering the applicability rules of the threshold
{T2S.08.300} {T2S.08.310} {T2S.08.320} {T2S.08.330} {T2S.08.410};
•
To include into relevant accounts the securities and cash received in the collection of
settlement transactions under consideration {T2S.08.380};
•
To fill the partial quantity/amount of each movement in the considered settlement
transactions according to the result of the Simulated Provision Checking {T2S.07.320}
{T2S.08.230}.
3.5.7.4. Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Transaction Status
Information (A)
In
Transaction status information
(settled/unsettled)
VPB module
Sequence Ready Event
(B)
In
Event for new night-time sequence
Sequencing module
Collection (Collection
Queued) (C)
Out
Collection of settlement transactions
resulting from an optimisation
process
VPB module
End of Sequence Event
(D)
Out
Information event for end of
sequence treatment
Sequencing
module
Time Event (E)
In
Triggering event for New Resources
Time Event Optimisation Series
Simulated AutoOut
collateralisation Request
(F)
Simulated Auto-collateralisation
Request
Simulated AutoIn
collateralisation Answer
(G)
Simulated Auto-collateralisation
Answer
Scheduling module
Autocollateralisation
module
Autocollateralisation
module
3.5.7.5. Data accessed by the module
DATA
ACCESS MODE
COMMENT
STATIC DATA
Securities Account
Read
For Provision Checking
T2S Dedicated Cash Account
Read
For Provision Checking
Limit
Read
For Net Buying Limit
Limit Group
Read
For Net Buying Limit
Final_T2S_GFS_110.doc
Page 398
T2S General Functional Specifications
Functional Description
Settlement
DATA
Security Valuation
ACCESS MODE
Read
COMMENT
For Optimisation Algorithms
DYNAMIC DATA
Collection
Read/Write
For Optimisation Algorithms
Cash Provisioning Net Flow
Read/Write
For Optimisation Algorithms and
Provision Checking
Securities Provisioning Net Flow
Read/Write
For Optimisation Algorithms and
Provision Checking
Settlement Transaction
Read/Write
For transaction type, status…
Cash Movement
Read/Write
For optimisation and partial settlement
Securities Movement
Read/Write
For optimisation and partial settlement
Restriction References
Read
Linked Restrictions
Read
Cash Balance
Read
Securities Position
Read
Partial Settlement Threshold
Read
Limit Utilisation
Read
Earmarking Limit Restriction
Read
Final_T2S_GFS_110.doc
For Net Buying Limit
Page 399
T2S General Functional Specifications
Functional Description
Settlement
3.5.8. Auto-collateralisation
3.5.8.1. Diagram of the module
Below is an Activity Diagram modelling the interactions between the functions within the module.
3.5.8.2. Description of the module
The core feature of this module is to provide intraday credit during the night-time and day-time
settlement periods in order to reduce the number and value of transactions failing to settle in case of lack
of liquidity {T2S.08.040} {T2S.08.050} {T2S.08.490}.
The module leads to the creation of settlement transactions dedicated to the auto-collateralisation and
linked with the underlying settlement transactions intended to settle {T2S.08.570}. Those settlement
transactions fit to each NCB context (pledge or repo) through pre-defined procedures {T2S.08.700}.
The auto-collateralisation is provided for all T2S eligible currencies {T2S.08.480} for trading-related
settlement instructions or corporate event instructions {T2S.08.730}.
Final_T2S_GFS_110.doc
Page 400
T2S General Functional Specifications
Functional Description
Settlement
The auto-collateralisation is provided both on stock and on flow. Whenever possible, the autocollateralisation on flow is used first and complemented by an auto-collateralisation on stock if necessary
{T2S.08.600}.
In addition to this main feature, the module also manages:
•
Dynamic reimbursement or automated substitution in case of potential fail during settlement
due to collateralised securities {T2S.08.910};
•
Intraday credit reimbursements requested by a T2S Party {T2S.08.820}, due to a
decreased Auto-Collateralisation Limit set by a Central bank (NCB) during the settlement day
{T2S.08.800}94 or due to the End-of-day process {T2S.08.850}.
In the case of decreased Auto-Collateralisation Limit set by a Central bank (NCB), if the cash needed is
not sufficient to ensure reimbursement and reduce the amount of outstanding intraday credit under the
limit set by the NCB, a pre-emption mechanism95 is activated in the module VPB. For each cash preemption, the module manages the remaining intraday credit reimbursements until decreasing the amount
of credit below the limit set by the NCB.
If the collection received contains several settlement transactions96, the module uses the technical netting
to limit {T2S.08.110} {T2S.08.200} {T2S.08.740}:
•
The intraday credit to the net amount of needed cash for each T2S Dedicated cash account;
•
The auto-collateralisation on flow to the net quantities for each bought ISIN in the collection
for a security account;
•
The dynamic reimbursement / automated substitution to the net quantity of securities for an
ISIN in a securities account needed for the settlement of the underlying settlement
transactions.
In case of request sent by the Recycling & Optimisation module, the Auto-collateralisation module
executes only a simulation of the possible auto-collateralisation and sends a positive or negative answer.
The creation of the actual collateral settlement transactions takes place on the Validation, Provisioning
and Booking request.
The Auto-collateralisation module is designed as follows:
•
The
Auto-collateralisation
Manager
function
(1)
manages
the
“(Simulated)
Auto-
collateralisation” request by iterating on lacks, launching the Intraday Credit Provider
94 Decreased Auto-collateralisation Settlement Bank limit do not trigger any automated reimbursement
95
The pre-emption mechanism used in this case is differs from the reservation mechanism. It applies to all the T2S Dedicated cash account owned by
the T2S Party and managed by the relevant NCB and not only to one T2S Dedicated cash account as is the case for the reservation mechanism.
96
Cf. Introduction of the Settlement domain for the collection description.
Final_T2S_GFS_110.doc
Page 401
T2S General Functional Specifications
Functional Description
Settlement
functions to fill in them and sending the “(Simulated) Auto-collateralisation” answer to the
calling module;
•
For each lack, Intraday Credit Provider functions (2 to 7) check the eligibility criteria and
limits to access to the auto-collateralisation, select collateral, attempt a dynamic
reimbursement and, if the considered lack is filled in, prepare the underlying collateral
settlement transactions;
•
For different possible reimbursements (excluding the dynamic reimbursement), Intraday
Credit Reimbursement functions (8 to 10) select the collateral to release and prepare the
underlying settlement transactions;
•
The Collateral Transactions Generator function (11) creates the settlement transactions
prepared by other functions in the module according to the applicable NCB autocollateralisation procedure.
Lastly, the Auto-collateralisation module does not manage the provision of information on autocollateralisation transactions to the involved NCBs collateral management systems, CSDs and directly
connected parties {T2S.06.440} {T2S.06.450}. This provision of information is done by the Status
Management module on the basis of information provided by Validation, Provisioning and Booking after
the booking of the settlement transactions created by the Auto-collateralisation module.
3.5.8.3. Description of the functions of the module
Common features for all functions
All functions in the Auto-collateralisation module:
•
Use data on ISIN eligibility {T2S.08.590}, collateral prices (haircut already deducted
{T2S.08.680}) and close links {T2S.06.430} {T2S.08.620} {T2S.08.670} retrieved by
the Static Data domain from external collateral management systems (CMS) for euro and for
non-euro NCBs;
•
Calculate the collateral value of a securities position or a securities movement by multiplying
the collateral price of the ISIN by the number of securities concerned;
•
Take into account the impact on stocks of the collateral settlement transactions previously
created to fill in other lacks within the same request.
1 – Auto-collateralisation manager
This function receives the “Auto-collateralisation” request from Validation, Provisioning and Booking and
the “Simulated Auto-collateralisation” request from Recycling & Optimisation.
Those requests contain:
Final_T2S_GFS_110.doc
Page 402
T2S General Functional Specifications
Functional Description
Settlement
•
The concerned underlying collection of settlement transactions for which an intraday credit is
needed;
•
The Provisioning Net Flows calculated on the main securities positions and main cash
balances involved in the underlying collection by the Provisioning functions of both
aforementioned modules.
Each Provisioning Net Flow is described with:
•
A securities position or cash balance;
•
The net flow resulting from the settlement of the collection (quantity or amount received i.e.
positive incoming flow, or sent i.e. negative outgoing flow);
•
The provision-checking (i.e. difference between the available securities or cash in the
securities position or the cash balance and the net flow) which indicates a lack of securities
or a lack of cash when it is negative.
If the (Simulated) Auto-collateralisation request contains several lacks on cash and/or securities, the
function sorts them before launches the intraday credit provision process for each lack. The detailed rules
used to sort lacks will be defined during the next specification phase in a way to optimise the use of
available resources for the auto-collateralisation (collateral and liquidity).
Once lacks are sorted, the function launches the intraday credit provision process for the first lack in the
list by sending its “Lack Description” (missing amount or quantity and cash balance or securities position
reference) to the:
•
T2S Party Eligibility Check function in case of lack of cash;
•
Collateralised Securities Check function in case of lack of securities.
If after the intraday credit provision process, the considered lack has been filled in, the Autocollateralisation Manager function receives the collateral settlement transactions prepared and checks if
another lack is still to fill in the (Simulated) Auto-collateralisation request. In this case, its “Lack
Description” is sent to the relevant function as previously.
When all the lacks are filled in, the function sends:
•
In case of “Simulated Auto-collateralisation” request, a positive “Simulation Autocollateralisation” answer (i.e. the underlying collection is settlable with auto-collateralisation)
to Recycling & Optimisation;
•
In case of “Auto-collateralisation” request, the collateral settlement transactions prepared to
the Collateral Transactions Generator function.
Final_T2S_GFS_110.doc
Page 403
T2S General Functional Specifications
Functional Description
Settlement
2 – T2S Party eligibility check97
On receipt of a cash “Lack Description”, this function checks if the T2S Party which owns the T2S
Dedicated cash account is set as eligible to auto-collateralisation98 by the relevant NCB {T2S.08.510}
{T2S.08.530}).
If the result of this check is negative, a negative “Auto-collateralisation answer” is sent to the calling
module. Else, the “Lack Description” is sent to the Auto-collateralisation Limits Check function.
3 – Auto-collateralisation limits check
This function checks if the remaining amounts in the applicable limits allow filling in the considered lack of
cash.
Two types of auto-collateralisation limits exist:
•
The Auto-Collateralisation Limit set by a Central bank (NCB) which limits the net amount of
intraday credit provided by the involved NCB to a T2S Party. This limit applies to all its T2S
dedicated cash accounts owned with this NCB and overrides other limits {T2S.08.520}
{T2S.08.540}
{T2S.08.550}
{T2S.08.560}
{T2S.08.690}
{T2S.08.770}
{T2S.16.595};
•
The Auto-Collateralisation Limit set by the Payment/Settlement bank which owns the
considered T2S Dedicated cash account which limits the amount of intraday credit in a
currency that can be obtained through auto-collateralisation. This limit applies for the
settlement of instructions pertaining to one or several securities accounts {T2S.08.750}
{T2S.08.760}.
Since the Validation, Provisioning and Booking has already checked that the Net Buying Limit is not
breached by the collection of settlement transactions submitted to the Auto-collateralisation module, the
latter does not check again these Net Buying Limits {T2S.08.780}.
If no limit is applicable, the amount of intraday credit is only limited by the amount of available collateral
{T2S.08.790}.
For its checks, the function uses the last limit value stored in the static-data99 {T2S.08.800}
{T2S.08.810}.
97 It is assumed that a NCB wishing to offer auto-collateralisation has previously met the pre-requisites in the module static data, i.e. that before
being able to allow the access of a settlement bank to auto-collateralisation, the NCB has opened the requested central bank cash account, and
defined all the parameters for the auto-collateralisation operations, according to its repo or pledge choice. In consequence, it is sufficient here to
check the settlement bank eligibility.
98 A settlement bank benefiting from auto-collateralisation is eligible for all its cash accounts held with a given NCB. The T2S Parties which can
benefit of auto-collateralisation for their operations on this cash account are managed with the Auto-collateralisation Limits set by a
Payment/Settlement bank processing.
Final_T2S_GFS_110.doc
Page 404
T2S General Functional Specifications
Functional Description
Settlement
To check the Auto-Collateralisation Limit set by a Central bank (NCB), the function:
•
Searches if an Auto-Collateralisation Limit set by a Central bank (NCB) is applicable to the
T2S Party which owns the T2S Dedicated cash account;
•
If a limit exists, determines its remaining amount by searching in the journaling of limit
utilisations if a use has already been done during the settlement day:
-
If no utilisation has been done, the remaining amount is equal to the amount of the limit;
-
If there is an utilisation, the remaining amount has been calculated during the booking of
the last utilisation;
•
Checks if the amount in the “Lack Description” can be filled in with this remaining amount:
-
If the amount is insufficient, a negative “Auto-collateralisation answer” is sent to the
calling module;
-
If the amount is sufficient, the function searches applicable Auto-Collateralisation Limit
set by a Payment/Settlement bank.
To check the applicable Auto-Collateralisation Limit set by a Payment/Settlement bank, the function:
•
Selects in the collection, all settlement transactions which debit the T2S Dedicated cash
account with the considered lack;
•
For each involved securities accounts, searches if a Auto-Collateralisation Limit set by a
Payment/Settlement bank is defined for the considered currency and determines the
remaining amount as for the Auto-Collateralisation Limit set by a Central bank (NCB) ;
•
If several securities accounts are involved, determines which limits to use by sorting the
settlement transactions selected in the first step in a way to respect the optimisation
objectives to maximise the settlement transactions settled100;
•
Checks if the amount in the “Lack Description” can be filled in with this remaining amount:
-
If the amount is insufficient, a negative “Auto-collateralisation answer” is sent to the
calling module;
-
If the amount is sufficient, the “Lack Description” is sent to the Intraday Credit Capacity
function.
99 In case of Static Data Maintenance Request received during a night-time settlement cycle, the Static-Data Management domain does not execute
it immediately but between the cycle in process and the next one or the start of the day-time settlement period (i.e. no modification on limits during
a night-time cycle).
100 The detailed sorting rules will be defined in the next specification phase. The main objective of such rules will be to settle the settlement
transactions in an account with no remaining amount left in the associated Auto-collateralisation Limits when using the available cash balance. In
addition, the settlement transactions having a remaining amount in the associated Auto-collateralisation Limits will be sorted according to this
remaining amount.
Final_T2S_GFS_110.doc
Page 405
T2S General Functional Specifications
Functional Description
Settlement
4 – Intraday credit capacity
Triggered by the “Lack Description” sent by the Auto-collateralisation limits check function, this function
checks the T2S Parties agreements to use flow and/or stock as collateral for the T2S Dedicated cash
account concerned with a lack.
The function also calculates the Intraday Credit Capacity (ICC) of the T2S Dedicated cash account (i.e.
potential collateral value of available collateral which is equal to the sum of the ICC on flow resulting from
the received collection and ICC on stock).
Auto-collateralisation on flow
For the auto-collateralisation on flow the function selects in the collection the settlement transactions
which respect the following criteria (hereafter the settlement transactions eligible to auto-collateralisation
on flow):
•
Trade an ISIN eligible as collateral for the considered currency {T2S.08.590}
{T2S.08.580};
•
Do not trade an ISIN for which a close link is identified with the relevant T2S Party
{T2S.08.670};
•
Have {T2S.08.640}
-
Either the T2S Party’s agreement to use purchased securities for auto-collateralisation on
flow with an indicator in the settlement transaction {T2S.08.660};
-
Or, if the indicator in the settlement transaction is empty, the T2S Party’s default
agreement for the securities account in the settlement transaction to use securities
received for auto-collateralisation on flow {T2S.08.650} {T2S.08.660}.
For the settlement transactions eligible to auto-collateralisation on flow, the function:
•
Selects the settlement transaction(s) which impact the T2S Dedicated cash account
concerned with the lack under examination;
•
Calculates for each securities position credited by those settlement transactions, their:
-
Quantity actually kept in the securities position after the settlement of the collection,
hereafter called Collateral Net Flow (incoming flow –sum of securities credits- minus
outgoing flow –sum of securities debits-) which is limited by the quantity of the received
Provisioning Net Flow for this securities position101;
101 The Collateral Net Flow is not calculated with all the settlement transactions of the underlying collection that impact the T2S dedicated cash
account under examination, but only with the settlement transactions eligible for the auto-collateralisation on flow. As a consequence, due to the
netting effect, this Collateral Net Flow may be greater than the Provisioning Net Flow (calculated with all the transactions). Therefore, in such a case
the Collateral Net Flow needs to be adjusted to the amount of the Provisioning Net Flow.
Final_T2S_GFS_110.doc
Page 406
T2S General Functional Specifications
Functional Description
Settlement
-
ICC on flow (collateral value of the Collateral Net Flow).
Auto-collateralisation on stock
For the auto-collateralisation on stock, the function selects the securities positions, of the securities
account linked to the T2S Dedicated cash account having a lack, that {T2S.08.630};
•
Concern an ISIN eligible as collateral for the considered currency {T2S.08.590};
•
Do not concern an ISIN for which a close link is identified with the relevant T2S Party
{T2S.08.620};
•
Are earmarked by the T2S Party for auto-collateralisation purpose in the considered currency
{T2S.08.610};
•
Or, if no earmarking is set up at the securities position level, belongs to a securities account
that has been earmarked by the T2S Party for auto-collateralisation purpose in the
considered currency {T2S.08.610}.
On the basis of these securities position, the function then:
•
Identifies, per securities position, the potential collateral quantity (i.e. available quantity in
the securities position limited if any by the remaining quantity in the earmarked restriction for
auto-collateralisation purpose that may have been set up on the considered securities
position) {T2S.08.610};
•
And calculates the ICC on stock of the T2S Dedicated cash account (sum of the collateral
value of each collateral quantity identified per securities position).
Lastly, the function calculates the ICC of the T2S Dedicated cash account concerned with the considered
lack, as the sum of the calculated ICC on flow and the calculated ICC on stock.
If the Intraday Credit Capacity is not sufficient to fill in the considered lack, a negative “Autocollateralisation answer” is returned to the module at the origin of the auto-collateralisation request.
Otherwise, the “Lack Description” is sent to the Collateral Selection function for further processing.
5 – Collateral Selection
Triggered by the “Lack Description” sent by the Intraday credit capacity function, this function selects the
collateral among Collateral Net Flows and securities positions with an Intraday Credit Capacity previously
calculated in a way to fill in the lack described in the “Lack Description”.
When both flows and stocks are available, the function selects first collateral on flows and, if necessary,
complements it with collateral on stock {T2S.08.600}.
Final_T2S_GFS_110.doc
Page 407
T2S General Functional Specifications
Functional Description
Settlement
While applying the rule above, if auto-collateralisation is possible on several eligible securities102, the
function seeks the one(s) which provides the lowest amount of intraday credit per security, i.e. the
minimum collateral value per security {T2S.08.040} {T2S.08.740}.
The amount of the provided intraday credit by this function against the selected collateral:
•
Does not exceed the remaining in the applicable limits checked before;
•
Is at least equal to the missing amount of cash on the considered T2S Dedicated cash
account {T2S.08.580};
•
Does not exceed a maximum percentage of the missing amount defined by the NCB which
provide the intraday credit {T2S.08.690}.
If the considered lack is filled in with the selected collateral, the function prepares the collateral
settlement transaction with:
•
An auto-collateralisation on flow securities movement for each selected collateral net flow
{T2S.08.720} {T2S.08.572} for the quantity of securities to be collateralised and which:
-
Debits the main securities position in the securities account credited in the underlying
settlement transactions;
-
Credits a final position in a securities account which will be filled by the Collateral
Transactions Generator function following the applicable NCB auto-collateralisation rules
(Repo, Pledge, Pledge Sub103);
•
An auto-collateralisation on stock securities movement for each selected securities position
for the quantity of securities to be collateralised {T2S.08.710} {T2S.08.572} which:
-
Debits the considered securities position;
-
Credits a final securities position in a securities account which will be filled by the
Collateral Transactions Generator function following the applicable auto-collateralisation
procedure (Repo, Pledge, Pledge Sub);
•
A cash movement for the amount collateralised (intraday credit provision) which:
-
Debits the main balance of the T2S Central Bank Account {T2S.08.500};
-
Credits the main balance of the T2S Dedicated Cash Account with the lack;
102 The detailed collateral selection rules still to be confirmed during next specification phase in order to optimise the process and to fulfil the central-
banks’ rules for collateral.
103 The different applicable auto-collateralisation procedures are the Repo (i.e. transfer of the collateralised securities in a securities account owned
by the NCB which provides the intraday credit), the Pledge (i.e. trans transfer of the collateralised securities in a securities account owned by the T2S
Party which receives the intraday credit and pledged to the NCB which provides it) or the Pledge Sub (i.e. reservation of the collateralised securities
for the NCB which provides the intraday credit in the securities account where they are hold by the T2S Party which receives the intraday credit).
Final_T2S_GFS_110.doc
Page 408
T2S General Functional Specifications
Functional Description
Settlement
In case of failure, a negative “Auto-collateralisation answer” is sent to the calling module.
6 – Collateralised Securities Check
Triggered by a “Lack Description” sent by the Auto-collateralisation Manager function in case of lack of
securities, this function checks if exist collateralised securities coming from the considered securities
position which can fill in the lack {T2S.08.920}.
In this case, the “Lack Description” is sent to the Dynamic Reimbursement function. Otherwise, a negative
“Auto-collateralisation answer” is sent to the calling module.
7 – Dynamic Reimbursement Manager
Triggered by a “Lack Description” sent by the Collateralised Securities Check function if exist enough
collateralised securities to fill in the considered lack of securities, this function:
•
Calculates the amount necessary to reimburse the underlying intraday credit (i.e.
corresponding to the collateral value of the securities to be released in order to fill in the
lack);
•
Checks on the main balance of the T2S Dedicated cash account which received the intraday
credit {T2S.08.930} if the amount of cash available is sufficient for ensuring the
reimbursement mentioned above {T2S.08.940};
•
If not, calculates if the addition of the positive cash net flow expected to be received on this
balance through the settlement of the underlying collection of settlement transactions would
be sufficient to ensure the reimbursement {T2S.08.950}.
If the reimbursement is possible with the calculated available cash (i.e. on the T2S Dedicated cash
account complemented by the cash net flow received), the function prepares a dynamic intraday credit
reimbursement settlement transaction linked to the settlement transactions in the collection which create
the lack of securities. This settlement transaction is the opposite of the initial collateral settlement
transaction which provided the intraday credit with:
•
A cash movement corresponding to the cash counter value of the collateral to be released
which:
-
Debits the main cash balance of the T2S Dedicated Cash Account which received the
intraday credit;
-
Credits the main balance of the relevant T2S Central Bank Account which provided the
intraday credit;
•
A securities movement for the quantity of securities to be released which:
Final_T2S_GFS_110.doc
Page 409
T2S General Functional Specifications
Functional Description
Settlement
-
Debits the securities position where the securities are collateralised (in the same
securities account –Pledge Sub- or in an other securities account –Repo or Pledge-);
-
Credits the securities position where the securities were hold before the autocollateralisation.
Other additional attributes will be added to this settlement transaction by the Collateral Transaction
Generator.
In case cash is insufficient to reimburse the collateral to be released, the function sends a “Lack Of Cash
Description For Substitution” to the T2S Party Eligibility function in a way to provide the liquidity
necessary for the dynamic reimbursement (cf. automated substitution description below).
Automated substitution processing
The automated substitution {T2S.08.960} is managed in two steps as follows, after a first failed attempt
of the dynamic reimbursement.
Firstly, based on the “Lack Of Cash Description For Substitution” sent by the Dynamic Reimbursement
Manager function, the module searches to provide the intraday credit necessary for the dynamic
reimbursement through a new auto-collateralisation by a standard lack of cash auto-collateralisation
processing104. In case of success (i.e. the necessary intraday credit can be provided), a collateral
settlement transaction linked to the settlement transaction which create the considered lack of securities
in the collection is prepared and sent to the Auto-collateralisation Manager function.
This new collateral settlement transaction provides the necessary amount for the dynamic reimbursement
but does not fill in the lack of securities previously received by the Dynamic Reimbursement function.
So, when the Auto-collateralisation Manager function receives the collateral settlement transaction, the
considered lack of securities remains the next lack to fill in for the underlying auto-collateralisation
request. Consequently, its “Lack Description” is re-sent to the Dynamic Reimbursement function (via the
Collateralised Securities Check function) to re-attempt a dynamic reimbursement.
This time, the function can proceed to the dynamic reimbursement with the liquidity provided during the
first step. The prepared collateral release settlement transaction is also linked to the settlement
transaction in the collection which creates the considered lack of securities.
Due to the collateral (i.e. new auto-collateralisation) and the collateral release (i.e. dynamic
reimbursement) settlement transactions are both linked with settlement transactions in the underlying
104 During this intraday credit provision processing, the possible reimbursement of the released collateralised securities due to the substitution is
simulated by the Auto-collateralisation Limits Check function in a way to not distort its calculation. For example, if the intraday credit required for the
reimbursement is equal to €100 and the remaining amount in the applicable auto-collateralisation limit is lower than €100, the check on limits will be
failed. It is necessary to anticipate the reimbursement of €100 which will be linked to the new collateral settlement transaction due to the automated
substitution.
Final_T2S_GFS_110.doc
Page 410
T2S General Functional Specifications
Functional Description
Settlement
collection {T2S.09.090}, both operations will be settled simultaneously and result in the automated
substitution.
8 – T2S Party Reimbursement Manager
This function handles the reimbursement requested by a T2S Party at any time of the day-time period
{T2S.08.820}.
Such request for reimbursement is instructed by the T2S Party either via an individual settlement
instruction (with the relevant ISO Transaction code105), or via a T2S interface (in this case, the interface
generates the same flow within T2S).
The function is triggered, in both cases, by an “Intraday Credit Reimbursement” request sent by
Validation, Provisioning and Booking when this latter processes the settlement transactions associated to
these instructions.
This “Intraday Credit Reimbursement” request is a collection of settlement transactions which includes an
intraday credit reimbursement settlement transaction with a cash movement corresponding to the
requested amount of cash to be reimbursed which:
105
The ISO Transaction Code used to request a reimbursement of intraday credit still to be specified at the current stage of the project.
Final_T2S_GFS_110.doc
Page 411
T2S General Functional Specifications
Functional Description
Settlement
•
Debits the main cash balance of a T2S Dedicated cash account owned by the considered T2S
Party;
•
Credits the main cash balance of the T2S Central-bank account which provided the intraday
credit;
In case of cash previously reserved for this reimbursement {T2S.08.890} {T2S.08.900} (following the
standard reservation processing), the Restriction Reference attribute of the received settlement
transaction has been already filled with the Restriction Reference(s) sent by the T2S Party in its request.
To prepare the release of collateral, the function searches in the Journaling Of Auto-collateralisation
entity, if collateral settlement transactions previously settled can be reimbursed. To that purpose, the
function checks:
•
If there is still pending intraday credit associated to the T2S Dedicated cash account debited
by the received settlement transaction for the reimbursement;
•
In case the amount of cash to be reimbursed is greater than the pending intraday credit
found on this account, if there is also pending intraday credit associated to others T2S
Dedicated cash accounts owned by the requester T2S Party and managed by the same NCB
{T2S.08.830} {T2S.08.840}.
If collateral settlement transactions associated to several T2S Dedicated cash account are found, the
function sorts the list of collateral settlement transactions in a way to reimburse those associated to the
T2S dedicated cash account used for the reimbursement before those associated to others T2S dedicated
cash account106.
By looking through this list, the function selects the collateral settlement transactions to release by
adjusting the sum of their pending amount to the amount of cash to be reimbursed and never exceed this
amount {T2S.08.880}.
Once this selection is done, the function creates the received intraday credit reimbursement settlement
transaction {T2S.08.870} with an opposite securities movement to each securities movement in the
original collateral settlement transactions corresponding to the released quantity of securities which:
•
Debits the restricted securities position where the securities are collateralised (in the same
securities account –Pledge Sub- or in an other securities account –Repo or Pledge-);
•
Credits the securities position where the securities were hold before the autocollateralisation;
106 Additional rules to sort the collateral settlement transactions for their reimbursement will be added in the next specification phase (e.g prices
which includes the haircut)
Final_T2S_GFS_110.doc
Page 412
T2S General Functional Specifications
Functional Description
Settlement
The sum of those added securities movements value can be different than the requested amount to be
reimbursed due to the collateral value of the released securities. In this case, the function fills in the
partial amount of the cash movement with the actual value of the securities movement (i.e. only this
amount will be actually debited of the T2S Dedicated cash account during its settlement)107.
The intraday credit reimbursement settlement transactions are sent to the Collateral Transaction
Generator function.
9 – Forced Reimbursement Manager
This function handles the forced reimbursement of intraday credit due to an Intraday Credit already
provided greater than a decreased Auto-Collateralisation Limit set by a Central bank (NCB) .
The function is triggered by:
•
a “Decreased NCB Limit” event sent by the function Actions on Transactions and Limits (SPS)
when an updated Auto-Collateralisation Limit set by a Central bank (NCB) has a negative
remaining amount (i.e. when the intraday credit already provided is greater than the new
limit);
•
a “Pre-empted Liquidity Information” sent by VPB when incoming cash credits a T2S
Dedicated cash account owned by a T2S Party with an Auto-Collateralisation Limit set by a
Central bank (NCB) with a negative remaining amount.
Initial forced reimbursement after the limit update
On a “Decreased NCB Limit” event triggering, the amount to reimburse is equal to the negative remaining
amount. In this case, the function:
•
Calculates the available liquidity for the forced reimbursement (sum of the amount in the
main cash balance of all the T2S Dedicated cash accounts owned by the T2S Party and
managed by the relevant NCB);
•
Searches all the collateral settlement transactions associated to those T2S Dedicated cash
accounts pending in the Journaling Of Auto-collateralisation entity;
•
Selects among those collateral settlement transactions for a sum of pending collateral value
limited by the available liquidity for the forced reimbursement;
•
Prepares the forced intraday credit reimbursement settlement transaction to reimburse the
intraday credit and release the collateral {T2S.08.870}.
107 For example, a T2S Party has requested a reimbursement of its current intraday credit for €100. A settlement transaction with a cash movement
for €100 is received by the Auto-collateralisation module. For the reimbursement, the function can only selected a collateral settlement transaction of
10 securities on an ISIN with a collateral value equal to €9.5 per security. The value of the securities movement is equal to €95 (i.e. €9.5x10) and is
lower than the requested amount to be reimbursed. Consequently, the function fills the partial amount of the received cash movement to €95 in a
way that this amount will be debited instead of the initial requested €100.
Final_T2S_GFS_110.doc
Page 413
T2S General Functional Specifications
Functional Description
Settlement
The forced intraday credit reimbursement settlement transaction is prepared for the actual reimbursed
amount (i.e. sum of the collateral value of the released collateral which can be slightly different from the
amount to reimburse due to the nominal collateral value of the released collateral). This transaction
involves:
•
A cash movement for each involved T2S Dedicated cash account corresponding to the
amount used for the reimbursement which:
•
-
Debits the main cash balance of the considered T2S Dedicated cash account;
-
Credits the main cash balance of the T2S Central-bank account;
An opposite securities movement to each securities movement in the original collateral
settlement transactions108 corresponding to the released quantity of securities, which:
-
Debits the restricted securities position where the securities are collateralised (in the
same securities account –Pledge Sub- or in an other securities account –Repo or Pledge-);
-
Credits the securities position where the securities were hold before the autocollateralisation.
If the available liquidity is insufficient to cover totally the amount to reimburse, the function fills in the
Requested Reimbursement Amount attribute of the considered Auto-Collateralisation Limit set by a Central
bank (NCB) with the remaining non-reimbursed amount (this remaining amount will remain negative
after the booking of the prepared collateral release settlement transactions).
This remaining negative amount will trigger the pre-emption by VPB of the incoming cash arriving on one
of the T2S dedicated cash account of the considered T2S Party before its booking109.
The prepared forced intraday credit reimbursement settlement transactions are sent to the Collateral
Transaction Generator function before their sent in the entry queue of VPB.
Additional forced reimbursement for incoming cash
On a “Pre-empted Liquidity Information” triggering (i.e. a T2S Dedicated cash account owned by a T2S
Party with negative remaining amount on its Auto-Collateralisation Limit set by a Central bank (NCB) is
credited by incoming cash credit), the function handles on additional forced reimbursement.
In this case, the amount to reimburse is equal to the pending remaining amount of the considered AutoCollateralisation Limit set by a Central bank (NCB) limited.
108
In the same securities accounts or different securities accounts depending of the auto-collateralisation procedure used by the relevant NCB.
109 Nevertheless, in order not to pre-empt cash before the reimbursement has been actually settled, the Requested Reimbursement Amount is
updated, based on the Limit utilisation update performed in VPB. VPB will only pre-empt cash if the negative Remaining Limit is higher than this
Requested Reimbursement Amount.
Final_T2S_GFS_110.doc
Page 414
T2S General Functional Specifications
Functional Description
Settlement
The function looks through the Provisioning Net Flows calculated by the Provision-Checking function (VPB)
and received with the collection of settlement transactions in the request in order to determine the cash
amount available for the forced reimbursement (i.e. sum of the positive Provisioning Net Flows on the
main cash balances of the T2S Dedicated cash account owned by the relevant T2S Party and managed by
the relevant NCB).
Based on this cash amount available for the forced reimbursement, the function selects the collateral to
release and prepares the forced intraday credit reimbursement settlement transaction following the same
processing than for the initial forced intraday credit reimbursement described above.
The function updates the amount of the Requested Reimbursement Amount attribute of the considered
Auto-Collateralisation Limit set by a Central bank (NCB) with this additional requested forced
reimbursement.
Lastly the prepared forced intraday credit reimbursement settlement transactions are sent to the
Collateral Transaction Generator function before their sent to the Provision-Checking function (VPB)
instead of the entry queue for the initial forced intraday credit reimbursement.
10 – End-Of-Day Intraday Credit Reimbursements Manager
This function is triggered with an “EoD Intraday Credit Reimbursement” event sent by the End-of-Day
Release function (SEQ). It generates the automatic reimbursements of all the intraday credit amounts
with all the available liquidity during the End-of-Day processing {T2S.08.850}.
To prepare the release of collateralised securities, the function:
•
Searches in the Journaling Of Auto-collateralisation all collateral settlement transactions with
a pending amount (i.e. partly or totally un-reimbursed);
•
For each involved T2S Dedicated Cash account:
-
Calculates its net pending amount of intraday credit (sum of the pending amount of
collateral settlement transactions associated to the T2S Dedicated cash account);
-
Checks the available liquidity on the main balance of this account;
If the available amount in the main balance of the considered T2S Dedicated cash account is insufficient
to reimburse its net pending amount of intraday credit, the function checks in others T2S Dedicated cash
accounts owned by the same T2S Party and managed by the same NCB, if some liquidity remains
available after the reimbursement of their own associated intraday credit {T2S.08.850}.
If the overall available liquidity found is sufficient to reimburse the pending intraday credit, the function
prepares EoD intraday credit reimbursement settlement transactions {T2S.08.870} with:
Final_T2S_GFS_110.doc
Page 415
T2S General Functional Specifications
Functional Description
Settlement
•
An opposite securities movement to each securities movement in the original collateral
settlement transactions corresponding to the quantity of collateral to be released (which can
stem from different auto-collateralisation) which:
-
Debits the restricted securities position where the securities are collateralised (in the
same securities account –Pledge Sub- or in an other securities account –Repo or Pledge-);
-
Credits the securities position where the securities were hold before the autocollateralisation;
•
A cash movement corresponding to the reimbursed amount of cash for each involved T2S
Dedicated cash account which:
-
Debits the main cash balance of the considered T2S Dedicated cash account;
-
Credits the relevant T2S Central-bank account.
If the available liquidity found is insufficient to reimburse the pending intraday credit reimbursement, the
function sends to the NCB Business Procedures module (LQMG) a “Pending Intraday Credit” request to
generate a forced liquidity transfer for an amount corresponding to the pending intraday credit amount
after use of all the liquidity available {T2S.08.860}:
•
From the relevant RTGS Dedicated Transit Account (i.e. the RTGS transit account belonging
to the NCB of the T2S Party);
•
To the T2S Dedicated Cash Account where cash is missing to ensure intraday credit
reimbursement.
Upon receipt of the requested forced liquidity transfer data, the function prepares the forced liquidity
transfer settlement transaction from the relevant T2S dedicated cash account and the T2S NCB cash
account. This liquidity transfer settlement transaction is linked to EoD intraday credit reimbursement
settlement transactions (see above).
If the settlement bank and/or the NCB involved in the associated RTGS system account are different from
the ones involved in the T2S Dedicated cash account, depending of the applicable NCB autocollateralisation rules, the collateral shall be relocated with a securities movement added in the EoD
intraday credit reimbursement settlement transaction110. This relocation can be followed by a collateral
release or transfer instructed by the relevant CMS sent in a standard settlement instruction
{T2S.06.460}.
All prepared EoD intraday credit reimbursement or liquidity transfer settlement transactions are sent to
the Collateral Transaction Generator function.
110
This relocation is a working assumption and still depends on confirmation regarding its legal feasibility.
Final_T2S_GFS_110.doc
Page 416
T2S General Functional Specifications
Functional Description
Settlement
11 – Collateral Transactions Generator
This function is triggered by the settlement transactions prepared by other functions in the module.
The function receives those settlement transactions already filled upfront with the following data:
•
For the securities and cash movements:
The “First account”;
-
•
-
The “First position/balance”;
-
The “Quantity/Amount”;
For the cash movements only:
-
The “Final account”;
-
The “Final balance”;
•
The reference to the underlying settlement transactions which create lacks;
•
The
relevant
reimbursement”,
settlement
“Forced
transaction
intraday
category
credit
(i.e.
“Collateral”,
reimbursement”,
“Intraday
credit
intraday
credit
“EoD
reimbursement” or “Forced liquidity transfer”)
The function creates the settlement transactions with the following data:
•
For the securities movements, depending on the auto-collateralisation procedure applicable
for the involved NCB {T2S.08.700}, with the Final Account and Final Position which are:
-
In case of REPO, the main securities position of the relevant NCB securities account;
-
In case of PLEDGE, the main securities position of a T2S Party pledged securities account;
-
In case of PLEDGE SUB, the Final Account is equal to the First Account; in this case, the
restricted securities position where the collateral has to be blocked will be created by
Validation, Provisioning and Booking during the settlement;
•
The status “Created”.
The function creates also the “Auto-collateralisation” links between:
•
The collateral settlement transactions and the underlying settlement transactions which
create the lack that have been filled in the received collection {T2S.08.570}
{T2S.09.090};
•
The forced intraday credit reimbursement settlement transactions and the underlying
settlement
transactions
which bring
the
cash
used for
a
forced
reimbursement
{T2S.08.800};
Final_T2S_GFS_110.doc
Page 417
T2S General Functional Specifications
Functional Description
Settlement
•
The EoD intraday credit reimbursement settlement transactions and the forced liquidity
transfer settlement transactions {T2S.08.860}.
If a collection of settlement transactions has been received in the triggering request, the function adds
the created settlement transactions in this collection. In other case, the function creates a new collection
with the created settlement transactions.
Lastly, the function sends:
•
The enriched collection of settlement transactions to the requesting function in case of
request received from the Validation, Provisioning and Booking module (with settlement
transactions status set to “Created”);
•
The created collection of settlement transactions with the “Collection Queued” status to the
entry queue of the Validation, Provisioning and Booking function in case of request received
from other module.
3.5.8.4. Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Auto-collateralisation
request
IN
Request for a new autocollateralisation to resolve lacks on
cash or securities during the
settlement processing
Validation,
AutoProvisioning and collateralisation
Booking
Manager
function
Simulated Autocollateralisation
request
IN
Request for a simulation of autocollateralisation operations to resolve
lacks on cash or securities during the
optimisation processing
Recycling &
Optimisation
Autocollateralisation
Manager
function
Intraday Credit
Reimbursement
request
IN
Request for an intraday credit
reimbursement sent by a T2S Party
via the T2S interface
VPB
T2S Party’s
Reimbursement
Manager
function
Decreased NCB Limits
Event
IN
Request for a forced reimbursement
due to negative remaining amount
after the update of a decreased AutoCollateralisation Limit set by a Central
bank (NCB)
SPS
Forced
Reimbursement
Manager
function
Pre-empted Liquidity
Information
IN
Request for a forced reimbursement
after pre-emption of cash for the
remaining reimbursement of intraday
credit
VPB
Forced
Reimbursement
Manager
function
EoD Intraday Credit
Reimbursement event
IN
Go to launch the end-of-day intraday
credit reimbursement processing
SEQ
End-Of-Day
Intraday Credit
Reimbursement
s Manager
function
Final_T2S_GFS_110.doc
Page 418
T2S General Functional Specifications
Functional Description
Settlement
FLOW
IN/OUT
DESCRIPTION
FROM
End-Of-Day
Intraday Credit
Reimbursement
s Manager
function
TO
Pending Intraday
Credit
OUT
Request for a forced liquidity transfer
from the RTGS system to provide the
necessary liquidity to reimburse the
net pending intraday credit amount
NCB Business
Procedures
(LQMG)
Forced RTGS Transfer
IN
Data to create the forced liquidity
Liquidity Control
transfer settlement transactions in
(LQMG)
case of pending intraday credit during
the Edo processing
End-Of-Day
Intraday Credit
Reimbursement
s Manager
function
Collection
OUT
Collection of settlement transactions
with “Forced intraday credit
reimbursement”, “EoD intraday credit
reimbursement” or “Forced RTGS
transfer” category
Collateral
Transaction
Generator
function
Validation,
Provisioning and
Booking
Auto-collateralisation
answer
OUT
Positive or negative answer to an
Auto-collateralisation request. In case
of successful the received collection
are enriched with the created
Settlement Transactions
Collateral
Transaction
Generator
function
Validation,
Provisioning and
Booking
Simulated Autocollateralisation
answer
OUT
Positive or negative answer to an
Simulated Auto-collateralisation
request. In both case, no Settlement
Transaction is created during the
simulation.
Collateral
Transaction
Generator
function
Recycling &
Optimisation
3.5.8.5. Data accessed by the module
DATA
ACCESS MODE
COMMENT
STATIC DATA
Payment Bank
Read
T2S Party’s Eligibility
Pledge Collateral Securities Account
Limit
Read
NCB or Payment/Settlement-bank Autocollateralisation Limits quantity or
amount
Remaining Amount
Requested Reimbursement Amount
Limit Group
Read
Earmarking Limit Restrictions (to be
defined)
Read
Security
Read
ISIN Eligibility
Close Link
Read
Close link between ISIN and T2S Party
Final_T2S_GFS_110.doc
Securities account concerned by an
Payment/Settlement-bank Autocollateralisation Limit
Page 419
T2S General Functional Specifications
Functional Description
Settlement
DATA
ACCESS MODE
COMMENT
T2S Dedicated Cash Account Link
Read
Link to use securities as collateral on
stock for a T2S Dedicated cash account
NCB Autocollateral Rule
Read
NCB Collateral Securities Account
T2S Dedicated Cash Account
Applicable auto-collateralisation
procedure (Repo, Pledge, Pledge Sub)
Security Valuation
Read
T2S Dedicated cash account
Read
Securities account
Read
ISIN collateral price
Default agreement to use securities
received as collateral on flow
DYNAMIC DATA
Settlement Transaction
Read/Write
Securities Movement
Read/Write
Cash Movement
Read/Write
Cash balances
Read/Write
Balance
Securities positions
Read
Position and agreement to use position
as collateral on stock
Limit Utilisation
Read
Remaining amount for a limit during a
settlement day
Earmarking Utilisation
Read
Journaling of Auto-collateralisation
Read
Final_T2S_GFS_110.doc
Agreement to use as collateral on flow
Follow the pending intraday credit
amount associated to the collateral
settlement transactions and their
reimbursement
Page 420
T2S General Functional Specifications
Functional Description
Liquidity Management
3.6. Liquidity Management
3.6.1. General Introduction
The Liquidity Management Domain consists of three modules (Liquidity Control, Notification and
Information Management and NCB Business Procedures) which are responsible for all the activities related
to liquidity transfers between RTGS accounts and T2S dedicated cash accounts as well as for pure cash
transfers between two T2S dedicated cash accounts. Liquidity Management performs all the preparatory
work for the booking of immediate, predefined and standing liquidity transfer orders on the T2S dedicated
Final_T2S_GFS_110.doc
Page 421
T2S General Functional Specifications
Functional Description
Liquidity Management
cash accounts. Furthermore it triggers the related communication (notifications) between T2S and the
involved RTGS system (e.g. Target 2) {T2S.06.200}.
For liquidity management purposes, messages provided in the cash management standard (e.g.
LiquidityCreditTransfer
(camt.05.001.01),
ModifyStandingOrder
(camt.024.001.02),
Receipt
(camt.025.001.01)) are used {T2S.06.195}.
The initiator of a liquidity transfer order can be both a payment bank as the account holder of the T2S
dedicated cash account and another party which is authorised by the account holder. {T2S.06.205}
When initiating a liquidity transfer between T2S dedicated cash accounts and the RTGS system, the
liquidity transfer order is checked and treated according to the specific features of the different liquidity
transfer types. A liquidity transaction is generated (module “Liquidity Control”) and routed to the
Settlement Domain (module “Sequencing”) for booking. Features for automated liquidity transfer orders
to the RTGS system are in place to move liquidity stemming from monetary policy repo transactions
settled on T2S dedicated cash accounts as well as to transfer cash resulting out of corporate actions (the
latter depending on user’s choice).
The Liquidity Management Domain takes into account the so-called “multiple liquidity providers”
functionality.
Liquidity transfers between an RTGS system and T2S are based on the exchange of notifications and on
the use of dedicated transit accounts (both in the RTGS system and in T2S). Incoming and outgoing
notifications are managed in order to enable the other system to align its accounting (module “Notification
and Information Management”). Furthermore, information on special booking events (ceiling, floor, partial
execution) is provided to T2S parties (module “Notification and Information Management”) by sending
Alert data to the Interface.
At the end of the business day, liquidity available on T2S dedicated cash accounts is automatically
transferred to the relevant RTGS accounts {T2S.06.220}. In case of insufficient liquidity available on the
T2S dedicated cash account to reimburse the total amount of an intraday credit stemming from autocollateralisation, additional liquidity has to be provided from the corresponding RTGS account (if
necessary with the use of marginal lending). Specific end-of-day procedures are implemented (module
“NCB Business Procedures”) to organize the collection of this liquidity from the RTGS system.
Final_T2S_GFS_110.doc
Page 422
T2S General Functional Specifications
Functional Description
Liquidity Management
3.6.2. Dynamic data managed by the domain
ATTRIBUTE
Transfer Type
DESCRIPTION
Possible values are:
•
Immediate liquidity transfer order;
•
Predefined liquidity transfer order;
•
Standing liquidity transfer order;
•
Notification.
Transfer Identifier
Automatically assigned, as primary identifier.
Order Reference ID
ID for the liquidity transfer as received from the RTGS system (incoming notification)
Entry Timestamp
Timestamp specifying the date and the time the liquidity transfer entered in T2S.
Settlement Timestamp
Timestamp specifying the date and the time the liquidity was settled in T2S.
RTGS Dedicated
Transit Account
Involved RTGS dedicated transit account.
Final_T2S_GFS_110.doc
Page 423
T2S General Functional Specifications
Functional Description
Liquidity Management
ATTRIBUTE
DESCRIPTION
Amount
Amount to be credited or debited with the liquidity transfer.
Blocking reference
Internal reference to assign the liquidity transfer to a previously blocked amount.
Transaction category
Identifies the kind of transaction for the Settlement. Possible values are
•
Liquidity Transfer Order
•
Forced RTGS Transfer
•
Blocking Liquidity Transfer Order
Rejection Flag
Boolean attribute specifying whether the liquidity transfer was rejected or not.
Error Code
In case the liquidity transfer was rejected the respective reason is mentioned through
an error code.
Reference
Identifies the reference given by the sender of the Liquidity transfer.
Status
Partial Execution
Final_T2S_GFS_110.doc
•
Business status for the liquidity transfer. Possible values are:
•
Received;
•
Rejected;
•
Created;
•
Blocking Liquidity;
•
Liquidity Blocked;
•
Executing;
•
Not Settled;
•
Partially Settled;
•
Settled;
•
Sent To RTGS;
•
Partially Executed;
•
Executed;
•
Executed/ACK From RTGS;
•
Executed/NAK From RTGS;
•
Partially Executed/ACK From RTGS;
•
Partially Executed/NAK From RTGS.
Flag if partial execution is possible or not.
Page 424
T2S General Functional Specifications
Functional Description
Liquidity Management
3.6.2.1. Liquidity Transfer
The term “liquidity transfer” summarizes all liquidity adjustments on T2S dedicated cash accounts allowed
according to the conditions recalled below. Since T2S is technically capable of providing cash settlement in
non-euro central bank money, liquidity transfers are possible in all T2S settlement currencies.
{T2S.02.050}
As far as credited and debited accounts are denominated in the same currency {T2S.06.050,
T2S.06.060, T2S.06.110}, liquidity transfers are possible under the following conditions
•
between a T2S dedicated cash account and any RTGS account and vice versa provided this is
allowed by the relevant NCB(s);
•
between two T2S dedicated cash accounts linked to the same RTGS account or between two
T2S dedicated cash accounts belonging to the same payment bank (i.e. proprietary and
clients’ accounts);
•
between a T2S dedicated cash account of an account holder and the T2S dedicated cash
account/T2S NCB account of an NCB.
As a general rule, a liquidity transfer from an RTGS system to T2S is initiated in the RTGS system
{T2S.06.390}; a liquidity transfer from T2S to an RTGS system is initiated in T2S. In any case, liquidity
transfers in T2S are executed real-time (except during the night-time settlement when a settlement cycle
is running) {T2S.06.230}.
Liquidity transfers between two T2S dedicated cash accounts not belonging to the same payment bank or
to another T2S party for whom the payment bank acts as liquidity provider are only possible via the RTGS
accounts of the respective account holders. {T2S.06.240}
3.6.2.2. Order
T2S system users initiate a liquidity transfer by submitting an order to T2S.
Orders can be initiated by the account holder of the T2S dedicated cash account that is debited or by a
related CSD (or another party) acting on behalf of the account owner. They are processed between the
T2S dedicated cash account and the RTGS account of the payment bank or another T2S party the
payment bank acts for as liquidity provider. An immediate liquidity transfer order can also be processed
between two T2S dedicated cash accounts of one payment bank or another T2S party the payment bank
acts for as liquidity provider. . This restriction for liquidity transfers within T2S ensures that T2S settles no
clean payments {T2S.06.130}.
The following order types are defined {T2S.06.240, T2S.06.270, T2S.06.330}:
Final_T2S_GFS_110.doc
Page 425
T2S General Functional Specifications
Functional Description
Liquidity Management
IMMEDIATE
CREATION “ON
BEHALF”
FROM T2S TO
RTGS
FROM T2S TO
T2S
Yes
Yes
Yes
Immediate
Yes (only when acting
on behalf of a
payment bank)
Yes
Yes
No
Date/Time
Yes
EXECUTION
LIQUIDITY
TRANSFER ORDERS
PREDEFINED
LIQUIDITY
Event
TRANSFER ORDERS
STANDING
PARTIAL EXECUTION
Yes
Yes
No
LIQUIDITY
TRANSFER ORDERS
Date/Time
Yes
Event
Depending on the type of the order, it can be executed either once or repeatedly at a certain day/time
(immediately or later) or when a T2S business event (e.g. End of DvP settlement) occurs:
•
Predefined and standing liquidity transfer orders are stored, changed and removed (changed
to zero or deleted) in a Static Data datastore. At the predefined point in time or after a
chosen business event, Liquidity Management interacts with Static Data in order to get all
information needed for order execution;
•
Predefined liquidity transfer orders are executed only once, while standing liquidity transfer
orders are executed on a regular basis at a special point in time/business event during the
business day in T2S. {T2S.06.410}.
Immediate liquidity transfer orders
In general, during the daytime settlement period, immediate liquidity transfer orders are executed
immediately after they arrive in T2S {T2S.06.250}. They are settled on an all-or-none basis, i.e. in case
of insufficient liquidity no liquidity is transferred at all. However, if another T2S Party initiates an
immediate liquidity transfer order on behalf of the payment bank owning the account, the available
amount of liquidity on the account to be debited is transferred. In both aforementioned cases (partial or
no execution) the payment bank (the CSD) receives an alert message (Notification and Information
Management). {T2S.06.260}
Predefined liquidity transfer orders
A payment bank (or a CSD on behalf of the payment bank) is able to define predefined liquidity transfer
orders for liquidity transfers between T2S dedicated cash accounts and RTGS accounts {T2S.06.290}.
In contrast to the immediate liquidity transfer orders it is not possible to establish predefined liquidity
transfer orders to transfer liquidity between different T2S dedicated cash accounts even if they are owned
by the same payment bank. {T2S.06.270}
Final_T2S_GFS_110.doc
Page 426
T2S General Functional Specifications
Functional Description
Liquidity Management
T2S system users can define a time or select a business event in T2S when the predefined liquidity
transfer order should be executed {T2S.06.280}.
In order to keep the use of predefined liquidity transfer orders as simple as possible a payment bank can
put in place (at maximum) one predefined liquidity transfer order per T2S dedicated cash account to be
executed at the same time/business event. But it is possible to define different predefined liquidity
transfer orders to decrease the liquidity available on the T2S dedicated cash account at different points in
time/business events during the business day of T2S {T2S.06.300}.
In case of insufficient liquidity available on the T2S dedicated cash account to be debited, the predefined
liquidity transfer order is partially executed, i.e. as much liquidity as possible is transferred. The payment
bank is alerted accordingly (module “Notification and Information Management”) {T2S.06.310}. The
amount of liquidity not transferred is not stored, i.e. it is not transferred later, even if additional liquidity
arrives on the T2S dedicated cash account that was initially debited. {T2S.06.320}
Standing liquidity transfer orders
Standing liquidity transfer orders can be defined to transfer money from a T2S dedicated cash account to
an RTGS account on a regular basis at a special point in time/business event during the business day in
T2S. {T2S.06.410}
It is not possible to establish standing liquidity transfer orders to transfer liquidity between T2S dedicated
cash accounts.
Payment banks have the possibility to define several standing liquidity transfer orders for the same point
in time/business event and in addition several for different points in time/business events during the
business day of T2S {T2S.06.340, T2S.06.350, T2S.06.360}.
In case of insufficient liquidity available on the T2S dedicated cash account to be debited, the standing
liquidity transfer order is partially executed. If several standing liquidity transfer orders are to be executed
at the same time/business event and there is insufficient liquidity available on the T2S dedicated cash
account, all standing liquidity transfer orders are partially executed. The available amount of liquidity is
distributed according to a “pro rata rule”. This means that the existing liquidity is divided by the total sum
of standing liquidity transfer orders and the resulting factor is used to reduce each standing liquidity
transfer order of the payment bank. The payment bank is alerted accordingly (module “Notification and
Information Management”). The amount of liquidity not transferred is not stored, i.e. it is not transferred
later if additional liquidity arrives on the account that was debited. {T2S.06.370, T2S.06.380}
Final_T2S_GFS_110.doc
Page 427
T2S General Functional Specifications
Functional Description
Liquidity Management
3.6.2.3. Notification
Liquidity transfers between T2S and RTGS systems rely on the use of dedicated transit accounts. After a
booking on one of the dedicated transit accounts has taken place, a notification is sent from one system
to the other. Therefore, there are incoming and outgoing notifications with different statuses:
•
If a T2S system user initiates a liquidity adjustment from its T2S dedicated cash account
towards the RTGS system, T2S sends a notification to the RTGS system after the successful
booking in T2S (on the RTGS dedicated transit account) has been confirmed;
•
If an RTGS system’s participant initiates a liquidity adjustment from its RTGS account in
favour of T2S, T2S receives a notification after the booking has taken place on the T2S
dedicated transit account in the RTGS system. On the basis of this notification, the Liquidity
Management Domain (module “Liquidity Control”) generates a liquidity transaction which is
used for the T2S internal bookings;
•
These two points are general rules for liquidity transfers at start-of-day and during the
business day. During the end-of-day management specific procedures apply for liquidity
transfers between the RTGS system and T2S. These procedures are described in the module
“NCB Business Procedures”.
Final_T2S_GFS_110.doc
Page 428
T2S General Functional Specifications
Functional Description
Liquidity Management
Liquidity transfer lifecycle:
Received
Created
Blocking
Liquidity
REJECTED
Executing
Liquidity
Blocked
Partially
Settled
NOT
SETTLED
SETTLED
Send to RTGS
PARTIALLY
EXECUTED
Partially
Executed/NAK
From RTGS
Partially
Executed/ACK
From RTGS
EXECUTED
Executed/ACK
From RTGS
Executed/NAK
From RTGS
Liquidity Transfer
Lifecycle
STATUS
DESCRIPTION
Received
Initial status after a new message was received and stored
Rejected
Final status in case of a failed validation check
Created
Validation check of liquidity transfer succeeded
Blocking Liquidity
Liquidity blocking request was sent to Settlement
Liquidity Blocked
Liquidity blocking status information was received from Settlement
Executing
Liquidity Transaction was sent to Settlement
Final_T2S_GFS_110.doc
Page 429
T2S General Functional Specifications
Functional Description
Liquidity Management
STATUS
DESCRIPTION
Not Settled
Final status in case of a failed settlement/blocking in T2S
Partially Settled
Insufficient liquidity on account but available liquidity was used for transfer partially booked in T2S
Settled
Sufficient liquidity on account and booked in T2S
Sent to RTGS
Notification was sent to RTGS system
Partially Executed
Final status in case of a partial settlement in T2S
Executed
Final status of a liquidity transfer in T2S
Executed/ACK From RTGS
After the final status “Executed” was reached in T2S, the RTGS system receiving
the liquidity transfer confirmed the booking.
Executed/NAK From RTGS
After the final status “Executed” was reached in T2S, the RTGS system receiving
the liquidity transfer refused the booking.
Partially Executed/ACK
From RTGS
After the final status “Partially Executed” was reached in T2S, the RTGS system
receiving the liquidity transfer confirmed the booking.
Partially Executed /NAK
From RTGS
After the final status “Partially Executed” was reached in T2S, the RTGS system
receiving the liquidity transfer refused the booking.
3.6.3. Liquidity Transfers (LT) use cases
Scope
This category of use cases covers the situations where liquidity transfer orders between RTGS accounts
and T2S dedicated cash accounts as well as between two T2S dedicated cash accounts take place. The
settlement of a cash leg of a securities transaction and the intraday credit provision through autocollateralisation are not subject of the liquidity transfer use cases.
Criteria
The criteria that characterize a liquidity transfer use case are: the communication mode, the instructing
party, the direction, the order type, the execution, the concrete transfer type and the action. These
criteria are summarized in the table below:
CRITERIA
POSSIBLE VALUES
DESCRIPTION
Communication mode
U2A, A2A
See glossary
Instructing party
Own, act on behalf
Instructing party intervening either
for its own account or on behalf of
another party
Direction
From RTGS to T2S, from T2S to RTGS, within
T2S
Increase or decrease of liquidity in
T2S
Order type
Standing, predefined, immediate
see glossary
Final_T2S_GFS_110.doc
Page 430
T2S General Functional Specifications
Functional Description
Liquidity Management
CRITERIA
POSSIBLE VALUES
DESCRIPTION
Execution
Real-time, selected event, defined time, at
different points in time
Defines at which point in time the
order is executed
Concrete transfer type
Specific amount, floor, ceiling, end-of-day,
reimbursement multiple liquidity providers,
optional intraday retransfer, partial
Concrete transfer type
List of Use Cases
This category of use cases covers the situations where a liquidity transfer order between a RTGS system
and T2S takes place. In addition, liquidity adjustments within T2S are also covered. However, the liquidity
transfer use cases do not cover cash-related situations where static data maintenance and/or query
request takes place. In other words, creating, changing, deleting or querying of standing and predefined
liquidity transfer orders are not covered by the liquidity transfer use cases.
Final_T2S_GFS_110.doc
Page 431
T2S General Functional Specifications
Functional Description
Liquidity Management
The initiating point of orders can be both user interaction and triggering system impulse (e.g. execution of
standing orders).
Liquidity
Transfers
U2A
A2A
Own
Act on behalf
From RTGS to
T2S
Standing order
Real-time
Specific amount
Final_T2S_GFS_110.doc
From T2S to
RTGS
Predefined order
Selected event
EoD
reimbursement
Within T2S
Immediate order
Defined time
Reimbursement
multiple liquidity
provider
At different points
in time
Optional intraday
retransfer
Partial
Page 432
T2S General Functional Specifications
Functional Description
Liquidity Management
Since not all combinations of liquidity transfer use case criteria and possible values constitute an actual
liquidity transfer use case, the combinations of criteria’s values that are relevant for the liquidity
management are presented in the complete list of use cases in the appendix.
3.6.4. Processing of Liquidity Transfers use cases
3.6.4.1. Selection of representative LT use cases
The processing of the following representative use cases is described:
•
UC-LT-1: Execution of immediate liquidity transfer orders within T2S;
•
UC-LT-2: Execution of immediate liquidity transfer orders from T2S to RTGS;
•
UC-LT-3: Execution of liquidity transfer orders from RTGS to T2S;
•
UC-LT-4: Execution of a single standing and predefined liquidity transfer orders from T2S to
RTGS;
•
UC-LT-5: End-of-Day Liquidity transfer;
•
UC-LT-6: Execution of several standing LTOs for the same point in time/business event from
T2S to RTGS.
Final_T2S_GFS_110.doc
Page 433
T2S General Functional Specifications
Functional Description
Liquidity Management
3.6.4.2. Processing of UC-LT-1: Execution of immediate liquidity transfer orders within T2S
The T2S dedicated cash account holder or another T2S actor acting on behalf of the cash account holder
is able to instruct an immediate liquidity transfer order between T2S dedicated cash accounts. Only if
another T2S actor on behalf of the account owner is the instructing party, the order is flagged for partial
execution.
Business assumption
A T2S System user sends an immediate liquidity transfer order between two T2S dedicated cash accounts
belonging to the same payment bank.
Processing
The liquidity transfer order enters the Interface. In the Interface the liquidity transfer order passes several
technical validations and checks.
Final_T2S_GFS_110.doc
Page 434
T2S General Functional Specifications
Functional Description
Liquidity Management
•
In case of a negative result the liquidity transfer order is stopped and a Rejection message is
sent to the T2S System user.
•
If the checks are confirmed the liquidity transfer order is forwarded via the Flow
Management to Liquidity Control Module.
The Liquidity Control Module carries out the relevant business checks (e.g. checks and validates
mentioned accounts, currency, contractual agreement, and duplicate submission of the incoming
message).
•
In case of a negative result the liquidity transfer order is stopped and a Rejection message is
sent to the T2S System user.
•
If the checks are confirmed the Liquidity Control Module stores and updates the order status
and, as a last step, creates and sends the liquidity transaction (debit T2S dedicated cash
account - credit another T2S dedicated cash account) to the Sequencing Module.
The Sequencing Module puts the transaction into a queue available for the Validation, Provisioning and
Booking Module in charge of performing the settlement. There are three different possible scenarios:
•
The available cash on the T2S dedicated cash account to be debited is sufficient to execute
the liquidity transaction:
-
In case the provision-checking is successful the transaction is sent via the “Pre-empting”
function to the “Booking” Function.
-
Then the “Booking” Function updates on a gross basis the balances of the T2S dedicated
cash accounts involved.
-
After the successful booking of the transaction, a Liquidity transfer booking information is
sent to the Notification and Information Management Module. On this basis, the
Notification and Information Management updates the liquidity transfer data store
accordingly.
-
Afterwards the Notification and Information Management sends the Confirmation data to
the Flow Management within the Interface, which sends the Status message
(Confirmation message) to the initiating T2S System user (depending on the subscription
preferences).
•
The available cash on the T2S dedicated cash account of the payment bank is only partly
sufficient to execute the liquidity transfer only in case of another T2S Actor acting on behalf
of the account owner.
-
The first steps are similar to the 3 first steps in scenario 1 above.
Final_T2S_GFS_110.doc
Page 435
T2S General Functional Specifications
Functional Description
Liquidity Management
Afterwards the Notification and Information Management sends the Alert data to the Flow
-
Management within the Interface, which sends a Status message (Alert message) to the
initiating T2S System user (depending on the subscription preferences).
•
There is no cash available (zero balance) on the T2S dedicated cash account to be debited.
The liquidity transaction could not be settled due to missing liquidity on the T2S dedicated
cash account. No liquidity is transferred at all. In this case, a liquidity transfer booking
information is sent to the Notification and Information Management Module. The Status
message (Alert message) is sent to the initiating T2S System user by the Flow Management
within the Interface (depending on the subscription preferences).
3.6.4.3. Processing of UC-LT-2: Execution of immediate liquidity transfer orders from T2S to
RTGS
Execution of immediate LTOs from T2S to RTGS
RTGS
LQMG: Liquidity
Control
Interface
T2S
System User
SETT:
Sequencing
SETT: Validation,
Provisioning and
Booking
LQMG: Notification and
Information
Management
Immediate liquidity
transfer order
Rejection message
Immediate liquidity
transfer order
Rejection message
Liquidity
transaction
Liquidity transaction
Alt
(Full execution)
Liquidity transfer booking
information
Notification
Response
(Confirmation message)
Outgoing notification
Confirmation data
Alt
(Partial execution)
Liquidity transfer booking
information
Notification
Response
(Alert message)
Outgoing notification
Alert data
Liquidity transfer booking
information
Alt
(No execution)
Response
(Alert message)
Final_T2S_GFS_110.doc
Alert data
Page 436
T2S General Functional Specifications
Functional Description
Liquidity Management
The T2S dedicated cash account holder or another T2S Actor acting on behalf of the cash account holder
is able to instruct an immediate liquidity transfer order from a T2S dedicated cash account to an RTGS
account.
Business assumption
A T2S System user sends an immediate liquidity transfer order from T2S to RTGS.
Processing
The liquidity transfer order enters the Interface. In the Interface the liquidity transfer order passes several
technical validations and checks.
•
In case of a negative result the liquidity transfer order is stopped and a Rejection message is
sent to the T2S System user.
•
If the checks are confirmed the liquidity transfer order is forwarded via the Flow
Management to the Liquidity Control Module.
The Liquidity Control Module carries out several business checks (e.g. checks and validates mentioned
accounts, currency, contractual agreement and duplicate submission of the incoming message).
•
In case of a negative result the liquidity transfer order is stopped and a Rejection message is
sent to the T2S System user.
•
If the checks are confirmed the Liquidity Control Module stores and updates the order status
and, as a last step, creates and sends the liquidity transaction (debit T2S dedicated cash
account - credit another T2S dedicated cash account) to the Sequencing Module.
The Sequencing Module puts the transaction into a queue available for the Validation, Provisioning and
Booking Module in charge of performing the settlement. There are three different possible scenarios:
•
The available cash on the T2S dedicated cash account to be debited is sufficient to execute
the liquidity transaction:
-
In case the provision-checking is successful the transaction is sent via the “Pre-empting”
function to the “Booking” function.
-
Then the “Booking” function updates on a gross basis the balances of the T2S dedicated
cash account involved the requested T2S dedicated cash account is debited and the RTGS
dedicated transit account of the responsible NCB is credited.
-
After the successful booking of the transaction, a Liquidity transfer booking information is
sent to the Notification and Information Management Module. On this basis, this module
updates the liquidity transfer data store accordingly.
Final_T2S_GFS_110.doc
Page 437
T2S General Functional Specifications
Functional Description
Liquidity Management
-
Afterwards the Notification and Information Management sends Confirmation data and
the Outgoing notification to the Flow Management within the Interface. A Notification is
sent to the involved RTGS system to initiate the booking there. A response (Confirmation
message) is sent to the initiating T2S System user (depending on the subscription
preferences).
-
A confirmation of the booking from the RTGS system (RTGS answer) is required to ensure
the liquidity transfer has reached its destination. If T2S receives:
an acknowledgement (ACK) from the RTGS system, the liquidity transfer has
completed successfully.
A negative acknowledgement (NAK) from the RTGS system, the liquidity transfer is
not unwound, but an alert is sent to the T2S Operator for further investigations.
No message from the RTGS system, an alert is sent to the T2S Operator for further
investigations.
•
The available cash on the T2S dedicated cash account of the payment bank is only partly
sufficient to execute the liquidity transfer.
-
The first steps are similar to the 3 first steps in scenario 1 above.
-
Afterwards the Notification and Information Management sends the Outgoing notification
and the Alert data to the Flow Management within the Interface, which sends a response
(Alert message) to the initiating T2S System user (depending on the subscription
preferences); the Outgoing notification is sent to the involved RTGS system to initiate the
booking there.
-
A confirmation of the booking from the RTGS system (RTGS answer) is required to ensure
the liquidity transfer has reached its destination. If T2S receives:
an acknowledgement (ACK) from the RTGS system the liquidity transfer has
completed successfully.
A negative acknowledgement (NAK) from the RTGS system the liquidity transfer is
not unwound, but an alert is sent to the T2S Operator for further investigations.
No message from the RTGS system an alert is sent to the T2S Operator for further
investigations.
•
There is no cash available (zero balance) on the T2S dedicated cash account to be debited.
The liquidity transaction could not be settled due to insufficient liquidity on the T2S dedicated
cash account. No liquidity is transferred at all. In this case:
Final_T2S_GFS_110.doc
Page 438
T2S General Functional Specifications
Functional Description
Liquidity Management
-
A Liquidity transfer booking information is sent to the Notification and Information
Management Module.
-
Afterwards the Notification and Information Management Module sends the Alert data to
the Flow Management within the Interface, which sends a response (Alert message) to
the initiating T2S System user (depending on the subscription preferences).
3.6.4.4. Processing of UC-LT-3: Execution of liquidity transfer orders from RTGS to T2S
Execution of orders from RTGS to T2S
RTGS
T2S
System User
Interface
LQMG: Liquidity
Control
SETT:
Sequencing
SETT: Validation,
Provisioning and
Booking
LQMG: Notification
and Information
Management
Incoming notification
Rejection message
Incoming notification
Incoming notification
Rejection message
Liquidity transaction
Liquidity transaction
Liquidity transfer
booking information
Status
(Confirmation message)
Confirmation data
After the booking of the liquidity transfer within the RTGS system has taken place, regardless of which
order type has been initiated by the RTGS system’s participant, it has also to be done within T2S.
Therefore T2S creates a liquidity transfer order based on the notification received from the RTGS system.
Business assumption
The RTGS system’s participant initiates a liquidity adjustment from its RTGS account in favour of a T2S
dedicated cash account. From T2S point of view a liquidity transfer order is created based on the
incoming notification.
Final_T2S_GFS_110.doc
Page 439
T2S General Functional Specifications
Functional Description
Liquidity Management
Processing
An RTGS system sends a notification which enters in the Interface. In the Interface the notification passes
several technical validations and checks.
•
In case of a negative result the notification is stopped and a Rejection message is sent to the
RTGS system.
•
If the checks are confirmed the notification is forwarded to the Notification and Information
Management Module.
The Notification and Information Management Module updates the data store accordingly and sends the
Incoming notification to the Liquidity Control Module. This module carries out several business checks,
(e.g. checks and validates mentioned accounts, currency and duplicate submission of the incoming
message),
•
In case of a negative result the liquidity transfer order is stopped and a Rejection message is
sent to the T2S System user.
•
If the checks are confirmed the Liquidity Control Module stores and updates order status
and, as a last step, creates and sends the liquidity transaction (credit T2S dedicated cash
account - debit RTGS dedicated transit account) to the Sequencing Module.
The Sequencing Module puts the transaction into a queue available for the Validation, Provisioning and
Booking Module, which checks whether the booking is feasible.
•
In case the provision-checking is successful the transaction is sent via the “Pre-empting”
function to the Booking function.
•
Then the “Booking” function updates on a gross basis the balances of the T2S dedicated cash
account and the RTGS dedicated transit account involved (The requested RTGS dedicated
transit account is debited and the T2S dedicated cash account is credited).
•
After the successful booking a Liquidity transfer booking information is sent to the
Notification and Information Management Module. On this basis, this module updates the
Liquidity Transfer data store accordingly and sends a Status (Confirmation message) to the
account holder of the credited T2S dedicated cash account via the Interface (depending on
the subscription preferences).
After a successful booking, the liquidity transfer order is finally settled in T2S. Hence, no information to
the RTGS system that the counter-entry was executed is envisaged.
Final_T2S_GFS_110.doc
Page 440
T2S General Functional Specifications
Functional Description
Liquidity Management
3.6.4.5. Processing of UC-LT-4: Execution of a single standing and predefined liquidity transfer
orders from T2S to RTGS
The T2S dedicated cash account holder or another T2S Actor acting on behalf of the cash account holder
is able to define standing and predefined liquidity transfer orders to be executed during the business day
of T2S. Standing and predefined liquidity transfer orders are stored in Static Data and are initiated when
the defined time or business event occurs.
Business assumption
A predefined or a single standing liquidity transfer order stored in T2S Static Data is activated by the
defined time and/or business event.
Processing
Standing and predefined liquidity transfer orders are stored in Static Data. After receiving a time and/or a
business event from the Scheduling Module the Liquidity Control module reads from the Static Data
datastore the liquidity transfer order data foreseen for this point in time and / or business event.
Final_T2S_GFS_110.doc
Page 441
T2S General Functional Specifications
Functional Description
Liquidity Management
Afterwards Liquidity Control Module creates a liquidity transaction (debit T2S dedicated cash account credit RTGS dedicated transit account) and forwards it to the Sequencing Module. The Sequencing Module
puts the transaction into a queue available for the Validation, Provisioning and Booking Module, which
checks whether the booking is feasible. There are three different possible scenarios:
•
The available cash on the T2S dedicated cash account to be debited is sufficient to execute
the transfer:
-
In case the provision-checking is successful the transaction is sent via the “Pre-empting”
function to the “Booking” function.
-
Then the “Booking” function updates on a gross basis the balances of the T2S dedicated
cash accounts involved. The requested T2S dedicated cash account is debited and the
RTGS dedicated transit account of the responsible NCB is credited.
-
After the successful booking a liquidity transfer booking information is sent to the
Notification and Information Management Module. On this basis, the Notification and
Information Management Module updates the liquidity transfer data store accordingly.
-
Afterwards the Notification and Information Management Module sends the Outgoing
notification and the Confirmation data to the Flow Management within the Interface. A
notification is sent to the involved RTGS system to initiate the booking there. A Response
(Confirmation message) is sent to the holder of the debited T2S dedicated cash account
(depending on the subscription preferences).
-
A confirmation of the booking from the RTGS system (RTGS answer) is required to ensure
the liquidity transfer has reached its destination. If T2S receives:
an acknowledgement (ACK) from the RTGS system, the liquidity transfer has
completed successfully.
A negative acknowledgement (NAK) from the RTGS system, the liquidity transfer is
not unwound, but an alert is sent to the T2S Operator for further investigations.
No message from the RTGS system, an alert is sent to the T2S Operator for further
investigations.
•
The available cash on the T2S dedicated cash account of the payment bank is only partly
sufficient to execute the transfer.
-
The first steps are similar to the 3 first steps in scenario 1 above.
-
Afterwards the Notification and Information Management Module sends the Outgoing
notification and the Alert data to the Flow Management within the Interface. The
Interface sends a Response (Alert message) to the account holder of the debited T2S
Final_T2S_GFS_110.doc
Page 442
T2S General Functional Specifications
Functional Description
Liquidity Management
dedicated cash account (depending on the subscription preferences), the Notification is
sent to the involved RTGS system to initiate the booking there.
-
A confirmation of the booking from the RTGS system (RTGS answer) is required to ensure
the liquidity transfer has reached its destination. If T2S receives:
an acknowledgement (ACK) from the RTGS system the liquidity transfer has
completed successfully.
A negative acknowledgement (NAK) from the RTGS system the liquidity transfer is
not unwound, but an alert is sent to the T2S Operator for further investigations.
No message from the RTGS system an alert is sent to the T2S Operator for further
investigations.
•
There is no cash available (zero balance) on the T2S dedicated cash account to be debited
The liquidity transaction could not be settled due to insufficient liquidity on the T2S dedicated
cash account. No liquidity is transferred at all. In this case:
-
A liquidity transfer booking information is sent to the Notification and Information
Management Module.
-
Afterwards the Notification and Information Management Module sends the Alert data to
the Flow Management within the Interface. The Interface sends a response (Alert
message) to the account holder of the T2S dedicated cash account for which the standing
or predefined liquidity transfer order had failed (depending on the subscription
preferences).
Final_T2S_GFS_110.doc
Page 443
T2S General Functional Specifications
Functional Description
Liquidity Management
3.6.4.6. Processing of UC-LT-5: End of Day Liquidity transfer
Complete End-of-Day processing
RGTS
(e.g. T2)
CMS
(e.g. CCBM2)
LQMG:
Notification &
Information
Management
Interface
T2S
Parties
LQMG:
NCB Business
Procedures
LQMG:
Liquidity Control
LCMM:
Status
Management
SETT:
SPS
SETT:
Sequencing
SETT:
Auto
Collateralisation
SETT:
VPB
SETT:
R&O
OPSR:
Scheduling
and its CSD
Time event
Step 1 – Deletion of the unsettled settlement transactions at the 18:00 cut-off
Deleted Tx
Data for generation
of a release restriction
transaction T1
Step 2 - End-of-Day release of unused cash restrictions
Created T1
Created T1
Settled T1
Data for Reservation status message
for End of Day release of cash restriction
Reservation status message
opt
Depending of the messages
subscritpion by T2S Parties
Transaction Status Information
Settled T1
Restriction Status Information
for End of Day release of cash restriction
SEQ waits settlement of all the settlement transactions
generated to release of unused cash restrictions before to
launch the autocollateralisation end-of-day process.
Transaction
Status
Information T1
EoD intraday credit
reimbursment event
Step 3 - End-of-Day release of auto-collateralised positions
alt
Collateral
settlement Transactions
T2a
[Scenario 2: the intraday credit can be reimbursed with the available cash]
Settled T2a
Collateral Settlement Information
Collateral Settlement Information
CMS Notification
opt
alt
Collateral Info message
Transaction
Status
Information T2a
Depending of the messages
subscritpion by T2S Parties
[Scenario 4: there is no available cash to reimburse the remaining intraday credit]
Pending Intraday Credit
EoD Data
Forced RTGS Transfer T2'
Collateral
Settlement Transactions T2b
linked to
Forced RTGS Transfer T2c
Settled T2b & T2c
Collateral Settlement Information
CMS Notification
opt
Collateral Info message
Notification
opt
Cash management message
Depending of the messages
subscritpion by T2S Parties
Outgoing
Notification
Liquidity Transfer Booking Information T2c
Depending of the messages
subscritpion by T2S Parties
SEQ waits the settlement of all the collateral settlement
transctions generated to reimburse and release the collateral
positions befor to send the message
[Collateral relocation]
opt
Collateral Settlement Information T2b
Individual Settlement Instruction I1
The settlement of I1 follows
the standard settlement processing
Business event
EoD Data
opt
Cash management message
End-of-Process event
In the scenario 3 (i.e. the intraday credit can be partly reimbursed with the available cash),
both scenarios 2 and 4 are executed.
The scenario 1 (i.e. no intraday credit, is not concerned by this step.
Step 4 - End-of-Day liquidity transfer
Notification
Transaction
Status Information
T2b & T2c
Outgoing
Notification
Liquidity Transaction T3
Liquidity Transfer Booking Information
Executed T3
Created T3
Settled T3
Depending of the messages
subscritpion by T2S Parties
This use case relates to the end-of-day processing for a settlement day.
Business assumption
At the 18:00 cut-off, in addition to the end of the real time processing, the Scheduling module sends a
Time event to Sequencing (SEQ) module to start the end-of-day processing.
Final_T2S_GFS_110.doc
Page 444
T2S General Functional Specifications
Functional Description
Liquidity Management
Processing
The following general cases can occur on cash accounts at the end of the settlement day:
•
Surplus liquidity at the end of the settlement day (if applicable after reimbursement): The
liquidity on the T2S dedicated cash account is automatically transferred to the corresponding
RTGS account (e.g. TARGET2) {T2S.06.220, T2S.03.180}.
•
Insufficient available liquidity to reimburse all pending intraday credits: The insufficient
liquidity on the T2S dedicated cash account would lead to a negative account balance.
Therefore linked liquidity transfer settlement transactions in T2S and actions in the RTGS
system have to be triggered for increasing the credit line (e.g. connected payment in
TARGET2).
Related to the general cases, which can occur on T2S dedicated cash accounts at the end of the
settlement day, there are four different scenarios possible:
•
1 - No pending intraday credit
•
2 - The available cash on the T2S dedicated cash account of the payment bank is sufficient
to reimburse the pending intraday credit
•
3 - The available cash on the T2S dedicated cash account of the payment bank is only partly
sufficient to reimburse the pending intraday credit.
•
4 - There is no cash available (zero balance) on the T2S dedicated cash account of the
payment bank.
This use case covers only the case of pending intraday credit when the accounts are owned by the same
settlement bank and managed by the same NCB in T2S and the RTGS system.
The end-of-day processing is organised in 4 steps, to determine the amount to be transferred from T2S to
the RTGS system (e.g. TARGET2) or vice versa:
•
Step 1 - Cancellation of the unsettled settlement transactions at the 18:00 “Cut-off”;
•
Step 2 - End-of-day release of unused cash restrictions;
•
Step 3 - End-of-day release of auto-collateralised positions and forced RTGS transfers;
•
Step 4- End-of-Day liquidity transfer.
Step 1 - Cancellation of the unsettled settlement transactions at the 18:00 cut-off
At the receipt of the Scheduling Time event, the Cut-off Processing function of SEQ checks if all
settlement transactions are only with a “Settled”, “Partially Settled” or “Unsettled” status (i.e. the entering
Final_T2S_GFS_110.doc
Page 445
T2S General Functional Specifications
Functional Description
Liquidity Management
queue of the Validation, Provisioning and Booking (VPB) module is empty and all optimisation algorithms
of Recycling & Optimisation (R&O) are stopped).
Once this check is performed, the “Settlement Transaction Status” attribute of all unsettled settlement
transactions is switched to “Cancelled”.
Step 2 - End-of-day release of unused cash restrictions
Once Step 1 is finished, the End-of-day Release function continues with Step 2, the release of unused
cash restrictions.
Therefore, the function searches all balances to detect restricted and not empty ones. When all balances
have been checked, the End-of-Day Release function sends to the Standardisation and Preparation to
Settlement (SPS) module the necessary “EoD Cash Restriction Release Information” to generate a
settlement transaction for each unused restricted cash balance. (T1 in sequence diagram)
This settlement transaction with the “EoD Cash Restriction Release” category is composed of a cash
movement for the restricted amount from the considered restricted balance to the main balance of the
account.
After their creation by SPS, the settlement transactions are sent via the Sequencing (SEQ) module to VPB
for their settlement. During their booking, VPB fills the “To be regenerated” attribute of the moved
restricted cash balance with the amount moved for the regeneration during the start of the next
settlement day.
A “Restriction Status Information” is sent from VPB to the Status Management module which forwards the
necessary data to the Interface module for communication to the T2S Parties (depending of their
messages subscriptions).
After receipt of a “Transaction Status Information” in SEQ from VPB after the settlement of all generated
cash restriction release settlement transactions, the End-of-day Release function sends the “EoD Intraday
Credit Reimbursement Event” to the Auto-collateralisation module to launch the step 3.
Step 3 - End-of-day release of auto-collateralised positions and forced RTGS transfers
At the receipt of the “EoD Intraday Credit Reimbursement Event”, the Auto-collateralisation module
searches all pending intraday credit positions.
Final_T2S_GFS_110.doc
Page 446
T2S General Functional Specifications
Functional Description
Liquidity Management
In case of scenario 2 (i.e. the intraday credit can be reimbursed with the available cash), Autocollateralisation creates a settlement transaction and the following movement(s):
SCENARIO
2
CASH MOVEMENT
SETTLEMENT
TRANSACTION
T2a
[EoD
intraday
credit
reimbursem
ent]
SECURITIES MOVEMENT(S)
DEBIT
CREDIT
DEBIT
CREDIT
T2S dedicated
cash account of
the payment
bank with the full
amount of
pending intraday
credit
T2S dedicated
cash account of its
NCB
NCB securities
account111 (to be
done for each ISIN)
Securities
account of the
settlement bank
(to be done for
each ISIN)
In case of scenario 4 (i.e. there is no cash available to reimburse the intraday credit), Autocollateralisation asks the Liquidity Management (LM) Domain for a liquidity transfer for the remaining
amount with the following data:
•
respective T2S dedicated cash accounts
•
remaining amount (i.e. complete amount of intraday credit)
•
link indicator (to settle simultaneously the collateral release and liquidity transfer settlement
transactions)
Having received all these data, the NCB Business Procedure module forwards the EoD data to Liquidity
Control module which creates the respective Forced RTGS transfers and sends them to Autocollateralisation that generates, if necessary, the settlement transaction to transfer the collateral. This
scenario results in the following linked settlement transactions:
SCENARIO
4
SETTLEMENT
TRANSACTION
T2b
[EoD
intraday
credit
reimbursem
ent]
CASH MOVEMENT
DEBIT
CREDIT
T2S dedicated
cash account of
the payment
bank with the
full amount of
pending
intraday credit
T2S dedicated
cash account of
its NCB with the
full amount of
pending
intraday credit
SECURITIES MOVEMENT(S)
DEBIT
No corresponding
booking
CREDIT
No corresponding
booking
111 The security movement which moves back the collateral to the original security account depends on the auto-collateralisation procedure of the
involved NCB. It can be from the securities account where the NCB received its collateral (repo), a securities account of the T2S Party pledged for the
NCB or a restricted position in the original securities account.
Final_T2S_GFS_110.doc
Page 447
T2S General Functional Specifications
Functional Description
Liquidity Management
SCENARIO
SETTLEMENT
TRANSACTION
T2c
[Forced
RTGS
Transfer]
SECURITIES MOVEMENT(S)
CASH MOVEMENT
DEBIT
CREDIT
DEBIT
CREDIT
RTGS dedicated
transit account
of its NCB
T2S dedicated
cash account of
the payment
bank
No corresponding
booking (transfer of
cash from the RTGS
system, optional
marginal lending
called in the RTGS
system)
No corresponding
booking (transfer of
cash from the RTGS
system, optional
marginal lending
called in the RTGS
system)
Lastly, the scenario 3 (i.e. the intraday credit can be partly reimbursed with the available cash) results in
a mix of scenarios 2 and 4. Firstly, as in scenario 2, Auto-collateralisation generates the following
settlement transaction to reimburse the intraday credit with the cash available:
SCENARIO
3
CASH MOVEMENT
SECURITIES MOVEMENT(S)
SETTLEMENT
TRANSACTION
DEBIT
CREDIT
DEBIT
CREDIT
T2a
[EoD
intraday
credit
reimbursem
ent]
T2S dedicated
cash account of
the payment
bank with the
available
amount
T2S dedicated
cash account of
its NCB
Debit the NCBs
securities account
for the quantity
corresponding to
the reimbursed
amount
Credit the
settlement banks
securities account
for the quantity
corresponding to
the reimbursed
amount
Secondly, as in scenario 4, Auto-collateralisation asks LM for a liquidity transfer for the remaining amount
(difference between reimbursed amount and balance at the beginning of the end-of-day process) and,
after its receipt (T2’ in sequence diagram), creates if necessary the settlement transaction to transfer the
collateral. This results in the following linked settlement transactions:
SCENARIO
3
CASH MOVEMENT
SECURITIES MOVEMENT(S)
SETTLEMENT
TRANSACTION
DEBIT
CREDIT
DEBIT
CREDIT
T2b
[EoD
intraday
credit
reimbursem
ent]
T2S dedicated
cash account of
the payment
bank with the
remaining
amount
T2S dedicated
cash account of
its NCB with the
remaining
amount
No booking,
collateral remains
on the securities
account of the NCB
(credit position)
No booking,
collateral remains
unchanged on the
settlement banks
securities account
(debit position)
T2c
[Forced
RTGS
Transfer]
RTGS dedicated
transit account
of its NCB
T2S dedicated
cash account of
the payment
bank
No corresponding
booking (transfer of
cash from the RTGS
system, optional
marginal lending
called in the RTGS
system)
No corresponding
booking (transfer of
cash from the RTGS
system, optional
marginal lending
called in the RTGS
system)
In all these scenarios, the settlement transactions have the status “Created” and the transaction category:
Final_T2S_GFS_110.doc
Page 448
T2S General Functional Specifications
Functional Description
Liquidity Management
•
“EoD intraday credit reimbursement” if generated by Auto-collateralisation ;
•
“Forced RTGS Transfer” if generated by LM.
They are sent to the entry queue of the VPB module.
Simultaneously of their booking, VPB sends:
•
for the settlement transaction with the “EoD intraday credit reimbursement” transaction
category,
-
a “Collateral Settlement Information” to the Status Management module to inform the
involved Collateral Management System (CMS) via the Interface (INTF) domain;
-
a “Transaction Status Information” to the End-of-day Release function (SEQ) to follow the
end-of-day reimbursement of intraday credit processing,
•
for the settlement transaction with the “Forced RTGS Transfer” transaction category, a
“Liquidity Transfer Booking Information” is sent to the Notification and Information
Management module (LQMG) to initiate the outgoing notification to the involved RTGS
system via INTF.
That information is also used to inform the involved T2S Parties (depending on their messages
subscriptions).
Once a “Transaction Status Information” has been received for all the settlement transactions generated
by Auto-collateralisation, the End-of-day Release function (SEQ) sends an “End-of-Process” event to the
Scheduling module.
After the End-of-day release of auto-collateralised positions processing, in case a collateral relocation is
asked by the involved CMS (I1 in sequence diagram), the corresponding individual settlement instructions
will follow the standard settlement processing.
Step 4 - End-of-Day liquidity transfer
After getting the business event from the Scheduling, the module NCB Business Procedures checks the
balance of all T2S dedicated cash accounts. After interaction with Static Data database, a matching
between the RTGS accounts and the T2S dedicated cash accounts takes place. For the accounts with cash
available at the end-of-day, the NCB Business Procedure sends the EoD data (amount, T2S dedicated
cash account, RTGS account) to Liquidity Control. A liquidity transaction is created and forwarded to
SEQ.(T3 in sequence diagram)
SEQ puts them into a queue available for the VPB module. The VPB executes the cash movement as they
are described in the settlement transactions (crediting RTGS dedicated transit account) that are
submitted. After the successful booking a “Liquidity Transfer Booking Information” is sent to the
Final_T2S_GFS_110.doc
Page 449
T2S General Functional Specifications
Functional Description
Liquidity Management
Notification and Information Management module. On this basis the notification data is created and stored
within the database. Afterwards this notification is forwarded to the Flow Management module.
SCENARIO
1
CASH MOVEMENT
SETTLEMENT
TRANSACTION
T3
[Forced
RTGS
Transfer]
SECURITIES MOVEMENT(S)
DEBIT
CREDIT
DEBIT
CREDIT
TS2 dedicated
cash account of
the payment
bank
RTGS dedicated
transit account
of its NCB
No corresponding
booking (retransfer
of cash to the RTGS
system)
No corresponding
booking (retransfer
of cash to the RTGS
system)
No corresponding booking (retransfer of cash to the RTGS system)
After all relevant bookings on the T2S dedicated cash accounts of the payment banks are done the
accounts have a balance of zero.
Final_T2S_GFS_110.doc
Page 450
T2S General Functional Specifications
Functional Description
Liquidity Management
3.6.4.7. Processing of C-LT-6: Execution of several standing LTOs for the same point in
time/business event from T2S to RTGS
Execution of several standing LTOs from T2S to RTGS
Interface
RTGS
LQMG: Liquidity
Control
T2S
System User
SETT:
Standardisation
and Preparation
to Settlement
SETT:
Sequencing
OPSR:
Scheduling
SETT:
Validation,
Provisioning and
Booking
LQMG: Notification
and Information
Management
Time/ business event
Liquidity blocking
request
Collection of
settlement
transactions
Settlement transactions
Liquidity blocking status information
Alt
(Full execution)
Liquidity transaction
Settlement transactions
Notification
Response
(Confirmation message)
Alt
(Partial execution)
Outgoing notification
Liquidity
transfer booking
information
Confirmation data
Liquidity transaction
Settlement transactions
Notification
Response
(Alert message)
Outgoing notification
Liquidity
transfer booking
information
Alert data
Alt
(No execution)
Alert data
Alert data
Response
(Alert message)
The T2S dedicated cash account holder or another T2S Actor acting on behalf of the cash account holder
is able to define several standing liquidity transfer orders for the same point in time/business event during
the business day of T2S. Standing liquidity transfer orders are stored in Static Data and are initiated when
the defined time or business event occurs.
Business assumption
Several standing liquidity transfer orders stored in T2S Static Data for the same point in time/ business
event are activated by the defined time and/or the business event.
Final_T2S_GFS_110.doc
Page 451
T2S General Functional Specifications
Functional Description
Liquidity Management
Processing
The standing liquidity transfer orders are stored in Static Data. After receiving a time and/or the business
event from the Scheduling Module, the Liquidity Control Module reads from the Static Data data store the
liquidity transfer order data foreseen for this point in time and / or business event.
The “Order Management” Function within the Liquidity Control Module creates a Liquidity blocking request
to be sent to the Standardisation and Preparation to Settlement Module.
Based on this Liquidity blocking request the Standardisation and Preparation to Settlement Module
generates a settlement transaction with one cash movement to set up a position restriction.
The settlement transaction is sent to the Sequencing Module, which puts it into a queue available for the
Validation, Provisioning and Booking Module.
The Validation, Provisioning and Booking Module creates a Liquidity blocking status information containing
the information that available liquidity is blocked and the amount of available liquidity on the T2S
dedicated cash account. This Liquidity blocking status information is sent to the “Order Management”
Function within the Liquidity Control Module.
On basis of this Liquidity blocking status information the “Order Management” function recognizes if:
•
The available cash on the T2S dedicated cash account to be debited is sufficient to execute
the several liquidity transfers orders:
-
The Liquidity Control Module creates and sends the Liquidity transactions (debit T2S
dedicated cash accounts - credit RTGS dedicated transit accounts) to the Sequencing
Module.
-
The Sequencing Module puts the transaction into a queue available for the Validation,
Provisioning and Booking Module.
-
The Validation, Provisioning and Booking Module performs some checks (e.g. currency,
accounts or T2S Party involved in the collection or if the net flows can be settled with the
resources available on the cash balances). Then the “Booking” function updates on a
gross basis the balances of the T2S dedicated cash accounts involved. The requested T2S
dedicated cash accounts are debited and the RTGS dedicated transit account(s) of the
responsible NCB(s) is/are credited. After successful booking the liquidity on the T2S
dedicated cash account is set to unblocked.
-
After the successful booking a Liquidity transfer booking information is sent to the
Notification and Information Management Module. On this basis, this module updates the
liquidity transfer data store accordingly.
Final_T2S_GFS_110.doc
Page 452
T2S General Functional Specifications
Functional Description
Liquidity Management
-
Afterwards the Notification and Information Management sends Confirmation data and
the Outgoing notification(s) to the Flow Management within the Interface. A notification is
sent to the involved RTGS system(s) to initiate the booking there. A response
(confirmation message) is sent to the initiating T2S Actor (depending on the subscription
preferences).
-
A confirmation of the booking from the RTGS system (RTGS answer) is required to ensure
the liquidity transfer has reached its destination. If T2S receives:
an acknowledgement (ACK) from the RTGS system the liquidity transfer has
completed successfully.
A negative acknowledgement (NAK) from the RTGS system the liquidity transfer is
not unwound, but an alert is sent to the T2S Operator for further investigations.
No message from the RTGS system an alert is sent to the T2S Operator for further
investigations.
•
The available cash on the T2S dedicated cash account of the payment bank is only partly
sufficient to execute the several liquidity transfer orders:
-
The Liquidity Control Module receives the Liquidity blocking status information and
recognizes that for the partial settlement the “pro rata rule” has to be used and calculates
the percentage of the original amount to be transferred by each Liquidity transfer.
-
The next steps are similar to the 4 first steps in scenario 1 above.
-
Afterwards the Notification and Information Management sends the Alert data to the Flow
Management within the Interface, which sends a Status message (Alert message) to the
initiating T2S Actor (depending on the subscription preferences). Furthermore an
Outgoing notification is sent to the involved RTGS system(s) to initiate the booking there.
-
A confirmation of the booking from the RTGS system (RTGS answer) is required to ensure
the liquidity transfer has reached its destination. If T2S receives:
an acknowledgement (ACK) from the RTGS system the liquidity transfer has
completed successfully.
a negative acknowledgement (NAK) from the RTGS system the liquidity transfer is
not unwound, but an alert is sent to the T2S Operator for further investigations.
no message from the RTGS system an alert is sent to the T2S Operator for further
investigations..
•
There is no cash available (zero balance) on the T2S dedicated cash account to be debited.
No liquidity is transferred at all. In this case:
Final_T2S_GFS_110.doc
Page 453
T2S General Functional Specifications
Functional Description
Liquidity Management
The Liquidity Control Module receives the Liquidity blocking status information and sends
-
Alert data to the Notification and Information Management Module.
A status message (Alert message) is sent to the initiating T2S Actor via the Flow
-
Management within the Interface (depending on the subscription preferences).
3.6.5. Liquidity Control
3.6.5.1. Diagram of the module
LQMG:Notification and
Information Management
INTF:Flow Management
Liquidity Control
Rejection
(Immediate
liquidity
transfer
order)
Status
information
Immediate
liquidity
transfer order
LQMG:NCB Business
Procedures
Rejection
(Incoming
notification)
Incoming
notification
Not ok
EoD
data
Clearing
entry
data
Not ok
Validation Check
Ok
<< data store >>
BC
<< data store >>
LT
Immediate liquidity
transfer order
<< data store >>
SD
Order Management
Liquidity transfer
order
Liquidity Transaction
Generator
Liquidity
blocking
status
informaton
Liquidity
event
LCMM:
Status Management Module
End of last
cycle
information
SETT:Standardisation and
Preparation to Settlement
SETT:Validation,
Provisioning and Booking
Final_T2S_GFS_110.doc
Liquidity
blocking
request
Liquidity
transaction
Forced
RTGS
transfer
Alert
data
Time
event
Business
event
SETT:
Auto-collateralisation
SETT:Sequencing
LQMG:Notification and
Information Management
Page 454
T2S General Functional Specifications
Functional Description
Liquidity Management
3.6.5.2. Description of the module
The Liquidity Control Module consists of three functions (Validation Check, Order Management and
Liquidity Transaction Generator) which are responsible for formatting the data related to liquidity transfers
received from Flow Management, Notification and Information Management, Cash Account Data
Management (Static Data Domain) and NCB Business Procedures so that liquidity transfers can be settled
smoothly.
Based on standing orders, the module Liquidity Control carries out the so-called “multiple liquidity
providers” functionality. {T2S.06.063, T2S.06.067} This means that for night-time settlement, liquidity
from different RTGS accounts can be transferred to a single T2S dedicated cash account. The transfers
are executed before the T2S night-time settlement phase starts. The amounts of liquidity effectively
transferred are stored in the Liquidity Transfer data store to be used in the refunding process after the
night-time settlement phase.
3.6.5.3. Description of the functions of the module
1 – Validation Check
This function validates all incoming liquidity transfers (incoming immediate liquidity transfer orders and
incoming notifications). To that purpose, this function checks (based on Static Data data store and
Liquidity Transfer data store) if
•
the mentioned accounts in the incoming immediate liquidity transfer orders and incoming
notifications are active;
•
the currency is eligible according to general rules and definitions and if it is compliant to the
currency of the T2S dedicated cash accounts involved;
•
there is a contractual agreement between the account owner of the T2S dedicated cash
account and the T2S party instructing the liquidity transfer order in case the instructing T2S
party is not the account owner himself {T2S.06.210, T2S.05.060};
•
there is a duplicate submission of the incoming message based on a combination of the order
type, T2S actor identifier and the order reference assigned by the instructing party
{T2S.05.030}. This is to prevent a double execution of the same message.
After the above mentioned checks are finalised the next steps to be performed by the Validation Check
are:
•
creating an internal rejection message (Rejection (Immediate liquidity transfer orders)) in
case of negative validation (e.g. account to be credited/debited not present in T2S) to be
forwarded to the Flow Management (for liquidity transfer orders within T2S and for liquidity
transfer orders from T2S to an RTGS system);
Final_T2S_GFS_110.doc
Page 455
T2S General Functional Specifications
Functional Description
Liquidity Management
•
creating an internal rejection message (Rejection (Incoming notification)) in case of negative
validation (e.g. account to be credited not present in T2S) to be forwarded to the Notification
and Information Management (for notifications sent by an RTGS system to T2S);
•
routing the liquidity transfer orders to Order Management in case of positive validation.
2 – Order Management
This function manages the order through the following features:
1) The function:
•
receives immediate liquidity transfer orders from the “Validation Check” function;
•
triggers the relevant liquidity transfer orders in the following cases:
-
at the predefined times and/or when the predefined event occurs, the function retrieves
from Static Data datastore the relevant standing and predefined liquidity transfer orders,
-
based on incoming liquidity events from the Status Management Module (automated
transfer of corporate actions and NCB repos to an RTGS system),
-
after receipt of the EoD data and Clearing entry data from the NCB Business Procedures
Module,
-
after night-time settlement, for the refunding of liquidity in case the “multiple liquidity
provider functionality” is used. The function:
gets from the Sequencing Module the information about the end of the night-time
settlement phase (End of last cycle information),
checks in Static Data which is the correct order to reimburse the liquidity to the
involved liquidity providers (liquidity is reimbursed in reverse order, i.e. the main
liquidity provider is the last one to be reimbursed),
checks in Static Data datastore which is the available amount on the involved T2S
dedicated cash account,
checks in the Liquidity Transfer data store the amount every liquidity provider sent
to the T2S dedicated cash account,
returns automatically all remaining cash to the RTGS account of its main liquidity
provider, even if this amount exceeds the amount of liquidity effectively granted
ahead of night-time settlement (if the payment bank owning the T2S dedicated
cash account opted for that).
Final_T2S_GFS_110.doc
Page 456
T2S General Functional Specifications
Functional Description
Liquidity Management
2) The function stores the incoming immediate liquidity transfer order or created liquidity transfer order in
the Liquidity Transfer data store and updates its status.
3) In case of several standing liquidity transfer orders at the same time the function creates liquidity
blocking requests to be sent to Standardisation and Preparation to Settlement. On basis of the answer to
this request (liquidity blocking status information from Validation, Provisioning and Booking) the function
recognizes
•
if the pro rata rule is to be used and calculates the percentage to be transferred by each
liquidity transfer order
•
if there is no liquidity available at all for a blocking. As a consequence the Order Management
changes the status of the Standing liquidity transfer orders into a negative final one and
sends the information as Alert data to the Notification and Information Management.
4) In all cases the function sends the liquidity transfer order to the Liquidity Transaction Generator
(flagged for partial execution and including a blocking reference where required)
5) In addition, the function answers requests from the Interface regarding the status of an order and
sends alert data to Notification and Information Management in case of negative liquidity blocking status
information (no liquidity available at all).
3 – Liquidity Transaction Generator
Out of the information resulting from the function “Order Management”, the function creates:
•
•
a liquidity transaction to:
-
debit RTGS dedicated transit account – credit T2S dedicated cash account,
-
debit T2S dedicated cash account - credit (another) T2S dedicated cash account,
-
debit T2S dedicated cash account – credit RTGS dedicated transit account;
or a forced RTGS transfer to credit a T2S dedicated cash account and debit the RTGS
dedicated transit account.
The function sends the liquidity transaction to the Sequencing Module and the forced RTGS transfers to
Auto-collateralisation Module.
3.6.5.4. Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
Immediate liquidity IN
transfer order
Flow Management
Business event
Scheduling
Final_T2S_GFS_110.doc
IN
TO
Page 457
T2S General Functional Specifications
Functional Description
Liquidity Management
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Time event
IN
Scheduling
Liquidity event
IN
Status Management
End of last cycle
information
IN
Sequencing
Liquidity blocking
status information
IN
Validation, Provisioning
and Booking
Status information
IN/OUT
Flow Management
Incoming
notification
IN
Notification and
Information
Management
EoD data
IN
NCB Business
Procedures
Clearing entry data
IN
NCB Business
Procedures
Rejection
(Immediate
liquidity transfer
order)
OUT
Flow Management
Rejection
(Incoming
notification)
OUT
Notification and
Information
Management
Liquidity
transaction
OUT
Sequencing
Forced RTGS
transfer
OUT
Auto-collateralisation
Liquidity blocking
request
OUT
Standardisation and
Preparation to
Settlement
Alert data
OUT
Notification and
Information
Management
Flow Management
3.6.5.5. Data accessed by the module
DATA
ACCESS MODE
Static Data
Read
Liquidity Transfer
Read/Write
Cash Balances
Read
Final_T2S_GFS_110.doc
STATUS
COMMENTS
Cash account related data; Prioritization of
Multiple liquidity providers
Balances for the Multiple liquidity providers
functionality
Page 458
T2S General Functional Specifications
Functional Description
Liquidity Management
3.6.6. Notification and Information Management
3.6.6.1. Diagram of the module
INTF:FlowManagement
Alert
data
Notification
and
Information
Management
Confirmation
data
Information Manager
Outgoing
notification
Incoming
notification
RTGS
answer
<<data store>>
LT
Execution
data
Storage and Status Management
Alert
data
Floor/
Ceiling
information
Liquidity
transfer
booking
information
Incoming
notification
Rejection
(Incoming
notification)
SETT:Validation,
Provisioning and Booking
LQMG:Liquidity Conttrol
3.6.6.2. Description of the module
This module consists of the functions Storage and Status Management and Information Manager. It
manages both incoming and outgoing notifications between T2S and other RTGS systems, including the
Start-of-day liquidity transfers (which are treated the same way as liquidity transfers during the business
day) {T2S.03.070}. In addition, Notification and Information Management also provides T2S actors with
information on predefined and/or special booking events on T2S dedicated cash accounts (ceiling, floor,
partial/no execution).
The following information needs to be reported by the Settlement Domain to the Notification and
Information Management:
Final_T2S_GFS_110.doc
Page 459
T2S General Functional Specifications
Functional Description
Liquidity Management
•
Liquidity transfer booking information in case of liquidity transfer orders at start of day,
during the settlement day and end-of-day processing which occurred on the RTGS dedicated
transit account;
•
exceed of predefined ceiling;
•
fall under predefined floor;
•
partial or no execution of liquidity transfer orders (Liquidity transfer booking information).
3.6.6.3. Description of functions of the module
1 – Storage and Status Management
This function keeps record on and manages the flow of all notifications from and to an RTGS system by:
•
Storing and updating the status of all incoming notifications from Flow Management in the
Liquidity Transfer data store and routing them to Liquidity Control. This includes the Start-ofDay liquidity transfers from the RTGS system to T2S as well as any other incoming liquidity
transfer which results in a booking on an RTGS dedicated transit account;
•
Creating outgoing notifications based on the Liquidity transfer booking information received
from the Validation, Provisioning and Booking Module in case a settlement on an RTGS
dedicated transit account has occurred during the settlement day and end-of-day processing;
•
Storing and changing the status of a notification according to the Liquidity transfer booking
information of all outgoing notifications in the Liquidity Transfer data store;
•
Forwarding execution data to the Information Manager function.
In case a notification is not able to pass the Validation Check in the Liquidity Control Module the Storage
and Status Management creates a new outgoing notification based on the rejection (incoming notification)
received from Liquidity Control and forwards it to the Flow Management like any other outgoing
notification.
After a booking on an RTGS dedicated transit account Storage and Status Management receives a
“Liquidity transfer booking information” from Validation, Provisioning and Booking. The status of the
liquidity transfer order is changed into a positive final one. On basis of this “Liquidity transfer booking
information” the Storage and Status Management Function takes the data of the related Liquidity transfer
order out of the Liquidity Transfer data store and creates an outgoing notification to be sent to Flow
Management. A confirmation of the booking from the RTGS system (RTGS answer) is required to ensure
the liquidity transfer has reached its destination. If T2S receives from the RTGS system:
•
An acknowledgement (ACK): the liquidity transfer has completed successfully;
Final_T2S_GFS_110.doc
Page 460
T2S General Functional Specifications
Functional Description
Liquidity Management
•
A negative acknowledgement (NAK): the liquidity transfer is not unwound, but an alert is
sent to the T2S Operator for further investigations;
•
No message: an alert is sent to the T2S Operator for further investigations.
2 – Information Manager
The Information Manager provides T2S system users with information on special booking events on T2S
dedicated cash accounts.
After receiving information from:
•
Validation, Provisioning and Booking Module when the available liquidity on the respective
T2S dedicated cash account exceeds the defined maximum amount (ceiling) {T2S.06.420};
•
Validation, Provisioning and Booking Module when the available liquidity falls under the
defined minimum amount (floor) {T2S.06.400};
•
Liquidity Control about standing orders not executed at all because there was no liquidity
available (Alert data),
the Information Manager sends these data as alert data to the Flow Management.
After receiving the Execution data from Storage and Status Management the Information Manager sends
•
in case of no execution or partial execution corresponding alert data to the Flow
Management
•
in case of execution corresponding confirmation data to the Flow Management
3.6.6.4. Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Floor/Ceiling information IN
Validation,
Provisioning and
Booking
Liquidity transfer
booking information
IN
Validation,
Provisioning and
Booking
Alert data
IN
Liquidity Control
Rejection (Incoming
notification)
IN
Liquidity Control
Incoming notification
IN
Flow Management
RTGS answer
IN
Flow Management
Alert data
OUT
Flow Management
Confirmation data
OUT
Flow Management
Final_T2S_GFS_110.doc
Page 461
T2S General Functional Specifications
Functional Description
Liquidity Management
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Outgoing notification
OUT
Flow Management
Incoming notification
OUT
Liquidity Control
3.6.6.5. Data accessed by the module
DATA
ACCESS MODE
Liquidity Transfer
STATUS
COMMENTS
Read/Write
3.6.7. NCB Business Procedures
3.6.7.1. Diagram of the module
LQMG:Liquidity Control
EoD
data
NCB Business
Procedures
Clearing
entry data
Account Number Retrieval
Cash account
balances
Transit account
balances
Account Balance Check
Pending
intraday credit
Business
event
SETT:
Auto-collateralisation
OPSR:
Scheduling
<<data store>>
SD
<<data store>>
BC
3.6.7.2. Description of the module
The module NCB Business Procedures is responsible for the end-of-day liquidity transfers between T2S
and the RTGS system. It is in charge of the automated transfer of surplus liquidity at the end of the day
as well as triggering linked liquidity transactions in case of insufficient liquidity (pending intraday credit).
Final_T2S_GFS_110.doc
Page 462
T2S General Functional Specifications
Functional Description
Liquidity Management
Additionally it triggers the bookings at the end-of-day between the RTGS dedicated transit accounts and
the “T2S technical account EoD”.
Based on a business event, the module NCB Business Procedures checks the balance of all T2S dedicated
cash accounts (data store BC). After retrieving information from Static Data the RTGS accounts are
matched to the T2S dedicated cash accounts (Account Number Retrieval) and the respective real-time
liquidity transfers (EoD data) are triggered through Liquidity Control Module {T2S.06.230}. The same is
to be performed for the RTGS dedicated transit accounts (Clearing entry data). In case of pending
intraday credit NCB Business Procedures gets the respective data from Auto-collateralisation Module and
forwards these data to Liquidity Control as EoD data.
The following cases can occur at the end of the settlement day:
•
Surplus liquidity at the end of the settlement day (if applicable after reimbursement): The
liquidity on the T2S dedicated cash account is automatically transferred to the corresponding
RTGS account {T2S.06.220, T2S.03.180};
•
Insufficient available liquidity to reimburse all pending intraday credits: The insufficient
liquidity on the T2S dedicated cash account would lead to a negative account balance. In this
case the module NCB Business Procedures triggers linked liquidity transactions to adjust the
balance with a liquidity increase from the RTGS system linked to a securities booking.
Related to the above mentioned general cases, which can occur on T2S dedicated cash accounts at the
end of the settlement day, there are four different scenarios possible:
6
No pending intraday credit;
7
The available cash on the T2S dedicated cash account of the payment bank is sufficient to reimburse
the pending intraday credit;
8
The available cash on the T2S dedicated cash account of the payment bank is only partly sufficient to
reimburse the pending intraday credit;
9
There is no cash available (zero balance) on the T2S dedicated cash account of the payment bank.
3.6.7.3. Description of the functions of the module
1 – Account Balance Check
After receiving a business event112 from Scheduling for transferring liquidity from the T2S dedicated cash
accounts to the corresponding RTGS accounts, the function Account Balance Check checks the balances of
all T2S dedicated cash accounts not owned by a Central Bank. For the accounts with cash available at the
112 The name of the event will be elaborated at a later stage. The whole EOD procedure will be clearly described in the
detailed functional
specification phase.
Final_T2S_GFS_110.doc
Page 463
T2S General Functional Specifications
Functional Description
Liquidity Management
end-of-day (scenario 1 and 2) the function forwards the cash account balances to the function Account
Number Retrieval for transferring the surplus liquidity from T2S to the RTGS system.
After receiving a second business event113 from Scheduling (which takes place in any case after the
completion of the step described above), the function checks the balances of all RTGS dedicated transit
accounts owned by a Central Bank. For all these accounts the function forwards the transit account
balances to the subsequent function Account Number Retrieval.
2 – Account Number Retrieval
For the T2S dedicated cash accounts with cash available at the end-of-day, the function matches the cash
account balances with the corresponding RTGS accounts and sends the EoD data (amount, T2S dedicated
cash account, RTGS account) to the Liquidity Control Module (scenario 1 and 2).
Information (respective T2S dedicated cash account, remaining amount, link indicator) of pending
intraday credit received from Auto-collateralisation Module is also matched with the corresponding RTGS
accounts and forwarded to the Liquidity Control Module as EoD data for a forced RTGS transfer from the
RTGS system to T2S (scenario 3 and 4).
RTGS transit account balances, received from the Account Balance Check Function are assigned to the
“T2S technical account EoD”. The corresponding clearing entry data are sent to the Liquidity Control
Module.
The respective NCB can receive their transit account balances via the report “Statement of End-of-Day
Balance” (according to their message subscription preference) in order to match the End-of-Day balance
on the RTGS dedicated transit account in T2S with the End-of-Day balance on the T2S dedicated transit
account in the RTGS.
3.6.7.4. Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Business event
IN
Scheduling
Pending intraday credit
IN
Auto-collateralisation
EoD data
OUT
Liquidity Control
Clearing entry data
OUT
Liquidity Control
3.6.7.5. Data accessed by the module
DATA
Cash Balances
113
ACCESS MODE
STATUS
COMMENTS
Read
The name of the event will be elaborated at a later stage. The whole EOD procedure will be clearly described in the DFS.
Final_T2S_GFS_110.doc
Page 464
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
DATA
ACCESS MODE
Static Data
STATUS
COMMENTS
Read
3.7. Statistics, Queries, Reports and Legal Archiving
3.7.1. General Introduction
The Statistics, queries, reports and archives domain provides a number of functionalities to the T2S
System User. It is split up in four modules:
•
Statistical Information;
•
Query management;
•
Report management;
•
Legal Archiving.
Statistical Information
The Statistical Information module provides T2S system users with tools for statistical analysis as a
support for decision-making.
The scope of this module is twofold:
•
To provide statistics to the T2S operator and the CSDs for some operational purpose, on the
level of use of the different components of the platform over time, to support the proper
management of the system. Such statistics are based on a “short term” repository including
data up to three months and the whole instruction life history (including all status changes
and relevant timestamps);
•
To offer to CSDs and NCBs on an optional basis wider scope statistics for analysis and
regulatory reporting purposes. These statistics are based on a “long term” repository storing
data with their final status. These statistics are available on data older than three months.
The functions in the module allow performing statistical queries and multi-dimensional analyses.
Query Management
The Query Management module allows different categories of pre-defined real-time and historical queries
on the production data. All User Queries are available for all CSDs in T2S, directly connected T2S Parties
(according to access rights set up by the CSD) and NCBs. User Queries are processed in real time, based
on the latest available data. The response to a User Query always contains the timestamp specifying the
T2S system time when the data selection was actually performed.
Final_T2S_GFS_110.doc
Page 465
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
Report Management
T2S provides T2S actors with a number of pre-defined reports for periodical information on the production
data but the Report Management Module does not cover any regulatory reporting. Reports are available
for all CSDs in T2S, T2S parties and NCBs. They can be sent to CSDs and directly connected T2S parties,
containing information on one or several accounts.
T2S reports can either be requested or sent on a business or time event (e.g. end-of-day, at a fixed time).
The reports are stored for the previous and current business day.
Legal Archiving
The Legal Archiving module addresses needs for a settlement related central archive for T2S purposes
and made available to T2S parties via their CSDs. It stores for a given period incoming and outgoing files
in their original format, transactional data with its related static data, and answers to the extraction
request to these data.
Requests are submitted on real-time through the interface. Archived data are made available through
restitution files within a maximum time-frame of three days, in compliance with the retrieval
requirements.
This module does not address neither the needs for Data Revision (replication of static data structures as
revision tables) and Data History (data stored with “valid from” and “valid to” date attributes) nor the
requirements regarding archiving on behalf of CSDs.
3.7.2. Dynamic Data managed by the domain
3.7.2.1. Report Management
Final_T2S_GFS_110.doc
Page 466
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
Report:
ATTRIBUTE
DESCRIPTION
Report Name
Name of the stored Report
Report Data
Content of the Report stored as flat file.
Report Timestamp
Timestamp reflecting date and time of the creation of the report.
3.7.2.2. Legal Archiving
Archiving date:
ATTRIBUTE
DESCRIPTION
Date
Archiving date
Archiving Date Status
“Archiving in process”, “Archived”
Archiving File:
ATTRIBUTE
DESCRIPTION
Creation Date
Date of creation of the file
Actual Archived Date
Timestamp of the actual archiving of the data
Archiving File Status
“Created”, “Sent for archiving”, “Waiting for archiving”, “Cancelled” or
“Archived”
Final_T2S_GFS_110.doc
Page 467
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
3.7.3. Statistical Information
3.7.3.1. Diagram of the module
3.7.3.2. Description of the module
The Statistical Information module is expected to provide T2S system users (i.e. the T2S operator and, on
an optional basis, CSDs and NCBs) with business intelligence tools to be used for statistical analysis and
as a decision support system.
It stores information on accounts (including position changes and event information), on instruction and
on queries and reports (including volumes generated).
The scope of this module is twofold:
•
To provide statistics to the T2S operator and the CSDs for some operational purpose, on the
level of use of the different components of the platform over time {T2S.15.040}, to
support the proper management of the system. Such statistics are based on a “short term”
repository including data up to three months and the whole instruction life history (including
all status changes and relevant timestamps) 114.{T2S.15.010} {T2S.17.060}
114 This period is meant as three months after the day the concerned data item (e.g. a static data object, a settlement instruction and so forth) has
reached its final status (e.g. settled, cancelled, deleted).
Final_T2S_GFS_110.doc
Page 468
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
•
To offer to CSDs and NCBs on an optional basis wider scope statistics for analysis and
regulatory reporting purposes. These statistics are based on a “long term” repository storing
data with their final status. These statistics are available on data older than three months.
Both repositories are separated from the live data repositories, in order to provide an easy access to high
quality and business oriented data without the risk of impacting the performance of the operational
settlement environment. {T2S.15.010}
In the present document, both dimensions are covered within the scope of the single Statistical
Information module. Nevertheless, this general description will be followed, during the next phase of the
project, by detailed specifications aiming at serving as a basis of the design of the technical (development
and infrastructure) solution(s): (i) one covering the statistics needed for the monitoring and management
of the platform by the T2S operator and (ii) the second covering wider scope statistics for analysis and
regulatory reporting purposes by CSDs and NCBs, on an optional basis.
The Statistical Information module provides functions to perform statistical query and reporting and multidimensional analysis:
•
Statistical query and reporting is the process of retrieving relevant data, transforming them
into the appropriate context, and displaying them in a readable format. It is driven by the
T2S system user, who issues queries or run reports to retrieve the relevant data;
•
Multi-dimensional analysis enables T2S system users to extend the capabilities of statistical
query and reporting. That is, rather than submitting queries or running reports, data are
represented as business-oriented objects (e.g. settlement instruction, party) and they are
categorized by different dimensions (e.g. instruction type, party type) that the user can
browse to perform more complex statistical analysis;{T2S.15.020}
Multi-dimensional analysis enables T2S system users to look at a large number of
interdependent factors involved in a business problem and to view the data in complex
relationships. T2S system users are interested in exploring the data at different levels of
detail, which can be determined dynamically. Complex relationships can be analyzed through
an iterative process that includes drilling down to lower levels of detail or rolling up to higher
levels of summarization and aggregation. Pivoting of data can also be used.
Both the “short term” and the “long term” data repositories are based on the following components:
•
Detailed Data Repository, including all the data of interest for statistical analysis for the
specific category of T2S system users performing such analysis and with the same level of
granularity of the operational data;
•
Aggregated Data Repository, including all the data of interest for statistical analysis for the
specific category of the T2S system users performing such analysis and with a lower level of
Final_T2S_GFS_110.doc
Page 469
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
granularity (obtained by means of detailed data aggregation) compared to the operational
data;
•
T2S System User Data Repositories, a set of repositories each of which including detailed and
aggregated data of interest for a specific category of T2S system users only (i.e. T2S
operator, CSDs, NCBs);
•
Statistical Workspaces Repository, defining the relevant set of business-oriented concepts to
be used for statistical analysis (e.g. securities account, DvP transaction, cash amount and so
forth) and their mapping to the physical objects available in the repositories (i.e. tables,
columns and so on). Each category of T2S system users can be assigned one or more
statistical workspaces.
The specific set of available statistical data and functions depends on the specific access profile of each
T2S system user. As to the set of accessible data, the T2S operator can access all the data needed to
perform its business and technical monitoring of the overall platform, while CSDs and NCBs would access
their own data and the data of their respective participants. With respect to the set of usable functions,
three main profiles are envisaged:
•
Basic Statistical User: this is the T2S system user performing statistical query and reporting.
Typically, they can simply view a set of standard statistical queries and reports run
automatically and periodically or run a pre-defined set of statistical queries and reports with
the possibility to input a specific set of search criteria. They cannot create new statistical
queries or reports autonomously;
•
Advanced Statistical User: this is the T2S system user performing multi-dimensional analysis.
Advanced statistical users analyze their data via the relevant workspace defined by the
statistical workspace administrator. They can also create new statistical queries and reports
and make them available to the basic statistical users (or to a specific sub-set of them);
•
Statistical Workspace Administrator: this T2S system user is in charge of defining the
statistical workspaces for the advanced and basic statistical users, i.e. the set of businessoriented objects they will use for their statistical analysis;
•
A single T2S system user can be linked to one or more profiles.
3.7.3.3. Description of the functions of the module
1 – Extraction, Transformation and Loading
This function manages a three-step process consisting, at each step, in extracting data from a source
repository, transforming them to fit the relevant business needs and loading them in a destination
repository.
Final_T2S_GFS_110.doc
Page 470
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
More in details:
•
In the first step, the function extracts raw data from the operational database, transforms
them and finally loads them into the detailed data repository. At this stage, data
transformations are normally data type conversions or functions applied to a single attribute
or a set of attributes at row level, without any changes in the level of granularity (i.e.
aggregation) compared to the operational data;
•
During the second step, data are extracted from the detailed data repository, transformed
and finally loaded into the aggregated data repository. At this stage, data transformations
are typically aggregations and summarizations, with a decreasing level of granularity
compared to the operational data;
•
In the final step, the function extracts data from the detailed and aggregated data
repositories, transforms them and finally loads them into the relevant T2S system user
repositories.
The Extraction, Transformation and Loading function is triggered at the End-of-Day to load on a daily
basis the relevant data into the “short term” and “long term” repositories. The first step of this function is
also triggered intra-day by a periodic time event to load quasi real time the relevant raw data into the
“short-term” repository.
2 –Statistical Workspace Management
This function allows statistical workspace administrators to create and manage workspaces for each user
profile, i.e. basic and advanced statistical users.
Each statistical workspace can be described as a set of business-oriented objects defined by means of a
set of quantitative and qualitative variables. For instance, an object called securities transaction might be
defined as a set of qualitative variables such as transaction type (i.e. DvP, FvP, etc.), ISIN, CSD
participant and period (according to the time hierarchy year, quarter and month) and quantitative
variables such as securities amount and cash amount. Moreover, multiple objects might be linked by
specific relationships (e.g., securities transaction may be linked to securities account and T2S dedicated
cash account).
Statistical workspace management provides statistical workspace administrators with all the functionalities
needed to maintain both workspaces and business-oriented objects, and to make them available to basic
and advanced statistical users for their analysis.
Hereafter, the main features for statistical workspace management are described:
Final_T2S_GFS_110.doc
Page 471
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
Statistical Workspace Maintenance
This feature enables statistical workspace administrators to maintain statistical workspaces, i.e. to create
new workspaces or to update or delete existing workspaces.
Statistical Workspace Assignment
This feature enables statistical workspace administrators to grant advanced statistical users with access to
statistical workspaces (i.e. all the business-oriented objects belonging to the granted workspace) and to
revoke that access.
Statistical Workspace Access
This feature enables authorized T2S system users (i.e. statistical workspace administrators and authorized
advanced statistical users) to access statistical workspaces, i.e. to view information concerning the
workspaces and all the business-oriented objects belonging to those workspaces.
Business-Oriented Object Maintenance
This feature enables statistical workspace administrators to maintain business-oriented objects, i.e. to
create new objects or to update or delete existing objects.
Business-Oriented Object Assignment
This feature enables statistical workspace administrators to grant advanced statistical users with access to
specific business-oriented objects defined in the relevant statistical workspaces (so that it can be used for
multi-dimensional analysis purposed) and to revoke that access. It is also possible to grant or revoke
access to a specific sub-set of the object’s attributes only.
Business-Oriented Object Access
This feature enables authorized T2S system users (i.e. statistical workspace administrators and authorized
advanced statistical users) to access business-oriented objects defined in the relevant statistical
workspace, i.e. to view information concerning the objects and their relationships with other objects in the
same workspace.
3 – Multi-dimensional Analysis
This function allows advanced statistical users to perform their multi-dimensional analysis, i.e. to analyze
their data via the relevant statistical workspace defined by the statistical workspace administrator and to
create new statistical queries and reports and make them available to the basic statistical users (or to a
specific sub-set of them). {T2S.15.040}
Going into further detail, advanced statistical users can browse, explore and analyze their businessoriented objects via drill-down, roll-up and pivoting functions. Moreover, they can create, update, run and
Final_T2S_GFS_110.doc
Page 472
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
delete statistical queries and report that they can then publish to make them available to selected basic
statistical users. {T2S.15.030}
Hereafter, the main features for multi-dimensional analysis are described:
Statistical Queries and Reports Maintenance
This feature enables advanced statistical users to maintain statistical queries and reports, i.e. to create
new queries and reports or to update or delete existing queries and reports. When creating a new query
or report, advanced statistical users can explore and analyze their business-oriented objects using drilldown, roll-up and pivoting functions and they can also combine different linked objects, in order to create
the data set that will be retrieved by the query or by the report.
Statistical Queries and Reports Assignment
This feature enables advanced statistical users to grants basic statistical users with access to specific
statistical queries and reports (i.e. with the possibility to view and/or run that queries and reports), and to
revoke that access.
Statistical Queries and Reports Access
This feature enables authorized T2S system users (i.e. advanced statistical users and authorized basic
statistical users) to access statistical queries and reports, i.e. to view information concerning the definition
of that queries and reports.
4 – Statistical Query and Reporting
This function allows basic statistical users to perform their query and reporting analysis, i.e. to view a set
of standard statistical queries and reports executed automatically and periodically or to run a pre-defined
(by the advanced statistical user) set of queries and reports with the possibility to input a specific set of
search criteria. {T2S.15.030}
Each basic statistical user is able to view and run only the set of queries and reports for which the
advanced statistical user has granted access.
The statistical reports showing time series analysis {T2S.15.040} are available both as tables and in
several graphic formats (e.g. charts, pie-chart).
Hereafter, the main features for statistical query and reporting are described:
Statistical Queries and Reports Browsing
This feature allows the basic statistical user to browse the set of available statistical queries and reports
and select one for access or execution.
Final_T2S_GFS_110.doc
Page 473
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
Statistical Queries and Reports Access
This feature allows the basic statistical users to retrieve the definition of a statistical query or a report.
Statistical Queries and Reports Execution
This feature allows the basic statistical user to run a statistical query or report (possibly entering a set of
input parameters), and returns the relevant retrieved data set.
5 – Export Data
This function allows both basic and advanced statistical users to export the result of their analysis (i.e. the
result of their statistical queries and reports) in many different formats (e.g. XML, .xls, .pdf, .csv and so
forth), for further utilization with other tools (e.g. MS Office).
3.7.3.4. Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Query and Report
Request
In
Request from
Interface
allowed T2S
system users for a
statistical
query/report
Statistical Query
and Reporting
Query and Report
Response
Out
Statistical
query/report
results to be
provided to
authorized T2S
system users
Statistical Query
and Reporting
Interface
S.W.M. Request
In
Request from
authorized T2S
system users for
creating/managin
g statistical
workspace
Interface
Statistical
Workspace
Management
S.W.M. Response
Out
Statistical
workspace
creation/manage
ment response to
be provided to
authorized T2S
system users
Statistical
Workspace
Management
Interface
M.D. Analysis Request
In
Request from
authorized T2S
system users for
performing
Multidimensional
Analysis
Interface
Multi Dimensional
Analysis
Final_T2S_GFS_110.doc
Page 474
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
FLOW
IN/OUT
DESCRIPTION
FROM
TO
M.D. Analysis
Response
Out
Multidimensional
Analysis results to
be provided to
authorized T2S
system users
Multi Dimensional
Analysis
Interface
Data Export Request
In
Request from
authorized T2S
system users for
exporting
query/report
results in different
formats
Interface
Export Data
Formatted Data
Out
Query/report
Export Data
results exported
in different format
to authorized T2S
system users
Interface
3.7.3.5. Data accessed by the module
DATA
ACCESS MODE
STATUS
COMMENT
STATIC DATA
All Static Data
Read
Data extracted
from all domains
of T2S for
statistical purposes
Long-term Data
Read/Write
Statistical data
older than three
months.
DYNAMIC DATA
All Dynamic Data
Read
-
Data extracted
from all domains
of T2S for
statistical purposes
Short-term Data
Read/Write
-
Statistical data up
to three months.
Final_T2S_GFS_110.doc
Page 475
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
3.7.4. Query Management
3.7.4.1. Queries (QU) use cases
Scope
This category of use cases describes the situations when a T2S Actor sends different real-time queries to
the system. All possible types of queries are covered, i.e. queries to monitor securities positions, cash
balances, instruction status and static data.
Criteria
The criteria used to identify the use cases are: the communication mode, the instructing party, the query
category, the query type and (optional) the query sub-type. The possible values are the following:
CRITERIA
POSSIBLE VALUES
DESCRIPTION
Communication mode
U2A, A2A
See glossary
Instructing party
CSDs, directly connected parties, NCBs
See glossary
Query category
CSD securities account monitoring, instructions,
security account, cash account, static data,
status of the settlement day, NCB liquidity
monitoring, cash account monitoring
The subject of the query as a
broad category
Query type
Holdings, transactions, instructions, cash liquidity, The concrete query type.
security instruction, security instruction history,
audit trail instructions, security balance, security
balance history, cash balance, cash forecast
current settlement day, cash forecast following
settlement day, cash account limits, cash
account list, total amount of liquidity, global
amount of orders, limits
Query sub-type
Cash balance: single balance, collateral value,
intraday credit, consolidated view on RTGS and
T2S
Sub-type of a query (optional)
Cash forecast: current or following settlement
day
Limits: defined limits, limit usage
Final_T2S_GFS_110.doc
Page 476
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
List of Use Case
The criteria described above are reported in the following tree:
Queries
U2A
A2A
Store/retrieve
query
parameter
Directly
connected
parties
CSDs
CSDs
securities
account
monitoring
Instructions
Security
account
Holdings
Security
Instruction
Security
balance
Transactions
Security
Instruction
History
Security
balance
history
Instructions
Audit Trail
Instructions
NCBs
Cash account
Cash account
monitoring
Status of the
settlement day
Cash balance
Cash forecast
current
settlement day
Cash forecast
following
settlement day
Static data
NCB liquidity
monitoring
Total Amount
of Liquidity
Global
Amount of
Orders
Limits
Cash account
limits
Cash Liquidity
Cash account
list
All the combinations of values are not relevant from a business point of view: the complete list of use
cases is presented in appendix.
3.7.4.2. Processing of Queries Use Cases
Processing of UC-QU-1: Query on Securities Settlement Instructions
Considering the high regularity of the Query Management process, only one representative use case is
defined.
Final_T2S_GFS_110.doc
Page 477
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
Sequence Diagram Query Management
SRQA: Query
Management
Interface
T2S System User
User query
Alt
[negative answer]
Rejection message
[positive answer]
User query
Alt
Error data (Queries)
[negative answer]
Response (Error message)
[positive answer]
Queried data
Queried data
Business assumption
A T2S System user sends a query on the status of pending securities instructions.
Processing
A T2S System user sends a security settlement instruction query which enters the Interface. In the
Interface the query passes several technical validations and checks. In case of a negative result the query
is stopped and a Rejection message is sent to the T2S System user. If the checks are confirmed the query
is forwarded to the Query Management Module.
Within the Query Management Module the “Plausibility Check” function verifies the plausibility of the
query. Using several logical checks it tries to identify zero-result queries or queries containing not
plausible characters to reduce unnecessary accesses to data stores. For example, queries which contain
Final_T2S_GFS_110.doc
Page 478
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
non valid ISINs or currencies neither eligible nor external recognised for T2S are blocked by the function
“Plausibility Check”. The reference values for the checks are stored in the Static Data data store.
•
Plausibility check fails: If a query fails one of the checks it is forwarded to the function “Error
handling”. This function identifies the reason of the failure and translates it into an error data
which is sent to the Interface.
•
Plausibility check is successful: The valid user query on securities settlement instruction is
forwarded to the function “Check Permission on Query Request”.
•
The function “Check Permission on Query Request” ensures that users can only query data
which they are permitted to access. The access authorisations are stored in the Static Data
data store.
-
If the sender of the security instruction query is not authorised to access the data, the
query is sent to the “Error Handling” function und thereafter the error data to the
Interface which sends a Response (Error message) to the T2S System user
-
Otherwise, the query is forwarded to the “Extracting Data” function.
The “Extracting Data” function extracts the requested data from the data store and sends the results to
the Interface. If the extraction from the data store fails, the “Error Handling” function sends Error data
(Queries) to the Interface.
Final_T2S_GFS_110.doc
Page 479
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
3.7.4.3. Static Functional Description
Diagram of the module
Final_T2S_GFS_110.doc
Page 480
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
Description of the module
The Query Management allows different categories of pre-defined real-time and historical queries on
the production data. A T2S System User can query historical data for a period of the last 90 business
days. Historical data beyond 90 business days can be accessed through the functions provided by the
Statistical Information Module.
The following types of queries are available:
QUERYNAME
TYPE OF DATA
Securities Settlement Instruction Queries
•
Securities Settlement Instruction Query
real-time
•
Securities Settlement Instruction History Query
historic
•
Securities Settlement Instruction Audit Trail Query
real-time
•
Securities Settlement Instruction History Audit Trail Query
historic
Securities Account Position Queries
•
Securities Account Position Query
real-time
•
Securities Account Position History Query
historic
•
CSD Securities Account Monitoring Query
real-time
T2S Dedicated Cash Account Balance Queries
•
T2S Dedicated Cash Account Balance Query
real-time
•
T2S Overall Liquidity Query
real-time
•
Cash Forecast Query
real-time
•
Limit Queries
real-time
•
NCB Liquidity Monitoring Query
real-time
Static Data Queries
•
Static Data Changes awaiting Approval Query
real-time
•
Static Data Audit Trail Query
real-time
•
Securities Reference Data Query
real-time
•
ISIN List Query
real-time
•
Securities Deviating Nominal Query
real-time
•
Securities CSD Link Query
real-time
•
Party Reference Data Query
real-time
•
Party List Data Query
real-time
Final_T2S_GFS_110.doc
Page 481
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
QUERYNAME
TYPE OF DATA
•
Restricted Party Query
real-time
•
Securities Account Reference Data Query
real-time
•
Securities Account List Query
real-time
•
Cash Account Reference Data Query
real-time
•
T2S Dedicated Cash Account List Query
real-time
•
T2S Dedicated Cash Account Links by Party or Securities Account Query
real-time
•
Securities Account Links by T2S Dedicated Cash Account Query
real-time
•
T2S Calendar Query
real-time
•
T2S Diary Query
real-time
•
System Entity Query
real-time
•
Attribute Domain Query
real-time
•
Privilege Query
real-time
•
Privilege Class Query
real-time
•
Role Query
real-time
•
T2S System User Query (T2S Actor Query)
real-time
•
Service Query
real-time
•
Service Configuration Query
real-time
•
Restriction/Segregation Query
real-time
•
Full Audit Trail
real-time
•
SWIFT BIC Code Query
real-time
The various queries are described in more detail in an appendix to the GFS.
•
All User Queries are available for all CSDs in T2S, directly connected T2S Parties
(according to access rights set up by the CSD) and NCBs, unless an exception is stated
explicitly {T2S.14.030}. When processing queries, the Query Management Module
takes
into
account
all
privileges
as
defined
in
Static
Data.
{T2S.14.060}
{T2S.14.525}
•
All User Queries are available in user-to-application mode (U2A) and in application-toapplication mode (A2A) {T2S.14.020}. The User Queries and their responses are set up
as XML messages (compliant with the ISO20022 standards). The use of proprietary
messages is avoided {T2S.14.010}. The response time of the user-to-application
interface within T2S to handle User Queries is at maximum 3 seconds for 95 % of the
queries (for basic User Queries with simple criteria). If the complexity of the User Query
Final_T2S_GFS_110.doc
Page 482
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
requires more time to be processed, T2S sends response on the status within 15 seconds
using a specific error message. The processing of the User Query proceeds nevertheless
until the result can be returned {T2S.17.140}. Whether the listed queries count as
simple or complex will be determined during the functional specification.
•
All User Queries are processed in real time, based on the latest available data
{T2S.14.050}. Exceptionally, during the night-time settlement cycles T2S stores all
User Queries (except Static Data Queries) sent in application-to-application mode and
replies with a message that the system is currently running a cycle. At the end of the
cycle T2S responds to the User Query based on the data at the end of the cycle.
{T2S.14.080}. User Queries sent in user-to-application mode during the night-time
settlement cycles are not stored for further processing. Instead the T2S System User
receives a real time response that a night-time settlement cycle is currently running.
The response to a User Query always contains the timestamp that specifies the T2S system time when
the data selection was actually performed. {T2S.14.250} {T2S.14.520}
Description of the functions of the module
1 – Plausibility Check
This function performs a plausibility check on the received User Query. Using several logical checks it
tries to identify zero-result queries (e.g. data range 01/01/08 < date and 01/01/08 > date) or queries
containing not plausible characters to reduce unnecessary database accesses. Furthermore User
Queries referring to currencies not recognised by T2S or non valid ISINs are blocked. The reference
values for the checks are stored in the Static Data data store.
Any User Query failing one of these checks is forwarded as Failed User Query to the function “Error
handling”. Otherwise the User Query is forwarded to the function “Check Permission on Query
Request”.
2 – Check Permission On Query Request
T2S System User privileges are checked against the access authorisations stored in the Static Data
datastore, guaranteeing that the requesting T2S System User will only receive the information/data in
a scale he is permitted to access. If the sender of the User Query is not authorised to access the data
the User Query is forwarded to the “Error Handling” function. {T2S.14.090} / {T2S.14.830}
All other User Queries are forwarded to the function “Extracting Data for Query”.
3 – Extracting Data for Query
The “Extracting Data for Query” function extracts the requested data from the relevant data stores
and sends the results as Queried Data to the Interface.
Final_T2S_GFS_110.doc
Page 483
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
Most User Queries allow the specification of search criteria for various fields. For these selections the
following rules apply:
•
In case more than one field is specified the criteria are combined using the logical AND
operation. If a User Query allows the specification of a list of values for a certain field,
these restrictions are combined using a logical OR operator. Fields not specified allow any
value.
•
For fields that allow the specification of a range for the field’s value an upper and a lower
limit can be specified. Depending on the actual User Query it may be sufficient if only one
value is given (e.g. to select all instructions sent after a specific time).
•
In User Queries that support the specification of a relation the actual comparison
operator (</<=/=/>=/>/<>) and a fixed value for comparison can be specified.
•
Wildcard characters that may be substituted for any allowed character can be used to
shorten the selection part when a list of similar values needs to be specified. In case
wildcards and relations are allowed for the same field, values containing wildcard
characters can only be combined with the relations “equal” and “unequal” (=/<>).
Only records that match the selection criteria are returned. {T2S.14.230}
If the extraction from the data store fails the User Query is forwarded to the “Error Handling”
function.
4 – Error Handling
If a User Query fails or an error is detected, this function translates the reason of the failure into Error
data (Queries) that is forwarded to the Interface.
Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
TO
User Query
IN
Flow Management
Plausibility Check
Queried Data
OUT
Extracting data for
Query
Flow Management
Error data
(Queries)
OUT
Error Handling
Flow Management
Data accessed by the module
DATA
ACCESS MODE
STATUS
COMMENTS
Static Data
Read
All
According to the diagram of the module,
all functions of the Query Management
Module are able to access the Static Data
data store.
Dynamic Data
Read
All
According to the diagram of the module,
Extracting Data for Query Function shall
access Dynamic Data Data stores.
Final_T2S_GFS_110.doc
Page 484
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
Query Filter Criteria
Data
Read/Write
All
n.a.
3.7.5. Report Management
3.7.5.1. Reports (RE) use cases
Scope
This category of use cases covers the situations where T2S sends reports to T2S Actors. Reports are
sent automatically at a fixed time and/or triggered by an event as well as taking into account the
subscription preferences of the T2S Actors.
Criteria
The criteria that characterize a report use case are: the communication mode, the information basis,
the report triggering, the report type and (optional) the report sub-type. These criteria are
summarized in the table below with their possible values:
CRITERIA
POSSIBLE VALUES
DESCRIPTION
Communication mode
U2A, A2A
See glossary
Information basis
On individual account, on a set of account
The underlying account or
accounts a report refers to
Report triggering
At a fixed time, triggered by an event, on
demand
Sending time of a report
Report type
Securities instructions, balance, static data
The concrete report type
Report sub-type
Cash forecast – current settlement day, Cash
forecast following settlement day, statement of
allegements, statement of pending instructions,
billing data report, statement of holdings,
statement of transactions, statement of static
data, statement of end-of-day balance
Sub-type of a report
Final_T2S_GFS_110.doc
Page 485
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
List of Use Case
The criteria described above are reported in the following tree:
All the combinations of values are not relevant from a business point of view: the complete list of use
cases is presented in appendix.
3.7.5.2. Processing of Reports use cases
Considering the high regularity of the Report Management process, only one representative use case
is defined
Final_T2S_GFS_110.doc
Page 486
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
Processing of UC-RE-1: Current Settlement Day Cash Information Report
Sequence Diagram Report Management
SRQA: Report
Management
Interface
OPSR: Scheduling
T2S System User
Time event
Alt
Error data (Reports)
[negative answer]
Response (Error message)
[positive answer]
Report
Report
Business assumption
T2S produces an automated report on an individual T2S dedicated cash account at a fixed time for the
cash forecast of the current settlement day.
Processing
Based on the End of night-time cycle event or a fixed time throughout the business day the Report
Management Module is launched by the Scheduler. The “Extracting Data for Report” function looks for
valid and eligible instructions that have entered T2S but have not been settled yet on the respective
individual T2S dedicated cash account as well as the liquidity that can be obtained through autocollateralisation against eligible collateral. It extracts the relevant business raw dynamic data and
submits it to the subsequent function “Calculating Report”. Within this function the received raw
dynamic data for the report are processed, e.g. sums, products, totals or averages are calculated. The
resulting report data, including business raw dynamic data and calculated values, are sent to the
function “Formatting Report”. This function formats the report, i.e.:
• Sorts the extracted and derived report data (the order of columns is defined, the sorting of
rows is performed);
• Groups them (e.g. totals are added to each group).
Final_T2S_GFS_110.doc
Page 487
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
Afterwards the function “Store/Load Report” stores the generated report received from the function
“Formatting Reports” in the report data store before forwarding the final report to the T2S System
user via the Flow Management of the Interface.
3.7.5.3. Static Functional Description
Diagram of the module
Final_T2S_GFS_110.doc
Page 488
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
Description of the module
T2S provides T2S actors with a number of pre-defined reports for periodical information on the
production data. The Report Management Module, however, does not cover any regulatory reporting.
The reports provided are set up as XML messages and comply to the largest possible extent with ISO
20022 standard. In cases where the standard is not able to meet T2S demands, proprietary messages
are defined {T2S.13.160}. All reports are available in user-to-application mode and in application-toapplication mode {T2S.13.170}. All securities instructions, balance and static data reports are
available for all CSDs in T2S, T2S parties and NCBs {T2S.13.180}. Reports can be sent to CSDs and
directly connected T2S parties, containing information on one or several accounts {T2S.13.210}.
T2S reports can either be sent on a business event (e.g. end-of-day) or on a time event (i.e. at a fixed
time) {T2S.13.190} {T2S.13.136}.
If a report got lost, it can be downloaded again by the affected T2S actor. Furthermore, in case a
report is incorrect, e.g. due to technical problems, the report of a specific day can be regenerated by
the T2S operator via a “Report Generation Request”. The reports are stored for a specified time.
The list of report types can be found in appendix.
Description of the functions of the module
1 – Extracting Data For Report
This function allows the selective extraction of business raw data for report from the relevant T2S
data stores. The reports are based on the latest data available {T2S.13.200}. All required data is
extracted taking into account the privileges of the requesting T2S system user.
T2S system users from directly connected T2S parties can receive reports on:
•
their own securities and cash balances and those of their clients;
•
instructions submitted by themselves or those clients;
•
instructions that refer to the respective securities or cash accounts.
T2S system users from a CSD in T2S can receive reports on:
•
instructions submitted by itself or by its directly to T2S connected clients;
•
securities and cash balances of their T2S accounts or of its T2S parties;
•
static data (own data and those of T2S parties who permit).
Where a CSD acts as an investor CSD, it is treated like a participant of the respective Issuer CSD in
T2S. An NCB only has access to cash balances and static data within its responsibility. Additionally, an
NCB can act as a participant of a CSD in T2S. In this case the NCB has the same privileges as any
other participant of this CSD in T2S for this part of its activities {T2S.13.220}.
The extracted raw data for report is forwarded to the function “Calculating Report”.
Final_T2S_GFS_110.doc
Page 489
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
2 – Calculating Report
The received raw data for report is processed, e.g. sums, products, totals or averages are calculated.
The resulting report data, including raw data and calculated values, is sent to the function “Formatting
Report”.
3 – Formatting Report
The received report data (raw data and calculated data) is formatted, sorted (order of columns is
defined, the sorting of rows is performed) and grouped (e.g. totals are added to each group). A
timestamp reflecting the point in time when the data was extracted is added. Finally the finished
Report is forwarded to the function “Store/Load Report”.
4 – Store/Load Report
This function:
•
stores any newly generated Report received from function “Formatting Reports” in the
report data store before forwarding it to the interface;
•
for each Report Requests received, loads the indicated Report from the report data store
and forwards it to the interface. Thus in case a report got lost, e.g. due to technical
problems at the T2S party’s site, the report can be downloaded again with a Report
Request send by a T2S system user through the interface.
5 – Validate Report Request
The function provides the business validation (e.g. plausibility) for all received requests.
After this Report Requests are forwarded to the function “Store/Load Report” while Report generation
requests are forwarded to the function “Extracting Data for Report”.
When the request fails the validation it is forwarded as Request failure to “Error Handling”.
6 – Error Handling
Based on the received Request failure this function creates a meaningful error data that is forwarded
to the Interface.
7 – Delete Report
All reports stored in the Reports data store are automatically deleted after a specified time.
Description of the Input/Output of the module
FLOW
Report
Generation
Request
IN/OUT
IN
Final_T2S_GFS_110.doc
DESCRIPTION
FROM
TO
Flow Management
Page 490
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Report
Request
IN
Flow Management
Business
event/Time
event
IN
Operational Services
Report
OUT
Flow Management
Error data
(Reports)
OUT
Flow Management
Data accessed by the module
DATA
ACCESS MODE
Static Data
Read
Dynamic Data
Read
Reports
Read/Write
STATUS
COMMENTS
3.7.6. Legal Archiving
3.7.6.1. Legal Archiving (LA) use cases
Scope
This category of use cases describes the possible uses of the Legal Arching module.
Criteria
The criteria used to identify the use cases are the Requester entity type and the Interface used. The
possible values for these criteria are:
CRITERIA
POSSIBLE VALUES
Requester Entity Type
CSD, NCB, T2S Operator
Interface used
U2A/A2A
COMMENT
List of Use Cases
The criteria described above are illustrated in the following tree. Each path constitutes a valid usecase.
Final_T2S_GFS_110.doc
Page 491
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
Request
for archived data
U2A
CSD
A2A
NCB
T2S Operator
The complete list of use cases is presented in appendix.
3.7.6.2. Processing of Legal Archiving use cases
Only one use case is considered as representative.
Processing of UC-LA-1 Answer processing to a request for archived data
Business assumption
Received from a CSD, or NCB or T2S Operator, the archive request is sent after its entry in the
Interface to the Legal Archiving module.
Final_T2S_GFS_110.doc
Page 492
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
Processing
In the Legal Archiving module, the archive request is submitted to a first check to control if:
• the CSD/or NCB/or T2S Operator is authorised to access to the requested archived data;
• the type of requested data corresponds to a type archived data for this CSD/or NCB/ or T2S
Operator.
Depending of the results of this first check, a negative acknowledgement is sent to the requester via
the Interface domain.
With a maximum response time of 3 days, the result of the extraction (requested archived data) is
sent to the requester115.
3.7.6.3. Static functional description
Diagram of the module
Below is the Activity Diagram modelling the interactions between the functions within the module.
Description of the module
This module addresses needs for a settlement related central archive. It stores for a given period
transactional data with its related static data and answers to the extraction request to these data
{T2S.17.070}. It does not address:
115
The proposed solution will be described during the DFS/UDFS phase.
Final_T2S_GFS_110.doc
Page 493
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
• The Data Revision (replication of static data structures as revision tables) and Data History
(data stored with “valid from” and “valid to” date attributes) described in URD section 16.4;
• Requirements to be detailed in the next phase regarding archiving on behalf of CSDs
(principles, location, duration, detailed contents...).
Besides, despite a “real time” access through the U-2-A and A-2-A interfaces, it is recalled that the
retrieval of archived data aims only at meeting requirements from a legal nature and therefore the
answer to an archive request is not to be expected on a “real time” basis (response time up to 3 days)
{T2S.17.130}.
Six functions handle the different steps of the archiving processing:
• Data Extraction for Archiving extracts the data from the T2S data stores, handles the logical
deletion of extracted data, creates archive files and follows their archiving process;
• Data Archiving handles the actual archiving of the archive files;
• Data Physical Deletion manages the physical deletion of the data previously logically deleted
by the Data Extraction for Archiving function;
• Archive Data Extraction extracts the archived files on a request and edits the archived data in
a restitution file;
• Archived Data Restitution posts the restitution files and informs the requester;
• Archived Data Purge deletes the archived files after a given period.
Description of the functions of the module
1 – Data Extraction for Archiving
During the maintenance window of each settlement day, triggered by an Archiving Event from the
Scheduling, the function:
• Extracts the data to archive in the T2S operational data store following archiving rules which
depend of the involved CSD or NCB;
• Proceeds to the logical deletion of data oldest than the “Archiving time” parameter (currently
defined at 90 days {T2S.17.090});
• Prepares and sends the archive files;
• Keeps tracks of the archiving process of the archive files depending on the received
acknowledgments value.
Data Extraction
The function extracts the following data in the T2S data stores:
• Incoming and outgoing files in their original format {T2S.17.080};
Final_T2S_GFS_110.doc
Page 494
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
• Individual settlement instructions in their final status (settled, partially settled, cancelled, or
rejected) {T2S.17.080} for more than the “Archiving time” parameter {T2S.17.090} and
their related dynamic data and static data (e.g. settlement transactions, traded ISIN,
securities positions and cash balances…) {T2S.17.080}.
Remark: The detailed content of the dynamic and static data to be archived may depend on the legal
analysis and may be different for each CSDs or NCBs {T2S.17.070}. Those “Archiving rules” are
checked in the static data entities which still have to be defined according to the future requirements.
Logical deletion and archive files creation
Once the extraction of data to archive is done, the function:
• Deletes logically {T2S.16.280}:
-
the data with a validity date oldest than the “Archiving time” parameter;
-
the data history and data revision oldest than the “Archiving time” parameter;
• Creates an archive file per CSDs and NCBs with:
-
The relevant extracted data;
-
An associated index116 to facilitate future search on the archived data;
-
The applicable archive duration indicated in the “Archiving rules” {T2S.17.110};
• Seals those archive files before their sending in order to ensure their integrity until their actual
archiving;
• Sends all the created archive files to the Data Archiving function.
Archiving process tracking
To keep track of the archiving process, the function stores for each archive file the:
• Concerned archiving date;
• Status (“Created”, “Sent for archiving”, “Cancelled” or “Archived”);
• Creation and archiving dates;
On receipt of the acknowledgement from the Data Archiving function, the function switches the status
of the considered archive files to:
• “Archived” in case of successful archiving;
• “Cancelled” in case of failed archiving.
If case of failure (status “Cancelled”), the function launches a new extraction for the considered data
end resent it to the Data Archiving function.
116
The detailed index rule will be defined during the next specification phase with the detailed contents of archived data.
Final_T2S_GFS_110.doc
Page 495
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
Once all the archive files of an archiving date takes the status “Archived”, the function sets this
archiving date as “Archived” to prepare the physical deletion done by the Data Physical Deletion
function.
2 – Data Archiving
Triggered by an archive file received from the Data Extraction for Archiving function, the function:
• Unseals the received archive file and its associated index;
• Archives the archive file for duration defined in the applicable archiving rules and indicated in
the metadata of the archive file;
• Sends to the Data Extraction for Archiving function {T2S.16.300}:
-
A positive acknowledgment in case of success;
-
A negative acknowledgment in case of failure.
3 – Data Physical Deletion
Triggered by an “Archived Data Physical Deletion” event from the Scheduling, the function:
• Searches the archiving date to physically delete117;
• Checks if the related archiving date has the “Archived” status (i.e. all the archive files of the
considered archiving date have been successfully archived);
• Proceeds to the actual physical deletion of the static and dynamic data occurrences which
have been previously logically deleted by the Data Extraction for Archiving function during the
considered archiving date {T2S.16.300} {T2S.17.100}.
4 –Archived Data Extraction
This function is triggered by an “Archive Request” from the Interface {T2S.17.120} which is
received after a request sent with the U-2-A or A-2-A interfaces by a CSD, a NCB or a T2S operator118.
On this request, the function realises a first check to control if:
• The CSD, NCB or T2S operator is authorised to access to the requested archived data;
• The type of requested archived data corresponds to a type of archived data for this CSD or
NCB by checking the applicable archiving rule.
Depending of this first check result, a positive or negative “Acknowledgment” is sent to the Interface
to inform the requester.
In case of successful first check, in a second step and in a maximum period of 3 days {T2S.17.130},
the function extracts the requested archived data by:
117 The parameter used will be defined in the next specification phase. It can allow a physical deletion following the actual archiving or several
days after.
118 Only CSDs, NCBs and T2S operators have direct access to archived data via interfaces. The other parties request their CSD for retrieval and
communication of archived data under message file or report format
Final_T2S_GFS_110.doc
Page 496
T2S General Functional Specifications
Functional Description
Statistics, Queries, Reports and Legal Archiving
• Searching the relevant archive file with the help of the index;
• Extracting the requested archived data from the considered archive file;
• Editing the requested archived data to prepare their restitution to the requester;
• Creating the restitution file;
Once all those steps have been successfully performed, the function sends the restitution file to the
Archived Data Restitution function.
5 – Archived Data Restitution
On receipt of the restitution file and in a maximum of 3 days after the reception of the request
{T2S.17.130}, the function:
• Makes available the considered restitution file to the requester119;
• Sends a “Requested archived data availability” information to the Interface in a way to inform
the requester of the availability of the restitution file in T2S.
Once the requester has received this message, it can get back the restitution file via both U2A and
A2A modes.
6 – Archived Data Purge
During the maintenance window of each settlement day, on reception of an “Archive Purge” event
from the Scheduling, the function checks the archived files for which the archiving duration is reached
and purges them {T2S.17.110}. The archiving duration can be different for each CSDs or NCBs
{T2S.17.070}.
Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
Archiving Event
In
Received daily during the
maintenance window to
launch the extraction of data
from the operational data
store and their archiving
Archived Data
Physical Deletion
Event
In
Received daily during the
Scheduling
maintenance window to
launch the physical deletion of
previously archived and
logically deleted data in the
T2S operational data store
Archiving Purge
Event
In
Received daily during the
maintenance window to
launch the deletion of
archived files which have
reach their archiving duration
119
TO
Scheduling
Scheduling
The process for the availability will be detailed during the next specification phase.
Final_T2S_GFS_110.doc
Page 497
T2S General Functional Specifications
Functional Description
Operational Services
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Archiving Request
In
Received after the reception of Flow
a request for archived data
Management
sent by a CSD, a NCB or a
T2S Operator via the U-2-A or
A-2-A interfaces
Acknowledgement
Out
Sent to inform the requester of
the successful or failure result
of the first check on its
request
Flow
Managemen
t
Requested Archived
Data Availability
Information
Out
Sent to inform the requester of
the availability of the
restitution file which it can get
back via the U-2-A or A-2-A
interfaces
Flow
Managemen
t
Data accessed by the module
DATA
ACCESS MODE
COMMENT
STATIC DATA
DYNAMIC DATA
Archiving rules
Read
Still to be defined according to the
future requirements on the detailed
contents of archived data and their
duration
Archiving Date
Write
To follow the archiving process of an
archiving date
Archive file
Write
To follow the archiving process of each
archive file associated to an archiving
date
3.8. Operational Services
3.8.1. General Introduction
The operational services domain provides a number of functionalities to the T2S System User. It is
split up in four modules:
• Scheduling;
• Operational Monitoring;
• Data Migration;
• Billing.
Final_T2S_GFS_110.doc
Page 498
T2S General Functional Specifications
Functional Description
Operational Services
Scheduling
The Scheduling module is responsible for managing the T2S operating day schedule as well as the
business date change process. Upon reaching the scheduled execution time for a given event (and
provided all predecessor events have been completed), a message is relayed to the relevant modules
in order to trigger the related processes.
The Scheduling module also offers features to manually modify the daily schedule (e.g. by changing
an event’s scheduled time) and the T2S closing days. Finally, the module responds to requests from
the Query module by providing information on the daily schedule.
Operational Monitoring
The Operational Monitoring module provides tools for monitoring, information provisioning and realtime problem detection on both operational and functional levels. The module is mainly used by the
T2S operator, but also offers services for other T2S system users, for instance online access to the
Trouble Management System, which provides information on incidents/problems and the related
investigation and resolution processes.
The module also registers information useful for the measurement of the Key Performance Indicators
(used for Service Information reporting and Monthly Service Management) as well as providing
information to the crisis manager for decision-making.
Data Migration
The Data Migration Module covers the need to migrate the major part of relevant data from the
securities settlement systems of the respective CSDs and relevant data from NCBs to T2S. This will
include static data as well as dynamic data to create the initial positions.
The Data Migration Module is used for setting up test environments, before go-live of T2S and in later
migration windows.
Billing
The T2S Billing Module produces the invoices for all CSDs in a monthly cycle covering the period of
one month’s activities. They are distributed in an electronic form after the completion of the last
business day of the month.
T2S Parties (i.e. individual CSD participants) are invoiced by the respective CSDs based on the
information provided by T2S and complemented by additional data possessed by the CSDs.
Final_T2S_GFS_110.doc
Page 499
T2S General Functional Specifications
Functional Description
Operational Services
3.8.2. Operational Monitoring
3.8.2.1. Diagram of the module
Final_T2S_GFS_110.doc
Page 500
T2S General Functional Specifications
Functional Description
Operational Services
3.8.2.2. Description of the module120
The aim of this module is to support the T2S operator {T2S.20.040} and, for some specific tasks,
other T2S system users (e.g. online access to the Trouble Management System for CSDs and
authorized T2S parties {T2S.20.070}) in the monitoring of the T2S platform, from two different
angles:
• operational monitoring, i.e. detection of functional or operational problems in real-time,
monitoring related to the SLA indicators, and information provisioning for crisis management
scenarios;
• technical monitoring, i.e. detection of hardware and software problems via real-time
monitoring of all the technical components involved in the processing, including the network
connections.
More into detail, the main objectives of the Operational Monitoring module are:
• to observe the behaviour of the T2S platform in operation and to detect changes that can
happen over time, ensuring that in case abnormal behaviour is detected, an alert is raised at
the appropriate level of priority at the earliest point in time {T2S.20.130};
• to provide aggregated up-to-date report of the monitoring information to be routed and used
for problem determination and solving by the appropriate team in the organisation of the T2S
operator {T2S.20.140};
• to notify the T2S operator about the status of the platform in order to trigger the appropriate
corrective actions;
• to register any information useful for the measurement of the Key Performance Indicators in
order to produce Service Information reporting {T2S.20.110} and Monthly Service
Management Information reporting {T2S.20.100};
• to provide information about the status of an incident/problem, its history log and the related
analysis and solution {T2S.20.070};
• to provide up-to-date, meaningful and comprehensive information to the crisis manager for
the decision making process.
As far as the way the T2S operator gains access and interacts with the operational monitoring tools is
concerned, it has to be highlighted that specific interfaces and authentication and authorisation
mechanisms are used, owing to the specific technical architecture and features of such tools
(therefore, the “dedicated T2S operator interface” should not be understood as an additional
dedicated interface for the T2S operator but rather as specific interfaces coming from the use of
specific technical tools).
120
Owing to the specificity of this module, dedicated to the operational monitoring of the platform, the description of its functions is more
focused on the technical features and the type of information provided for this purpose, rather than detailing the business logic of such
functions.
Final_T2S_GFS_110.doc
Page 501
T2S General Functional Specifications
Functional Description
Operational Services
The information coming from T2S is integrated with other external sources of information, in order to
obtain a meaningful overview in crisis management. For this purpose the Operational Monitoring
module integrates the information coming real-time from T2S with the news and markets data feed
provided by financial channels.
3.8.2.3. Description of the functions of the module
1 – Data integration and extraction
The aim of this function is to integrate data coming from different sources (“short-term” statistical
information repositories and external data sources), extracting, merging and organising data in the
format required for the presentation to the T2S system users both in push and pull mode (e.g. raising
alarms or answering to specific requests), in order to monitor the operational and technical status of
the T2S actors and to collect data about the performance of the platform for the real time verification
of the respect of the agreed service levels.
Data retrieval for the purposes of Service Information reporting and Monthly Service Desk
Management Information reporting is also integrated in this function.
The function uses the data stored in the “short-term” statistical information repositories to compare
the current behaviour of the platform (and of its components) with a set of predefined thresholds and
with data related to the last three months, in order to signal to the T2S operator any deviation from
the normal expected behaviour. In what follows, a non exhaustive possible list of key indicators for
different T2S components is described, together with the criteria used to raise alarms for the T2S
operator, when applicable. The following list is tentative and should not be considered exhaustive; the
final list will be detailed in the DFS.
Final_T2S_GFS_110.doc
Page 502
T2S General Functional Specifications
Functional Description
Operational Services
Overall T2S monitoring
Indicators belonging to this area provide information on the different message flows and ongoing
processes in T2S. For instance:
Transit time - CSD xyz, DVP instructions
60
50
Transit Time
40
30
20
10
10.30
10.20
10.10
10.00
9.50
9.40
9.30
9.20
9.10
9.00
8.50
8.40
8.30
8.20
8.10
8.00
7.50
7.40
7.30
7.20
7.10
7.00
0
• Instruction transit time - The aim of this indicator is to monitor the trend of instructions
processing within the platform during the operating day. It is defined as the maximum
interval, measured in 1 minute, between the arrival of the relevant input message and the
dispatch of the related notification. Instructions not processed for legitimate reasons are
excluded. In case of irregular and excessive increase of the concerned value, an alarm is
raised. The following diagram provides an example showing the transit time related to a
specific CSD and instruction type.
• Incoming / outgoing messages – These indicators are defined as the number of messages
arrived to (or sent from) the platform within the last x minutes/hours. If these figures differ by
a certain amount from the pre-defined reference thresholds, an alarm is raised. The following
diagram provides an example showing the incoming and outgoing message related to a
specific CSD and message type for the current operating day.
Final_T2S_GFS_110.doc
Page 503
T2S General Functional Specifications
Functional Description
Operational Services
Message throughput - No. of DVP Instructions for CSD XYZ
700
600
500
400
300
200
Sent
100
Received
22.00
21.00
20.00
19.00
18.00
17.00
16.00
15.00
14.00
13.00
12.00
11.00
10.00
9.00
8.00
7.00
6.00
5.00
4.00
3.00
2.00
1.00
0
• Most active T2S parties. This indicator provides the list of the x most active T2S parties, based
on different parameters (e.g. number of settled instructions, total settled amount, number of
sent messages).
• Network alarms. Several alarms can be defined in order to cope with many different network
problems. For instance, specific alarms can be raised when:
-
there are messages that can not be sent from the platform to the network (i.e. an
acknowledgement from the network is still missing);
-
the connection with TARGET2 (or other RTGS systems) or CCBM2 (or other collateral
management systems) is not working properly (i.e. there are messages that can not
be sent from the platform to the external system or vice versa);
-
the dedicated connection with a CSD or a directly connected participant is not working
properly121.
Scheduling domain monitoring
Monitoring in this area provides information about the current T2S business status, i.e. detailed
information about planned, revised and actual timestamps of the scheduled events. Appropriate
alarms are raised when events are not triggered/reached/completed by the foreseen deadline.
Liquidity management domain monitoring
Indicators belonging to this area provide information concerning liquidity availability and usage within
the platform throughout the operating day. For instance:
121 For this kind of connections (including the ones related to TARGET2, CCBM2 and other external systems) it is envisaged to develop
watchdogs that periodically check the relevant connections.
Final_T2S_GFS_110.doc
Page 504
T2S General Functional Specifications
Functional Description
Operational Services
• Available liquidity. This indicator shows the amount of available liquidity per NCB and/or
currency. The following diagram provides an example showing the trend of the available
liquidity for a specific NCB, compared with the money market rates.
2,07
20.000.000
2,06
18.000.000
2,05
16.000.000
2,04
14.000.000
2,03
12.000.000
2,02
10.000.000
Money market
rates
2,01
2
8.000.000
6.000.000
Liquidity
available
1,99
4.000.000
1,98
2.000.000
1,97
0
7.00
8.00
9.00
10.00
11.00
12.00
13.00
14.00
15.00
16.00
17.00
18.00
• Intraday liquidity. This indicator provides information concerning the usage of intraday
liquidity during the operating day and can be helpful in order to have an early warning of
possible problems in the flow of liquidity.
• Most active payment banks. This indicator provides the list of the x most active payment
banks, based on different parameters (e.g. number of settled payments, total settled amount,
and number of sent messages).
Settlement domain monitoring
Indicators belonging to this area provide information on the T2S settlement engine. For instance:
• Last transaction settlement timestamp. If the time span between this indicator and the current
time is greater than a given threshold (that can be different for different time periods of the
operating day), an alarm is raised.
• Securities settlement volume. This indicator is calculated both in absolute figures (number of
settled instructions) and percentages (based on the total number of instructions processed by
T2S).
• Securities settlement amount. This indicator is calculated both in absolute figures (total settled
amount) and percentages (based on the total amount related to instructions processed by
T2S).
• Optimization algorithm performance. It refers to information about the current status of the
algorithm and its performance (processing time and number of settled transactions per each
iteration).
Lifecycle management and matching domain monitoring
This area provides a view on the lifecycle of an instruction, graphically representing the different paths
that a settlement or maintenance instruction can take through the system. For each lifecycle status,
Final_T2S_GFS_110.doc
Page 505
T2S General Functional Specifications
Functional Description
Operational Services
an indicator displays the volume of instructions currently in that status for the operating day. If one or
more of these indicators reach an abnormal value compared to the total an alarm is raised.
Trouble management system monitoring
Indicators belonging to this area provide information on the performance and workload of the Trouble
Management System, e.g.
• Trouble management performance. This indicator measures, for each trouble case category
(request/incident/problem), the average time between the opening and closure of a trouble
case. Indicators are also separated by case priority.
• Trouble cases volume. This indicator measures the amount of cases in a status other than
“closed” in any given moment. Cases are organized by category.
• Maximum resolution time. This indicator monitors the time span from the opening of the
oldest non-closed case. If this value surpasses a set threshold (which is defined separately for
each case category), an alarm is raised.
2 – Operational data and status presentation
This function presents the output of the monitoring activity in an organised and human-readable form
to the T2S operator, according to the following features:
•
Delivery. Data delivery and updates are processed in real-time push mode, without
additional delay, filtering, aggregation or other processes that could affect the quality of
data.
•
Interfaces. The T2S operator can access data using a web browser and/or a native client.
•
Formats. The relevant formats are pages (plain text information), tables and graphs.
•
Comparative monitoring. It is possible to plot different time series in the same screen.
•
Data integration. The tool can integrate data from internal and external sources.
•
Customise front-end. The presentation of data can be customized by the T2S system
user.
•
Print. It is possible to print the information displayed in the pages/grids/charts
•
Export. It is possible to export data as plain and/or formatted text for further processing
with other tools (e.g. MS Office applications).
•
Alarms. The application can generate alarms triggered by the crossing of configurable
thresholds; the triggered alarms remain active as long as the relevant triggering condition
is present. It is also possible to view a history log of all raised alarms, including their start
and end timestamps.
Reports related to Service Information reporting and Monthly Service Desk Management Information
reporting are provided in this function and are based on the data retrieved by the Data integration
Final_T2S_GFS_110.doc
Page 506
T2S General Functional Specifications
Functional Description
Operational Services
and extraction function. While these data are extracted automatically by the function, it is also
possible for the T2S Operator to integrate them with qualitative information and comments.
3 – Technical monitoring and compare
This function provides the T2S operator with the possibility to monitor every single component of the
platform with real-time information. The information provided helps the T2S operator to identify any
malfunction in the platform; the available information is role-based, with different data and levels of
detail shown depending on the user profile. Moreover, this information is detailed enough to allow the
T2S operator to understand the business impact of the malfunction and the related technical.
This function is also able to provide the T2S operator with hints as to the actions to be taken to solve
the relevant incident.
Information (e.g. operational and technical status, alarms) can be presented as grouped at different
levels (i.e. entire platform, domain, module, function).
4 – Technical status presentation
This function provides a graphical display of the T2S processes and indicators in order to provide a
global view on the whole system for monitoring purposes. From an aggregated view of the processes
it is possible to focus on a single process or sub-process and obtain specific status displays with
increasing levels of detail. When an alarm is raised, the relevant process in the technical status view
immediately displays an alert; by opening the detailed view it is possible to read the alert message
and receive preliminary information on the event that triggered it. Finally, it is possible to
automatically send e-mail notifications to operators when an alarm is raised.
5 – Trouble case maintenance
This function encompasses aspects related to the management and processing of trouble cases via a
specific Trouble Management System (TMS) application. Trouble cases may be defined as:
•
Service request: a case opened to submit requests to the support teams, usually for
information on any specific issue or to request interventions that are part of standard
operation (e.g. running specific applications or issuing new user passwords). Request
cases are not linked to interruptions or reductions in the quality of the service.
•
Incident: a case reporting any event which does not fall within standard operation and
causes an interruption or reduction in quality of the service. The resulting intervention is
limited to the individual Incident and the case is closed upon restoring normal service
operation; further investigations and interventions, if necessary, may be carried out by
opening a linked Problem case.
•
Problem: a case opened to further the analysis related to one or more Incidents after
they have been closed, normally to investigate the underlying cause and minimize or
nullify possible future impacts.
Final_T2S_GFS_110.doc
Page 507
T2S General Functional Specifications
Functional Description
Operational Services
Regardless of their category, all Trouble cases are identified by a Case ID number along with
information detailing the specific case. A specific field displays the status of the case (whether it is a
newly opened case, assigned to a specific support unit, being worked on, resolved or closed) and the
team it is currently assigned to for treatment. Each case will record timestamps for each intervention,
most notably for its opening and closure. A “security impact” flag is available to mark the cases which
have potential bearing on security issues. Finally, it is possible to categorize tickets by increasing
levels of priority, depending on the urgency of the matter, the impact on the system’s functionality
and the timeframe by which a solution is expected.
6 – Trouble case access
This function allows read-only access to Trouble cases, for informational purposes, to all actors linked
to a specific Trouble Case. While direct interventions on Trouble Cases are performed by the T2S
Operator, this function allows all involved parties to constantly monitor the status of the case.
3.8.2.4. Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Pull data request
In
Request from T2S Actor
Interface
Data integration
and extraction
Pull data request
In
Request from T2S Operator
Dedicated T2S
Operator Interface
Technical
Monitoring and
compare
System status
In
Information on the system status
for monitoring and diagnostic
purposes
Technical
infrastructure
Technical
Monitoring and
compare
Status request
Out
Request for information on the
system status
Technical
Monitoring and
compare
Technical
infrastructure
Alert/Display/Report
Out
Information sent to the T2S Actor
via Interface
Technical Status
presentation /
Operational Data
and Status
presentation
Interface
Trouble case
maintenance request
In
Information needed to maintain
(i.e. to create, update or delete) a
trouble case.
Dedicated T2S
Operator Interface
Trouble case
maintenance
Trouble case
Out
maintenance response
Information concerning the result
of a specific trouble case
maintenance request
Trouble case
maintenance
Interface /
Dedicated T2S
Operator Interface
Trouble case access
request
In
Information needed to retrieve a
specific trouble case
Interface /
Dedicated T2S
Operator Interface
Trouble case
access
Trouble case access
response
Out
Information concerning a trouble
case to be sent to the T2S Actor
or the T2S Operator
Trouble case
access
Interface /
Dedicated T2S
Operator Interface
Final_T2S_GFS_110.doc
Page 508
T2S General Functional Specifications
Functional Description
Operational Services
3.8.2.5. Data accessed by the module
DATA
ACCESS MODE
STATUS
COMMENT
STATIC DATA
Short-term
Statistics
Read
Short-term
statistical data to
support the T2S
operator for the
proper
management of
the system.
External Data
Read
Information from
external sources to
complement T2S
data, such as news
and markets data
feeds
DYNAMIC DATA
Short-term
Statistics
Read
Short-term
statistical data to
support the T2S
operator for the
proper
management of
the system.
External Data
Read
Information from
external sources to
complement T2S
data, such as news
and markets data
feeds
3.8.3. Data Migration
3.8.3.1. Data Migration (MG) use cases
Scope
This category of use cases covers the initial data migration situation where the CSDs transfer all their
relevant data to the T2S system. Both static and dynamic data transfer is covered, i.e. party master
data, securities account data, securities positions, securities master data and the BIC directory.
Criteria
The criteria characterising the migration use cases are summarized in the table below:
CRITERIA
Communication mode
Final_T2S_GFS_110.doc
POSSIBLE VALUES
U2A, A2A
DESCRIPTION
See glossary
Page 509
T2S General Functional Specifications
Functional Description
Operational Services
Data transfer channel
Standard Channel for Transactions/Instructions,
Manual User Entry, Upload
Channel via initial data migration
take place
Transferred data
Party Master Data, Securities Account Data,
Securities Positions, Securities Master Data, BIC
Directory
Type of transferred data
List of Use Cases
The criteria described above are reported in the following tree:
Data Migration
U2A
Standard Channel
for Transactions/
Instructions
Party Master Data
Securities Account
Data
A2A
Manual User Entry
Securities Position
Upload
Securities Master
Data
BIC Directory
All the combinations of values are not relevant from a business point of view: the complete list of use
cases is presented in appendix.
3.8.3.2. Processing of Data Migration use cases
Considering the high regularity of the Data Migration process, only one representative use case is
defined.
Final_T2S_GFS_110.doc
Page 510
T2S General Functional Specifications
Functional Description
Operational Services
Processing of UC-MG-1: Upload of Party Master Data
Sequence Diagram Data Migration
Interface
OPSR:
Data Migration
T2S System user
Flat file / Excle file
Alt
[negative answer]
Rejection message
[positive answer]
Flat file / Excle file
Alt
Error data
(Data Migration)
[negative answer]
Response (Error message)
[positive answer]
Migration success
report
Migration success report
Business assumption
A CSD submits one of its participant’s party master data for the integration into T2S.
Processing
The CSD submits its participant’s party master data to T2S, including all relevant information about
the institution (e.g. name, address, legal form and other relevant attributes).
An excel/flat file enters the Interface. In the Interface the excel/flat file passes several technical
validations and checks.
•
In case of a negative result the process is stopped and a rejection message is sent to the
T2S System user;
Final_T2S_GFS_110.doc
Page 511
T2S General Functional Specifications
Functional Description
Operational Services
•
In case of a positive result the Interface forwards the excel/flat file to the module Data
Migration.
Within this module, the function “Data Entry” identifies the data as party master data and forwards it
to the function “Convert Migration Data” which converts the party master data into the T2S format.
Afterwards the converted data is transferred to the “Validation Check” function. This function checks
whether the incoming migration data comply with the requirements of the system.
•
Validation check is negative: The function sends the negative validation result to the
“Error Handling” function. This function identifies the reason of the failure forwards the
error data to the interface. The Interface sends a response (error message) to the
initiating T2S System user.
•
Validation check is successful: The module Data Migration stores the converted party
master data in the Static Data data store.
-
If the storage of the data fails, the “Error handling” function sends a response (error
message) to the initiating T2S System user via the Interface;
-
Otherwise it generates a Migration success report and transfers it to the T2S System
user via the Interface.
Final_T2S_GFS_110.doc
Page 512
T2S General Functional Specifications
Functional Description
Operational Services
3.8.3.3. Static functional description
Diagram of the module
Description of the module
The Data Migration Module covers the need to migrate the major part of relevant data from the
securities settlement systems of the respective CSDs and relevant data from NCBs to T2S. Static data
as well as dynamic data like account balances which are needed to build the initial position (like
securities positions) will be imported to T2S.
Final_T2S_GFS_110.doc
Page 513
T2S General Functional Specifications
Functional Description
Operational Services
The Data Migration Module is used for different situations:
•
for setting up test environments,
•
before go-live of T2S, and
•
before an additional CSD joins T2S (e.g. in later migration windows).
Before a CSD or an NCB is able to upload migration data it has to be registered within T2S by T2S
operators. Any kind of means is envisaged: flat file, excel file, paper and in any case a GUI to key in
or correct the static data in the T2S system. The Data Migration Module enables the CSDs and NCBs
to transfer securities account data, party master data, securities positions, securities master data and
account balances to T2S. Besides that, the BIC directory can be uploaded from the relevant source.
Thus, the description of the Data Migration deals mainly with static data. Nevertheless, this module
supports also the migration of dynamic data like securities positions {T2S.21.320}. The instructions
which are pending at the point of migration will be carried over to T2S by the affected CSDs via
normal settlement instructions. This is not part of the Data Migration.
Data Migration is not provided to directly connected participants but only to the CSDs, as they keep
the respective data (securities account data, securities positions, securities master data). Also the
party master data of all existing and future CSD participants can be uploaded from the CSDs.
There will not be a migration of any historical data of the CSDs.
The Data Migration Module consists of three functions (Data Entry, Convert Migration Data and
Validation Check and Store Migration Data) which provide migration functionality to participating
CSDs. Furthermore, an additional error handling function provides information about where and in
which way errors have been occurred.
The Data Migration Module supports the transfer of data from the CSDs and NCBs to T2S and
potentially to T2 regarding the cash accounts. {T2S.21.280} Hereby, the specific needs for multi
market group of CSDs are considered (i.e. a group of CSDs will migrate in one shot). However, this
will be further described at later stages of the project.
The Data Migration Module is able:
•
to receive Flat files and migrate the data into a T2S data store and
•
to receive Excel files and migrate the data into a T2S data store.
In addition, the migration can take place via the standard channel of communication. {T2S.21.290}
The CSDs and NCBs can enter their respective data directly using a Graphical User Interface.
Additional specific migration tools are determined by dedicated project teams during the process of
the migration period. This is e.g. the case for high volume data files structure and processing to
establish the instructions, transactions and securities data store for the CSDs. {T2S.21.300}
Final_T2S_GFS_110.doc
Page 514
T2S General Functional Specifications
Functional Description
Operational Services
Technical resources are provided in the T2S development area to address the requirements of the
specific migration tools at the earliest and to develop these tools and carefully test them before the
first migration. {T2S.21.310}
A standard fall-back plan is established and made available before the first migration period
{T2S.21.180}. The fall-back plan and the roll-back procedures are tested before the migration
starts. {T2S.21.245}
Description of the functions of the module
1 – Data entry
The Data entry function deals with static and dynamic data which have to be imported to T2S. This
includes party master data, securities account data, securities account balances data and securities
master data and the BIC directory.
CSDs are provided with standardised input tables for all migration data. The CSDs are responsible for
the mapping of their data from internal structures to the T2S input table structure. Before the
migration process starts, T2S is initialized. Automatic procedures are used for this. This will be further
described at later stages of the project.
The Data entry function receives and validates flat files, excel files and data via GUI from the Flow
Management. If a business validation error occurs (e.g. if some ISINs in one uploaded Excel file
contain invalid prefix), the failed data is sent to the Error Handling function. The positive validated
migration data is forwarded
•
to the Convert Migration Data function in case of flat files and excel files
•
to the Validation Check and Store Migration Data function in case of data entered already
in T2S data format via GUI.
Import Party Master Data
This sub function imports the relevant data of the T2S parties of the participating CSDs. This includes
the name, address, legal form and all other relevant attributes.
Import Securities Account Data
•
The complete securities account data of the participating CSDs is transmitted to T2S by
this sub-function.
Import Securities Positions
The securities positions as settled transactions are transferred to T2S by this sub function.
The handling of pending instructions is foreseen as follows: At the end of the last business day before
the start of the migration, there are still settlement instructions in the system of the CSDs, which have
not been settled and would normally be recycled or settled later on schedule. These instructions will
be sent to T2S as new settlement instructions using the standard communication channels.
Final_T2S_GFS_110.doc
Page 515
T2S General Functional Specifications
Functional Description
Operational Services
(Otherwise, the procedures for the migration of pending instructions would have to take into account
the different instruction status, priorities, interdependencies between different instructions and other
points which is expected to be as a much more difficult handling for the lifecycle management of
T2S.)
Import Securities Master Data
This sub function enables the migration of all the security master data which is available on the
market into T2S. The data will be imported by one or more external providers.
Import BIC Directory
This sub function imports the SWIFT BIC Directory.
2 – Convert Migration Data
The Convert Migration Data function converts the migration data coming in from the Data Entry
Function via standardised input tables into the T2S data format. If an error occurs during the
converting process only the relevant failed data is sent to the Error Handling Function. The converted
migration data in T2S format is sent to the Validation Check and Store Migration Data Function.
3 – Validation Check and Store Migration Data
The Validation Check and Store Migration Data Function receives the migration data in T2S format
from the Convert Migration Data Function or the Data Entry Function. It checks if the conversion was
successful (e.g. whether the data are readable) and complies with the requirements of T2S. In this
case, the function also stores only the successfully converted data in the respective Static Data data
store and sends a success report to the Flow Management. If an error is detected the relevant failed
data is sent to the Error Handling Function.
4 – Error Handling
The Error Handling function receives all failed data identified in one of the other functions (Data Entry,
Convert Migration Data and Validation Check and Store Migration Data) of the module, i.e. all the data
which could not be migrated successfully including the reason of the failure. It analyses the failed data
and sends error data to the Flow Management covering all relevant information.
Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Flat File
IN
Flow Management
Excel File
IN
Flow Management
Data via GUI
IN
Flow Management
Success Report
OUT
Flow Management
Error data (Data
Migration)
OUT
Flow Management
Final_T2S_GFS_110.doc
Page 516
T2S General Functional Specifications
Functional Description
Operational Services
Data accessed by the module
DATA
ACCESS MODE
Securities Account Data
Read/ Write
Party Master Data
Read/Write
Securities Positions
Read/Write
Securities Master Data
Read/Write
BIC Directory
Read/Write
STATUS
COMMENTS
3.8.4. Events
3.8.4.1. Events use cases
Scope
This category of use cases describes the possible uses of the scheduling module.
Criteria
The type of action required is the sole relevant criterion and the possible values are:
CRITERIA
Action Type
POSSIBLE VALUES
Operating Day Management, Daily Scheduler
COMMENT
Type of request to be processed.
3.8.4.2. Processing of Events use cases
The processing of the following representative use cases is described:
•
UC-EV-1 Operating Day Management
•
UC-EV-2 Daily Scheduler
Processing of UC-EV-1 Operating Day Management
This use case allows a T2S Operator inserting/updating/deleting event instances in the daily planner,
where the operating day is identified in terms of event instances planned for the specified business
date to be triggered.
For the new instance of a specific event inserted it is possible to update the time schedule. The
update is allowed not only for a single event but also for a set of instances.
The T2S Operator can delete the event instance planned for the current business date from the time
schedule.
Final_T2S_GFS_110.doc
Page 517
T2S General Functional Specifications
Functional Description
Operational Services
Business assumption
As far as operating day management use case is concerned, one possible scenario is identified with
three possible types of request: insert, update and delete of planned event.
Processing
The following sequence diagram details the scenario:
Processing of UC-EV-2 Daily Scheduler
On a regular basis, events to be triggered are identified and they are notified to the relevant modules.
Business assumption
The actual date/time for an event is reached122.
122 The actual triggering time of an event might be different from the planned scheduled time owing to the presence of predecessor events
not yet completed (see the description of the Daily Scheduler function for more information).
Final_T2S_GFS_110.doc
Page 518
T2S General Functional Specifications
Functional Description
Operational Services
Processing
When the actual date/time of an event is reached, the event is notified to the interested module, so
that it can trigger the relevant process. Upon completion of the process, the interested module
notifies back this information to the Scheduler.
Final_T2S_GFS_110.doc
Page 519
T2S General Functional Specifications
Functional Description
Operational Services
3.8.4.3. Scheduling
Diagram of the module
Description of the module
The Scheduling module is in charge of managing the operating day events and the daily business date
change in T2S {T2S.11.020} {T2S.11.040}. The daily schedule is generated by the Daily Planner
function at each business date change, taking into account the Business Day Type and the Default
Event Schedule entities. A portion of each day’s events is also generated dynamically throughout the
business day depending on information received from other modules.
Besides the scheduled time, each event is characterized by its priority dependencies with other events
of the same business day schedule {T2S.11.040}. If present, a dependency can suspend the
execution of the successor event (and the related processes) until the predecessor events are
completed123. During normal activity, these dependencies have priority over the actual scheduled time
of the events; i.e. if event A is a predecessor and event B is a successor, the latter must wait for the
completion of the former even if this means starting past its scheduled time.
123
By completion of an event is meant the completion of the process triggered by the event itself.
Final_T2S_GFS_110.doc
Page 520
T2S General Functional Specifications
Functional Description
Operational Services
Planned events can be either time-activated (started simply upon reaching the planned time) or
sequenced (started upon reaching the planned time and following completion of all predecessors).
Furthermore, unplanned events may be generated by other modules and inserted into the daily plan
throughout the day.
Events can also be related to processes that need to be triggered on a timed basis within other
modules or within an external workload manager application. The Scheduling module does not directly
activate these processes; its scope is limited to generating and sending to the relevant module a
notification that a certain event has been reached. The related processes are then managed by the
appropriate module. Once the scheduled time for an event is reached (and all the predecessor events
are completed), the Daily Scheduler generates a time event and routes it to the relevant module (or
within the Scheduling module) in order to trigger the related processes. Depending on the event type,
the Scheduling module might also expect a notification from the relevant module once the processes
are complete.
T2S has an internal business date, independent of the system date in the operating system
{T2S.11.005}. It is possible for the T2S operator to manually change the T2S Closing Days in order
to skip certain business dates {T2S.11.010}; furthermore, the T2S operator is able to modify the
current business day event schedule at run-time, by inserting, updating, time-shifting and deleting
event instances. In the T2S production environment, manual interventions which influence the
business date will be limited to business contingency situations.
Below is a tentative list of the possible events that may appear on the daily schedule. Note that the
following list should not be considered exhaustive:
CATEGORY
EVENT TYPE
DESTINATION DOMAIN:MODULE
Planned sequenced events
EoD
LCMM: Instruction Maintenance
Planned sequenced events
SoD
LCMM: Instruction Validation
Planned sequenced events
SoD
LCMM: Settlement Eligibility
Planned sequenced events
EoD
LCMM: Settlement Eligibility
Planned time-activated events Matching Allegement Sending
LCMM: Settlement Eligibility
Planned time-activated events Linked Instructions Eligibility Control LCMM: Settlement Eligibility
Planned time-activated events Check if time for
standing/predefined orders is
reached
LCMM: Liquidity Control
Planned sequenced events
End of each night-cycle
LCMM: Status Management
Unplanned events
Time Event - Order Management
LQMG: Liquidity Control
Planned sequenced events
End of each night-cycle
LQMG: Liquidity Control
Planned sequenced events
DVP Cut-off
LQMG: Liquidity Control
Planned sequenced events
Beginning of Day-time
LQMG: Liquidity Control
Planned sequenced events
Liquidity Transfers EoD finished
LQMG: NCB Business Procedures
Final_T2S_GFS_110.doc
Page 521
T2S General Functional Specifications
Functional Description
Operational Services
CATEGORY
EVENT TYPE
DESTINATION DOMAIN:MODULE
Planned sequenced events
End of reimbursement of autocollateralisation
LQMG: NCB Business Procedures
Planned sequenced events
Beginning of Night-time
STTL: Sequencing
Planned sequenced events
Beginning of Day-time
STTL: Sequencing
Planned sequenced events
Cut-off
STTL: Sequencing
Planned sequenced events
EoD
STTL: Sequencing
Unplanned events
Event – Releasing Collateral
STTL: Auto-collateralisation
Unplanned events
Event – Optimisation algorithm
manager
STTL: Recycling and Optimisation
Planned sequenced events
EoD
SDMG: Static Data
Planned sequenced events
EoD – last business day of each
month
OPSR: Billing
Planned sequenced events
EoD
OPSR: Scheduling
Planned sequenced events
EoD
SRQA: Report Management
Planned time-activated events Check if report can be deleted
SRQA: Report Management
Planned sequenced events
Beginning of Day-time
SRQA: Report Management
Planned sequenced events
Beginning of Night-time
SRQA: Report Management
Planned sequenced events
DVP Cut-off
SRQA: Report Management
Planned sequenced events
End of each night-cycle
SRQA: Report Management
Planned sequenced events
Start of each night-cycle
SRQA: Query Management
Planned sequenced events
End of each night-cycle
SRQA: Query Management
Planned time-activated events Check if time is reached for
Statement of Settlement
Allegements
SQRA: Report Management
Planned time-activated events Check if time is reached for Current
Settlement Day Cash Information
Report
SQRA: Report Management
Planned sequenced events
SRQA: Statistical Information
EoD
Planned time-activated events Archiving Event
SRQA: Legal Archiving
Planned time-activated events Archived Data Physical Deletion
SRQA: Legal Archiving
Planned time-activated events Archiving Purge
SRQA: Legal Archiving
Planned sequenced events
Start of Maintenance Window
INTF: Access Management
Planned sequenced events
End of Maintenance Window
INTF: Access Management
Planned sequenced events
Start of Maintenance Window
INTF: GUI
Planned sequenced events
End of Maintenance Window
INTF: GUI
Final_T2S_GFS_110.doc
Page 522
T2S General Functional Specifications
Functional Description
Operational Services
Dynamic data managed by the module
Below is a list of the attributes for the various dynamic data entities and description of the relevant
relationships, as provided in the data model (see the Rules and Parameters Data Management module
for a detailed description of the relevant static data entities).
1 – Operating Day
This entity includes all the information related to events scheduled and occurred in the actual
operating days. New occurrences of this entity are generated upon each business date change by the
Daily Planner function, according to the operating day type and the default events’ schedule
information stored as static data.
ATTRIBUTE
DESCRIPTION
Event Schedule Time
Scheduled time for each Event
Updated Event Schedule Time
Scheduled time for each Event following an update
Event Start Time
Actual start time of the Event
Event End Time
Actual end time of the Event
Each operating day’s occurrence is linked to the relevant event type and business date.
2 – Business Date
This entity defines the current business date. The next current date is calculated by the Business Date
Change function, according to the T2S closing days information stored as static data.
ATTRIBUTE
Current Date
DESCRIPTION
Date of the current operating day.
Each business date is linked to all the relevant operating day’s occurrences.
Final_T2S_GFS_110.doc
Page 523
T2S General Functional Specifications
Functional Description
Operational Services
Description of the functions of the module
At each new business day, the Daily Planner function generates the new schedule and the Business
Date Change function takes care of updating the current Business Date. Throughout the operating
day, the Daily Scheduler function triggers event instances once the scheduled time is reached.
Information to other domains and to the users is provided via the Access to Current Day Schedule
function, while the Operating Day Management and Business Date User Update functions are used for
manual interventions.
1 – Daily Planner function
The Daily Planner function is activated to set up the new business day schedule. At every business
date change, the function creates the new business date time schedule. Upon successful completion
of the procedure, the function generates a positive outcome notification to the module. Combined
with the notification from the Business Date Change function, this marks the successful completion of
the EoD/SoD procedure.
2 – Daily Scheduler function
The Daily Scheduler function has two purposes, described below:
Start Next Scheduled Processes
The function is activated on a regular basis to perform a check and identify the event instances that
have been reached, depending on the current business day schedule. A check is performed both on
the scheduled time and possible predecessors for each event; first, the system time is checked against
the scheduled time for each event. Then, if an event for which the scheduled time has been reached
is of the “Sequenced” type, the Daily Scheduler also checks that all predecessor events have been
successfully completed. Once the relevant time and business conditions are reached, the related event
is generated by the Daily Scheduler function and forwarded to the relevant module or function, so
that
the
related
process
(transaction or
workload
manager
application)
can be
started
{T2S.11.030}. The event instance start time for the current business day is also updated.
Receive Start Next Scheduled Processes
Once a process is triggered, the function receives a notification when said process is completed and
updates the event’s end time value for the current business day accordingly.
Concerning the EoD/SoD procedure, once the EoD cut-off time is reached, the Daily Scheduler
proceeds to generate the EoD time events (each at their own scheduled time, and respecting the
dependencies between them) and to send them to the relevant T2S domains in order to activate the
related EoD processes.
3 – Operating Day Management function
The Operating Day Management function allows the T2S Operator performing manual changes on the
current day schedule. It is possible for the T2S Operator to perform the following operations:
Final_T2S_GFS_110.doc
Page 524
T2S General Functional Specifications
Functional Description
Operational Services
•
Insert a new event instance;
•
Change a single event’s scheduled time (provided it has not been reached yet) by moving
the event forward or backward in the current day schedule. If the updated event is
moved past or ahead of another event, the modification is still carried out and a warning
message is displayed to warn the T2S Operator of this change in priorities. If the event
contains predecessor or successor constraints, these are automatically updated based on
the event’s new relative position in the daily schedule;
•
Time-shift a portion of the daily schedule (i.e. an event and all events following it in the
daily schedule, provided the first event has not been reached yet), without changing their
dependencies;
•
Force completion of an event instance before its actual occurrence. The effect of this
action is simply to generate a notification within the Scheduling module indicating that
the event is complete. The management of the related processes is left entirely up to the
relevant modules. With regards to events which are related to processes triggered by
other modules, two cases are possible. Manual completion can be done when the event
has not yet been reached (in which case the Scheduling module sends no notification to
the relevant module once the scheduled time is reached) or if it is already started but not
yet completed (in which case the event is considered complete by the Scheduling
module, but the actual process is managed by the relevant module). Forcing the
completion of an event causes all dependent events (successors) to be executed as if the
first one had been completed normally. Finally, it is worth to stress that this feature may
be activated exclusively by the T2S Operator and its use is limited to testing and
contingency situations.
4 – Access to Current Day Schedule function
This function provides detailed information on the current day schedule in response to enquiries
performed by T2S Actors or by other domains.
5 – Business Date Change function
This function is activated by an EoD event in the daily schedule. It calculates the new Business Date
increasing by 1 the current one and skipping Saturdays, Sundays and dates included in the entity T2S
Closing Day. Upon successful completion of the procedure, the function generates a positive outcome
notification to the module. Combined with the notification from the Daily Planner function, this marks
the successful completion of the EoD/SoD procedure.
6 – T2S Closing Day User Update function
This function allows the T2S Operator to manually update the values stored in the T2S Closing Day
entity. By doing this the T2S Operator can induce the “Business Date Change” function to deviate
from the usual operating day sequence, specifically to skip certain business dates. The function is
Final_T2S_GFS_110.doc
Page 525
T2S General Functional Specifications
Functional Description
Operational Services
activated by the Interface domain. In the T2S production environment, the use of this function is
limited to business contingency situations.
Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
All domains
TO
Access Scheduling
Information Request
In
Request for information concerning
current business day schedule
Access to Current
Day Schedule
Event Maintenance
Request
In
Manual intervention from T2S operator Interface
or event owner on current business
day schedule
Operating Day
Management
Business Date Update
Request
In
Manual intervention from T2S operator Interface
on next business date
Business Date
User Update
Scheduling
Information Response
Out
Data concerning current business day
schedule
Access to
Current Day
Schedule
All domains
Maintenance Response Out
Outcome of manual intervention
Daily Scheduler
Interface
Business Date Update
Response
Out
Outcome of manual intervention
Business Date
Update
Interface
Event
Out
Event to be delivered to the relevant
domain/module.
Daily Scheduler
All domains
Process completed
notification
In
Notification of process completion
received by the relevant
domain/module.
All domains
Daily Scheduler
Data accessed by the module
DATA
ACCESS MODE
COMMENT
STATIC DATA
Default Event Schedule
Read
Default schedule based on dependencies
between T2S processes
Operating Day Type
Read
Identifier of operating day type. Used to
generate the T2S operating day
schedule
Event Type
Read
Information on the various types of
Operating Day Events
T2S Closing Day
Read/Write
Contains information on the days on
which the T2S system is closed.
Information is organized by date and a
flag to determine whether a closing day
is recurrent (on an annual basis) or a
one-time occurrence. This information is
used in the determination of the new
business date.
Final_T2S_GFS_110.doc
Page 526
T2S General Functional Specifications
Functional Description
Operational Services
DATA
ACCESS MODE
COMMENT
DYNAMIC DATA
Operating Day
Read/Write
Information necessary to manage the
current Operating Day plan. When a
new Operating Day starts, the table is
compiled with the time schedule
extracted from the static data Default
Event Schedule
Business Date
Read/Write
Contains the current business date of
T2S to be provided all over the T2S
system. At each business date change,
the new business date is calculated
increasing by 1 the previous one and
taking into account information from
static entity T2S Closing Day (i.e.
closing days are skipped).
3.8.5. Billing
CAVEAT: The current version of the GFS includes the description of T2S billing functionality. However,
the provision of raw billing data may be envisaged in the future steps of the project.
3.8.5.1. Billing (BI) use cases
Scope
This category of use cases describes the possible uses of the billing module: the automatic generation
of an invoice, the download of an existing invoice and also the functionalities which are only permitted
to T2S Operators (i.e. cancellation of an incorrect invoice and a new generation of an invoice).
Criteria
The criteria used to identify the use cases are the activation request and the action type to be
performed. The possible values for these criteria are:
CRITERIA
POSSIBLE VALUES
COMMENT
Activation request
Event, CSD request, T2S Operator request
Activation request of billing
functionalities.
Action Type
Invoice generation request, Invoice cancellation
request, Invoice request (download)
Type of request to be processed.
Final_T2S_GFS_110.doc
Page 527
T2S General Functional Specifications
Functional Description
Operational Services
List of Use Cases
The criteria described above are reported in the following tree:
The complete list of use cases is presented in appendix.
3.8.5.2. Processing of Billing use cases
Selection of representative BI use cases
The processing of the following representative use cases is described:
•
UC-BI-1: Automatic invoice generation;
•
UC-BI-2: Invoice request;
•
UC-BI-3: Invoice cancellation request;
•
UC-BI-4: Invoice generation request.
Final_T2S_GFS_110.doc
Page 528
T2S General Functional Specifications
Functional Description
Operational Services
Processing of UC-BI-1: Automatic invoice generation
Business assumption
At the end of a billing period an invoice is automatically produced and sent to the CSD.
Processing
The Scheduling module sends a defined business event (i.e. within the end-of-day process at the last
business day of the month) to the Billing module. In the Billing module, the “Extracting data for
billing” function extracts all relevant data for billing, covering only the billing period of the last month,
from the T2S data stores of the different domains.
Afterwards the calculation on the basis of this extracted data (Raw data) for the billing positions of the
CSD’s bill is performed by the “Calculating bill” function. On the basis of the calculated billing data the
”Formatting Invoice” function creates the invoice, which is send to the subsequent function
“Store/Load invoice”. The “Store/Load Invoice” function stores the requested invoice in the Invoices
data store and sends it to the initiating CSD via the Interface.
Final_T2S_GFS_110.doc
Page 529
T2S General Functional Specifications
Functional Description
Operational Services
Processing of UC-BI-2: Invoice Request
Business assumption
A CSD requests an existing invoice.
Processing
The Invoice request enters T2S via the Interface. In the Interface the Invoice request passes several
technical validations and checks.
•
In case of a negative result the Invoice request is stopped and a Rejection message is
sent to the initiating T2S System user.
•
If the checks are confirmed the Invoice request is forwarded via the Flow Management to
the Billing Module.
Final_T2S_GFS_110.doc
Page 530
T2S General Functional Specifications
Functional Description
Operational Services
Within the Billing Module the function “Check permission for request” ensures that a CSD can only
download its own invoice. The access authorisations are stored in the Static Data datastore.
•
If the requesting CSD is not authorised to download the requested invoice, a request
failure is sent to the error handling function und thereafter a response (error message) is
sent to the requesting CSD via the Interface.
•
In case of a positive result of the Permission check, the Invoice request is forwarded to
the function “Store/Load Invoice”.
The “Store/Load Invoice” function extracts a “copy” of the requested invoice from the Invoices data
store and sends it to the initiating CSD via the Interface.
Processing of UC-BI-3 Invoice cancellation request
Sequence Diagram Invoice Cancellation Request
Interface
OPSR: Billing
T2S System user
Invoice Cancellation Request
Alt
[negative answer]
Rejection message
[positive answer]
Invoice Cancellation Request
Alt
Error data (Billing)
[negative answer]
Response (Error message)
[positive answer]
Response (Invoice
Cancellation)
Invoice Cancellation
Business assumption
In case of an incorrect invoice the original invoice is cancelled by the T2S Operator.
Final_T2S_GFS_110.doc
Page 531
T2S General Functional Specifications
Functional Description
Operational Services
Processing
The incoming Invoice cancellation request enters T2S via the Interface. In the Interface the Invoice
cancellation request passes several technical validations and checks.
•
In case of a negative result the Invoice cancellation request is stopped and a Rejection
message is sent to the T2S Operator.
•
If the checks are confirmed the Invoice cancellation request is forwarded via the Flow
Management Module to the Billing Module.
Within the Billing Module the function “Check permission for request” ensures that only T2S Operators
who are permitted can request to cancel an invoice. The access authorisations are stored in the Static
Data data store.
•
If the requesting T2S Operator is not authorised, a request failure is sent to the error
handling function und thereafter a response (error message) is sent to the requesting
T2S Operator via the Interface.
•
In case of a positive result of the permission check, the Invoice cancellation request is
forwarded to the function “Cancel Invoice”.
Afterwards the function “Cancel Invoice” sets the status of the invoice to "cancelled" and sends a
response (invoice cancellation message) to the T2S Operator via the Interface.
Final_T2S_GFS_110.doc
Page 532
T2S General Functional Specifications
Functional Description
Operational Services
Processing of UC-BI-4: Invoice generation request
Sequence Diagram Invoice generation Request
Interface
OPSR: Billing
T2S System user
Invoice generation Request
Alt
[negative answer]
Rejection message
[positive answer]
Invoice generation Request
Alt
Error data (Billing)
[negative answer]
Response (Error message)
[positive answer]
Invoice
Invoice message
Business assumption
After an incorrect invoice has been cancelled a new one is created by the T2S Operator.
Processing
The incoming Invoice generation request enters T2S via the Interface. In the Interface the Invoice
generation request passes several technical validations and checks.
•
In case of a negative result the Invoice generation request is stopped and a Rejection
message is sent to the T2S Operator.
•
If the checks are confirmed the Invoice generation request is forwarded via the Flow
Management Module to the Billing Module.
Final_T2S_GFS_110.doc
Page 533
T2S General Functional Specifications
Functional Description
Operational Services
Within the Billing Module the function “Check permission for request” ensures that only T2S Actors
who are permitted can request to generate an invoice. The access authorisations are stored in the
Static Data datastore. Only authorised T2S Operators are allowed to generate an invoice.
•
If the requesting T2S Operator is not authorised, a request failure is sent to the error
handling function and thereafter a response (error message) is sent to the requesting
T2S Operator via the Interface.
•
In case of a positive result of the permission check, the Invoice generation request is
forwarded to the function “Extracting data for billing”.
The billing period has to be defined by the T2S Operator within the invoice generation request. The
function extracts all relevant data for the billing from the T2S data store.
Afterwards the calculation on the basis of this extracted data for the billing positions of the CSD’s bill
is performed by the “Calculating bill” function. On the basis of the calculated billing data the
”Formatting Invoice” function creates the invoice, which is send to the subsequent function
“Store/Load invoice”. The “Store/Load Invoice” function stores the requested invoice in the Invoices
data store and sends it to the concerned CSD via the Interface.
3.8.5.3. Static functional description
T2S provides a specific Billing module to invoice all participating CSDs. By means of this functionality
all CSDs are provided with invoices which are produced on a monthly cycle covering the period of one
month’s activities {T2S.15.120}.
T2S Parties (i.e. individual CSD participants) are invoiced by the respective CSDs based on the
information provided by T2S and complemented by additional data possessed by the CSDs
{T2S.15.110}.
The pricing principles and the detailed billing model will be established in the next steps of the project.
A fee schedule for all billable elements and fixed fees is stored in a data store of T2S {T2S.15.140}
Changes in the fee schedule during the billing period (month) are flagged within the monthly invoice
per CSD. Therefore no additional invoice is created.
A closure of a security account is flagged as specific information for CSDs separately on each bill.
In case of a CSD leaving T2S within the monthly billing period, the respective invoice is generated and
sent to the CSD immediately.
Final_T2S_GFS_110.doc
Page 534
T2S General Functional Specifications
Functional Description
Operational Services
Diagram of the module
Final_T2S_GFS_110.doc
Page 535
T2S General Functional Specifications
Functional Description
Operational Services
Description of the module
The Billing module automatically produces bills containing static data, fixed fees, variable fees and
billable events {T2S.15.050}.
At the end of a billing period an invoice is automatically produced and sent to each CSD. The invoice
sums up all relevant billing information per CSD {T2S.15.100}. They are distributed in an electronic
form after the completion of the last business day of the month. As additional information, the Report
Management module transmits CSDs a billing report containing the data providing details backing an
invoice at the end of the billing period {T2S.13.290}.
Only CSDs are charged via the invoices created in the Billing module of T2S. As already mentioned,
the customers of the CSDs acting in T2S (both direct and indirect participants) are invoiced by the
CSDs based on the information provided by T2S and complemented by additional data possessed by
the CSDs {T2S.15.110}
This module doesn’t provide any functionality to control the receipt of an invoice payment nor does it
support the dunning process.
All invoices are stored and available for possibly later inquiries by authorised parties {T2S.15.130}.
Form of invoices
Each invoice consists of:
•
the general invoice (including CSDs and their connected T2S parties)
•
an itemised list for the respective CSD with the information used for the bill calculation;
as a basis for calculation of the total billing amount for the respective CSD (information
given here like number of securities accounts, total number of FOP, DVD… transactions
etc.)
•
an itemised list of each account kept in T2S on behalf of the CSD with all relevant
detailed information, as a basis for billing of CSDs vis-à-vis their participants
Content of invoices
The following billing information stored in a data store of T2S are used for the creation of the monthly
billing file:
•
All events related to the lifecycle of an instruction will be counted, i.e. the number of
events is registered in view of potential billing. Additionally all events related to queries or
business reports and events like instruction matching and settlement are stored for each
T2S party {T2S.15.070}. Also each instruction type is recognised as billable event for
each T2S party, e.g. FOP and DVP are counted. Each instruction type is numbered for
each party {T2S.15.080}.
•
All transmission volumes triggered by messages, business reports or queries are added
for potential billing {T2S.15.090}
Final_T2S_GFS_110.doc
Page 536
T2S General Functional Specifications
Functional Description
Operational Services
•
Information on services provided to T2S parties, (e.g. auto-collateralisation) is stored in a
data store of T2S {T2S.15.060}
Description of the functions of the module
1 – Check permission for request
This function checks each request of a T2S system user, which was forwarded by the Interface (i.e.
invoice generation request, invoice request, invoice cancellation request) against the permission rights
of the respective user stored in a data store. In general, a CSD is only allowed to download its own
invoices. Furthermore, the new generation of an invoice (in case the automatic generation failed) as
well as the cancellation of an existing invoice is a specific privilege of T2S Operators.
In case of a positive result of the permission check
•
the invoice generation request is sent to the function Extracting data for billing,
•
the invoice request is forwarded to the function Load invoice and
•
the invoice cancellation request is transmitted to the function Cancel invoice.
In case of denial, the request failure is passed to the function Error handling.
2 – Extracting data for billing
This function extracts all relevant data for the billing from the T2S data store.
This function is triggered either by
•
an event i.e. within the end-of-day process at the last business day of the month, or
•
an invoice generation request initiated by a T2S Operator.
In case the extracting is automatically triggered at the last business day of the month, the billing
period covers only the last month. In case the extracting is initiated by an invoice generation request
sent by a T2S Operator, the billing period has to be defined within the invoice generation request.
Raw data for billing will be sent to Calculating bill.
3 – Calculating bill
This function calculates on the basis of the raw data for billing the positions of the CSD’s bill, which
will be forwarded to the function Formatting Invoice.
4 – Formatting invoice
This function creates invoices on the basis of the billing data and forwards them to the subsequent
function Store/Load invoice.
5 – Store/Load invoice
This function stores the already formatted invoices in the invoice data store and then delivers them to
the CSDs via the Flow Management.
Final_T2S_GFS_110.doc
Page 537
T2S General Functional Specifications
Functional Description
Operational Services
In case of an invoice request, this function uploads the requested invoice from the invoice data store
and sends it to the requesting T2S system user via the Flow Management.
6 – Cancel invoice
This function carries out the cancellation of an invoice. For example, in case of an incorrect invoice,
the original invoice can be cancelled by the T2S Operator (and afterwards a new one can be created).
The behaviour of this function will be explained more in detail at a later stage after legal aspects will
have been clarified.
The function Cancel invoice sets the status of the invoice to “cancelled” and sends a cancellation
message to the T2S Operator via the Flow Management.
7 – Error handling
In case of a request failure due to insufficient user permissions, this function prepares an error text
and sends it to the respective user via the Flow Management.
Description of the Input/Output of the module
FLOW
IN/OUT
DESCRIPTION
FROM
TO
Invoice
Out
Invoice for CSD
Billing module
Flow Management
Invoice
cancellation
Out
Sub-invoice per account and Billing module
details of invoices
Flow Management
Error data (Billing)
OUT
For operational monitoring
Billing module
Flow Management
Invoice generation
request
In
Intervention by a T2S
Operator
Flow Management
Billing module
Invoice request
In
Request of a CSD to
download an already sent
invoice
Flow Management
Billing module
Invoice
cancellation
request
In
Intervention by a T2S
Operator
Flow Management
Billing module
Data accessed by the module
DATA
ACCESS MODE
STATUS
COMMENTS
Static data
Read
All static data relevant for billing
Dynamic data
Read
All dynamic data relevant for billing
Final_T2S_GFS_110.doc
Page 538
T2S General Functional Specifications
Appendices
List of Use Cases
4. Appendices
4.1. List of Use Cases
4.1.1. Presentation
4.1.2. Devising the use cases
This appendix presents the list of the identified T2S Use Cases, being understood as “An interaction between a user and a system or a component within a
system by defining the discrete goal that the user wants to achieve with the system, without the requirement to reveal or to specify the system's internal
behaviour” (T2S URD Glossary).
The approach for devising these use cases is based on the definition of the following categories covering the main situations of interaction of a T2S System
user with T2S:
• SI: Settlement Instructions, including both trade and non-trade instructions;
• MI: Maintenance Instructions;
• SM: Static Data Management;
• QU: Queries;
• RE: Reports;
• LT: Liquidity Transfers;
Final_T2S_GFS_110.doc
Page 539
T2S General Functional Specifications
Appendices
List of Use Cases
• MG: Data Migration;
• EV: Events;
• BI: Billing;
• LA: Legal Archiving.
The description of each category of use cases, provided into the relevant sections of the main document includes:
• A short explanation of the scope of the category;
• The criteria that characterise a T2S System user interaction with T2S in this category: for instance, the criteria that characterise a use case of the
“Reports” category are the communication mode, the information basis, the report triggering, the report type and the report sub-type;
• The possible values for each criterion. For instance, the possible values for the criterion “Report Type” are “Securities instructions”, “balance” and
“static data”.
On this basis, a T2S use case within a given category is defined as a combination of criteria values relevant from a business perspective.
For instance, a use case into the category “Report” can be defined as follows:
COMMUNICATION MODE
A2A
INFORMATION BASIS
On individual account
TRIGGERING
Event
TYPE
Securities instructions
SUB-TYPE
Statement of pending instructions
Such use case covers the situation where a report listing the pending securities instructions on a single account is triggered by a business event and accessed
by a T2S system user in A2A mode.
Within a given category, the exhaustive list of use cases is therefore constituted of all the combinations of criteria values relevant from a business point of
view. These combinations are provided in two different ways:
• In the description of the category provided into the main document, a decisional tree shows graphically the relevant combinations of criteria values;
Final_T2S_GFS_110.doc
Page 540
T2S General Functional Specifications
Appendices
List of Use Cases
• In this appendix, an exhaustive list of all the use cases in each category is provided.
4.1.3. Settlement Instruction
The following criteria are omitted from the table, since all their combinations of values are possible:
•
CSD configuration (Intra CSD, Cross-CSD, In/Out T2S)
•
Partial (Yes/No)
•
Auto-collateralisation (Yes/No)
•
Communication mode (A2A/U2A)
CRITERIA
ID
GROUP OF
INSTRUCTIONS
COSD
LINKED
INSTRUCTION
TYPE
COMMENT
REPRESENTATIVE USE CASES
MATCHING
1
Standard DvD matching not required
2
DvD for securities conversion (matching not
required)
3
Standard
4
No
No
DvD
Autocollateralisation substitution (matching not
Non required/ required)
Already
DvD already matched
Matched
5
Monetary policy operation pledge/collateral
management (already matched)
6
DvD for collateral substitution (already
matched)
Final_T2S_GFS_110.doc
Page 541
UC-SI-1:Settlement of a standard settlement
instruction
UC-SI-11:Settlement of a corporate action with
associated liquidity transfer
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
GROUP OF
INSTRUCTIONS
COSD
LINKED
INSTRUCTION
TYPE
COMMENT
REPRESENTATIVE USE CASES
MATCHING
7
DvD for collateral substitution (matching not
required)
8
Securities exchanges, e.g. conversions (CE)
(matching not required)
9
DvD with linked instruction, matching not
required
Standard
No
Yes
DvD
10
Non required/
Already
Matched
DvD already matched with linked instruction
DvD conditional with linked instruction
(matching not required)
11
Standard
Y
Yes
DvD
12
Non required/
Already
DvD already matched conditional with linked
Matched
instruction
13
DvD conditional for CE (matching not required)
UC-SI-6: Conditional Securities Delivery
instruction
UC-SI-2: Intra-CSD Standard Linked DvP
Instructions
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
Standard
Y
No
DvD
Non required/
Already
DvD already matched conditional
Matched
UC-SI-6: Conditional Securities Delivery
instruction
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
Standard
No
No
DvD
Yes
UC-SI-3: Intra CSD-Standard DvP with
14
15
UC-SI-2: Intra-CSD Standard Linked DvP
Instructions
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
Final_T2S_GFS_110.doc
DvD for collateral substitution
Page 542
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
GROUP OF
INSTRUCTIONS
COSD
LINKED
INSTRUCTION
TYPE
COMMENT
16
17
Standard
No
Yes
DvD
REPRESENTATIVE USE CASES
MATCHING
Yes
18
Standard DvD with Matching
Matching
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
DvD with linked instruction
UC-SI-2: Intra-CSD Standard Linked DvP
Instructions
UC-SI-3: Intra CSD-Standard DvP with
Matching
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
Registered securities DvD
Standard
19
Final_T2S_GFS_110.doc
Y
Yes
DvD
Yes
DvD conditional with linked instruction and
matching required
Page 543
UC-SI-6: Conditional Securities Delivery
instruction
UC-SI-2: Intra-CSD Standard Linked DvP
Instructions
UC-SI-3: Intra CSD-Standard DvP with
Matching
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
GROUP OF
INSTRUCTIONS
20
21
22
Standard
Block-Trade
Block-Trade
COSD
Y
No
No
LINKED
No
Yes
No
INSTRUCTION
TYPE
DvD
Standard
25
Final_T2S_GFS_110.doc
No
No
REPRESENTATIVE USE CASES
Yes
UC-SI-6: Conditional Securities Delivery
instruction
UC-SI-3: Intra CSD-Standard DvP with
Matching
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
DvD conditional
Non required/
Already
DvD Block trade (matching not required)
Matched
UC-SI-7: Intra CSD-Standard DvP with Block
Trade instruction
UC-SI-2: Intra-CSD Standard Linked DvP
Instructions
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
DvD
Non required/
DvD block trade with linked instruction
Already
(matching not required)
Matched
UC-SI-7: Intra CSD-Standard DvP with Block
Trade instruction
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
DvP/DwP
DwP (matching not required)
Non required/
Already
DwP (already matched)
Matched
DwP instructed by CCP (matching not required)
UC-SI-1:Settlement of a standard settlement
instruction
UC-SI-11:Settlement of a corporate action with
associated liquidity transfer
DvD
23
24
COMMENT
MATCHING
Page 544
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
GROUP OF
INSTRUCTIONS
COSD
LINKED
INSTRUCTION
TYPE
COMMENT
REPRESENTATIVE USE CASES
MATCHING
26
DvP already matched
27
DvP matching not required
28
Plain vanilla: CSDs, SE, TP and CCPs already
matched
29
Securities lending: CSD already matched
30
Auto-collateralisation
31
Buy-in/sell out CSD (already matched)
32
Market claim transaction: CSD (already
matched)
33
Back-to-back: CSD (already matched)
34
Securities issuance and redemption (CE)
(already matched)
35
Redemptions (CE) (already matched)
36
Cash distribution with securities delivery (CE)
(already matched)
37
DvP matching not required with linked
instruction
38
Standard
No
Yes
DvP/DwP
Standard
Yes
Yes
DvP/DwP
39
40
Final_T2S_GFS_110.doc
Non required/
Delivery by value (DbV) (already matched)
Already
Matched
DvP already matched with linked instruction
Non required/ DvP matching not required with linked
instruction, conditional
Already
Page 545
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
UC-SI-2: Intra-CSD Standard Linked DvP
Instructions
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
UC-SI-6: Conditional Securities Delivery
instruction
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
GROUP OF
INSTRUCTIONS
COSD
LINKED
INSTRUCTION
TYPE
COMMENT
REPRESENTATIVE USE CASES
MATCHING
Matched
41
DvP already matched with linked instruction,
conditional
42
DvP matching not required, conditional
Standard
Yes
No
DvP/DwP
43
Non required/
Already
DvP already matched, conditional
Matched
44
Standard DvP (with matching)
45
Plain vanilla: CSD Participant
46
Securities lending: Participant
47
Standard
No
No
DvP/DwP
Yes
DwP (with matching)
48
Buy-in sell out CSD (with matching)
49
Buy-in/sell out: Participant
50
Market claim transaction: CSD
51
DvP with linked instruction
Standard
52
Final_T2S_GFS_110.doc
No
Yes
DvP/DwP
UC-SI-2: Intra-CSD Standard Linked DvP
Instructions
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
UC-SI-6: Conditional Securities Delivery
instruction
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
UC-SI-3: Intra CSD-Standard DvP with
Matching
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
UC-SI-2: Intra-CSD Standard Linked DvP
Instructions
Yes
Back-to-back CSD Participant
Page 546
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
GROUP OF
INSTRUCTIONS
COSD
LINKED
INSTRUCTION
TYPE
COMMENT
53
Basket: CSD Participant
54
DvP conditional
55
Issuer CSD external to T2S
Standard
Yes
No
DvP/DwP
UC-SI-3: Intra CSD-Standard DvP with
Matching
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
UC-SI-6: Conditional Securities Delivery
instruction
UC-SI-3: Intra CSD-Standard DvP with
Matching
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
Yes
56
57
REPRESENTATIVE USE CASES
MATCHING
Registered securities DvP
Standard
Final_T2S_GFS_110.doc
Yes
Yes
DvP/DwP
Yes
DvP with linked instruction, conditional
Page 547
UC-SI-6: Conditional Securities Delivery
instruction
UC-SI-2: Intra-CSD Standard Linked DvP
Instructions
UC-SI-3: Intra CSD-Standard DvP with
Matching
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
GROUP OF
INSTRUCTIONS
58
59
Block-Trade
Block-Trade
COSD
No
No
LINKED
No
Yes
INSTRUCTION
TYPE
DvP
DvP
COMMENT
REPRESENTATIVE USE CASES
MATCHING
Non required/
Already
DvP Block trade (matching not required)
Matched
UC-SI-7: Intra CSD-Standard DvP with Block
Trade instruction
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
Non required/
DvP Block trade with linked instruction
Already
(matching not required)
Matched
UC-SI-7: Intra CSD-Standard DvP with Block
Trade instruction
UC-SI-2: Intra-CSD Standard Linked DvP
Instructions
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
60
DvP for two legged instructions
61
DvP for two legged instructions, in separate
instructions
Two-legged
No
Yes
DvP
Yes
62
DvP for two legged instructions in one
instruction
63
DvP for two legged instructions already
matched
Two-legged
64
Final_T2S_GFS_110.doc
No
No
DvP
Non required/
Already
DvP for two legged instructions in one
Matched
instruction, already matched
Page 548
UC-SI-8: Intra CSD- Two-legged instruction
UC-SI-2: Intra-CSD Standard Linked DvP
Instructions
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
UC-SI-8: Intra CSD- Two-legged instruction
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
GROUP OF
INSTRUCTIONS
65
Standard
COSD
No
LINKED
No
INSTRUCTION
TYPE
DvP
COMMENT
REPRESENTATIVE USE CASES
MATCHING
Non required/
Monetary policy operations (REPO) (already
Already
matched)
Matched
66
FoP for special purpose (same owner or CE)
(matching not required)
67
Mark-up/Mark-down (matching not required)
68
Securities distribution, e.g. Rights distribution
(CE)
69
Book out (CE)
70
Primary market and IPO (CE)
71
Standard
72
No
No
FoP
Non required/ UCITS increase/decrease (matching not
Already
required)
Matched
Transfer of securities between accounts of the
same owner (matching not required)
73
Coupon stripping and reattachment: Participant
(matching not required)
74
Pledge (collateral management) (matching not
required)
75
Cross CSD transaction (realignment) (matching
not required)
Final_T2S_GFS_110.doc
Page 549
UC-SI-1:Settlement of a standard settlement
instruction
UC-SI-11:Settlement of a corporate action with
associated liquidity transfer
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
UC-SI-1:Settlement of a standard settlement
instruction
UC-SI-11:Settlement of a corporate action with
associated liquidity transfer
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
GROUP OF
INSTRUCTIONS
COSD
LINKED
INSTRUCTION
TYPE
COMMENT
REPRESENTATIVE USE CASES
MATCHING
76
FoP already matched
77
Pledge (collateral management) CSD (matching
not required)
78
Monetary policy operation pledge/collateral
management (already matched)
79
Pledge (collateral management) (matching not
required)
80
Standard FoP
81
Transfer of securities Participant
82
Pledge (collateral management) CSD Participant
(matching not required)
83
FoP matching not required with linked
instruction
Standard
No
Yes
FoP
84
Non required/
Already
Matched
FoP already matched with linked instruction
85
FoP matching not required conditional
86
FoP already matched conditional
87
Standard
88
89
Final_T2S_GFS_110.doc
Yes
No
FoP
Non required/
Issuer CSD external to T2S
Already
Matched
Registered securities
FoP Conditional
Page 550
UC-SI-7: Intra CSD-Standard DvP with Block
Trade instruction
UC-SI-2: Intra-CSD Standard Linked DvP
Instructions
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
UC-SI-6: Conditional Securities Delivery
instruction
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
GROUP OF
INSTRUCTIONS
COSD
LINKED
INSTRUCTION
TYPE
COMMENT
FoP matching not required with linked
instruction, conditional
90
Standard
Yes
Yes
FoP
91
92
93
REPRESENTATIVE USE CASES
MATCHING
Standard
Standard
Final_T2S_GFS_110.doc
Yes
No
Yes
Yes
FoP
FoP
Non required/
Already
FoP already matched with linked instruction,
Matched
conditional
Yes
Yes
UC-SI-6: Conditional Securities Delivery
instruction
UC-SI-2: Intra-CSD Standard Linked DvP
Instructions
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
FoP matching required with linked instruction,
conditional
UC-SI-6: Conditional Securities Delivery
instruction
UC-SI-2: Intra-CSD Standard Linked DvP
Instructions
UC-SI-3: Intra CSD-Standard DvP with
Matching
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
FoP with linked instruction
UC-SI-2: Intra-CSD Standard Linked DvP
Instructions
UC-SI-3: Intra CSD-Standard DvP with
Matching
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
Page 551
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
GROUP OF
INSTRUCTIONS
94
Standard
COSD
Yes
LINKED
No
INSTRUCTION
TYPE
FoP
COMMENT
Yes
95
UC-SI-6: Conditional Securities Delivery
instruction
UC-SI-3: Intra CSD-Standard DvP with
Matching
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
FoP Conditional
FoP for special purpose (same owner or CE)
Standard
No
No
FoP
96
97
REPRESENTATIVE USE CASES
MATCHING
Yes
Securities issuance and redemption (CE)
Block-Trade
Final_T2S_GFS_110.doc
No
No
FoP
Non required/
Already
FoP Block trade (matching not required)
Matched
Page 552
UC-SI-3: Intra CSD-Standard DvP with
Matching
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
UC-SI-7: Intra CSD-Standard DvP with Block
Trade instruction
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
GROUP OF
INSTRUCTIONS
98
99
100
Block-Trade
Standard
Standard
Final_T2S_GFS_110.doc
COSD
No
No
No
LINKED
Y
No
No
INSTRUCTION
TYPE
FoP
PFOD
RESA
COMMENT
REPRESENTATIVE USE CASES
MATCHING
Non required/
FoP Block trade with linked instruction
Already
(matching not required)
Matched
UC-SI-7: Intra CSD-Standard DvP with Block
Trade instruction
UC-SI-2: Intra-CSD Standard Linked DvP
Instructions
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
Non required/
Payment free of delivery (matching not
Already
required)
Matched
UC-SI-1:Settlement of a standard settlement
instruction
UC-SI-11:Settlement of a corporate action with
associated liquidity transfer
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
Non required/
Reservation of securities or cash (matching not
Already
required)
Matched
UC-SI-10: Reservation instruction
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
Page 553
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
GROUP OF
INSTRUCTIONS
101
Standard
COSD
No
LINKED
Y
INSTRUCTION
TYPE
RESA
REPRESENTATIVE USE CASES
Non required/
Reservation of securities or cash with linked
Already
instructions (matching not required)
Matched
Block securities or cash position with linked
instruction (matching not required)
102
Standard
No
No
BLK
103
104
COMMENT
MATCHING
Standard
Final_T2S_GFS_110.doc
No
Y
BLK
UC-SI-10: Reservation instructionUC-SI-2:
Intra-CSD Standard Linked DvP Instructions
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
Non required/
Already
No settlement involved CE (CE) (matching not
Matched
required)
UC-SI-9: Blocking instruction
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
Non required/
Block securities or cash position with linked
Already
instruction (matching not required)
Matched
UC-SI-9: Blocking instruction
UC-SI-2: Intra-CSD Standard Linked DvP
Instructions
UC-SI-12: Cross CSD/Inout CSD Standard DvP
UC-SI-4: Intra CSD-Standard DvP with Partial
Settlement
UC-SI-5: Intra CSD-Standard DvP with Autocollateralisation
Page 554
T2S General Functional Specifications
Appendices
List of Use Cases
4.1.4. Maintenance Instruction
CRITERIA
ID
MAINTENANCE
FIELDS TO BE
INSTRUCTION
AMENDED
TYPE
STATUS OF THE
GROUP OF
ORIGINAL
INSTRUCTION.
SETTLEMENT
COMMENT
REPRESENTATIVE USE CASE
INSTRUCTION.
105
HOLD
N/A
Standard
ALL but end status, Maintenance instruction to put on hold
eligible or
instructions that are not with the status eligible,
unsettled
unsettled or with an end status
UC-MI-2: Hold / Release Maintenance
Instructions
106
HOLD
N/A
Standard
Eligible or
Unsettled
Maintenance instruction to put on hold
instructions that are with the status eligible or
unsettled
UC-MI-2: Hold / Release Maintenance
Instructions
107
HOLD
N/A
Standard
End status
Maintenance instruction to put on hold
instructions that are with an end status
UC-MI-2: Hold / Release Maintenance
Instructions
108
HOLD
N/A
Block Trade /
Two-legged
ALL but end status, Maintenance instruction to put on hold
eligible or
instructions that are not with the status eligible,
unsettled
unsettled or with an end status and where the
original instruction is a block trade instruction or
a two-legged instruction
UC-MI-2: Hold / Release Maintenance
Instructions
UC-MI-4: Maintenance of two legged
instructions and block-trade instructions
109
HOLD
N/A
Block Trade /
Two-legged
Eligible or
Unsettled
Maintenance instruction to put on hold
instructions that are with the status eligible or
unsettled and where the original instruction is a
block trade instruction or a two-legged
instruction
UC-MI-2: Hold / Release Maintenance
Instructions
UC-MI-4: Maintenance of two legged
instructions and block-trade instructions
110
HOLD
N/A
Block Trade /
Two-legged
End status
Maintenance instruction to put on hold
instructions that are with an end status and
where the original instruction is a block trade
instruction or a two-legged instruction
UC-MI-2: Hold / Release Maintenance
Instructions
UC-MI-4: Maintenance of two legged
instructions and block-trade instructions
111
RELEASE
N/A
Standard
ALL but end status, Maintenance instruction to release instructions on UC-MI-2: Hold / Release Maintenance
eligible or
hold that are not with the status eligible,
Instructions
Final_T2S_GFS_110.doc
Page 555
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
MAINTENANCE
FIELDS TO BE
INSTRUCTION
AMENDED
TYPE
STATUS OF THE
GROUP OF
ORIGINAL
INSTRUCTION.
SETTLEMENT
COMMENT
REPRESENTATIVE USE CASE
INSTRUCTION.
unsettled
unsettled or with an end status
112
RELEASE
N/A
Standard
"Eligible on hold"
or "Unsettled on
hold"
Maintenance instruction to release instructions on UC-MI-2: Hold / Release Maintenance
hold that are with the status eligible or unsettled Instructions
113
RELEASE
N/A
Standard
End status
Maintenance instruction to release instructions
that are with an end status
114
RELEASE
N/A
Block Trade /
Two-legged
ALL but end status, Maintenance instruction to release instructions on UC-MI-2: Hold / Release Maintenance
eligible or
hold that are not with the status eligible,
Instructions
unsettled
unsettled or with an end status and where the
UC-MI-4: Maintenance of two legged
original instruction is a block trade instruction or
instructions and block-trade instructions
a two-legged instruction
115
RELEASE
N/A
Block Trade /
Two-legged
"Eligible on hold"
or "Unsettled on
hold"
Maintenance instruction to release instructions on UC-MI-2: Hold / Release Maintenance
hold that are with the status eligible or unsettled Instructions
and where the original instruction is a block
UC-MI-4: Maintenance of two legged
trade instruction or a two-legged instruction
instructions and block-trade instructions
116
RELEASE
N/A
Block Trade /
Two-legged
End status
Maintenance instruction to release instructions
that are with an end status and where the
original instruction is a block trade instruction or
a two-legged instruction
UC-MI-2: Hold / Release Maintenance
Instructions
UC-MI-4: Maintenance of two legged
instructions and block-trade instructions
117
AMEND
Matching
Fields
Standard
Before matching
Amendment of matching fields before matching
UC-MI-1: Amend Maintenance Instruction
118
AMEND
Matching
Fields
Standard
After matching
Amendment of matching fields after matching
UC-MI-1: Amend Maintenance Instruction
119
AMEND
Matching
Standard
End status
Amendment of matching fields once the
instruction is with an end status (settled,
UC-MI-1: Amend Maintenance Instruction
Final_T2S_GFS_110.doc
Page 556
UC-MI-2: Hold / Release Maintenance
Instructions
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
MAINTENANCE
FIELDS TO BE
INSTRUCTION
AMENDED
TYPE
STATUS OF THE
GROUP OF
ORIGINAL
INSTRUCTION.
SETTLEMENT
COMMENT
REPRESENTATIVE USE CASE
INSTRUCTION.
Fields
rejected, cancelled)
120
AMEND
Matching
Fields
Block Trade /
Two-legged
Before matching
Amendment of matching fields before matching
and where the original instruction is a block
trade instruction or a two-legged instruction
UC-MI-1: Amend Maintenance Instruction
UC-MI-4: Maintenance of two legged
instructions and block-trade instructions
121
AMEND
Matching
Fields
Block Trade /
Two-legged
After matching
Amendment of matching fields after matching
and where the original instruction is a block
trade instruction or a two-legged instruction
UC-MI-1: Amend Maintenance Instruction
UC-MI-4: Maintenance of two legged
instructions and block-trade instructions
122
AMEND
Matching
Fields
Block Trade /
Two-legged
End status
Amendment of matching fields once the
instruction is with an end status (settled,
rejected, cancelled) and where the original
instruction is a block trade instruction or a twolegged instruction
UC-MI-1: Amend Maintenance Instruction
UC-MI-4: Maintenance of two legged
instructions and block-trade instructions
123
AMEND
Non
Matching
Fields
/Process
indicators
Standard
ALL but end status, Amendment of non matching fields or process
eligible or
indicators when the original instructions are not
unsettled
with the status eligible, unsettled or with an end
status
UC-MI-1: Amend Maintenance Instruction
124
AMEND
Non
Matching
Fields
/Process
indicators
Standard
Eligible or
Unsettled
Amendment of non matching fields or process
indicators when the original instructions are with
the status eligible or unsettled
UC-MI-1: Amend Maintenance Instruction
125
AMEND
Non
Matching
Fileds/Proc
ess
Standard
End status
Amendment of non matching fields or process
indicators when the original instructions are with
an end status
UC-MI-1: Amend Maintenance Instruction
Final_T2S_GFS_110.doc
Page 557
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
MAINTENANCE
FIELDS TO BE
INSTRUCTION
AMENDED
TYPE
STATUS OF THE
GROUP OF
ORIGINAL
INSTRUCTION.
SETTLEMENT
COMMENT
REPRESENTATIVE USE CASE
INSTRUCTION.
indicators
126
AMEND
Non
Matching
Fileds/Proc
ess
indicators
Block Trade /
Two-legged
ALL but end status, Amendment of non matching fields or process
eligible or
indicators when the original instructions are not
unsettled
with the status eligible, unsettled or with an end
status and where the original instruction is a
block trade instruction or a two-legged
instruction
UC-MI-1: Amend Maintenance Instruction
UC-MI-4: Maintenance of two legged
instructions and block-trade instructions
127
AMEND
Non
Matching
Fileds/Proc
ess
indicators
Block Trade /
Two-legged
Eligible or
Unsettled
Amendment of non matching fields or process
indicators when the original instructions are with
the status eligible or unsettled and where the
original instruction is a block trade instruction or
a two-legged instruction
UC-MI-1: Amend Maintenance Instruction
UC-MI-4: Maintenance of two legged
instructions and block-trade instructions
128
AMEND
Non
Matching
Fileds/Proc
ess
indicators
Block Trade /
Two-legged
End status
Amendment of non matching fields or process
indicators when the original instructions are with
an end status and where the original instruction
is a block trade instruction or a two-legged
instruction
UC-MI-1: Amend Maintenance Instruction
UC-MI-4: Maintenance of two legged
instructions and block-trade instructions
129
CANCEL
N/A
Standard
Before matching or
Matching not
required
Cancellation of instructions before matching or
cancellation of instructions with matching not
required
UC-MI-3: Cancellation Maintenance
Instruction
130
CANCEL
N/A
Standard
Matched
Cancellation of instructions with the status
"matched"
UC-MI-3: Cancellation Maintenance
Instruction
131
CANCEL
N/A
Standard
Eligible or
Unsettled
(instructions that
Cancellation of instructions with the status
UC-MI-3: Cancellation Maintenance
eligible or unsettled (instructions that are already Instruction
matched)
Final_T2S_GFS_110.doc
Page 558
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
MAINTENANCE
FIELDS TO BE
INSTRUCTION
AMENDED
TYPE
STATUS OF THE
GROUP OF
ORIGINAL
INSTRUCTION.
SETTLEMENT
COMMENT
REPRESENTATIVE USE CASE
INSTRUCTION.
are already
matched)
132
CANCEL
N/A
Standard
Eligible or
Unsettled
(instructions with
matching not
required)
Cancellation of instructions with the status
eligible or unsettled (instructions with matching
not required)
133
CANCEL
N/A
Standard
End status
Cancellation of instructions with an end status
UC-MI-3: Cancellation Maintenance
(non modifiable, i.e.: settled, rejected, cancelled) Instruction
134
CANCEL
N/A
Block Trade /
Two-legged
Before matching or
Matching not
required
Cancellation of instructions before matching or
cancellation of instructions with matching not
required and where the original instruction is a
block trade instruction or a two-legged
instruction
UC-MI-3: Cancellation Maintenance
Instruction
UC-MI-4: Maintenance of two legged
instructions and block-trade instructions
135
CANCEL
N/A
Block Trade /
Two-legged
Matched
Cancellation of instructions with the status
"matched" and where the original instruction is a
block trade instruction or a two-legged
instruction
UC-MI-3: Cancellation Maintenance
Instruction
UC-MI-4: Maintenance of two legged
instructions and block-trade instructions
136
CANCEL
N/A
Block Trade /
Two-legged
Eligible or
Unsettled
(instructions with
already matched)
Cancellation of instructions with the status
UC-MI-3: Cancellation Maintenance
eligible or unsettled (instructions that are already Instruction
matched) and where the original instruction is a
UC-MI-4: Maintenance of two legged
block trade instruction or a two-legged
instructions and block-trade instructions
instruction
137
CANCEL
N/A
Block Trade /
Two-legged
Eligible or
Unsettled
(instructions with
matching not
Cancellation of instructions with the status
eligible or unsettled (instructions with matching
not required) and where the original instruction
is a block trade instruction or a two-legged
Final_T2S_GFS_110.doc
Page 559
UC-MI-3: Cancellation Maintenance
Instruction
UC-MI-3: Cancellation Maintenance
Instruction
UC-MI-4: Maintenance of two legged
instructions and block-trade instructions
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
138
STATUS OF THE
MAINTENANCE
FIELDS TO BE
INSTRUCTION
AMENDED
TYPE
CANCEL
N/A
GROUP OF
ORIGINAL
INSTRUCTION.
SETTLEMENT
COMMENT
REPRESENTATIVE USE CASE
INSTRUCTION.
Block Trade /
Two-legged
required)
instruction
End status
Cancellation of instructions with an end status
UC-MI-3: Cancellation Maintenance
(non modifiable, i.e.: settled, rejected, cancelled) Instruction
and where the original instruction is a block
UC-MI-4: Maintenance of two legged
trade instruction or a two-legged instruction
instructions and block-trade instructions
4.1.5. Static Data Management
CRITERIA
ID
INSTRUCTING PARTY
ACCESS
TYPE
COMMENT
MODE
FUNCTION TYPE
DATA TYPE
ACTION TYPE
139
NCB, CSD, T2S Operator U2A
2 eyes
Create
Parties
Maintenance Request
140
CSD
U2A
2 eyes
Create
Securities
Maintenance Request
141
CSD
U2A
2 eyes
Create
Securities Account
Maintenance Request
142
NCB
U2A
2 eyes
Create
T2S Dedicated Cash
Account
Maintenance Request
143
NCB, CSD, T2S Operator U2A
2 eyes
Create
Rules
Maintenance Request
144
NCB, CSD, T2S Operator U2A
2 eyes
Create
Parameters
Maintenance Request
145
NCB, CSD, T2S Operator U2A
2 eyes
Update
Parties
Maintenance Request
146
CSD
U2A
2 eyes
Update
Securities
Maintenance Request
147
CSD
U2A
2 eyes
Update
Securities Account
Maintenance Request
Final_T2S_GFS_110.doc
Page 560
REPRESENTATIVE USECASE
UC-SM-1: Static Data
Maintenance
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
INSTRUCTING PARTY
ACCESS
TYPE
COMMENT
MODE
FUNCTION TYPE
DATA TYPE
ACTION TYPE
148
NCB
U2A
2 eyes
Update
T2S Dedicated Cash
Account
Maintenance Request
149
NCB, CSD, T2S Operator U2A
2 eyes
Update
Rules
Maintenance Request
150
NCB, CSD, T2S Operator U2A
2 eyes
Update
Parameters
Maintenance Request
151
NCB, CSD, T2S Operator U2A
2 eyes
Delete
Parties
Maintenance Request
152
CSD
U2A
2 eyes
Delete
Securities
Maintenance Request
153
CSD
U2A
2 eyes
Delete
Securities Account
Maintenance Request
154
NCB
U2A
2 eyes
Delete
T2S Dedicated Cash
Account
Maintenance Request
155
NCB, CSD, T2S Operator U2A
2 eyes
Delete
Rules
Maintenance Request
156
NCB, CSD, T2S Operator U2A
2 eyes
Delete
Parameters
Maintenance Request
157
All
U2A
2 eyes
Retrieve
Parties
Access Request
158
All
U2A
2 eyes
Retrieve
Securities
Access Request
159
CSD, CSD Participant
U2A
2 eyes
Retrieve
Securities Account
Access Request
160
NCB, Payment Bank
U2A
2 eyes
Retrieve
T2S Dedicated Cash
Account
Access Request
161
All
U2A
2 eyes
Retrieve
Rules
Access Request
162
All
U2A
2 eyes
Retrieve
Parameters
Access Request
163
NCB, CSD, T2S Operator U2A
4 eyes
Create
Parties
Maintenance Request
164
CSD
U2A
4 eyes
Create
Securities
Maintenance Request
165
CSD
U2A
4 eyes
Create
Securities Account
Maintenance Request
Final_T2S_GFS_110.doc
Page 561
REPRESENTATIVE USECASE
UC-SM-3: Static Data
Access
UC-SM-1: Static Data
Maintenance
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
INSTRUCTING PARTY
ACCESS
TYPE
COMMENT
MODE
FUNCTION TYPE
DATA TYPE
ACTION TYPE
166
NCB
U2A
4 eyes
Create
T2S Dedicated Cash
Account
Maintenance Request
167
NCB, CSD, T2S Operator U2A
4 eyes
Create
Rules
Maintenance Request
168
NCB, CSD, T2S Operator U2A
4 eyes
Create
Parameters
Maintenance Request
169
NCB, CSD, T2S Operator U2A
4 eyes
Update
Parties
Maintenance Request
170
CSD
U2A
4 eyes
Update
Securities
Maintenance Request
171
CSD
U2A
4 eyes
Update
Securities Account
Maintenance Request
172
NCB
U2A
4 eyes
Update
T2S Dedicated Cash
Account
Maintenance Request
173
NCB, CSD, T2S Operator U2A
4 eyes
Update
Rules
Maintenance Request
174
NCB, CSD, T2S Operator U2A
4 eyes
Update
Parameters
Maintenance Request
175
NCB, CSD, T2S Operator U2A
4 eyes
Create
Parties
Approval Request
176
CSD
U2A
4 eyes
Create
Securities
Approval Request
177
CSD
U2A
4 eyes
Create
Securities Account
Approval Request
178
NCB
U2A
4 eyes
Create
T2S Dedicated Cash
Account
Approval Request
179
NCB, CSD, T2S Operator U2A
4 eyes
Create
Rules
Approval Request
180
NCB, CSD, T2S Operator U2A
4 eyes
Create
Parameters
Approval Request
181
NCB, CSD, T2S Operator U2A
4 eyes
Update
Parties
Approval Request
182
CSD
U2A
4 eyes
Update
Securities
Approval Request
183
CSD
U2A
4 eyes
Update
Securities Account
Approval Request
Final_T2S_GFS_110.doc
Page 562
REPRESENTATIVE USECASE
UC-SM-2: Static Data
Approval
UC-SM-2: Static Data
Approval
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
INSTRUCTING PARTY
ACCESS
TYPE
COMMENT
MODE
FUNCTION TYPE
DATA TYPE
ACTION TYPE
184
NCB
U2A
4 eyes
Update
T2S Dedicated Cash
Account
Approval Request
185
NCB, CSD, T2SOperator
U2A
4 eyes
Update
Rules
Approval Request
186
NCB, CSD, T2SOperator
U2A
4 eyes
Update
Parameters
Approval Request
187
NCB, CSD, T2SOperator
U2A
4 eyes
Delete
Parties
Approval Request
188
CSD
U2A
4 eyes
Delete
Securities
Approval Request
189
CSD
U2A
4 eyes
Delete
Securities Account
Approval Request
190
NCB
U2A
4 eyes
Delete
T2S Dedicated Cash
Account
Approval Request
191
NCB, CSD, T2S Operator U2A
4 eyes
Delete
Rules
Approval Request
192
NCB, CSD, T2S Operator U2A
4 eyes
Delete
Parameters
Approval Request
193
NCB, CSD, T2S Operator U2A
4 eyes
Delete
Parties
Maintenance Request
194
CSD
U2A
4 eyes
Delete
Securities
Maintenance Request
195
CSD
U2A
4 eyes
Delete
Securities Account
Maintenance Request
196
NCB
U2A
4 eyes
Delete
T2S Dedicated Cash
Account
Maintenance Request
197
NCB, CSD, T2S Operator U2A
4 eyes
Delete
Rules
Maintenance Request
198
NCB, CSD, T2S Operator U2A
4 eyes
Delete
Parameters
Maintenance Request
199
NCB, CSD, T2S Operator A2A
2 eyes
Create
Parties
Maintenance Request
200
CSD
A2A
2 eyes
Create
Securities
Maintenance Request
201
CSD
A2A
2 eyes
Create
Securities Account
Maintenance Request
Final_T2S_GFS_110.doc
Page 563
REPRESENTATIVE USECASE
UC-SM-2: Static Data
Approval
UC-SM-1: Static Data
Maintenance
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
INSTRUCTING PARTY
ACCESS
TYPE
COMMENT
MODE
FUNCTION TYPE
DATA TYPE
ACTION TYPE
202
NCB
A2A
2 eyes
Create
T2S Dedicated Cash
Account
Maintenance Request
203
NCB, CSD, T2S Operator A2A
2 eyes
Create
Rules
Maintenance Request
204
NCB, CSD, T2S Operator A2A
2 eyes
Create
Parameters
Maintenance Request
205
NCB, CSD, T2S Operator A2A
2 eyes
Update
Parties
Maintenance Request
206
CSD
A2A
2 eyes
Update
Securities
Maintenance Request
207
CSD
A2A
2 eyes
Update
Securities Account
Maintenance Request
208
NCB
A2A
2 eyes
Update
T2S Dedicated Cash
Account
Maintenance Request
209
NCB, CSD, T2S Operator A2A
2 eyes
Update
Rules
Maintenance Request
210
NCB, CSD, T2S Operator A2A
2 eyes
Update
Parameters
Maintenance Request
211
NCB, CSD, T2S Operator A2A
2 eyes
Delete
Parties
Maintenance Request
212
CSD
A2A
2 eyes
Delete
Securities
Maintenance Request
213
CSD
A2A
2 eyes
Delete
Securities Account
Maintenance Request
214
NCB
A2A
2 eyes
Delete
T2S Dedicated Cash
Account
Maintenance Request
215
NCB, CSD, T2S Operator A2A
2 eyes
Delete
Rules
Maintenance Request
216
NCB, CSD, T2S Operator A2A
2 eyes
Delete
Parameters
Maintenance Request
217
All
A2A
2 eyes
Retrieve
Parties
Access Request
218
All
A2A
2 eyes
Retrieve
Securities
Access Request
219
CSD, CSD Participants
A2A
2 eyes
Retrieve
Securities Account
Access Request
Final_T2S_GFS_110.doc
Page 564
REPRESENTATIVE USECASE
UC-SM-3: Static Data
Access
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
INSTRUCTING PARTY
ACCESS
TYPE
COMMENT
MODE
FUNCTION TYPE
DATA TYPE
ACTION TYPE
220
NCB, Payment Banks
A2A
2 eyes
Retrieve
T2S Dedicated Cash
Account
Access Request
221
All
A2A
2 eyes
Retrieve
Rules
Access Request
222
All
A2A
2 eyes
Retrieve
Parameters
Access Request
REPRESENTATIVE USECASE
4.1.6. Queries
CRITERIA
ID
COMMENT
COMMUNICATION MODE
INSTRUCTING PARTY
223
QUERY CATEGORY
QUERY TYPE
U2A
CSDs
CSD securities account
monitoring
Holdings
U2A
CSDs
CSD securities account
monitoring
Transactions
U2A
CSDs
CSD securities account
monitoring
Cash Liquidity
226
U2A
CSDs
Instructions
Security Instruction
227
U2A
CSDs
Instructions
Security Instruction history
228
U2A
CSDs
Instructions
Audit trail instructions
229
U2A
CSDs
Security account
Security balance
230
U2A
CSDs
Security account
Security balance history
231
U2A
CSDs
Cash accounts
Cash balance
232
U2A
CSDs
Cash accounts
Cash forecast current settlement day
224
225
Final_T2S_GFS_110.doc
REPRESENTATIVE USE
CASE
UC-QU-1: Query on
Securities Settlement
Instructions
Page 565
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
COMMENT
COMMUNICATION MODE
INSTRUCTING PARTY
QUERY CATEGORY
QUERY TYPE
233
U2A
CSDs
Cash accounts
Cash forecast following settlement day
234
U2A
CSDs
Cash accounts
Cash account limits
235
U2A
CSDs
Cash accounts
Cash account list
236
U2A
CSDs
Cash account monitoring
Cash account monitoring
237
U2A
CSDs
Status of the settlement day
Status of the settlement day
238
U2A
CSDs
Static data
Static Data
239
U2A
Directly connected parties
Instructions
Security Instruction
240
U2A
Directly connected parties
Instructions
Security Instruction history
241
U2A
Directly connected parties
Instructions
Audit trail instructions
242
U2A
Directly connected parties
Security account
Security balance
243
U2A
Directly connected parties
Security account
Security balance history
244
U2A
Directly connected parties
Cash accounts
Cash balance
245
U2A
Directly connected parties
Cash accounts
Cash forecast current settlement day
246
U2A
Directly connected parties
Cash accounts
Cash forecast following settlement day
247
U2A
Directly connected parties
Cash accounts
Cash account limits
248
U2A
Directly connected parties
Cash accounts
Cash account list
249
U2A
Directly connected parties
Cash account monitoring
Cash account monitoring
250
U2A
Directly connected parties
Status of the settlement day
Status of the settlement day
251
U2A
Directly connected parties
Static data
Static Data
252
U2A
NCBs
Instructions
Security Instruction
253
U2A
NCBs
Instructions
Security Instruction history
Final_T2S_GFS_110.doc
Page 566
REPRESENTATIVE USE
CASE
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
COMMENT
COMMUNICATION MODE
INSTRUCTING PARTY
QUERY CATEGORY
QUERY TYPE
254
U2A
NCBs
Instructions
Audit trail instructions
255
U2A
NCBs
Security account
Security balance
256
U2A
NCBs
Security account
Security balance history
257
U2A
NCBs
Cash accounts
Cash balance
258
U2A
NCBs
Cash accounts
Cash forecast current settlement day
259
U2A
NCBs
Cash accounts
Cash forecast following settlement day
260
U2A
NCBs
Cash accounts
Cash account limits
261
U2A
NCBs
Cash accounts
Cash account list
262
U2A
NCBs
Cash account monitoring
Cash account monitoring
263
U2A
NCBs
Status of the settlement day
Status of the settlement day
264
U2A
NCBs
Static data
Static Data
265
U2A
NCBs
NCB liquidity monitoring
Total amount of liquidity
266
U2A
NCBs
NCB liquidity monitoring
Global amount of orders
267
U2A
NCBs
NCB liquidity monitoring
Limits for NCB liquidity monitoring
A2A
CSDs
CSD securities account
monitoring
Holdings
A2A
CSDs
CSD securities account
monitoring
Transactions
A2A
CSDs
CSD securities account
monitoring
Cash Liquidity
271
A2A
CSDs
Instructions
Security Instruction
272
A2A
CSDs
Instructions
Security Instruction history
268
269
270
Final_T2S_GFS_110.doc
Page 567
REPRESENTATIVE USE
CASE
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
COMMENT
COMMUNICATION MODE
INSTRUCTING PARTY
QUERY CATEGORY
QUERY TYPE
273
A2A
CSDs
Instructions
Audit trail instructions
274
A2A
CSDs
Security account
Security balance
275
A2A
CSDs
Security account
Security balance history
276
A2A
CSDs
Cash accounts
Cash balance
277
A2A
CSDs
Cash accounts
Cash forecast current settlement day
278
A2A
CSDs
Cash accounts
Cash forecast following settlement day
279
A2A
CSDs
Cash accounts
Cash account limits
280
A2A
CSDs
Cash accounts
Cash account list
281
A2A
CSDs
Cash account monitoring
Cash account monitoring
282
A2A
CSDs
Status of the settlement day
Status of the settlement day
283
A2A
CSDs
Static data
Static Data
284
A2A
Directly connected parties
Instructions
Security Instruction
285
A2A
Directly connected parties
Instructions
Security Instruction history
286
A2A
Directly connected parties
Instructions
Audit trail instructions
287
A2A
Directly connected parties
Security account
Security balance
288
A2A
Directly connected parties
Security account
Security balance history
289
A2A
Directly connected parties
Cash accounts
Cash balance
290
A2A
Directly connected parties
Cash accounts
Cash forecast current settlement day
291
A2A
Directly connected parties
Cash accounts
Cash forecast following settlement day
292
A2A
Directly connected parties
Cash accounts
Cash account limits
293
A2A
Directly connected parties
Cash accounts
Cash account list
Final_T2S_GFS_110.doc
Page 568
REPRESENTATIVE USE
CASE
T2S General Functional Specifications
Appendices
List of Use Cases
CRITERIA
ID
COMMENT
COMMUNICATION MODE
INSTRUCTING PARTY
QUERY CATEGORY
QUERY TYPE
294
A2A
Directly connected parties
Cash account monitoring
Cash account monitoring
295
A2A
Directly connected parties
Status of the settlement day
Status of the settlement day
296
A2A
Directly connected parties
Static data
Static Data
297
A2A
NCBs
Instructions
Security Instruction
298
A2A
NCBs
Instructions
Security Instruction history
299
A2A
NCBs
Instructions
Audit trail instructions
300
A2A
NCBs
Security account
Security balance
301
A2A
NCBs
Security account
Security bala