T2S ITNUG
8^ riunione
Milano, 26 maggio 2010
Banca d’Italia
Servizio Sistema dei Pagamenti
Fabrizio Palmisani
Paolo Bramini
Luca Rissolo
Barbara Lupi
Alessandra Baruzzo
Sommario

Stato di avanzamento del progetto T2S

Governance esterna

Aggiornamento su pricing e connectivity

Graphic User Interface

Processo di adeguamento di Monte Titoli a T2S

Varie ed eventuali
Stato di avanzamento del
progetto T2S
T2S: nuove key dates


La tempistica dell’intero progetto è stata ampiamente rivista, principalmente per
permettere alle 4CB di recepire le numerose richieste di integrazione delle
specifiche funzionali formulate dal mercato.
Le tappe del progetto sono state posticipate di circa un anno.
Development Phase
Aprile 2011:
Firma (FA e CPA)

Luglio 2010:
GovC accetta
l’offerta di
Governance
Sett 2013
Consegna software
delle 4CB
all’Eurosistema
Testing Phase
Gennaio 2014
Inizio test esterni
Migration Phase
Sett 2014:
Avvio di T2S
(prima finestra
Di CSDs)
Più a breve termine, le scadenze più significative del 2010/inizio 2011 sono le
seguenti:
Settembre 2010:
Asta per i network
providers
Ott 2010-Genn 2011:
Firma contratti
Eurosistema-CSDs
UDFS 1.0
Marzo 2011:
UDFS 1.0
Aprile 2011:
Firma (FA e CPA)
T2S FA and CPA

L’attività più importante dei prossimi mesi sarà la finalizzazione del Framework
Agreement (FA), base per tutte le relazioni contrattuali tra Eurosistema e CSDs.
L’FA sarà composto da : il “Core FA”; diversi allegati (c.d. schedule), relativi ai
vari aspetti del framework (es: SLA, pricing, governance).
Le tappe fondamentali sono:






Luglio 2010: approvazione dell’interim-FA dal parte del Consiglio direttivo;
Luglio 2010: consegna della bozza del FA ai supervisori europei (CESR);
Ottobre 2010: risposta del CESR;
Novembre 2010: ulteriore confronto con i CSDs per integrare eventuali commenti e modifiche
suggerite dal CESR;
Gennaio 2011: approvazione del GovC;
Aprile 2011: firma del FA da parte dei CSDs.
L’FA potrà essere modificato soltanto con il consenso di entrambe le parti
(Eurosistema e maggioranza dei CSDs).

Il secondo accordo contrattuale riguarda le banche centrali non appartenenti
all’area dell’euro che hanno accettato di regolare le loro valute in T2S (Currency
Participation Agreement, CPA), la cui finalizzazione è prevista per la fine del
2010.
Migrazione a T2S






Previste 3 finestre di migrazione.
Durata del periodo di migrazione ancora in via di definizione (termine:
non oltre il 2015).
Esigenza di una “light wave zero” (i.e. migrazione di CSDs con una
quota di mercato non superiore a una determinata percentuale) ma …
… inclusione nella prima finestra di CSD con operatività il più
possibile differenziata.
La Banca centrale greca si è dichiarata disponibile a migrare nella
prima finestra.
Costituzione di un gruppo di CSD “pilota” che verrebbe coinvolto
dall’Eurosistema nelle attività di carattere tecnico-funzionale anche
prima dell’avvio ufficiale dei test esterni (gennaio 2014).
Futura governance “esterna”

L’attuale governance esterna (AG e CCG) rimarrà in essere fino alla
firma del FA.

E’ stata elaborata una proposta per la futura governance esterna, che sarà
presentata all’AG per la discussione nel meeting di giugno.

All’inizio del 2010 era stata costituita una task force per valutare
l’opportunità di istituire una Separate Legal Entity (SLE). Solo le banche
non appartenenti all’area dell’euro che regoleranno le loro valute in T2S
erano a favore di tale soluzione. Il Consiglio direttivo ha pertanto deciso
che, nel definire la futura struttura di governance, non venga più presa in
considerazione l’ipotesi di costituire una SLE.
Date prossimi meeting

Prossimo AG: Frankfurt, 1-2 giugno 2010.

