JOURNAL TRANSCRIPT

---

General Information (Origin of Request) User Requirements (URD) Other User Functional or Technical Documentation (SYS) Request raised by: XMAP

Institute: ECB

Request title: Currency, Settlement amount and debit/credit indicator should be additional matching fields for FOP instructions

Date raised: 29/06/2015 Request ref. no: T2S 0526 URD

Request type: Common

Urgency: Fast-track

1. Legal/business importance parameter: High

2. Market implementation efforts parameter: Low

3. Operational/Technical risk parameter: Low

4. Financial impact parameter: Medium

Requestor Category: T2S sub-group

Status: Assessed

Reason for change and expected benefits/business motivation: T2S is designed as a multi-currency securities settlement platform in Central Bank Money, and provides the possibility to settle securities against payment (DVP) as well as Free-Of-Payment (FOP). For the initial release of T2S however, Euro will be the only eligible settlement currency. The Danish Krone will become eligible in 2018. T2S also offers the flexibility to facilitate settlement in non-T2S settlement currencies, e.g. through the use of the Conditional Securities Delivery (COSD) functionality. This is deemed as a key functionality as several CSDs offer settlement services in multiple currencies. As part of the business validation process, T2S validation rules prevent any non-T2S currency to be used in a DVP settlement instruction (see UDFS, page 229, line 6: “To that purpose, the following checks are performed: - The Currency of a Settlement Instruction against payment or of a Settlement Restriction on cash is a T2S Settlement Currency.”). In order to cope with settlement of transactions containing a cash leg in a non-T2S currency, DVP instructions in non-T2S currencies can be submitted into T2S as FOP instructions (i.e. with Payment Flag FREE), and use the COSD process to ensure DVP. This approach implies that such “masked DVP” instructions are subject to the matching rules of a FOP instruction. In particular this implies that neither currency nor amount nor credit/debit indicator is considered during the matching process. As a consequence, such non-T2S Currency FOP instructions could be subject to the following matching results. E.g.:   

A non-T2S Currency FOP Instruction could be matched to a “true” FOP instruction A non-T2S Currency FOP Instruction in USD could be matched to a non-T2S Currency Instruction in GBP The cash amounts of two non-T2S Currency Instructions which are matched could be outside of the matching tolerance  A non-T2S Currency FOP which mimics a DVP could be matched to another one which mimics a RWP instruction. The risk of mismatching in T2S is therefore deemed high for settlement of those transactions with a cash leg in nonT2S-currencies. Furthermore, in case of discrepancy in the fields informed by the two counterparties of the transaction for FOP instructions, the COSD functionality might not have the expected behaviour, as the check on the fulfilment of a rule is performed at transaction level but the value assigned is derived from a single leg. An approach must be found to make sure that the matching process of such non-T2S Currency FOP instructions provides meaningful results. Following a CRG written procedure, the CRG members indicated below list of non-T2S currencies being currently maintained in their system:

Code

Currency

AUD

Australian dollar

BHD

Bahraini dinar

T2S Programme Office

CAD

Canadian dollar

CHF

Swiss franc

CNY

Chinese yuan

CZK

Czech koruna

DKK

Danish krone

GBP

Pound sterling

HKD

Hong Kong dollar

HUF

Hungarian forint

JPY

Japanese yen

MXN

Mexican peso

NOK

Norwegian krone

NZD

New Zealand dollar

PLN

Polish złoty

SEK

Swedish krona/kronor

RUB

Russian ruble

TRY

Turkish lira

SGD

Singapore dollar

USD

United States dollar

ZAR

South African rand

ZMK

Zambian kwacha

BRL

Brazilian real

ARS

Argentine peso

BAM

Bosnia and Herzegovina convertible mark

BGN

Bulgarian lev

COP

Colombian peso

EGP

Egyptian pound

HRK

Croatian kuna

Request: T2S 0526 URD

2

T2S Programme Office

IDR

Indonesian rupiah

ILS

Israeli new shekel

ISK

Icelandic króna

KRW

South Korean won

KZT

Kazakhstani tenge

MYR

Malaysian ringgit

PEN

Peruvian nuevo sol

PHP

Philippine peso

QAR

Qatari riyal

RON

Romanian leu

RSD

Serbian dinar

SAR

Saudi riyal

THB

Thai baht

Request: T2S 0526 URD

It should be possible for the T2S Operator to maintain a list with an OMG procedure to configure the tolerance for the currency. The number of decimals for the settlement amount in the FOP with the non-T2S currency need not be validated in T2S against the number of decimals defined for that currency, as the cash settlement will never be done in T2S for non-T2S currencies. _______________________________________________________________________________________________ Description of requested change: In order to ensure correct processing of DVP transactions in non-T2S currency, the following solution is proposed: Extend set of additional matching fields for FOP instructions: The set of additional match fields for FOP instructions must be extended by the following three fields: “Currency”, “Amount” and “Credit/Debit” Indicator. If such fields are present in a FOP instruction, T2S must ensure during the matching process that the corresponding attributes in the counter-leg match. This will ensure that the risk of mismatching is minimised, while not forcing to populate the field in “normal” FOP instruction due to the additional character of the field. To enable correct matching for amounts based on tolerance level, the tolerance amount per currency must be configurable in T2S. In case the tolerance amount is not available for a currency defined in ISO 4217 standard, T2S must do matching with the exact amount available in the instruction. _______________________________________________________________________________________________ Submitted annexes / related documents: _______________________________________________________________________________________________ Proposed wording for the URD Change request: The User Requirement Document shall be modified as follows:

3

T2S Programme Office

Request: T2S 0526 URD

5.5.3 Non-mandatory matching fields […] DVP

FOP

