Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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
3 / 54 Ami-Pay BE NSG
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
4 / 54 Ami-Pay BE NSG
Schedule
Description
Iteration 1 (UDFS v0.1)
Iteration 2 (UDFS v0.2)
Iteration 3 (UDFS v0.3)
Iteration 4 (UDFS v0.4)
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.
5 / 54 Ami-Pay BE NSG
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
6 / 54 Ami-Pay BE NSG
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
8 / 54 Ami-Pay BE NSG
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
9 / 54 Ami-Pay BE NSG
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
10 / 54 Ami-Pay BE NSG
Credit Transfer
1. CB: credit transfer
order
2. Verification and
booking in CLM
3. Optional confirmat°
to participant:
camt.054
4. Optional confirmat°
to CB: pacs.002
ESMIG = Eurosystem Single Market Infrastructure Gateway
11 / 54 Ami-Pay BE NSG
Direct Debit
1. CB: Direct debit
instruction
2. Verification and
booking in CLM
3. Optional confirmat°
to participant:
camt.054
4. Optional confirmat°
to CB: pacs.002
ESMIG = Eurosystem Single Market Infrastructure Gateway
12 / 54 Ami-Pay BE NSG
Amendment of payments
► Possible as long as
a payment is not
settled
► Reordering
► Changing execution
time
► Revocation
Mandatory feedback via camt.025
13 / 54 Ami-Pay BE NSG
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.)
14 / 54 Ami-Pay BE NSG
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
15 / 54 Ami-Pay BE NSG
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
16 / 54 Ami-Pay BE NSG
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
17 / 54 Ami-Pay BE NSG
LT from CLM MCA to RTGS DCA
18 / 54 Ami-Pay BE NSG
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
19 / 54 Ami-Pay BE NSG
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
20 / 54 Ami-Pay BE NSG
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
21 / 54 Ami-Pay BE NSG
Reference Data Management
► Create/Modify/Delete common reference
data entity
22 / 54 Ami-Pay BE NSG
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
23 / 54 Ami-Pay BE NSG
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
25 / 54 Ami-Pay BE NSG
Future RTGS
26 / 54 Ami-Pay BE NSG
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
27 / 54 Ami-Pay BE NSG
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
28 / 54 Ami-Pay BE NSG
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
29 / 54 Ami-Pay BE NSG
Sending pacs.008/009 – Direct
participant A to direct participant B
30 / 54 Ami-Pay BE NSG
Sending pacs.010 – Direct participant A
to direct participant B
31 / 54 Ami-Pay BE NSG
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
32 / 54 Ami-Pay BE NSG
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
bilateral high value payments.
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
bilateral high value payments.
Settlement on dedicated liquidity account
(sub-accounts) (interfaced)
Usual real-time gross mode settlement of
bilateral high value payments.
33 / 54 Ami-Pay BE NSG
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.
34 / 54 Ami-Pay BE NSG
Settlement on dedicated liquidity account
(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.
35 / 54 Ami-Pay BE NSG
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
36 / 54 Ami-Pay BE NSG
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
37 / 54 Ami-Pay BE NSG
Liquidity Transfers RTGS
► RTGS DCA RTGS DCA (intra-service)
► RTGS DCA TIPS/T2S DCA (inter-service)
► RTGS DCA CLM MCA (inter-service)
38 / 54 Ami-Pay BE NSG
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
39 / 54 Ami-Pay BE NSG
Initiation of Liquidity Transfers
► By who?
● RTGS participant (direct or multi-addressee
access)
● Ancillary System on behalf
● CB on behalf
► How?
● A2A or U2A
40 / 54 Ami-Pay BE NSG
LT between two DCAs of the RTGS
41 / 54 Ami-Pay BE NSG
LT from RTGS to CLM
42 / 54 Ami-Pay BE NSG
LT from RTGS to other service
(T2S/TIPS)
43 / 54 Ami-Pay BE NSG
LT from other service (T2S/TIPS) to
RTGS
44 / 54 Ami-Pay BE NSG
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
45 / 54 Ami-Pay BE NSG
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
47 / 54 Ami-Pay BE NSG
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
48 / 54 Ami-Pay BE NSG
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
49 / 54 Ami-Pay BE NSG
Camt.056 message flow
► 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
50 / 54 Ami-Pay BE NSG
Camt.056 message flow
► 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
51 / 54 Ami-Pay BE NSG
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
….
52 / 54 Ami-Pay BE NSG
Messages published at Mystandards
► https://www2.swift.com/mystandards/#/groups
53 / 54 Ami-Pay BE NSG
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
54 / 54 Ami-Pay BE NSG
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