Potential change requests for a next release of T2S
Updated in January 2015
ECB T2S Programme Office
European Central Bank
1
Potential change requests for a next release of T2S
Background

ECB has been keeping a log of requests for changes that have been
postponed

The log of potential changes is kept for informative purposes

CRG members may add potential items to the log or provide comments

The log of potential changes needs to be revisited and assessed based on
the experience in production after the start of T2S
2
Potential change requests for a next release of T2S
List of request for changes (I)
Topic
Portfolio transfers
via FOP instructions
for which matching
is not required
Description
The French Market, in particular, retail custodians resort extensively to unmatched FoP transactions
for portfolio transfers. These transactions are processed on a STP basis using Euroclear proprietary
message which contains all relevant data (especially regarding taxes concerns). The current URDs
do not allow this type of transactions and require that all transactions should be submitted by both
counterparties and matched.
Pool counter should The internal counter of a pool ID is increased each time that a new instruction of the same pool ID is
be decrease when successfully validated by T2S. Likewise, T2S should decrease the internal pool counter if a SI were
an instruction is
cancelled later on by any reason (unilateral/bilateral T2S Actor cancellation or revalidation by T2S).
cancelled
Check that no
position remains
before securities
deletion
Securities Creation
in one step
Settlement unit
multiple should be
date dependent
Validations to check that there is no remaining position when there is a deletion request of a
security or a T2S account should be foreseen in T2S current design.
The creation of securities in T2S requires multiple steps. This may need to be simplified and
messages to be exchanged between the CSD and T2S in real-time and in STP manner.
The attribute settlement unit multiple of the Securities entity should be date dependent.
3
Potential change requests for a next release of T2S
List of request for changes (II)
Topic
Description
• A Static Data object creation and an update of an Static Data object related to a restriction for
type 1 should trigger a revalidation of all relevant settlement instructions (e.g. creation of a new
Revalidation upon a
restriction, addition of a rule to an existing restriction, update of rule parameters for a specific rule,
modification of
change of values in a rule matrix entry, etc.).
values of a market
• T2S should check the applicable restrictions for type 1 again when T2S performs a revalidation
specific attribute
of SI due to recycling or Static data update (e.g. a SI might be put on CSD Validation Hold again
after a revalidation; a static data update of security's MSA triggers revalidation).
Definition of
Restriction
A Central Bank (CB) should be able to define restriction processing types ‘Rejection’ or ‘CSD
Processing Types by Validation Hold’ on Settlement Instructions (SI) and Intra-balance movements
Central Banks
Securities Valuation UR T2S.16.520 predicates that each occurrence of the Securities Valuation entity is linked to one
entity might be linked and only one party. This is not the case for Eurosystem collateral where many central banks have
to more than a party the same collateral prices for a given financial instrument
Reverse booking of
failed liquidity
transfer via GUI
New message
subscription
parameters for cash
account, cash
parties and
instructing party
There should be a pre-filled GUI screen allowing triggering the unwinding of outbound liquidity
transfers that have failed to settle in the RTGS system.
• It should be possible to subscribe to a sese.024 based on the DCA impacted by the settlement
instruction
• For sese.024 and sese.025 the cash related parties, the instructing party should be added as
eligible message subscription parameters.
4
Potential change requests for a next release of T2S
List of request for changes (III)
Topic
Creation of new A2A
messages for
existing U2A
functions
Description
• Creation of new messages to cover the maintenance of Restriction type rules or some queries
• Maintenance of roles and privileges in A2A
• Message subscription rule maintenance in A2A
• Close links need to be maintained via A2A
• There should be an A2A message to make securities ineligible for auto-collateralisation (T2S0384-SYS)
Enhancement of the It might be needed to assess whether the close links model for Central Banks and Payment Banks
close link model
is adequate in the day-to-day operation.
Enhancement of the • It might be needed to assess whether the rule-based model is adequate in the day-to-day
rule-based model
operation
• CoSD rules could be enhanced to add market specific attributes as parameters.
Enhancement of
query possibilities
via U2A and A2A
• Enhancements to query search parameters to fine-tune the queries output after an assessment
of the day-to-day operation
• Query of business and technical objects such as settlement transactions/ collections by T2S
Operators and other T2S system users of a CSD/ NCB/ etc.
• Provision of alert features in T2S GUI. E.g. If the counterpart CSD can see in the GUI, that the
other CSD (cross CSD scenario) has not set-up the static data (kind of warning).
Possibility of Already The purpose of the change is to allow T2S actors to send already matched securities settlement
Matched Cross-CSD instructions both for intra-CSD and for inter-CSD settlement. A pre-condition for any such
Settlement
instructions is, of course, that the T2S Actor has received the rights to instruct over the relevant
Instructions
securities accounts (T2S-0383-URD)
5
Potential change requests for a next release of T2S
List of request for changes (IV)
Topic
The Effective
Settlement Date
should provide
“datetime” instead of
the “date” across
different reports
Description
The “datetime” instead of the “date” should be used for the Effective Settlement Date in a
harmonised way across different T2S reports and response messages. While Securities
Transaction Posting Report (semt.017) provides the “datetime” the following messages provide
the “date”: Intra-Position Movement Posting Report (semt.016), Securities Settlement Transaction
Query Response(semt.027), Intra-Position Movement Query Response (semt.029), Intra-Balance
Movement Query Response (camt.079), Intra-Balance Movement Posting Report (camt.084)
Currency should be Add the currency as a search criteria in the standing and pre-defined liquidity transfer query in the
a search criteria in
T2S GUI (see approved Change Request T2S-0416-BFD).
the standing and
pre-defined liquidity
transfer query in the
T2S GUI
Lot number and lot
quantity fields should
report the restriction
references
The Securities Settlement Transaction Confirmation (sese.025) could use the lot number and the
lot quantity fields to report the restriction references used by T2S as currently the sese.025 only
communicates one restriction reference in a direct debit scenario (i.e. scenario where in the
settlement of a settlement instruction, the usage of restriction references is not complemented by
another securities position).
Remove the
Specific conditions applying to exchanges of messages between T2S and T2S Actors during the
coexistence rules for so-called “coexistence period”, during which information carried out by ISO 20022 messages
messages
remain compatible with equivalent information carried out by ISO 15022 messages. At the end of
the coexistence period, the related rules could be lifted.
6
Potential change requests for a next release of T2S
List of request for changes (V)
Topic
Description
Adaptation to the
evolution of BIC’s
structure based on
ISO9362
implementation
The evolution of BIC’s structure could have an impact on how the T2S Actors uses the
BIC in T2S (e.g. configuration of Credit Memorandum Balance) and might require some
changes in T2S. SWIFT as Registration Authority proposes to continue to respect the
BIC1 convention for FIN connectivity in the ISO 9362 registration process during an
extended transition period that will be agreed with the community and with ISO, and make
the same connectivity information available as a new attribute in SWIFTRef directories.
During this transition period, legacy applications that depend on the BIC1 convention will
be protected. Users building or refreshing applications that refer to the BIC1 will be
strongly encouraged to switch to the use of the new attribute rather than derive
connectivity information from the value of the 8th character of the BIC.
Some solution could be envisage to support an investor CSD to ensure alignment of
positions between a mirror account and related omnibus account (this possibility was
discussed at the end of 2013 in the context of the provision check on omnibus account)
Support investor
CSD to ensure
alignment of
positions between
a mirror account
and related
omnibus account
T2S should inform The response message to the securities valuation file should include information about
about ineligible
whether a Security for which a security valuation is provided, was not eligible for autosecurities for auto- collateralisation
collateralisation
when uploading
prices
7
Potential change requests for a next release of T2S
List of request for changes (VI)
Topic
Description
Invoice with itemised
billing data instead of
cumulative billing
data
Automated
procedure to upload
T2 RTGS accounts
from the T2 directory
Possibility to receive T2S invoice with itemised billing data instead of cumulative billing
data
Functionality to turn
off the message
subscription during a
specific phase of the
settlement day
Identification of the
Securities
Maintaining Entity
(SME) in the Security
screen
A fully automated upload of the T2 RTGS static data into T2S by a regular import of the
TARGET2 directory, substituting the manual input of static data in U2A mode by the
NCBs for the accounts within their domain.
There should be a functionality to turn off the message subscription for specific parties
(e.g. Directly Connected Parties) in order that T2S does not send messages during a
particular phase of the settlement day (e.g. to turn off subscription to receive the
settlement confirmation during the night-time settlement)
The SME attribute should be added to the existing security list screen. The screen
should allow filtering to retrieve all ISINs for which a CSD is SME, the SME attribute(s)
for an individual ISIN or a group of ISINs identified by the ISO country code contained in
the ISIN.
It should be possible to download the results in a supported format (.xml, .csv or .xls).
The access to this information shall be controlled via specific access rights.
Update of Security & To add a column for the Restriction Type (e.g.BLO1, RES1, etc.) in the Security & Cash
Cash Restrictions
Restrictions screens in T2S GUI
screens
8
Potential change requests for a next release of T2S
List of request for changes (VII)
Topic
Description
Acceptance of liquidity T2S should be able to accept liquidity transfer orders with a future settlement date. For
transfer order with a
example, if an RTGS is closed on the Good Friday and Easter Monday but T2S is open
future value date
on these dates, the RTGS should be able to send a liquidity transfer order on the
previous Thursday with a value date on Tuesday.
Further breakdown of
the billing data
It should be possible to have a further breakdown of the billing data to do a validation of
the T2S data.
Parameter in the
restriction type for
ICP/DCP
As part of the XMAP analysis of restriction rules, we see many CSDs are obliged to
create an MSA on party with party flag as DCP versus ICP. This is to prevent that
restriction rules apply on instructions sent by ICPs, which the CSD could already
validate, or to identify and further control DCP instructions. It would be good if there
could be a parameter in the restriction type for ICP/DCP.
CSD participants to
To allow CSD participants to send instructions to T2S even after the maturity date of a
send settlement
security till another specified date (long-term solution raised by the CASG in the context
instructions to T2S
of CR 471):
even after the maturity The preferred (long-term) solution of the CASG is to adhere to the standards and allow
date
CSD participants to send instructions to T2S even after the maturity date of a security till
another date (as of today 20 business days after the maturity date of a security but
should be a parameter that can be configured).
The reserved priority
default per CSD
T2S should allow definition of the reserved priority default per CSD.
ESMA technical
standards of CSDR
level 2
Potential changes from the technical standards (Settlement discipline, CSD
recordkeeping of CSDR level 2
9
Potential change requests for a next release of T2S
List of request for changes (VIII)
Parked CR
T2S-0346-URD
T2S-0350-URD
T2S-0354-SYS
Description
In the settlement process of an instruction without a link, T2S should consider any other
unmatched instructions having a link with it
Pre-defined Orders for EOD FOP account transfers
T2S-0355-URD
Counterparty BIC and Counterparty CSD BIC as additional validation parameters for case
1 restrictions
New account flag “negative position only”
T2S-0358-URD
Unblocking of ISINs as part of Corporate Action Handling
T2S-0359-URD
Changes of hold/release to counterparty before the Intended Settlement Date
T2S-0362-URD
Account nature compatibility check
T2S-0365-SYS
Addition of validity date to Market-specific attributes
T2S-0367-SYS
Possibility to subscribe to copies based on the sending channel (A2A or U2A)
T2S-0368-SYS
Easier retrieval of the ex/cum indicators for market claims
T2S-0375-URD
Control of provision on position earmarked for auto-collateralisation
Description of parked CRs is available on the T2S website (Change Request list)
10
Potential change requests for a next release of T2S
List of request for changes (IX)
Parked CR
Description
T2S-0375-URD
Control of provision on position earmarked for auto-collateralisation
T2S-0397-SYS
Addition of the Category attribute to the static data entities Securities, Party and Securities
Account
T2S-0436-URD
Client-collateralisation: allow payment banks to set up their own list of close links
T2S-0439-SYS
Decoupling of the link between securities and cash accounts for settlement and the link for
the provision of collateral
T2S-0444-BFD
User authentication without USB-token/SmartCard for GUI-access
T2S-0446-SYS
Blocking of U2A interface for submitting new instructions to T2S during reconciliation
process post RAD (Recovery After Disaster)
Description of parked CRs is available on the T2S website (Change Request list)
11
Thank you for your attention
www.t2s.eu
12