TARGET Services UDFS v0.2 Workshop...4 / 54 Ami-Pay BE NSG Schedule Description fteration 1 (UDcS v0.1) fteration 2 (UDcS v0.2) fteration 3 (UDcS v0.3) fteration 4 (UDcS v0.4) Publication

TARGET Services UDFS

v0.2 Workshop

14-06-2018

2 / 54 Ami-Pay BE NSG

Contents

► TARGET Services UDFS v0.2 Workshop

● Overview

● UDFS CLM

● UDFS RTGS

● Outcome consultation

● ISO20022 Messages


Overview

• Iterations:

– The drafting of UDFS v1.0 will be split into 4 iterations, during which incremental drafts will

be shared with TCCG for review:

• Iteration 1: UDFS v0.1

• Iteration 2: UDFS v0.2 (revised v0.1 plus new chapters)

• Iteration 3: UDFS v0.3 (revised v0.2 plus new chapters)

• Iteration 4: UDFS v0.4 (revised v0.3 plus the remaining new chapters)

Part 4

Revised part 3

Revised part 2

Revised part 1Part 1

Part 2

Revised part 1

Part 3

Revised part 2

Revised part 1

Iteration 2 Iteration 3Iteration 1 Iteration 4

UDFS v0.1

UDFS v0.2

UDFS v0.3

UDFS v0.4


Schedule

Description

Iteration 1 (UDFS v0.1)




Publication of UDFS 1.0

Jun JulJan Feb Mar Apr May Aug Sep Oct Nov Dec

Finalisation

of the draft

• The Central Banks play a pivotal role in the review of the UDFS

drafts, by involving their national banking communities and ensuring

that their views are taken on board during the review.


Shared functional modules

Central Liquidity Management

HVP

AS

Credit line

Static Data

Securities

SettlementInstant

Payments

Eurosystem Single Market Infrastructure Gateway

Data Warehouse

GUI

Common Reference Data

Future RTGS

Services

T2S TIPS

HVP, AS

Service-related

Reference Data

Instant

Payments

Shared Billing

Service-related

Reference Data

Service-related

Reference Data

Securities

Settlement

GUI GUI

Central Bank OperationsDashboard

(GUI)

Auto-Collat

RM


High level project timeline T2-T2S Consolidation

Description Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q1 Q2

Realisation Phase

Development phase

Functional Specifications

NSP dossier

Internal Testing phase

EAT and CB phase *, **

User Testing phase *

User Training

Migration phase

Go-live of sharable

components for TIPS

Go-live

Operational Phase

Stabilisation phase

* covering preparation and execution in equal proportions

** Under analysis

20222020 20212018 2019

TARGET Services CLM UDFS v0.2


Basic model CLM and main account

Party A

CB 1

Main Cash

Account

T2S

DCATIPS

DCA

Securities settlement

TIPS settlement

Payment to third parties

Ancillary systems

Intraday credit

Marginal lending / overnight deposit

CB operations

RTGS

DCA


Settlement of payments linked to CBOs

► Central Bank can initiate payments orders:

● Credit Transfert

pacs008 and pacs009

● Direct Debit

pacs010

● Central Bank Operations / cash withdrawal linked

to a CLM Participant that holds a MCA in CLM

● A2A / U2A

► During whole business day (except EoD)

► Up to 10 calendar days in advance

● Warehoused payments


Credit Transfer

1. CB: credit transfer

order

2. Verification and

booking in CLM

3. Optional confirmat°

to participant:

camt.054


to CB: pacs.002

ESMIG = Eurosystem Single Market Infrastructure Gateway


Direct Debit

1. CB: Direct debit

instruction

2. Verification and

booking in CLM


to participant:

camt.054


to CB: pacs.002

ESMIG = Eurosystem Single Market Infrastructure Gateway


Amendment of payments

► Possible as long as

a payment is not

settled

► Reordering

► Changing execution

time

► Revocation

Mandatory feedback via camt.025


Liquidity management

► Main cash account (MCA)

● source of liquidity for the different settlement

services (RTGS, T2S, TIPS)

● Credit line connected to MCA

► Liquidity transfer

● = cash management (camt.)

● ≠ payment (pacs.)


LT Possibilities

Central Liquidity

Management

TIPS T2S RTGS

1. MCA to MCA

2. MCA to DCA /

DCA to MCA

3. DCA to DCA

4. DCA to DCA via CLM


Liquidity Transfer Group

► Restriction do not apply to Central Banks

► No controls for liquidity transfers between

services

Setup NCBs link payment banks

Coverage Cross-border

Usage For intra-service Liquidity

transfers only


Liquidity Transfer Instruction

► Initiator

● Participant in CLM

● Central Bank acting on behalf

► Initiated as

● Immediate LT

● Event-based LT

● Standing LT orders

► MCA to MCA identified by BIC11, to other

services by account number


LT from CLM MCA to RTGS DCA


Overnight deposit

► Possibility to transfer liquidity from MCA to

overnight deposit account

● Not from other DCAs

