82
TARGET2-BE User Group 15 June 2017
TARGET2-BE User Group15 June 2017
T2UG2 / 82
Agenda
► T2-T2S consolidation● High level overview
► Future RTGS services● High level overview● URD
► Releases and testing● Release 11.0 November 2017● Release 12.0 November 2018
► Self-certification► Miscellaneous
T2UG3 / 82
T2-T2S consolidation
► T2-T2S consolidation project● TF with Eurosystem and market participants
Review current scope RTGS services Identification of new services Adapt and improve existing services multi-currency
● Market consultation on future RTGS services URD
T2UG4 / 82
High level business domains
Operational Monitoring Business Monitoring
Eurosystem Single Market Infrastructure Gateway (ESMIG)
Central Liquidity Management
RTGS SettlementHigh Value Payments and
Ancillary Systems
Reference Data Management
Data Warehouse
PT LT
Service Interface: Technical Validation, Information and Reporting
LT
Busin
ess D
ay
Multi‐curren
cy
Billing
T2S
PT – Payment Transaction; LT – Liquidity Transfer; SI – Settlement Instruction; CL – Credit Lines
ECMSSI
SI
CLTIPS
PT
LT Contingency Settlement (*)
(*) Contingency settlement to be addressed i.a. under the umbrella of cyber resilience
Central Bank Services
Focus for Task Force
In scope for T2/T2S Consolidation
Out of scope for T2/T2S Consolidation, but interfaces are in scope
Transversal Topic
Legend
A2A U2A
System Operators
Non‐Euro RTGSDirect Participants
Central BanksNetwork
SI
Usi
ng a
ltern
ative
Gat
eway
PT
PT
T2UG5 / 82
Shared functional modules
Central Liquidity Management
HVP
AS
Credit line
Static Data
SecuritiesSettlement
InstantPayments
Eurosystem Single Market Infrastructure Gateway
Data Warehouse
GUI
Common Reference Data
Future RTGS Services
T2S TIPS
HVP, AS
Service-related Reference Data
InstantPayments
Shared Billing
Service-related Reference Data
Service-related Reference Data
Securities Settlement
GUI GUI
Central Bank Operations Dashboard(GUI)
Auto-Collat
RM
T2UG6 / 82
Future RTGS Services
► New Central Liquidity Management (CLM)● Transactions with Central Banks● Credit line● Manage and monitor liquidity
RTGS and AS, TIPS, T2S
► RTGS Services● Settlement of high-value payments● Settlement of AS transactions● One or multiple RTGS accounts● Settlement mechanism almost unchanged
T2UG7 / 82
Future RTGS Services
► Common Services● Reference data● Datawarehouse● Billing
► ESMIG● Unique entry point for all Eurosystem Market
Infrastructures● Network agnostic● A2A and U2A
T2UG8 / 82
Future RTGS Services – Key Benefits
► Centralised management and control over paymentcapacity
► Segregation of interaction with Central Banks fromRTGS services
► Minimum reserve calculation and automated standing facilities
► Multi-vendor approach for connectivity► Introduction of ISO20022► Common reference data management► Shared Data warehouse► Longer opening hours for HVP settlement (under
consideration)
T2UG9 / 82
T2/T2S Consolidation
URD’s in detail
T2UG10 / 82
T2UG11 / 82
T2/T2S Consolidation Consultation
► URD ● Shared Services● Central Liquidity Management● Future RTGS Services
► Introduction to most important processes► Consultation: invitation to share comments► http://www.ecb.europa.eu/paym/cons/html/inde
x.en.html
T2UG12 / 82
How to provide comments?
T2UG13 / 82
Timing
► 15/06 National User Group
► 28/06 Feedback to NBB/BNB
► 30/06 Reporting to ECB
T2UG14 / 82
T2-T2S Consolidation
Shared Services
T2UG15 / 82
European Single Market InfrastructureGateway (ESMIG)
► Single access point to all market infrastructures
► Network agnostic► Business continuity► Cost effective access including low volume
customers► Authentication and basic authorisation for U2A► Data Exchange Protocol for A2A► Cybersecurity
T2UG16 / 82
ESMIG
► ESMIG archives communication and events forup to 30 days
► Store & forward and real-time communication► Routing of messages and files to the
appropriate services or external party► Queue► Opening hours aligned with market
infrastructures
T2UG17 / 82
ESMIG
► Validation checks:● Sender allowed to use the adressed service?
● Duplicates?
● XML message well-formatted?
T2UG18 / 82
Common Reference Data Management
► Common: data shared with other services► Reference Date: data required for configuration
and operation of the services► Management: creation, amendment and
deletion of reference data► Available to any party
● Via U2A and A2A► Audit Trail
T2UG19 / 82
CRDM Business Processess
► Create/Amend/Delete an occurrence
► Propagate changes
► (Un)Block an occurrence
► Close a cash account
► Directory Service
T2UG20 / 82
T2UG21 / 82
Create/amend/delete an occurrence
► Valid from date; valid from time/event► Valid to date; valid to time/event► Technical validation► Business Validation► Validation failed => rejection notification► Logical changes are status updates
T2UG22 / 82
Propagate changes
► CRDM monitors which services require anupdate of the change
► Any successful change to any occurrence is propagated intra-day to each relevant service asap.
► Activation is based on time or event
T2UG23 / 82
(Un)Blocking of Cash Accounts andParties
► Initiated by Central bank or Operator on behalf
► Business process:● Technical validations● Business validations● Validations passed => occurrence (un)blocked
► Can be a participant, Ancillary System, cash account.
T2UG24 / 82
Closing a Cash Account
► Any type of Cash Account► Account must exist and be active► Technical and business validations► Relevant Central Bank can transfer the
remaining balance to another cash account► Impacted data to be updated:
● Deletion of standing orders● Setting credit line to zero● Reference data saved
T2UG25 / 82
Directory Service
► Each service has a directory► Providing relevant data to reachable parties► For each service, containing the parties
reachable through this service via BIC11► Every party will be published► Wildcard rules► Distributed within a service► Directory updates will be distributed► Structure similar to current T2 Directory
T2UG26 / 82
Business Day
► Managed in CRDM for all services► EoD/SoD process initiated by Scheduler
● Tasks EoD: Closure Rejection Reporting Change of Business Day Standing facilities and minimum reserve
● Task SoD: receiving and updating reference data
T2UG27 / 82
Business Day Schedule
T2UG28 / 82
User Roles & Access
► Service checks if user may perform business functions through roles and privileges
► Two-eyes or four-eyes principle► A2A roles two-eyes only► Confirm, revoke or amend► Four-eyes changes not treated at EoD will
result in rejection► Set-up & maintenance users & roles in CRDM
T2UG29 / 82
Information and reporting
► Query
► Produce and send a scheduled report
► Request a report
► A2A and U2A
T2UG30 / 82
Data Warehouse Service
► Providing data for statistical and regulatoryreporting
► All relevant data entries are mirrored to theData Warehouse
► Available from D+1► 10 years retention► Access also for participants
T2UG31 / 82
Business Data Definitions
► Description of the business data entities andattributes referred to within the business process descriptions.
► Relationship diagrams
T2UG32 / 82
T2UG33 / 82
T2UG34 / 82
T2-T2S Consolidation
Central Liquidity Management
T2UG35 / 82
Main functional objective of theconsolidation
► Manage liquidity more efficiently betweenservices● Overall view
Main Cash Account
Dedicated liquidity for each service
Dedicated Cash Accounts for each settlement service (TIPS, HVP, T2S)
● Re-allocation of liquidity inter-service via Central Liquidity Management
T2UG36 / 82
Basic model CLM and MCA
T2UG37 / 82
CLM and Multi country banks
T2UG38 / 82
CLM functions
► Processing of Central Bank Operations to bebooked on MCA● Update of the credit line● Standing Facilities (marginal lending & deposits)● Cash withdrawals● Monetary policy operations● Debit of billing amounts● Interest payments (marginal lending, overnight
deposits, minimum reserves an excess reserves)● Any other activity by CB as central bank.
T2UG39 / 82
CLM functions
► Processing of liquidity transfers
► Liquidity reservation requests
► Priority for Central Banking Operations
T2UG40 / 82
Drawing LiquidityMain Cash Account (MCA) RTGS Dedicated Cash Account (DCA)
Business Purpose MCA Operations Non-reserved Highly Urgent Urgent (U) Non-reserved
Main Cash Account
Credit line decrease 2 1 5 4 3
Central Bank Operation 1 2 5 4 3
Cash Withdrawal 1 2 5 4 3
Inter-Service and Intra-Service Liquidity
Transfer1 n/a n/a n/a
RTGS Dedicated Cash Account
Inter-Service and Intra-Service Liquidity
Transfer*) *) *)
Ancillary System transaction 4** 1 3 2
U Payment 3** 1 2
N Payment 2** 1
• *subject to the priority defined by the Party,• ** subject to prior configuration by the Party
T2UG41 / 82
Liquidity transactionsORDER TYPESTANDING ORDERIMMEDIATE
SERVICEINTERFACETECHNICALVALIDATION
RESULT BUSINESSVALIDATION
RESULT SETTLEMENTATTEMPT
RESULT
Inter-serviceMCA to DCA
-Mandatoryfields-Duplicates-Other
Passed => -Proxy check-Mandatoryattributes-Account check
Passed => -Checkbalances
Full Execution (optionalnotification)
Rejected +Notification
Rejected + Notification Standing Order: PartialExecution (optionalnotification)No Execution + notification
Inter-serviceDCA to MCA
-Mandatoryfields-Duplicates-Other
Passed => -Proxy check-Mandatoryattributes-Account check
Passed => -Checkbalances
Full Execution (optionalnotification)
Rejected +Notification
Rejected + Notification Partial Execution (if initiatedautomatically by CLM)No Execution + notification
Intra-serviceMCA to MCA (same bankinggroup required)
-Mandatoryfields-Duplicates-Other
Passed => -Proxy check-Mandatoryattributes-Account check-Banking group
Passed => -Checkbalances
Full Execution (optionalnotification)
Rejected +Notification
Rejected + Notification Standing Order: PartialExecution (optionalnotification)No Execution + notification
DCA to DCA differentsettlement services
-Mandatoryfields-Duplicates-Other
Passed => -Proxy check-Mandatoryattributes-Account check
Passed => -Checkbalances
Full Execution (optionalnotification)
Rejected +Notification
Rejected + Notification No Execution + notification
Central Bank Operations onMCA
-Mandatoryfields-Duplicates-Other
Passed => -Proxy check-Mandatoryattributes-Account check
Passed => -Checkbalances-Check priorityqueue
Full Execution (optionalnotification)
Rejected +Notification
Rejected + Notification No Execution EoD +notification
T2UG42 / 82
Inter-service Liquidity Transfer MCA toDCA
T2UG43 / 82
Inter-service Liquidity Transfer MCA toDCA
► Settlement principles:● Immediate settlement attempt after submission● FIFO-principle● Access only to the non-reserved pool of liquidity● Limits do not apply to inter-service transfers
► Full, partial or no execution
T2UG44 / 82
Inter-service Liquidity Transfer MCA toDCA Feedback process
Positive confirmationfeedback
LiquidityMCA LiquidityDTA DCA
Negative confirmationfeedback
Liquidity
MCA
Liquidityreversal
DTA
T2UG45 / 82
Inter-service Liquidity Transfer DCA toMCA
► Settlement principles:● Immediate settlement attempt after submission● Not queued, not to be revoked● FIFO-principle
► Execution: ● Full execution:
CLM books and updates balances DCA => DTA => MCA Confirmation notification to settlement service
● No execution: Rejection notification
T2UG46 / 82
Intra-service Liquidity Transfer MCA toMCA (same banking group)
► Standing order or immediate transfer order► Settlement principles:
● Orders not queued, not to be revoked● Offsetting not required● FIFO-principle● Only access to non-reserved pool of available
liquidity● Limits do not apply
► Full, partial or no execution
T2UG47 / 82
Liquidity Transfers between 2 DCAs
► Hold and have access to a DCA
DCA
DTA
DCA
T2UG48 / 82
Payment order linked to CB operations and cash withdrawal
► MCA (debit/credit)
► Floor and ceiling► Queuing► Normal or urgent
► CB account, MarginalLending account, overnight depositaccount (credit/debit)
T2UG49 / 82
Resolving the queue
► Additional liquidity● Automatic trigger of LT from RTGS DCA● Increase of credit line● Incoming payments
► Stop processing by EoD
T2UG50 / 82
Liquidity reservation CLM
► Can be increased, decreased or reset to zero
► “Pending value”● Lack of liquidity for full reserved amount● Available liquidity is reserved and CLM auto-
triggers LT from RTGS DCA● If DCA balance allows for only a partial LT, CLM
executes partially and creates new LT order fromRTGS DCA
► Stop processing EoD
T2UG51 / 82
CLM features
► A2A or U2A► GUI for U2A► Audit trail► Confirm/reject tasks► Act on behalf:
● Central bank for its community● Operator for any party
► Access rights connected to users/roles
T2UG52 / 82
Time Schedule CLM
Process TimingStart of Day 18:45-19:00Operating Time 19:00-00:30Maintenance 00:30-02:30Operating Time 02:30-18:00End of Day 18:00-18:45
T2UG53 / 82
T2-T2S Consolidation
Future RTGS service
T2UG54 / 82
Future RTGS
T2UG55 / 82
Future RTGS functionalities
► Create High Value Payment► Queue Management/Payment order
Amendment:● Change order of payments in a queue● Modify a payment in a queue● Cancel a payment in a queue
► Manage dedicated Liquidity:● Create a Intra-RTGS liquidity transfer● Liquidity Reservation
► Create a back-up payment
T2UG56 / 82
Payment Order Processing:
Technical Validation1. RTGS participant sends
payment order message
2. Service interface performsTechnical Validation: Are allmandatory fields filled in properly?
3. Failed: Rejection Notification sent. Succeeded: order sent toBusiness Validation
T2UG57 / 82
Business Validation1. Authorisation check
2. Check on intended settlementdate
3. Payment type specific checks
4. White list check
5. Field and reference date checks
6. Duplicate checks
7. Failed: rejection notificationsent with reason code Succeeded: to Timing Constraint Checks
T2UG58 / 82
Check on Timing Constraints1. From time
2. Reject time
3. End of Day - specific cut-offtimes
• Customer payments• Interbank payments• Cut-off depends on currency
4. End of Day – revocation of queued orders
• Customer payments• Interank payments• Cut-off depends on currency
5. Failed: failure notification sent Succeeded: to Entry Disposition
T2UG59 / 82
Entry Disposition1. Priority classification:
• Highly Urgent• Urgent• Normal
2. HU and U FIFO principle3. Normal payment: bypass
possible4. Exception: Offsetting with
liquidity increase5. Failed: payment will be queued
and a liquidity transfer order can be sent. Succeeded: perform checks foravailable liquidity and intradayrestrictions
T2UG60 / 82
Perform checks foravailable liquidity andblocked accounts1. Blocked debit/credit account or
parties? In case check fails, NCB can
release or reject order2. Bi-/Multilateral limits not
breached for normal payments Check fails: order queued
3. Balance is sufficient Check fails: order queued +
liquidity transfer order4. Reservation is sufficient
Check fails: order queued + liquidity transfer order
5. Checks succeeded: order settled, cash balances andlimits updated
T2UG61 / 82
Floor and ceiling
► In case an account balance falls below its floor limit, RTGS services willgenerate a liquiditytransfer IN requestto the CLM
► In case an account balance breaks through its ceiling, RTGS services willgenerate a liquiditytransfer OUT to theCLM
T2UG62 / 82
Payment order amendments/cancellation
► Possible amendments:● Change priority (except HU)
● Put on top of queue
● Move to bottom of queue
● Change of execution time
● Cancel order
T2UG63 / 82
Payment order amendments/cancellation process
► Similar to payment order► Technical/Business validation► Check availability of original instruction
(eligibility)► Stop processing of original order and make
amendement► Validation successful => Next stage► Validation failed => Rejection notification
T2UG64 / 82
Intra-RTGS Liquidity Transfer
► From RTGS HVP DCA to RTGS AS DCA andvice versa
► Liquidity Transfer Order (ad hoc)
► Pre-defined Order (Time based)
T2UG65 / 82
Intra-RTGS Liquidity Transfer Process
► Technical/Business validation► Validation failed => Rejection notification► Validation successful => Next stage► Available liquidity check ► Partial execution (multiple = pro-rate)► Update cash balances► Check on floor/ceiling
T2UG66 / 82
Liquidity reservation RTGS
► Initiated through:● Standing order● Liquidity reservation request
► Can be increased, decreased or revoked► “Pending value”
● Lack of liquidity for full reserved amount● Part reserved, rest queued = pending value● Incoming credit: update of reservation● No automated LT to bring liquidity to DCA
T2UG67 / 82
Liquidity reservation process
► Technical/Business validation► Validation failed => Rejection notification► Validation successful => Next stage► Check reserved amount vs available liquidity► Create (and queue) reservation order► Update defined value
T2UG68 / 82
Future RTGS features
► A2A or U2A► GUI for U2A► Audit trail► Confirm/reject tasks► Act on behalf:
● Central bank for its community● Operator for any party
► Access rights connected to users/roles
T2UG69 / 82
Future RTGS features
► Queries on:● Payments● Warehoused
payments● Liquidity Transfers● XML messages● Account balance● Reservations
● Limits● Broadcasts● Account Statements● Copy of a report on
Account Statement
• Four-eyes approval possible on all services
T2UG70 / 82
Time Schedule Future RTGS
HVP serviceProcess TimingStart of Day 18:45-19:30LT only 19:30-00:30Maintenance 00:30-02:30Maintenance of warehousedpayments
02:30-03:00
Operating time 03:00-18:00Cut-off Customer Payments
17:00
Cut-off InterbankPayments
18:00
End of Day 18:00-18:45
AS serviceProcess TimingStart of Day 18:45-19:30Operating time 19:30-00:30Maintenance 00:30-02:30Operating time 02:30-18:00Cut-off InterbankPayments
18:00
End of Day 18:00-18:45
T2UG71 / 82
TARGET2 Releases
T2UG72 / 82
Target2 release 11.0 ► Content:
● CR-767: Instant payments in Target2 ASI procedure 6 realtime; Use of a technical account at the level of Target2; Cross AS settlement possible
● CR-772: New fields in user header Fin messages MT 103 & 202 COV; In context GPI initiative; Tags 111 & 121 accepted & forwarded by Target2; In order to send: registration for CUG needed
● CR-759: Leading/trailing blanks not allowed Currently deleted; Can lead to situation first character not allowed eg. “/”
T2UG73 / 82
Target2 release 11.0► Testing:
Testing activities published at site ECB: http://www.ecb.europa.eu/paym/t2/professional/nov_2017
/html/index.en.html
Category of test cases: Mandatory: applicable to all participants; Conditional: applicable in case functionality will be used in
the production environment Eurosystem is working on a common solution to allow
CB’s to act as a counterparty (sending of messagesincluding GPI tags)
T2UG74 / 82
Target2 release 11.0► Test Calendar:
T2UG75 / 82
Target2 release 12.0 ● No change requests raised by participants● Current content:
potential changes needed for adapting to the SWIFT 2018 Standard Release;
Adaptation Target2 to TIPS
● Changes to ISO standards: Target2 currently supports 2 camt versions:
Camt 4; Camt 5 (ISO 20022 version 2012)
Target2 release 12.0 in November 2018: Camt 4 not longer supported; Camt 5 remains and becomes lowest version; ISO 20022 version used by TIPS Participants currently using camt 4 messages in A2A
communication will have to upgrade their systems
T2UG76 / 82
Self-certification
► Legal basis: art. 28 of Annex II TARGET2 guideline► Currently only critical participants and critical
Ancillary Systems► Requirements based on ISO/IEC 27002
standards● Information security● Business continuity● contingency
► Annual renewal► Authorized signatures
● Senior executives from business and IT
T2UG77 / 82
Self-certification
► Bangladesh case► As from 2018 applicable to all participants
● Critical participants Same requirements and process But signing also by Audit (internal or external)
● Non-critical participants Same process but
Subset of requirements» Focus on protection of integrity
Signing only by senior executives business and IT
► More information will follow in September 2017► Contact person
T2UG78 / 82
Miscellaneous
► T2S migration final wave:● Pre-migration starts 20/06/2017● Migration weekend 15-18/09/2017● NBB to support weekend if needed
T2UG79 / 82
New Contingency DCA of the NBB
► The NBB will open a new DCA for contingencypurpose● CBEEURNBBEBEBB203CONTINGENCY
► Use:● to inject liquidity in the contingency module ● in case of problems with the interface between T2 and T2S
► Testing on voluntary basis● Contact TARGET2-BE helpdesk
► Go-live1 July 2017
T2UG80 / 82
Fresh liquidity for the Contingencymodule of TARGET2
► In order to use the liquidity of his DCA for the CM, the participant sends the form I Banking Community Chapter 6 to debit his DCA in favorof the NBB Contingency DCA
► The NBB will perform the LT in the GUI of T2S and inject the cash on the account of the participant in the CM
► At the closing of the CM, the balance willautomatically be transferred to the RTGS account of the participant
T2UG81 / 82
Interface problem T2/T2S
► A participant wants to perform a LT from hisRTGS account to a DCA:● MT202 in favour of the contingency account 100-
0085904-93 of the NBB● NBB performs via the T2SGUI a LT debiting the
contingency DCA of the NBB and crediting the DCA
T2UG82 / 82
Interface problem T2S/T2
► A participant wants to perform a LT from hisDCA to a RTGS account:● DCP’s can perform a LT form their DCA to the
contingency DCA of the NBB ● ICP’s can request the NBB to act on behalf via the
form I Banking Community Chapter 6● NBB performs a MT202 debiting the contingency
account of the NBB in favour of the RTGS
