TARGET2-BE User Group. 15 June 2017

Transcription

1 TARGET2-BE User Group 15 June 2017

2 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 2/ 82

3 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 3/ 82

4 High level business domains System Operators Direct Participants Network Central Banks Non Euro RTGS Legend In scope for T2/T2S Consolidation Focus for Task Force A2A U2A Transversal Topic Out of scope for T2/T2S Consolidation, but interfaces are in scope Eurosystem Single Market Infrastructure Gateway (ESMIG) TIPS PT LT Multi currency Business Day PT Service Interface: Technical Validation, Information and Reporting SI T2S RTGS Settlement High Value Payments and Ancillary Systems LT PT LT Central Liquidity Management PT Central Bank Services SI CL SI ECMS Contingency Settlement (*) (*) Contingency settlement to be addressed i.a. under the umbrella of cyber resilience Using alternative Gateway Reference Data Management Operational Monitoring Business Monitoring Data Warehouse Billing PT Payment Transaction; LT Liquidity Transfer; SI Settlement Instruction; CL Credit Lines 4/ 82

5 Shared functional modules Central Liquidity Management Credit line RM Central Bank Operations Dashboard (GUI) T2S Securities Settlement Securities Auto-Collat Settlement Future RTGS Services HVP, HVPAS AS TIPS Instant Payments Instant Payments Service-related Reference Data Static Data Service-related Reference Data Common Reference Data Shared Billing Data Warehouse Service-related Reference Data GUI GUI GUI Eurosystem Single Market Infrastructure Gateway 5/ 82

6 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 6/ 82

7 Future RTGS Services Common Services Reference data Datawarehouse Billing ESMIG Unique entry point for all Eurosystem Market Infrastructures Network agnostic A2A and U2A 7/ 82

8 Future RTGS Services Key Benefits Centralised management and control over payment capacity Segregation of interaction with Central Banks from RTGS 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) 8/ 82

9 T2/T2S Consolidation URD s in detail 9/ 82

10 10 / 82

11 T2/T2S Consolidation Consultation URD Shared Services Central Liquidity Management Future RTGS Services Introduction to most important processes Consultation: invitation to share comments x.en.html 11 / 82

12 How to provide comments? 12 / 82

13 Timing 15/06 National User Group 28/06 Feedback to NBB/BNB 30/06 Reporting to ECB 13 / 82

14 T2-T2S Consolidation Shared Services 14 / 82

15 European Single Market Infrastructure Gateway (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 15 / 82

16 ESMIG ESMIG archives communication and events for up 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 16 / 82

17 ESMIG Validation checks: Sender allowed to use the adressed service? Duplicates? XML message well-formatted? 17 / 82

18 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 18 / 82

19 CRDM Business Processess Create/Amend/Delete an occurrence Propagate changes (Un)Block an occurrence Close a cash account Directory Service 19 / 82

20 20 / 82

21 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 21 / 82

22 Propagate changes CRDM monitors which services require an update 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 22 / 82

23 (Un)Blocking of Cash Accounts and Parties 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. 23 / 82

24 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 24 / 82

25 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 25 / 82

26 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 26 / 82

27 Business Day Schedule 27 / 82

28 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 28 / 82

29 Information and reporting Query Produce and send a scheduled report Request a report A2A and U2A 29 / 82

30 Data Warehouse Service Providing data for statistical and regulatory reporting All relevant data entries are mirrored to the Data Warehouse Available from D+1 10 years retention Access also for participants 30 / 82

31 Business Data Definitions Description of the business data entities and attributes referred to within the business process descriptions. Relationship diagrams 31 / 82

32 32 / 82

33 33 / 82

34 T2-T2S Consolidation Central Liquidity Management 34 / 82

35 Main functional objective of the consolidation Manage liquidity more efficiently between services 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 35 / 82

36 Basic model CLM and MCA 36 / 82

37 CLM and Multi country banks 37 / 82

38 CLM functions Processing of Central Bank Operations to be booked 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. 38 / 82

39 CLM functions Processing of liquidity transfers Liquidity reservation requests Priority for Central Banking Operations 39 / 82

40 Drawing Liquidity Main 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 Central Bank Operation Cash Withdrawal Inter-Service and Intra-Service Liquidity Transfer 1 n/a n/a n/a RTGS Dedicated Cash Account Inter-Service and Intra-Service Liquidity Transfer *) *) *) Ancillary System transaction 4** U Payment 3** 1 2 N Payment 2** 1 *subject to the priority defined by the Party, ** subject to prior configuration by the Party 40 / 82