► Interest calculated and booked automatically

on next business day


OD reimbursement and interest calculation

1. CB sends camt.050 to

CLM

2. OD account of CB

debited and MCA of

participant credited

3. Optional camt.054 sent

to CLM participant

4. Acknowledgement sent

to CB via pacs.002


OD reimbursement and interest calculation

5. CB calculate interests

(+ or -) and sends

camt.050

6. CLM debits/ credits

MCA of CB and

credits/debits MCA of

participant

7. camt.054 sent to

participant

8. pacs.002 sent to CB


Reference Data Management

► Create/Modify/Delete common reference

data entity


Information Management

► Reports (for CLM and

RTGS services) can be:

● Sent out directly

● Stored for later

retrieval

► Can be received by

several receivers

► Configuration of the

report in advance

► Available U2A and A2A


Query Management for CLM/RTGS

► Requesting information

► The necessary priviliges are needed to retrieve

the requested info via a query.

► Predefined query types

● camt.003/GetAccount

● camt.005/GetTransaction

● …

► A2A

● XML Messages: ISO20022

► U2A

TARGET Services RTGS UDFS v0.2


Future RTGS


Future RTGS service (HVP)

► Migration to ISO 20022 compliant formats

► Network agnostic: communication via V-shape

instead of Y-copy

► Service will not support 2 versions in parallel:

migration via big-bang approach

► Possibility to consider liquidity EOD for

minimum reserve calculation

► Multi-currency without offering conversion

features


Payment types (UDFS 6.1)

► Timed payments:

● Earliest debit time indicator : /FROTIME/

● Latest debit time indicator : /REJTIME/ - /TILTIME/

► Warehouse functionality :

● Up to 10 calendar days in advance

● Warehoused payments can be managed in queue

► Backup contingency payments via GUI:

● CLS;

● Euro1;

● Liquidity redistribution payments


Settlement of payments (UDFS 6.2)

► A payment can be submitted/received by

● Direct RTGS participant;

● Central bank;

● Indirect participant /addressable BIC via DP;

● Multi-addressee

► Main messages used:

XML message Column1 MT message

pacs.008 Customer payment MT103

pacs.009 Bank to bank payment MT202

pacs.010 Direct debit MT204

pacs.002 FIToFIPaymentStatusReport MT019/MT012

camt.054 BankToCustomerDebitCreditNotification MT900/MT910

camt.053 BankToCustomerStatement MT950

camt.056 FIToFIPaymentCancellationRequest

pacs.004 PaymentReturn


Sending pacs.008/009 – Direct

participant A to direct participant B


Sending pacs.010 – Direct participant A

to direct participant B


Settlement of Ancillary Systems

Types of AS

► Retail payment systems

► Large value payment

systems

► Foreign exchange

systems

► Money market systems

► Clearing houses (CCP)

► Securities settlement

systems (SSS)

Accounts used for AS

settlement

Account type Owner

RTGS DCA AS participant

Sub-account AS participant

Guarantee funds

account

Guarantor, central

bank or ancillary

system

Technical account Central bank or

ancillary system


AS settlement procedures

Procedure Description

Real-time settlement (under review) Usual real-time gross mode settlement of

bilateral high value payments.

Bilateral settlement (under review) Usual real-time gross mode settlement of


Standard multilateral settlement "Debits first", i.e. first all the debits are

executed, then all the credits. If one of the

transactions fails the others, probably

already executed, are unwound.

Simultaneous multilateral settlement "All or nothing", i.e. debits and credits are

simultaneously executed. If one of the

transactions fails, all the others aren't

executed neither.

Settlement on dedicated liquidity account

(technical account for procedure 6) (real-

time)

Usual real-time gross mode settlement of



(sub-accounts) (interfaced)

Usual real-time gross mode settlement of



Simultaneous multilateral settlement

► Settles a set of multilateral balances (debits

and credits) on RTGS DCAs by sending a file.

► Either settled immediately or at the end of the

information period (also possible to have a

settlement period “till”).

► “All or nothing” settlement only if all needed

funds have been block. New attempts until end

of the settlement period.



(technical account for procedure 6/real-time)

► Ancillary system uses technical account to

collect the liquidity set aside by settlement

banks and mirrors it in cash positions within its

own system.


Procedure 6 RT (de)funding

► Standing Order (U2A/A2A by SB)

● For real-time only one standing order per business

day can be set. Executed at the start of the night-

time processing (19:30).

► Current order (U2A/A2A by SB or AS on

behalf)

► Payments via pacs.009 (preferably only as

contingency measure)

► Defunding can only be initiated in the Ancillary

System


Liquidity Transfers

► Camt.050 Liquidity Transfer Order Message

► Possible within RTGS only if:

● All accounts in same liquidity transfer group

● With CB account

● Accounts belong to same party

● To sub-accounts

► Principle: never queued, settled immediately

(full or partial) or rejected.● Exc. when MCA has insufficient liquidity for CB operation


Liquidity Transfers RTGS

► RTGS DCA RTGS DCA (intra-service)