Prossima T2S Info Session: Copenhagen, 24 giugno
2010 (prevista la discussione su tematiche quali la
connectivity e il liquidity management).
Governance esterna
Stakeholders’ objectives

Euro & non-euro central banks: control of their respective currencies;
efficient oversight; level playing field for market participants.

Eurosystem: in addition, recovery of investment as owner and operator
of T2S.

CSDs: control over customers’ securities accounts; development of
innovative services; compliance with evolving legal and regulatory
requirements.

Users: ensure good and efficient T2S service; maintaining level
playing field.
Governance principles





Eurosystem
l

Reflected in the current governance
Proposal: future governance should follow
these principles
Crucial: market involvement and transparency
re
a
c
e
n
tra

Ownership
Financial and reputational risk
Legal requirements
Impact on business models
Users
CSDs
euro a
No
n

System of checks and balances
Varying degree of influence of different stakeholders,
depending inter alia on
banks

Main governance bodies and
their composition

ECB Governing Council.

T2S Managing Board (Eurosystem, non euro-central banks,
independents)

Foreign Currency Steering Group (non-euro central banks)

CSD Steering Group (CSDs and MB)

Advisory Group (equal representation of market stakeholders)
Governing Council and
T2S Managing Board (MB)

Functioning of cash accounts and DvP settlement in central bank money are core
tasks of the Eurosystem.

Governing Council can delegate only limited and pre-defined managerial,
technical and operational tasks MB responsibility limited to administrative tasks


Possibility for CSDs to obtain certain rights and responsibilities regarding the functioning of securities
accounts  Framework Agreement
Agreement of non-euro central banks for issues relating to functioning of cash accounts required 
Currency Participation Agreement

MB / Governing Council retain possibility to object, for objective and transparent
reasons related to the functioning of the cash accounts and to the integrity of T2S.
Foreign Currency
Steering Group (FCSG)

Currency Participation Agreement for rights and obligations of
Eurosystem and non-euro central banks.

Full and exclusive authority for non-euro central banks for management
of respective cash accounts.

FCSG meetings on ad hoc – basis at level of deputy governors.

Majority rules to be defined by non-euro central banks.

Eurosystem involvement limited to potential mediation role.
CSD Steering Group (CSG)

Framework Agreement for rights and obligations of Eurosystem and CSDs.

Full and exclusive authority for CSDs for management of respective
securities accounts.

Responsibilities:


Discussion and adoption of possible amendments to the functioning of securities accounts.
Adoption of resolutions on any matter concerning T2S.

Majority rules to be defined by CSDs to prevent individual CSD veto right
in T2S.

Exceptional direct access to Governing Council.
Advisory Group (AG)

AG maintains its function as advisory body to the Eurosystem.

Responsibilities:


View requested on all decisions of the Governing Council and all relevant issues delegated to
the MB, in particular the assessment of proposals affecting the level playing field in securities
settlement markets
Involvement in any matter concerning T2S upon AG initiative

Meetings at least twice a year.

Simple majority of full members.

Exceptional direct access to Governing Council.
Resolution adoption for
technical and other changes







Same transparent process with involvement of all relevant stakeholders and
without unilateral Eurosystem decisions as in previous phases.
Any member of the AG, CSG or the FCSG can propose a resolution.
Need for MB assessment of CSG resolutions prior to implementation.
If consensus between MB and CSG (and, if applicable, the AG / FCSG) and
proposal is of administrative nature (i.e. delegated to MB) 
implementation.
Otherwise  Governing Council decides.
Hence, special safeguards for strategic issues such as T2S Principles
including direct access to Governing Council for CSG and AG.
Key: transparency of whole process via T2S website.
Additional governance
arrangements

Option for CSDs to have specific changes implemented at their own cost.

Prioritisation: CSG for change requests from CSDs, MB for all change
requests.

Changes driven by legal and regulatory requirements:


Implementation with high priority in line with Principle 20.
In exceptional cases, Eurosystem might object for objective and transparent reasons, in
particular related to the functioning of cash accounts and the integrity of T2S.

Dispute resolution procedure in an amicable way: technical / expert level,
CSG, MB, Governing Council, subject to challenge in court.