41 Liquidity transactions ORDER TYPE STANDING ORDER IMMEDIATE SERVICE INTERFACE TECHNICAL VALIDATION RESULT BUSINESS VALIDATION RESULT SETTLEMENT ATTEMPT RESULT Inter-service MCA to DCA -Mandatory fields -Duplicates -Other Passed => Rejected + Notification -Proxy check -Mandatory attributes -Account check Passed => -Check balances Full Execution (optional notification) Rejected + Notification Standing Order: Partial Execution (optional notification) No Execution + notification Inter-service DCA to MCA -Mandatory fields -Duplicates -Other Passed => Rejected + Notification -Proxy check -Mandatory attributes -Account check Passed => Rejected + Notification -Check balances Full Execution (optional notification) Partial Execution (if initiated automatically by CLM) No Execution + notification Intra-service MCA to MCA (same banking group required) -Mandatory fields -Duplicates -Other Passed => Rejected + Notification -Proxy check -Mandatory attributes -Account check -Banking group Passed => -Check balances Full Execution (optional notification) Rejected + Notification Standing Order: Partial Execution (optional notification) No Execution + notification DCA to DCA different settlement services -Mandatory fields -Duplicates -Other Passed => Rejected + Notification -Proxy check -Mandatory attributes -Account check Passed => Rejected + Notification -Check balances Full Execution (optional notification) No Execution + notification Central Bank Operations on MCA -Mandatory fields -Duplicates -Other Passed => Rejected + Notification -Proxy check -Mandatory attributes -Account check Passed => -Check balances -Check priority queue Full Execution (optional notification) Rejected + Notification No Execution EoD + notification 41 / 82

42 Inter-service Liquidity Transfer MCA to DCA 42 / 82

43 Inter-service Liquidity Transfer MCA to DCA 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 43 / 82

44 Inter-service Liquidity Transfer MCA to DCA Feedback process Positive confirmation feedback Negative confirmation feedback MCA Liquidity DTA Liquidity DCA MCA Liquidity DTA Liquidity reversal 44 / 82

45 Inter-service Liquidity Transfer DCA to MCA 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 45 / 82