► RTGS DCA TIPS/T2S DCA (inter-service)

► RTGS DCA CLM MCA (inter-service)


Liquidity Transfer Types

► Immediate LT

● Directly after initiation

► Event based

● Non-recurring LT of all liquidity or a certain amount

at a pre-defined event

► Standing Order

● Recurring LT of all liquidity or a certain amount at a

certain point in time or event


Initiation of Liquidity Transfers

► By who?

● RTGS participant (direct or multi-addressee

access)

● Ancillary System on behalf

● CB on behalf

► How?

● A2A or U2A


LT between two DCAs of the RTGS


LT from RTGS to CLM


LT from RTGS to other service

(T2S/TIPS)


LT from other service (T2S/TIPS) to

RTGS


Validations

► Technical validations

● Syntax/Schema checks

● Duplicate checks

● If failed: admi.007 with error code

► Business validations

● Duplicate check

● Authorisation checks

● Liquidity transfer group

● Field and reference data checks

● Subsequent processes and checks (available

liquidity/floor/ceiling/…)

● If failed: camt.025 with error code


Information Management:Status Management

► Each instruction has a status, which is subject

to change through its lifecycle in the service.

► Status provides actors with information on the

situation of the instruction at a certain point in

time.

► Types of statuses:

● Intermediate status: further processing will follow;

● Final status: settled, executed, cancelled or

denied.

► Negative result: reason code will be

communicated

Follow-up


User Consultation Camt.056 vs Camt.008

► 2 proposed options for the cancellation request

of a payment (order)

● Use of camt.008

● Use of camt.056

► Majority of the European market prefers the

use of camt.056

► Will be implemented in the RTGS service of

the consolidation


Camt.056 message flow

► For a non-final payment order:

Camt.056

1. The participant A sends a camt.056 message to

the RTGS service to request the cancellation of

an already sent payment message

2. The RTGS service checks status of requested

payment message. In case of not final status the

RTGS service revokes requested payment and

deletes it from the payment queue.

3. The RTGS service sends a positive camt.029 to

notify participant A

Participant BParticipant A

DCA A

DCA B

Camt.029

2

1

camt.056

3

RTGS

Queue

A to B 100



► For a final payment order (positive)

1. The participant A sends a camt.056 message to participant B to request the cancellation of a payment message

2. The RTGS service checks payment status

3. If payment is booked or not available in RTGS the camt.056 will beforwarded to participant B

4. The RTGS service generates a camt.029 with code PTNA (Passed To The Next Agent) to participant A

5. Participant B processes the cancellation request and generates a pacs.004

6. Participant B sends a payment return message pacs.004 via the RTGS service to participant A

7. The payment has to pass several validations, e.g. availability of sufficient cover. participant B is debited and participant A simultaneously credited

8. Participant B receives a notification pacs.002 from the RTGS service(optional)

9. The pacs.004 message will be forwarded to the credited participant A.

Participant BParticipant A

DCA A

DCA B

pacs.004

camt.056

pacs.004

3

2

1

camt.056

6

9

8

pacs.002

RTGS

100

100

DCA A

DCA B

7

100

100

5

Processing

cancellation

request

Camt.029

4



► For a final payment order (negative)

1. The direct participant A sends a camt.056 message to B to

request the cancellation of a payment message

2. RTGS checks payment status

3. If payment is booked or not available in RTGS the camt.056 will

be forwarded to participant B

4. RTGS generates a camt.029 with code PTNA (Passed To The

Next Agent) to participant A

5. Participant B cannot process the cancellation request and

generates a negative camt.029

6. Participant B sends the negative camt.029 to RTGS for

forwarding to participant A

7. The camt.029 message will be forwarded by RTGS to participant

A.

Participant B

(Receiver)Participant A

(Sender)

DCA A

DCA B

camt.029

camt.056

camt.029

5

1

camt.056

6

7

4

RTGS

camt.029

3

100

100

2


ISO20022 messages

► All messages published on MyStandards

● EMIP group

4CB, ECB and subset of banks

Subscription via NCB needed

● Strong demand from banks to comment on

messages

Content

Use

….


Messages published at Mystandards

► https://www2.swift.com/mystandards/#/groups

https://www2.swift.com/mystandards/#/groups


ISO20022 messages / NSP

► Subscription to optional messages

● Equivalent of MT012

● All or nothing

Demand to have more granularity (e.g. only for urgent

payments)

► NSP certification process

● Currently mid 2020

● Demand for end 2019

● 4CB: September 2018 more info


Big Bang strategy

► Eurosystem will develop document on Big

Bang strategy

● Root causes and mitigating actions

Connectivity

Communication

Liquidity

Internal problems

Other

● Actors

NSP

NCB

Participant

Documents

TARGET Services UDFS v0.2 Workshop...4 / 54 Ami-Pay BE NSG Schedule Description fteration 1 (UDcS v0.1) fteration 2 (UDcS v0.2) fteration 3 (UDcS v0.3) fteration 4 (UDcS v0.4) Publication