Opt-out ISO transaction condition indicator

Opt-out ISO transaction condition indicator

Ex/cum ISO transaction condition indicator

Ex/cum ISO transaction condition indicator

n/a

Currency

n/a

Settlement Amount

n/a

Credit/Debit

Proposed wording for the SYS Change request: UDFS section Diagram 70 on page 317 of the UDFSv2.1 must be updated to include the additional matching fields for FOP instructions: DVP/DWP

FOP

Opt-out ISO transaction condition indicator CUM/EX Indicator * n/a

Currency

n/a

Settlement Amount

n/a

Credit/Debit

The corresponding picture for diagram 70 must be updated to include the new additional matching fields and a footnote to clarify why such attributes would be present in a FOP instruction, namely in case of DVP settlement in a non-T2S currency where the instructions are entered into T2S as FOP instructions with the DVP-related attributes are filled.

The statement on the tolerance amount (UDFS page 291, “If all the Matching fields on both instructions match, except for the Settlement Amount, T2S checks if the difference between both Settlement Amounts is compliant with the tolerance amount configured in T2S.”) implicitly applies equally to the case where the amount is contained in a FOP instruction as an additional match field.

4

T2S Programme Office

Request: T2S 0526 URD

GFS section To update the list of Additional Matching fields described in page 246 of the GFS 5.1:

DVP/DWP

FOP

Opt-out Settlement transaction condition indicator CUM/EX Indicator n/a

Currency

n/a

Settlement Amount

n/a

Credit/Debit

_______________________________________________________________________________________________ High level description of Impact: _______________________________________________________________________________________________ Outcome/Decisions: * CRG meeting of 9 July 2015: The CRG decided to put the Change Request on hold and agreed that the Change Request T2S-0526-URD could be a potential candidate for fast-track Release 1.2. The CRG also agreed that the Change Request needs to be updated with regards to the currency values which will be included in operations and a procedure for revising their tolerance values on a regular (e.g. yearly) basis. * CRG meeting of 17-18 September 2015: The CRG agreed to put the Change Request on hold and agreed to include it in the list of Change Requests for Release 1.2. The CRG considered that the Change Request is critical for the migration of wave 3 participants. * CRG teleconference of 1 October 2015: The CRG recommended to launch the detailed assessment on the Change Request. * Advisory Group’s advice on 8 October 2015: Following a written procedure, the AG was in favour of launching the detailed assessment on the Change Request. * CSG resolution on 9 October 2015: Following a written procedure, the CSG was in favour of launching the detailed assessment on the Change Request. * OMG on 16 October 2015: During a written procedure from 2 October 2015 to 16 October 2015, the Operations Managers Group did not identify any operational impact of the Change Request.

5

T2S Programme Office

Request: T2S 0526 URD

EUROSYSTEM ANALYSIS – GENERAL INFORMATION

Impact On T2S

Static data management Party data management Securities data management T2S Dedicated Cash account data management Securities account data management Rules and parameters data management

Interface Communication Outbound processing Inbound processing

Settlement Standardisation and preparation to settlement Night-time Settlement Daytime Recycling and optimisation Daytime Validation, provisioning & booking Auto-collateralisation

Liquidity management Outbound Information Management

Operational services Data Migration Scheduling Billing Operational monitoring

NCB Business Procedures Liquidity Operations LCMM Instructions validation Status management x Instruction matching Instructions maintenance Statistics, queries reports and archive Report management Query management x Statistical information Legal archiving

All modules (Infrastructure request) No modules (infrastructure request) Business operational activities Technical operational activities Impact on major documentation Document Chapter 3.4.5 Instruction Matching Impacted GFS chapter Section 1.6.1.2.3 Matching Process Impacted UDFS chapter

Change To update the list of Additional Matching fields To update the pictures for table 111 To add a footnote to clarify why some attributes would be present in a FOP instruction

Additional deliveries for Message Specification UHB External training materials

No impact LCMM T2S_FA_WS 2_Part3_SETT_MTCH_MNTN

Update matching training materials

Other documentations Links with other requests Links Reference Title OVERVIEW OF THE IMPACT OF THE REQUEST ON THE T2S SYSTEM AND ON THE PROJECT Summary of functional, development, infrastructure and migration impacts The impacts of this change request on the T2S domains/modules are the following: LCMM:

6

T2S Programme Office

Request: T2S 0526 URD

The matching algorithm function needs to be updated in order to include the credit debit indicator, the currency and the settlement amount as new additional matching fields for FoP instructions. Also, the settlement amount tolerance function should be updated in order to take into account the FoP instructions. If no tolerance amount is found when accessing Static Data, then both settlement amounts must be identical. Fields credit/debit indicator, settlement amount and currency of the FoP instructions will behave as any other additional matching field. I.e. they are initially not mandatory but their values have to match when one of the counterparties provides a value for them in its instruction. Therefore, when an Additional matching field is filled in by one Counterparty, the other Counterparty should also fill it in, since a filled-in Additional matching field cannot match with a field with no value. It should also be noted that given the structure of the message schema, as soon as one of the three fields is filled in, the other two become mandatory as otherwise the instruction would not be schema compliant.  



Credit Debit Indicator: when one of the instructions contains CRDT, the counterpart instruction must contain DBIT and vice versa. Settlement Amount: when one of the instructions states a settlement amount, the counterpart instruction must contain identical values unless a tolerance amount is specified for the currency and related amount. In this later case, the difference between both instructions must be compliant with the tolerance amount. Currency: when one of the instructions contains a currency, the counterpart instruction must contain the same value.

STSI FOPs in non-T2S currency shall be identified and reported. Summary of project risk No Security analysis No potentially adverse effect was identified during the security assessment.

7