46 Intra-service Liquidity Transfer MCA to MCA (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 46 / 82

47 Liquidity Transfers between 2 DCAs Hold and have access to a DCA DTA DCA DCA 47 / 82

48 Payment order linked to CB operations and cash withdrawal MCA (debit/credit) CB account, Marginal Lending account, overnight deposit account (credit/debit) Floor and ceiling Queuing Normal or urgent 48 / 82

49 Resolving the queue Additional liquidity Automatic trigger of LT from RTGS DCA Increase of credit line Incoming payments Stop processing by EoD 49 / 82

50 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 autotriggers LT from RTGS DCA If DCA balance allows for only a partial LT, CLM executes partially and creates new LT order from RTGS DCA Stop processing EoD 50 / 82

51 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 51 / 82

52 Time Schedule CLM Process Timing Start of Day 18:45-19:00 Operating Time 19:00-00:30 Maintenance 00:30-02:30 Operating Time 02:30-18:00 End of Day 18:00-18:45 52 / 82

53 T2-T2S Consolidation Future RTGS service 53 / 82

54 Future RTGS 54 / 82

55 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 55 / 82

56 Payment Order Processing: Technical Validation 1. RTGS participant sends payment order message 2. Service interface performs Technical Validation: Are all mandatory fields filled in properly? 3. Failed: Rejection Notification sent. Succeeded: order sent to Business Validation 56 / 82

57 Business Validation 1. Authorisation check 2. Check on intended settlement date 3. Payment type specific checks 4. White list check 5. Field and reference date checks 6. Duplicate checks 7. Failed: rejection notification sent with reason code Succeeded: to Timing Constraint Checks 57 / 82

58 Check on Timing Constraints 1. From time 2. Reject time 3. End of Day - specific cut-off times 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 58 / 82

59 Entry Disposition 1. Priority classification: Highly Urgent Urgent Normal 2. HU and U FIFO principle 3. Normal payment: bypass possible 4. Exception: Offsetting with liquidity increase 5. Failed: payment will be queued and a liquidity transfer order can be sent. Succeeded: perform checks for available liquidity and intraday restrictions 59 / 82

60 Perform checks for available liquidity and blocked accounts 1. Blocked debit/credit account or parties? In case check fails, NCB can release or reject order 2. Bi-/Multilateral limits not breached for normal payments Check fails: order queued 3. Balance is sufficient Check fails: order queued + liquidity transfer order 4. Reservation is sufficient Check fails: order queued + liquidity transfer order 5. Checks succeeded: order settled, cash balances and limits updated 60 / 82

61 Floor and ceiling In case an account balance falls below its floor limit, RTGS services will generate a liquidity transfer IN request to the CLM In case an account balance breaks through its ceiling, RTGS services will generate a liquidity transfer OUT to the CLM 61 / 82

62 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 62 / 82

63 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 63 / 82

64 Intra-RTGS Liquidity Transfer From RTGS HVP DCA to RTGS AS DCA and vice versa Liquidity Transfer Order (ad hoc) Pre-defined Order (Time based) 64 / 82

65 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 65 / 82

66 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 66 / 82

67 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 67 / 82

68 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 68 / 82

69 Future RTGS features Four-eyes approval possible on all services Queries on: Payments Warehoused payments Liquidity Transfers XML messages Account balance Reservations Limits Broadcasts Account Statements Copy of a report on Account Statement 69 / 82

70 Time Schedule Future RTGS HVP service Process Timing Start of Day 18:45-19:30 LT only 19:30-00:30 Maintenance 00:30-02:30 Maintenance of 02:30-03:00 warehoused payments Operating time 03:00-18:00 Cut-off Customer 17:00 Payments Cut-off Interbank 18:00 Payments End of Day 18:00-18:45 AS service Process Timing Start of Day 18:45-19:30 Operating time 19:30-00:30 Maintenance 00:30-02:30 Operating time 02:30-18:00 Cut-off Interbank 18:00 Payments End of Day 18:00-18:45 70 / 82

71 TARGET2 Releases 71 / 82

72 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. / 72 / 82

73 Target2 release 11.0 Testing: Testing activities published at site ECB: /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 messages including GPI tags) 73 / 82

74 Target2 release 11.0 Test Calendar: 74 / 82

75 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 version 2012) Target2 release 12.0 in November 2018: Camt 4 not longer supported; Camt 5 remains and becomes lowest version; ISO version used by TIPS Participants currently using camt 4 messages in A2A communication will have to upgrade their systems 75 / 82

76 Self-certification Legal basis: art. 28 of Annex II TARGET2 guideline Currently only critical participants and critical Ancillary Systems Requirements based on ISO/IEC standards Information security Business continuity contingency Annual renewal Authorized signatures Senior executives from business and IT 76 / 82

77 Bangladesh case Self-certification 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 77 / 82

78 Miscellaneous T2S migration final wave: Pre-migration starts 20/06/2017 Migration weekend 15-18/09/2017 NBB to support weekend if needed 78 / 82

79 New Contingency DCA of the NBB The NBB will open a new DCA for contingency purpose 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 / 82

80 Fresh liquidity for the Contingency module 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 favor of 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 will automatically be transferred to the RTGS account of the participant 80 / 82

81 Interface problem T2/T2S A participant wants to perform a LT from his RTGS account to a DCA: MT202 in favour of the contingency account of the NBB NBB performs via the T2SGUI a LT debiting the contingency DCA of the NBB and crediting the DCA 81 / 82

82 Interface problem T2S/T2 A participant wants to perform a LT from his DCA 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 82 / 82