Beschluss (EU) 2022/911 der Europäischen Zentralbank vom 19. April 2022 zu den TARGET-EZB-Bedingungen und zur Aufhebung des Beschlusses EZB/2007/7 (EZB/2022/22)

Durchsuchbarer Text in vereinfachter Darstellung. Tabellen, Abbildungen und verbindliche Gestaltung bitte anhand der Originaldateien prüfen.

system may opt to receive notifications of the crediting and debiting of its TIPS AS technical account. If the ancillary system opts for this service notification is provided immediately upon the debit or credit of the TIPS AS technical account. 5. An ancillary system may send instant payment orders, and positive recall answers to any TIPS DCA holder or TIPS AS. A ancillary system shall receive and process instant payment orders, recall requests and positive recall answers from any TIPS DCA holder or TIPS AS. Article 2 Sending and receiving messages 1. A TIPS AS technical account holder may send messages: a) directly; b) via one or more instructing parties. 2. A TIPS AS technical account holder shall receive messages: a) directly; or b) via one instructing party. Article 7 of Part I shall apply to a TIPS AS technical account holder that sends or receives messages via an instructing party as though that TIPS AS technical holder sends or receives messages directly. Article 3 Immediate liquidity transfer orders A TIPS AS technical account holder may submit immediate liquidity transfer orders. Article 4 Processing of cash transfer orders on TIPS AS technical accounts 1. A timestamp for the processing of cash transfer orders is allocated in the sequence of their receipt. 2. All cash transfer orders submitted to TARGET-ECB shall be processed following the ‘first in, first out‘ (FIFO) principle without prioritisation or reordering. 3. After an instant payment order has been accepted as set out in Part I, Article 17(1), the ECB shall check if sufficient funds are available on the payer’s TIPS AS technical account to effect settlement and the following shall apply: a) if sufficient funds are not available, the instant payment order shall be rejected; b) if sufficient funds are available, the corresponding amount shall be reserved while awaiting the payee’s response. In the event of acceptance by the payee, the instant payment order shall be settled and the reservation shall be simultaneously lifted. In the event of rejection by the payee or the absence of a timely response, within the meaning of the SCT Inst scheme, the instant payment order shall be rejected and the reservation shall be simultaneously lifted. 4. Funds reserved in accordance with paragraph 3(b) shall not be available for the settlement of subsequent cash transfer orders. 5. Without prejudice to paragraph 3(b), the ECB shall reject an instant payment order if the amount of the instant payment order exceeds any applicable credit memorandum balance (CMB). 6. After a liquidity transfer order from a TIPS AS technical account to a TIPS DCA has been accepted as set out in Part I, Article 17(1), the ECB shall check if sufficient funds are available on the payer’s TIPS AS technical account. If sufficient funds are not available the liquidity transfer order shall be rejected. If sufficient funds are available the liquidity transfer order shall be settled immediately. 7. After a positive recall answer has been accepted as set out in Part I, Article 17, the ECB shall check if sufficient funds are available on the TIPS AS technical account to be debited. If sufficient funds are not available the positive recall answer shall be rejected. If sufficient funds are available the positive recall answer shall be settled immediately. 8. Without prejudice to paragraph 7, the ECB shall reject positive recall answers if the amount of the positive recall answer exceeds any applicable CMB. Article 5 Recall request 1. A TIPS AS technical account holder may submit a recall request. 2. The recall request shall be forwarded to the payee of the settled instant payment order which may answer with a positive or negative recall answer. Article 6 TIPS AS settlement procedure The TIPS AS settlement procedure shall be operational during the times set out in Appendix V. Article 7 Reachable parties via a TIPS AS technical account 1. A TIPS AS technical account holder may designate one or more reachable parties. Reachable parties shall have adhered to the SCT Inst scheme signing the SEPA Instant Credit Transfer Adherence Agreement. 2. A TIPS AS technical account holder shall provide evidence to the ECB of each designated reachable party’s adherence to the SCT Inst scheme. 3. A TIPS AS technical account holder shall inform the ECB if any designated reachable party no longer adheres to the SCT Inst scheme and shall, without undue delay, take steps to prevent the reachable party from accessing the TIPS AS technical account. 4. A TIPS AS technical account holder may allow its designated reachable parties access via one or more instructing parties. 5. Part I, Article 7 shall apply to an AS that has designated reachable parties. 6. A TIPS AS technical account holder that has designated a reachable party shall ensure that reachable party is at all times available for the purpose of receiving messages. Article 8 Transactions processed on TIPS AS technical accounts 1. The following transactions shall be processed via a TIPS AS technical account in TARGET-ECB: a) instant payment orders; b) positive recall answers; c) liquidity transfer orders to TIPS DCAs. Article 9 TIPS directory 1. The TIPS directory is a list of BICs used for the purpose of routing information and comprises the BICS of: a) TIPS DCA holders; b) reachable parties; 2. The TIPS directory shall be updated daily. 3. TIPS AS technical account holders may only distribute the TIPS directory to their designated reachable parties and their instructing parties. Reachable parties may only distribute the TIPS directory to their branches. 4. A specific BIC shall only appear once in the TIPS directory. 5. TIPS AS technical account holders acknowledge that the ECB and other CBs may publish names and BICs of reachable parties designated by the TIPS AS technical account holders and TIPS AS technical account holders shall ensure that reachable parties have agreed to such publication. Article 10 MPL repository 1. The central Mobile Proxy Lookup (MPL) repository contains the proxy — IBAN mapping table for the purposes of the MPL service. 2. Each proxy may be linked to only one IBAN. An IBAN may be linked to one or multiple proxies. 3. Part I, Article 28 shall apply to the data contained in the MPL repository. Article 11 Processing of cash transfer orders in the event of suspension or extraordinary termination 1. Upon termination of a TIPS AS technical account holder’s participation in TARGET-ECB, the ECB shall not accept any new cash transfer orders to or from that TIPS AS technical account holder. 2. If a TIPS AS technical account holders‘ participation in TARGET-ECB is suspended on grounds other than those specified in Part I, Article 24(1), point (a), the ECB shall: a) reject all of its incoming cash transfer orders; b) reject all of its outgoing cash transfer orders; or c) reject both its incoming and outgoing cash transfer orders. 3. If a TIPS AS Technical Account Holder’s participation in TARGET-ECB is suspended on the grounds specified in Part I, Article 24(1), point (a), the suspended TIPS AS technical account holder’s CB shall reject all of its incoming and outgoing sash transfer orders. 4. The ECB shall process instant payment orders of a TIPS AS technical account holder whose participation in TARGET-ECB has been suspended or terminated under Part I, Article 24(1) or (2) and in relation to which the ECB has reserved funds on a TIPS AS technical account pursuant to Article 4(3), point (b) prior to the suspension or termination. (1) Directive 98/26/EC of the European Parliament and of the Council of 19 May 1998 on settlement finality in payment and securities settlement systems (OJ L 166, 11.6.1998, s. 45). (2) Directive 2014/59/EU of the European Parliament and of the Council of 15 May 2014 establishing a framework for the recovery and resolution of credit institutions and investment firms and amending Council Directive 82/891/EEC, and Directives 2001/24/EC, 2002/47/EC, 2004/25/EC, 2005/56/EC, 2007/36/EC, 2011/35/EU, 2012/30/EU and 2013/36/EU, and Regulations (EU) No 1093/2010 and (EU) No 648/2012, of the European Parliament and of the Council (OJ L 173, 12.6.2014, S. 190). APPENDIX I TECHNICAL SPECIFICATIONS FOR THE PROCESSING OF CASH TRANSFER ORDERS In addition to the Conditions, the following rules shall apply to the processing of cash transfer orders: 1. Testing requirements for participation in TARGET-ECB Each participant shall pass a series of tests to prove its technical and operational competence before it may participate in TARGET-ECB. 2. Account numbers Each participant’s account shall be identified by a unique account number of up to 34 characters made up of five sections as follows: Name No. of Characters Content Account type 1 M = MCA R = RTGS DCA C = T2S DCA I = TIPS DCA T = RTGS AS Technical account U = Sub-account A = TIPS AS Technical account G = AS Guarantee funds account D = Overnight deposit account X = Contingency Account Country Code of Central Bank 2 ISO Country code: 3166-1 Currency code 3 EUR BIC 11 Account holder BIC Account name Max. 17 Free text (1) 3. Messaging rules in TARGET a) Each participant shall comply with the message structure and field specifications, as defined in Part 3 of the relevant User Detailed Functional Specifications (UDFS). b) Business application headers shall be attached to all message types processed on MCAs, RTGS DCAs (including sub-accounts) RTGS AS technical accounts, AS guarantee fund accounts and T2S DCAs as follows: Message Type Description head.001 Business application header head.002 Business file header 4. Message types processed in TARGET a) The following message types are processed on MCAs: Message Type Description Administration (admi) admi.004 SystemEventNotification admi.005 ReportQueryRequest admi.007 ReceiptAcknowledgement Cash Management (camt) camt.003 GetAccount camt.004 ReturnAccount camt.005 GetTransaction camt.006 ReturnTransaction camt.018 GetBusinessDayInformation camt.019 ReturnBusinessDayInformation camt.025 Receipt camt.046 GetReservation camt.047 ReturnReservation camt.048 ModifyReservation camt.049 DeleteReservation camt.050 LiquidityCreditTransfer camt.053 BankToCustomerStatement camt.054 BankToCustomerDebitCreditNotification Payments clearing and Settlement (pacs) pacs.009 FinancialInstitutionCreditTransfer pacs.010 FinancialInstitutionDirectDebit b) The following message types are processed on RTGS DCAs, and where relevant on the RTGS AS technical accounts and AS guarantee funds accounts: Administration (admi) admi.004 SystemEventNotification admi.005 ReportQueryRequest admi.007 ReceiptAcknowledgement Cash Management (camt) camt.003 GetAccount camt.004 ReturnAccount camt.005 GetTransaction camt.006 ReturnTransaction camt.007 ModifyTransaction camt.009 GetLimit camt.010 ReturnLimit camt.011 ModifyLimit camt.012 DeleteLimit camt.018 GetBusinessDayInformation camt.019 ReturnBusinessDayInformation camt.021 ReturnGeneralBusinessInformation camt.025 Receipt camt.029 ResolutionOfInvestigation camt.046 GetReservation camt.047 ReturnReservation camt.048 ModifyReservation camt.049 DeleteReservation camt.050 LiquidityCreditTransfer camt.053 BankToCustomerStatement camt.054 BankToCustomerDebitCreditNotification camt.056 FIToFIPaymentCancellationRequest Payments Clearing and Settlement (pacs) pacs.002 PaymentStatusReport pacs.004 PaymentReturn pacs.008 CustomerCreditTransfer pacs.009 FinancialInstitutionCreditTransfer pacs.010 FinancialInstitutionDirectDebit Payments Initiation (pain) pain.998 ASInitiationStatus pain.998 ASTransferNotice pain.998 ASTransferInitiation c) The following message types are processed on T2S DCAs: Message Type Description Administration (admi) admi.005 ReportQueryRequest admi.006 ResendRequestSystemEventNotification admi.007 ReceiptAcknowledgement Cash Management (camt) (camt.003) GetAccount (camt.004) ReturnAccount (camt.005) GetTransaction (camt.006) ReturnTransaction (camt.009) GetLimit (camt.010) ReturnLimit (camt.011) ModifyLimit (camt.012) DeleteLimit (camt.018) GetBusinessDayInformation (camt.019) ReturnBusinessDayInformation (camt.024) ModifyStandingOrder (camt.025) Receipt (camt.050) LiquidityCreditTransfer (camt.051) LiquidityDebitTransfer (camt.052) BankToCustomerAccountReport (camt.053) BankToCustomerStatement (camt.054) BankToCustomerDebitCreditNotification (camt.064) LimitUtilisationJournalQuery (camt.065) LimitUtilisationJournalReport (camt.066) IntraBalanceMovementInstruction (camt.067) IntraBalanceMovementStatusAdvice (camt.068) IntraBalanceMovementConfirmation (camt.069) GetStandingOrder (camt.070) ReturnStandingOrder (camt.071) DeleteStandingOrder (camt.072) IntraBalanceMovementModificationRequest (camt.073) IntraBalanceMovementModificationRequestStat usAdvice (camt.074) IntraBalanceMovementCancellationRequest (camt.075) IntraBalanceMovementCancellationRequestStat usAdvice (camt.078) IntraBalanceMovementQuery (camt.079) IntraBalanceMovementQueryResponse (camt.080) IntraBalanceModificationQuery (camt.081) IntraBalanceModificationReport (camt.082) IntraBalanceCancellationQuery (camt.083) IntraBalanceCancellationReport (camt.084) IntraBalanceMovementPostingReport (camt.085) IntraBalanceMovementPendingReport d) The following message types are processed on TIPS DCAs and TIPS AS technical accounts: Message Type Description Administration (admi) Pacs.002 FIToFIPayment Status Report Pacs.004 PaymentReturn Pacs.008 FIToFICustomerCreditTransfer Pacs.028 FIToFIPaymentStatusRequest Cash Management (camt) camt.003 GetAccount camt.004 ReturnAccount camt.011 ModifyLimit camt.019 ReturnBusinessDayInformation camt.025 Receipt camt.029 ResolutionOfInvestigation camt.050 LiquidityCreditTransfer camt.052 BankToCustomerAccountReport camt.053 BankToCustomerStatement camt.054 BankToCustomerDebitCreditNotification camt.056 FIToFIPaymentCancellationRequest acmt.010 AccountRequestAcknowledgement acmt.011 AccountRequestRejection acmt.015 AccountExcludedMandateMaintenanceRequest Reference data (reda) reda.016 PartyStatusAdviceV01 reda.022 PartyModificationRequestV01 5. Double-entry check All cash transfer orders shall pass a double-entry check, the aim of which is to reject orders that have been submitted more than once (duplicated cash transfer orders). Details can be found in Part I, Section 3 of the relevant UDFS. 6. Validation rules and error codes Validation of messages is carried out according to High Value Payments Plus (HVPS+) guidelines on message validations specified by the ISO 20022 standard, and TARGET-specific validations. The detailed validation rules and error codes are described in the respective parts of the UDFS as follows: a) for MCAs, in Chapter 14 of the CLM UDFS; b) for RTGS DCAs, in Chapter 13 of the RTGS UDFS; c) for T2S DCAs, in Chapter 4.1 of the T2S UDFS. If an instant payment order or a positive recall answer is rejected for any reason, the TIPS DCA holder shall receive a payment status report [pacs.002], as described in Chapter 4.2 of the TIPS UDFS. If a liquidity transfer order is rejected for any reason, the TIPS DCA holder shall receive a rejection [camt.025], as described in Chapter 1.6 of the TIPS UDFS. 7. Predetermined settlement times and events RTGS DCAs a) For payment orders using the Earliest Debit Time Indicator, the message element ‘/FromTime/’ shall be used. b) For payment orders using the Latest Debit Time Indicator, two options shall be available. i) Message element ‘RejectTime‘: if the payment order cannot be settled by the indicated debit time, the cash transfer order shall be rejected. ii) Message element ‘TillTime‘: if the payment order cannot be settled by the indicated debit time, the cash transfer order shall not be rejected but shall be kept in the relevant queue. Under both options, if a payment order with a Latest Debit Time Indicator is not settled 15 minutes prior to the time indicated therein, a notification shall automatically be sent via the GUI. T2S DCAs a) For immediate liquidity transfer orders, no specific XML tag is required; b) Predefined liquidity transfer orders and standing liquidity transfer orders may be triggered by a specific time or event on the day of settlement: i) for settlement at a specific time, the XML tag ‘Time(/ExctnTp/Tm/)‘ shall be used, ii) for settlement upon occurrence of a specific event, the XML tag ‘(EventType/ExctnTp/Evt/)‘ shall be used. c) the validity period for standing liquidity transfer orders shall be set by the following XML tags: ‘FromDate/VldtyPrd/FrDt/’ and ‘ToDate/VldtyPrd/ToDt/‘. 8. Offsetting of cash transfer orders on RTGS DCAs Offsetting checks and, if appropriate, extended offsetting checks (both terms as defined in subparagraphs a) and b) shall be carried out on cash transfer orders to facilitate the smooth settlement. a) An offsetting check shall determine whether the payee’s cash transfer orders that are at the front of the queue for cash transfer orders with the priority ‘urgent‘ or, if inapplicable, ’high‘ are available to be offset against the payer’s cash transfer order (hereinafter ‘offsetting cash transfer orders‘). If an offsetting cash transfer order does not provide sufficient funds for the respective payer’s cash transfer order it shall be determined whether there is sufficient available liquidity on the payer’s RTGS DCA. b) If the offsetting check fails, the ECB may apply an extended offsetting check. An extended offsetting check determines whether offsetting cash transfer orders are available in any of the payee’s queues regardless of when they joined the queue. However, if in the queue of the payee there are higher priority cash transfer orders addressed to other participants, the FIFO principle may only be breached if settling such an offsetting cash transfer order would result in a liquidity increase for the payee. 9. Optimisation algorithms on RTGS DCAs and sub-accounts Four algorithms shall be applied to facilitate the smooth settlement of payment flows. Further information is available in the RTGS UDFS Part 2. a) Under the ‘partial optimisation‘ algorithm the ECB shall: i) calculate and check the liquidity positions, limits and reservations of each relevant RTGS DCA; and ii) if the total liquidity position of one or more relevant RTGS DCA is negative, extract single payment orders until the total liquidity position of each relevant RTGS DCA is positive. Thereafter, the ECB and the other CBs involved shall, provided there are sufficient funds, settle the relevant remaining cash transfer orders (except the extracted payment orders described in point (ii)) simultaneously on the RTGS DCAs of the participants concerned. When extracting payment orders, the ECB shall start from the participant’s RTGS DCA with the highest negative total liquidity position and from the payment order at the end of the queue with the lowest priority. The selection process shall only run for a short time, to be determined by the ECB at its discretion. b) Under the ‘multiple optimisation‘ algorithm the ECB shall: i) compare pairs of participants‘ RTGS DCAs to determine whether queued payment orders can be settled within the available liquidity of the two participants‘ RTGS DCAs concerned and within the limits set by them (by starting from the pair of RTGS DCAs with the smallest difference between the payment orders addressed to each other), and the CBs involved shall book those payments simultaneously on the two participants‘ RTGS DCAs; and ii) if, in relation to a pair of RTGS DCAs as described in point (i), liquidity is insufficient to fund the bilateral position, extract single payment orders until there is sufficient liquidity. In this case the CBs involved shall settle the remaining payments, except the extracted ones, simultaneously on the two participants‘ RTGS DCAs. After performing the checks specified in points (i) to (ii), the ECB shall check the multilateral settlement positions (between a participant’s RTGS DCA and other participants‘ RTGS DCAs in relation to which a multilateral limit has been set). For this purpose, the procedure described under subparagraphs (i) to (ii) shall apply mutatis mutandis. c) Under the algorithm ‘partial optimisation with AS‘ which supports settlement procedure B, the ECB shall follow the same procedure as for the partial optimisation algorithm, but without extracting AS transfer orders (for an AS which settles on a simultaneous multilateral basis i.e. RTGS AS settlement procedure B). d) The algorithm ‘optimisation on sub-accounts‘ is used to optimise the settlement of urgent priority AS transfer orders on participants‘ sub-accounts. When using this algorithm the ECB shall calculate the total liquidity position of each participant’s sub-account by establishing whether the aggregate of all outgoing and incoming AS transfer orders pending in the queue is negative or positive. If the outcome of these calculations and checks is positive for each relevant sub-account, the ECB and other CBs involved shall settle all cash transfers simultaneously on the sub-accounts of the participants concerned. If the outcome of these calculations and checks is negative no settlement shall take place. Furthermore, this algorithm does not take account of any limits or reservations. For each settlement bank the total position is calculated and, if the positions for all settlement banks are covered, all transactions shall be settled. Transactions which are not covered are returned to the queue. e) Cash transfer orders entered after the multiple optimisation algorithm, the partial optimisation algorithm or the partial optimisation with AS algorithm has started may nevertheless be settled immediately if the positions and limits of the participants‘ RTGS DCAs concerned are compatible with both the settlement of these orders and the settlement of cash transfer orders in the current optimisation procedure. f) The partial optimisation algorithm and the multiple optimisation algorithm shall be run sequentially in that order. They shall not be run if RTGS AS settlement procedure B is running. g) The algorithms shall run flexibly by setting a pre-defined time lag between the application of different algorithms to ensure a minimum interval between the running of two algorithms. The time sequence shall be automatically controlled. Manual intervention shall be possible. h) While included in a running algorithm, a payment order shall not be reordered (change of the position in a queue) or revoked. Requests for reordering or revocation of a payment order shall be queued until the algorithm is complete. If the payment order concerned is settled while the algorithm is running, any request to reorder or revoke shall be rejected. If the payment order is not settled, the participant’s requests