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.

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 ▼M4 e) The following additional message subtypes are used for TIPS OLO credit transfer orders: Message Type Description pacs.002.001.03 FIToFIPayment Status Report pacs.008.001.08 FIToFICustomerCreditTransfer pacs.028.001.03 FIToFIPaymentStatusRequest Messages related to TIPS OLO credit transfer orders will be identified with the suffix XCY in the message exchange protocol. ▼B 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. ▼M4 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, a TIPS OLO credit transfer 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. ▼B 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 shall be taken into account immediately. 10. Connectivity Participants shall connect to TARGET using one of the following modes. a) The user to application (U2A) mode: in the U2A mode, participants connect via a GUI which allows users to perform business functions based on their respective access rights. It allows users to enter and maintain business data as well as to retrieve business information. The relevant User Handbook (UHB) provides exhaustive information on each of the business functions that the respective GUI provides. b) The application to application (A2A) mode: in A2A mode software applications communicate with TARGET by exchanging single messages and files based on their respective access rights and message subscription and routing configuration. The A2A communication relies on XML messages, using the ISO 20022 standard where applicable, for both inbound and outbound communication. The modes of connection are described in further detail in the ESMIG UDFS. 11. The UDFS and the User Handbook Further details and examples explaining the above rules are contained in the respective UDFS and the User Handbooks for each service, as amended from time to time and published on the ECB’s website in English. APPENDIX II TARGET COMPENSATION SCHEME 1. General principles a) If there is a technical malfunction of TARGET, participants may submit claims for compensation in accordance with the TARGET compensation scheme laid down in this Appendix. b) Unless otherwise decided by the ECB’s Governing Council, the TARGET compensation scheme shall not apply if the technical malfunction of TARGET arises out of external events beyond the reasonable control of the CBs concerned or as a result of acts or omissions by third parties. c) Compensation under the TARGET compensation scheme shall be the only compensation procedure offered in the event of a technical malfunction of TARGET. Participants may, however, use other legal means to claim for losses. If a participant accepts a compensation offer under the TARGET compensation scheme, this shall constitute the participant’s irrevocable agreement that it thereby waives all claims in relation to the cash transfer orders concerning which it accepts compensation (including any claims for consequential loss) it may have against any CB, and that the receipt by it of the corresponding compensation payment constitutes full and final settlement of all such claims. The participant shall indemnify the CBs concerned, up to a maximum of the amount received under the TARGET compensation scheme, in respect of any further claims which are raised by any other participant or any other third party in relation to the cash transfer order or cash transfer concerned. d) The making of a compensation offer shall not constitute an admission of liability by the ECB or any other CB in respect of a technical malfunction of TARGET. 2. Conditions for compensation offers a) A payer may submit a claim for an administration fee and interest compensation if, due to a technical malfunction of TARGET cash transfer order was not settled on the business day on which it was accepted. b) A payee may submit a claim for an administration fee if due to a technical malfunction of TARGET it did not receive a cash transfer that it was expecting to receive on a particular business day. The payee may also submit a claim for interest compensation if one or more of the following conditions are met: i) in the case of participants that have access to the marginal lending facility: due to a technical malfunction of TARGET, a payee had recourse to the marginal lending facility; and/or ii) in the case of all participants: it was technically impossible to have recourse to the money market or such refinancing was impossible on other, objectively reasonable grounds. 3. Calculation of compensation a) With respect to a compensation offer for a payer: i) the administration fee shall be EUR 50 for the first non-settled cash transfer order, EUR 25 for each of the next four such cash transfer orders and EU 12,50 for each further such cash transfer order. The administration fee shall be calculated separately in relation to each payee; ii) interest compensation shall be determined by applying a reference rate to be fixed from day to day. This reference rate shall be the lower of the euro short term reference rate (EURSTR) rate and the marginal lending facility rate. The reference rate shall be applied to the amount of the cash transfer order not settled as a result of the technical malfunction of TARGET for each day in the period from the date of the actual or, in relation to cash transfer orders referred to in paragraph 2(b)(ii), intended submission of the cash transfer order until the date on which the cash transfer order was or could have been successfully settled. Any interest or charges resulting from the placing of any nonsettled cash transfer orders on deposit with the Eurosystem shall be deducted from, or charged to, the amount of any compensation, as the case may be; iii) no interest compensation shall be payable if and in so far as funds resulting from nonsettled cash transfer orders were placed in the market or used to fulfil minimum reserve requirements. b) With respect to a compensation offer for a payee: i) the administration fee shall be EUR 50 for the first non-settled cash transfer order, EUR 25 for each of the next four such cash transfer orders and EUR 12,50 for each further such cash transfer order. The administration fee shall be calculated separately in relation to each payer; ii) the method set out in subparagraph (a)(ii) for calculating interest compensation shall apply except that interest compensation shall be payable at a rate equal to the difference between the marginal lending facility rate and the reference rate, and shall be calculated on the amount of any recourse to the marginal lending facility occurring as a result of the technical malfunction of TARGET. 4. Procedural rules a) A claim for compensation shall be submitted on the claim form available on the website of the ECB (see https://www.ecb.europa.eu). Payers shall submit a separate claim form in respect of each payee and payees shall submit a separate claim form in respect of each payer. Sufficient additional information and documents shall be provided to support the information indicated in the claim form. Only one claim may be submitted in relation to a specific payment or payment order. b) Within four weeks of a technical malfunction of TARGET, participants shall submit their claim forms to the ECB. Any additional information and evidence requested by the ECB shall be supplied within two weeks of such request being made. c) The ECB shall review the claims and forward them to the ECB. Unless otherwise decided by the ECB’s Governing Council and communicated to the participants, all received claims shall be assessed no later than 14 weeks after the technical malfunction of TARGET occurs. d) The ECB shall communicate the result of the assessment referred to in subparagraph (c) to the relevant participants. If the assessment entails a compensation offer, the participants concerned shall, within four weeks of the communication of such offer, either accept or reject it, in respect of each cash transfer order comprised within each claim, by signing a standard letter of acceptance (in the form available on the website of the ECB (see https://www.ecb.europa.eu). If such letter has not been received by the ECB within four weeks, the participants concerned shall be deemed to have rejected the compensation offer. e) The ECB shall make compensation payments on receipt of a participant’s letter of acceptance of compensation. No interest shall be payable on any compensation payment. APPENDIX III TERMS OF REFERENCE FOR CAPACITY AND COUNTRY OPINIONS Terms of reference for capacity opinions for participants in TARGET European Central Bank Sonnemannstrasse 20 60314 Frankfurt am Main GERMANY Participation in TARGET-ECB [location] [date] Dear Sir or Madam, We have been asked to provide this Opinion as [in-house or external] legal advisers to [specify name of Participant or branch of Participant] in respect of issues arising under the laws of [jurisdiction in which the Participant is est