Viable exit procedure.

Day-to-day operations & crisis management  see Manual of Procedures.
Proposed T2S Governance
ECB Governing Council
Executive Board
Foreign Currency
Steering
Group
National
User
Groups
Subgroup
…
T2S Management
Board
CSD
Steering
Group
Subgroup
…
Advisory
Group
Subgroup
…
Subgroup
…
Information
Sessions
with all
Stakeholders
Subgroup
…
Aggiornamento su pricing e
connectivity
Pricing: richieste dell’AG
Eliminare i seguenti elementi del quadro tariffario:








Surcharge for top priority
Charge for fail on intended settlement day
Hold and release charge
Day settlement surcharge
Account management service
Subscription fee
Auto-collateralisation with NCB
Fees for cancellation and blocking (riduzione)
Pricing: nuova proposta del PB

Eliminate le subscription fees.

Mantenute le altre tariffe, sempre espresse come Process Weight Factor
(PWF) rispetto al servizio base (DVP night time settlement instruction
without matching).

Tariffare separatamente ogni istruzione derivante dal partial settlement.

Ridotte le fees for cancellation.

Introdotta una tariffa aggiuntiva (message subscription services)
Principali elementi della nuova proposta (i)

Auto-collateralisation with NCB: tariffa forfettaria per ogni conto ritenuto idoneo
(livello della tariffa ancora da definire).

Auto-collateralisation with payment/settlement bank (CMB): tariffa forfettaria per
ogni conto ritenuto idoneo, più alta di quella di cui al punto 1).

Daytime settlement: maggiorazione di (almeno) il 20% rispetto a quella notturna;
previsione di una ulteriore maggiorazione per il “last two-hour settlement”
(inizialmente non applicata).

Message subscription service: tariffa applicata, a fronte di ogni singola istruzione,
per tutti i msg. oltre il 4°.

FoP: PWF 60%.

Matching: PWF 20%.
Principali elementi della nuova proposta (ii)







Queries and reports: nei primi 6 mesi, tariffa fissa in base al numero
di istruzioni di regolamento; successivamente, tariffa indifferenziata
per queries e report; differenziata tra A2A (tariffa fissa in base al
“business item report”) e U2A (Kb of output? Fixed charge?)
richiesta all’AG di indicazioni sui criteri di tariffazione ritenuti
più idonei.
Fail on intended settlement day: aumentata la tariffa (PWF dal 40% al
60%).
Account allocation: PWF 30%.
Settlement modification: PWF 10% (solo per Hold and Release, e
solo in caso di modifica; provvisoriamente azzerate le tariffe
applicate alle altre tipologie di modifica).
Cancellation: PWF dal 50% al 40%.
Blocking/Unblocking/Reservation/Earmarking: PWF dal 50% al 40%
High and Top Priority: PWF = 10%.
User connectivity

Estate 2010: Public consultation sui criteri di selezione.

Autunno 2010: asta pubblica (gestita da Banca d’Italia per conto
dell’Eurosistema).

Autunno 2011: selezione dei network providers.

E’ ancora in discussione la tematica relativa al disaster recovery
(i.e. retrivial vs. resending).
Graphic User Interface
Stato della documentazione
sulla GUI
INPUT:
Documento sui Requisiti utente
General Functional Specifications
Funzionalità di Business della GUI
T2S: Analisi e Documentazione
OUTPUT:
Descrizione delle funzionalità di Business
della GUI e
Framework dell’Interfaccia Utente
L’attività fornirà la documentazione di supporto per il disegno tecnico e
funzionale della GUI di T2S (schermate reali)
Principi generali della GUI (i)

Neutralità
La GUI T2S non dovrà risultare specifica per un singolo Paese o istituzione finanziaria, ma
dovrebbe presentare le caratteristiche di un sistema pan Europeo.

Chiarezza e semplicità nella navigazione
La GUI T2S dovrà risultare chiara da un punto di vista visivo, concettuale e linguistico, e
presentare un facile accesso alle funzionalità che permetta un’identificazione immediata delle
funzionalità.

Comprensibilità
La GUI T2S dovrebbe consentire agli utenti una comprensione e un apprendimento rapida del
sistema. L’utente deve essere in grado di sapere:



Cosa fare
Cosa tenere sotto controllo
Quando, dove e come farlo.
Il disegno della GUI T2S relativo al flusso di azioni, risposte, e preparazione visiva delle
informazioni dovrebbe essere tale da rendere facile raccogliere e contestualizzare le
informazioni stesse
Principi generali della GUI (ii)

Coerenza


Aspetti relativi alla sicurezza


E’ auspicabile un accordo sullo stile e il layout per assicurare una identica
implementazione delle funzioni comuni.
L’autenticazione degli utenti dovrebbe essere richiesta solo al momento di stabilire la
connessione a T2S e dovrà rimanere valida durante tutta la sessione. L’utente non dovrà
aver bisogno di effettuare ulteriori login nella singola sessione.
Supporto

Il disegno della GUI T2S dovrà presentare una sezione di aiuto (comprendente p. es.
alcune FAQ) per ogni interfaccia utente. Nelle GFS i principi di “Usabilità”, “Controllo
Utente” e “Tempi di reazione” vengono citati ripetutamente.
Scope della GUI

Supportare tutte le funzionalità standard di T2S quali, ad es.:
 Servizi di regolamento:
Ricerca e manutenzione di istruzioni, aggiunta di istruzioni ecc.
 Servizi di gestione della liquidità
Ricerca e manutenzione di trasferimenti immediati di liquidità, aggiunta di
trasferimenti immediati di liquidità, Inquiry sulla gestione di liquidità ecc.
 Servizi relativi agli “Static data”
Dati di riferimento sulle Valute, dati di rifermento sui titoli, Dati di riferimento sulle
controparti ecc.
 Servizi di operatività e supporto
Gestione del “4-Eyes”, gestione della Riattivazione e della Revisione
 Servizi informativi
Gestione del “4-Eyes”, gestione della Riattivazione e della Revisione
 Servizi di connettività/comunicazione
Gestione dei messaggi

Si potranno definire ruoli e assegnare privilegi
Varie ed eventuali
Cross-CSD settlement

Al prossimo AG di giugno verrà proposta la costituzione di un
apposito gruppo (substructure) per analizzare le specificità dei diversi
sistemi di regolamento titoli che possono essere di ostacolo allo
“smooth cross-CSDs settlement” in T2S.

I compiti della substrucutre sarebbero i seguenti:




analisi di aspetti tecnico-funzionali di T2S (es: utilizzo delle funzionalità “CSD
Validation Hold” e “Rejection” come “restriction processing type”; utilizzo della
Conditional Securities Delivery);
definizione di una lista completa degli elementi che impediscono l’end-to-end
processing nel cross-CSD settlement (es: calcolo e introito della withholding tax,
rilevante anche per il sistema Italia);
definire le priorità degli interventi da realizzare, nonché i relativi tempi e costi di
realizzazione, per standardizzare i processi (impatto sulle URD?);
operare in stretto contatto con i mercati nei quali sono presenti le specificità
nazionali, coinvolgendo poi tutti i mercati nella valutazione delle proposte per
standardizzare i processi.
Cross-CSDs settlement:
specificità nazionali











Checks for preventing money laundering and terrorist financing
(Germany)
Nationality declaration (the UK, Ireland)
Registered References for Spanish equities (Spain)
Layered model (Direct holding markets)
Collection of withholding tax (Belgium, Italy)
Calculation and collection of stamp tax (the UK, Ireland)
Securities not eligible for certain account or investor types (many
markets)
Operations not eligible on certain accounts (many markets)
Non-eligible parties for instructing on certain accounts (many
markets)
Settlement of non-fungible securities (many markets)
Mandatory segregation of assets on CSD accounts (many markets)
ISO coexistence 15022/20022

Le 4CB stanno conducendo una impact analysis per valutare
la possibilità di gestire entrambi gli standard dopo la go-livedate di T2S (sia per i messaggi inbound sia per quelli
outbound).

L’analisi viene condotta sulla base, oltre che delle URD v. 5.0
e delle GFS v. 4.0, anche della c.d. “list of coexistence rules”
della SWIFT.

Non è attualmente prevista una end-date per l’ISO 15022.