Guideline (EU) 2022/912 of the European Central Bank of 24 February 2022 on a new... (32022O0912)
EU - Rechtsakte: 10 Economic and monetary policy and free movement of capital

GUIDELINE (EU) 2022/912 OF THE EUROPEAN CENTRAL BANK

of 24 February 2022

on a new-generation Trans-European Automated Real-time Gross Settlement Express Transfer system (TARGET) and repealing Guideline 2013/47/EU (ECB/2012/27)

(ECB/2022/8)

THE GOVERNING COUNCIL OF THE EUROPEAN CENTRAL BANK,
Having regard to the Treaty on the Functioning of the European Union, and in particular the first and fourth indents of Article 127(2) thereof,
Having regard to the Statute of the European System of Central Banks and of the European Central Bank, and in particular Article 3.1 and Articles 17, 18 and 22 thereof,
Whereas:
(1) The Trans-European Automated Real-time Gross settlement Express Transfer system (TARGET2) is governed by Guideline 2013/47/EU of the European Central Bank (ECB/2012/27) (1).
(2) On 20 March 2018 the ‘Collective Agreement’ signed between the central banks operating TARGET2 component systems and the central securities depositories (CSDs) operating on the TARGET2-Securities platform entered into force. This Agreement covers the provision of information and liability in the event of the insolvency of a participant in the systems and defines a common moment of entry for payments and securities transfer orders that are settled in these systems.
(3) On 6 December 2017 the Governing Council approved the T2-T2S Consolidation Project, the objective of which is to consolidate and optimise TARGET2 and TARGET2-Securities (T2S), benefiting from state-of-the-art approaches and technological innovation, enabling a decrease in their combined operational cost, and enhancing liquidity management across the various services. The result of the T2-T2S Consolidation Project is the new-generation Trans-European Automated Real-time Gross settlement Express Transfer system settling in euro in central bank money (TARGET).
(4) From 21 November 2022, TARGET2 should be replaced by TARGET. Therefore, Guideline 2013/47/EU (ECB/2012/27) should be repealed.
(5) As is the case for TARGET2, TARGET should be legally structured as a multiplicity of payment systems, where all TARGET component systems are harmonised to the greatest extent possible.
(6) As is the case for TARGET2, in TARGET there should be three separate levels of governance. Level 1 (Governing Council) should have final competence in relation to TARGET and safeguard its public function. Level 2 (Technical and operational management body) should have subsidiary competence for the management and steering of TARGET, while Level 3 (providing national central banks) should build and operate the TARGET systems for the Eurosystem’s benefit.
(7) TARGET should provide central liquidity management services, including the settlement of central bank operations through main cash accounts (MCAs), large value real-time gross settlement (RTGS) for payments through RTGS dedicated cash accounts (DCAs), cash payments in relation to securities settlement through T2S dedicated cash accounts (T2S DCAs) and settlement of instant payments through TARGET Instant Payment Settlement (TIPS) dedicated cash accounts (TIPS DCAs), and services for ancillary system (AS) settlement through sub-accounts, RTGS AS technical accounts, AS guarantee fund accounts and TIPS AS technical accounts.
(8) In order to ensure clarity and equal treatment, it is appropriate that the provision of these services should be governed by harmonised sets of conditions for participation in TARGET, which should be concluded between each TARGET participant and the national central bank (NCB) operating the respective TARGET component system.
(9) In order to increase competitiveness, TARGET should provide for multiple network service providers (NSPs) responsible for establishing the technical connection to TARGET. TARGET participants should be allowed to enter into a contractual relationship with an NSP within the framework of the concession contract concluded between the Banca d'Italia, as Eurosystem agent and the NSP, or with a subcontractor of the latter, of their choice.
(10) TARGET2 component systems owned and operated by the respective Eurosystem CBs have been collectively identified (2) as a systemically important payment system (SIPS) subject to Regulation of the European Central Bank (EU) No 795/2014 (ECB/2014/28) (3). The respective TARGET component systems, as the payment systems replacing those TARGET2 component systems, should likewise fall within the scope of Regulation (EU) No 795/2014 (ECB/2014/28) and comply with the oversight requirements laid down in that Regulation.
(11) TARGET is essential for the performance of certain basic Eurosystem tasks, i.e. implementing the Union’s monetary policy and promoting the smooth operation of payment systems.
(12) TARGET component systems constitute the legal successors to the corresponding TARGET2 component systems,
HAS ADOPTED THIS GUIDELINE:

SECTION I

GENERAL PROVISIONS

Article 1

Subject matter and scope

TARGET provides the following accounts for settlement in euro in central bank money,
(a) Main cash accounts (MCAs) for the settlement of operations with central banks;
(b) Real-time gross settlement dedicated cash accounts (RTGS DCAs) and sub-accounts for real-time interbank and customer payments, and settlement of transactions with ancillary systems (AS);
(c) Real-time gross settlement ancillary system technical accounts (RTGS AS technical accounts), TARGET Instant Payment Settlement (TIPS) ancillary system technical accounts (TIPS AS technical accounts) and ancillary systems guarantee funds accounts (AS guarantee funds accounts) for the settlement of transactions with AS;
(d) TARGET2-Securities dedicated cash accounts (T2S DCAs) for cash payments in relation to securities transactions; and
(e) TARGET instant payment settlement dedicated cash accounts (TIPS DCAs) for the settlement of instant payments.

Article 2

Definitions

For the purposes of this Guideline each of the following terms shall have the meaning ascribed to it in Annex III:
(1) ‘account monitoring group’;
(2) ‘addressable BIC holder’;
(3) ‘ancillary system’ (AS);
(4) ‘ancillary system guarantee funds account’ (AS guarantee funds account);
(5) ‘ancillary system settlement procedure’ (AS settlement procedure);
(6) ‘ancillary system transfer order’ (AS transfer order);
(7) ‘auto-collateralisation’;
(8) ‘automated liquidity transfer order’;
(9) ‘available liquidity’;
(10) ‘banking group’;
(11) ‘branch’;
(12) ‘broadcast message’;
(13) ‘business day’ or ‘TARGET business day’;
(14) ‘Business Identifier Code’;
(15) ‘capacity opinion’;
(16) ‘cash transfer order’;
(17) ‘central bank’ (CB);
(18) ‘central bank operation’;
(19) ‘connected NCB’;
(20) ‘Contingency Solution’;
(21) ‘credit institution’;
(22) ‘credit memorandum balance’ (CMB);
(23) ‘cross-system settlement’;
(24) ‘dedicated cash account’ (DCA);
(25) ‘deposit facility rate’;
(26) ‘deposit facility’;
(27) ‘euro area NCB’;
(28) ‘European Payments Council’s SEPA Instant Credit Transfer (SCT Inst) scheme’ or ‘SCT Inst Scheme’;
(29) ‘Eurosystem CB’;
(30) ‘event of default’;
(31) ‘guarantee funds’;
(32) ‘insolvency proceedings’;
(33) ‘instant payment order’;
(34) ‘instructing party’;
(35) ‘intraday credit’;
(36) ‘investment firm’;
(37) ‘Level 3 NCBs’;
(38) ‘liquidity transfer order’;
(39) ‘marginal lending facility rate’
(40) ‘marginal lending facility’;
(41) ‘mobile proxy look-up (MPL) service’;
(42) ‘near instant payment’;
(43) ‘network service provider’;
(44) ‘non-settled cash transfer order’;
(45) ‘participant’;
(46) ‘payee’;
(47) ‘payer’;
(48) ‘payment order’;
(49) ‘positive recall answer’;
(50) ‘public sector body’;
(51) ‘reachable party’;
(52) ‘Real-time gross settlement ancillary system settlement procedure’ (RTGS AS settlement procedure);
(53) ‘Real-time gross settlement ancillary system technical account’;
(54) ‘recall request’;
(55) ‘rule-based liquidity transfer order’;
(56) ‘settlement bank account group’;
(57) ‘settlement bank’;
(58) ‘suspension’;
(59) ‘TARGET account’;
(60) ‘TARGET component system’;
(61) ‘TARGET coordinator’;
(62) ‘TARGET Instant Payment Settlement (TIPS) ancillary system settlement procedure’ (TIPS AS settlement procedure);
(63) ‘TARGET Instant Payment Settlement (TIPS) ancillary system technical account’ (TIPS AS technical account);
(64) ‘TARGET settlement manager’;
(65) ‘TARGET2-Securities’ (T2S);
(66) ‘technical malfunction of TARGET’.

Article 3

TARGET component systems

1.   TARGET is legally structured as a multiplicity of payment systems which make up the component systems of TARGET.
2.   Each Eurosystem CB shall operate its own TARGET component system.
3.   Each TARGET component system shall be a system designated as such under the relevant national legislation implementing Directive 98/26/EC of the European Parleament and of the Council (4).
4.   The names of the TARGET component systems shall only include ‘TARGET’ and the name or abbreviation of the relevant Eurosystem CB or of the Member State of such Eurosystem CB. The ECB’s TARGET component system shall be called TARGET-ECB.

Article 4

Connection of NCBs of Member States whose currency is not the euro

The NCBs of Member States whose currency is not the euro may only connect to TARGET if they conclude an agreement with the Eurosystem CBs. Such agreement shall specify that the connected NCBs will comply with this Guideline, subject to any mutually agreed appropriate specifications and modifications.

Article 5

Intra-ESCB transactions

Intra-European System of Central Banks (ESCB) transactions denominated in euro shall be processed through TARGET, with the exception of payments that the CBs bilaterally agree to process through correspondent accounts, where appropriate.

Article 6

Intra-Eurosystem obligations and claims

1.   Any settlement of cash transfer orders between participants in different TARGET component systems shall automatically be aggregated and adjusted to form part of a single obligation or claim of each euro area NCB vis-à-vis the ECB as set out in an agreement between the Eurosystem CBs. Any obligation or claim of each euro area NCB vis-à-vis the ECB shall be adjusted for book-keeping purposes on a daily basis, using the delta of the end-of-day balances of all the TARGET accounts in the books of the respective euro area NCB.
2.   For accounting and reporting purposes, each euro area NCB shall maintain an account to record its obligation or claim towards the ECB, resulting from the settlement of cash transfer orders between its own and other TARGET component systems.7
3.   The ECB shall open on its books an account for each euro area NCB in order to mirror at the end of the day such euro area NCB’s obligation or claim towards the ECB.

SECTION II

GOVERNANCE

Article 7

Governance levels

1.   Without prejudice to Article 8 of the Statute of the European System of Central Banks and of the European Central Bank (hereinafter the ‘Statute of the ESCB’), the management of TARGET shall be based on a three-level governance scheme. The tasks assigned to the Governing Council (Level 1), the Level 2 technical and operational management body and the Level 3 NCBs are laid down in Annex II.
2.   The Governing Council shall be responsible for the direction, management and control of TARGET. The tasks assigned to Level 1 fall within the exclusive competence of the Governing Council.
3.   In accordance with the third subparagraph of Article 12.1 of the Statute of the ESCB, the Eurosystem CBs shall be responsible for the tasks assigned to Level 2, within the general framework defined by the Governing Council. A Level 2 body has been established by the Governing Council and entrusted by the Eurosystem CBs with certain technical and operational management tasks related to TARGET.
4.   The Eurosystem CBs shall organise themselves through the conclusion of appropriate agreements.
5.   In accordance with the third subparagraph of Article 12.1 of the Statute of the ESCB, the Level 3 NCBs shall be responsible for the tasks assigned to Level 3, within the general framework defined by the Governing Council.
6.   The Level 3 NCBs shall conclude agreements with the Eurosystem CBs governing the provision of the services to be provided by the Level 3 NCBs. Such agreements shall also include, where appropriate, the connected NCBs.
7.   The Eurosystem, as provider of T2S services, and the Eurosystem CBs, as operators of their respective national TARGET component systems, shall conclude an agreement governing the services to be provided by the former to the latter in respect of the operation of the T2S DCAs. Such agreements shall also be entered into, where appropriate, by the connected NCBs.

SECTION III

OPERATION OF TARGET

Article 8

System support desk

Each Eurosystem CB shall establish and maintain a system support desk providing support to the participants of its respective national TARGET component system. The support desk shall be provided at a minimum between the hours of 07:00 CET and 18:15 CET. This will be extended to 18:30 CET on the last day of the Eurosystem reserve maintenance period.

Article 9

Harmonised Conditions for participation in TARGET

1.   Each euro area NCB shall adopt arrangements implementing the Harmonised Conditions for participation in TARGET as laid down in Annex I and so that terms used therein that are listed in Annex III shall have the meaning ascribed to them in Annex III. These arrangements shall exclusively govern the relationship between the relevant euro area NCB and its participants in respect of the opening and operation of TARGET accounts.
2.   With effect from 20 November 2023, Eurosystem CBs shall not open accounts other than TARGET accounts for participants eligible to participate in TARGET for the purpose of providing services falling within the scope of this Guideline, subject to the following exceptions:
(a) accounts for those participants listed under Annex I, Part I, Article 4(2), points (a) and (b) of the Harmonised Conditions for participation in TARGET;
(b) accounts where funds are held intraday for the sole purpose of carrying out cash lodgements and withdrawals;
(c) accounts used to hold seized funds or funds pledged to a third-party creditor or funds referred to in Article 3(1)(d) of Regulation (EU) 2021/378 of the European Central Bank (ECB/2021/1) (5);
(d) accounts used by participants in systems operated by an NCB and used to clear instant payments complying with the SCT Inst scheme.
3.   The ECB shall adopt the Terms and Conditions of TARGET-ECB by implementing the Harmonised Conditions for participation in TARGET as laid down in Annex I except that:
(a) TARGET-ECB shall only provide clearing and settlement services to clearing and settlement organisations, including entities established outside the European Economic Area (EEA), if they are subject to oversight by a competent authority and their access to TARGET-ECB has been approved by the Governing Council;
(b) TARGET-ECB shall not provide intraday credit or auto-collateralisation.
4.   The standard arrangements adopted by the Eurosystem CBs implementing the Harmonised Conditions for participation in TARGET shall be made public.
5.   The Eurosystem CBs may request derogations from the Harmonised Conditions for participation in TARGET on the basis of national law constraints. The Governing Council shall consider such requests on a case-by-case basis and shall grant derogations where appropriate.
6.   Subject to the relevant monetary agreement, the ECB may determine appropriate conditions for participation in TARGET by entities referred to in Annex I, Part I, Article 4(2), point (e).
7.   The Eurosystem CBs shall not allow any entity to be an addressable BIC holder or reachable party in their TARGET component system if this entity acts via a TARGET account holder that is an NCB of a Member State but is neither a Eurosystem CB nor a connected NCB.
8.   The Eurosystem CBs shall not register addressable BIC holders which are eligible to participate in TARGET as set out in Annex I, Part I, Article 4, with the exception of their own branches and those entities listed under Annex I, Part I, Article 4(2), points (a) and (b).
9.   With the exception of rules in connection with AS, the Eurosystem CBs shall implement no additional rules in connection with participation in TARGET other than those set out in the Harmonised Conditions for participation in TARGET. No fees shall be charged for the use of or in connection with TARGET, other than those set out in Annex I, Appendix VI, with the exception of fees charged for services related to an NCB co-managing an MCA (as set out in Annex I, Part II, Article 2) if these services are offered by the Eurosystem CB. A Eurosystem CB offering co-management of an MCA shall observe the principle of full cost recovery in setting its fees for these services and pass on, as a minimum, the full costs arising from these services.
10.   By way of derogation from paragraph 9, the Eurosystem CBs may set additional rules with respect to TARGET accounts opened to hold funds provided as cash collateral or forming part of a cover pool.

Article 10

Intraday credit — auto-collateralisation

1.   The euro area NCBs may grant intraday credit to a participant. Intraday credit may only be granted on its primary MCA and only in accordance with the arrangements implementing the rules on the provision of intraday credit laid down in Annex I, Part II. No intraday credit shall be granted to a participant whose eligibility as a counterparty for Eurosystem monetary policy operations has been suspended or terminated.
2.   Further to a request from a participant with access to intraday credit, the euro area NCBs shall offer an auto-collateralisation facility on T2S DCAs, provided that this is done in accordance with the conditions for Auto-collateralisation Operations laid down in Annex I, Part IV.
3.   Participants which are subject to restrictive measures adopted by the Council of the European Union or Member States pursuant to Article 65(1), point (b), Article 75 or Article 215 of the Treaty, the implementation of which, in the view of relevant euro area NCB and after informing the ECB, is incompatible with the smooth functioning of TARGET, shall not be eligible for intraday credit or auto-collateralisation.
4.   The euro area NCBs may grant intraday credit to AS as set out in Annex I, Part II, Article 10(2), point (d) provided that the arrangements have been submitted to the Governing Council in advance and have been approved by the Governing Council.
5.   The euro area NCBs may provide overnight credit to certain eligible central counterparties (CCPs), under the conditions set out in Annex I, Part II, Article 10(5), provided that the request has been submitted to the Governing Council in advance and has been approved by the Governing Council.
6.   The Governing Council may, upon a proposal by the relevant euro area NCB, exempt the treasury departments referred to in Annex I, Part II, Article 10(2), point (b) from the requirement to provide adequate collateral before obtaining intraday credit.
7.   Where a euro area NCB decides to suspend, limit or terminate a participant’s access to intraday credit or auto-collateralisation, on grounds of prudence as set out in Annex I, Part II, Article 13(1), point (c) or Annex I, Part IV, Article 11, respectively, it shall immediately notify the ECB and other euro area NCBs and connected NCBs thereof in writing. Where appropriate, the Governing Council shall decide upon uniform implementation of the measures taken in all TARGET component systems.
8.   If a counterparty’s access to monetary policy instruments is suspended, limited or excluded on the grounds of prudence or otherwise in accordance with the national provisions implementing Article 158 of Guideline (EU) 2015/510 of the European Central Bank (ECB/2014/60) (6), the relevant euro area NCB shall, in respect of access to intraday credit, implement that decision pursuant to provisions in the contractual or regulatory arrangements applied by the relevant euro area NCB.
9.   Where a euro area NCB decides to suspend, limit or terminate a Eurosystem monetary policy counterparty’s access to intraday credit or auto-collateralisation facilities in accordance with Annex I, Part II, Article 13(3) or Annex I, Part IV, Article 11, respectively, such decision shall not take effect until the Governing Council of the ECB has approved it.
10.   By derogation from paragraph 9, in urgent circumstances a euro area NCB may suspend a Eurosystem monetary policy counterparty’s access to intraday credit and/or auto-collateralisation facilities with immediate effect. In such cases the euro area NCB concerned shall immediately notify the Governing Council of the ECB thereof in writing. The Governing Council of the ECB shall have the power to reverse the euro area NCB’s action. However, if the Governing Council of the ECB does not send the euro area NCB notice of such reversal within 10 business days of the ECB’s receipt of notification, the Governing Council of the ECB shall be deemed to have approved the euro area NCB’s action.
11.   The Governing Council of the ECB may decide to waive or reduce the penalties set out in Annex I, Part II, Article 12(4) if the end-of-day debit balance of the entity in question is attributable to force majeure and/or technical malfunction of TARGET, the latter phrase as defined in Annex III.

Article 11

Additional conditions for AS

1.   In addition to the provisions of Article 9(1) to (9), the following shall apply to the relationship between the relevant Eurosystem CB and the AS including ASs operated by Eurosystem CBs.
2.   The Eurosystem CBs shall provide fund transfer services in central bank money to AS acting in that capacity. These services shall be offered via either:
(a) the TIPS AS Settlement procedure only to support the settlement of instant payments pursuant to the SCT Inst scheme or near instant payments in the books of the AS; or
(b) the RTGS AS Settlement Procedures for all other business cases.
3.   The Eurosystem CBs may, exceptionally and following approval of the Level 2 body as referred to in Annex II, approve the use of an RTGS DCA by an AS except in relation to the settlement of instant payments pursuant to the SCT Inst scheme. An application for permission shall include a reasoned request of the AS. If the request is granted the pricing set out in Annex I, Appendix VI, paragraph 4 will apply.
4.   Each Eurosystem CB shall open a sub-account on request for any settlement bank for which it holds an RTGS DCA when the AS of the settlement bank participates either in the TARGET component system of that Eurosystem NCB or in a different TARGET component system.
5.   The Eurosystem CBs may, in addition to those conditions in Annex I, set conditions in connection with participation of AS in TARGET that are related to:
(a) business continuity and contingency procedures;
(b) the nature of the entitlement to funds held on a TARGET account where the funds held do not form part of the estate of the AS;
(c) the CBs’ rights of pledge and set off on TARGET accounts held by or on behalf of AS;
(d) collection and distribution of accrued interest;
(e) regulatory requirements (including oversight) on AS or AS settlement banks (including those applied by foreign regulators);
(f) information exchange to verify compliance with a Eurosystem policy.
6.   Eurosystem CBs shall exchange information regarding any significant event during the settlement process of AS.

Article 12

Financing and cost methodology

1.   The Governing Council shall determine the rules applicable to the financing of TARGET.
2.   The Governing Council shall determine the pricing structure for TARGET using a common Eurosystem cost methodology.

Article 13

Security provisions

The Eurosystem CBs shall comply with measures specified by the Governing Council setting out the security policy and security requirements and controls applicable to TARGET, including in relation to cyber resilience and information security.

Article 14

Audit rules

Audit assessments shall be performed in accordance with the principles and arrangements set out in the Governing Council’s ESCB Audit Policy.

Article 15

Obligations in the event of suspension or termination

1.   Eurosystem CBs shall immediately terminate without prior notice or suspend a participant’s participation in the relevant TARGET component system if:
(a) insolvency proceedings are opened in relation to a participant; or
(b) a participant no longer meets the access criteria for the participation in the relevant TARGET component system.
2.   If a Eurosystem CB suspends or terminates a participant’s participation in TARGET in accordance with paragraph 1 or on the grounds of prudence in accordance with Article 17, it shall immediately notify all other Eurosystem CBs thereof, providing all of the following:
(a) the participant’s name and BIC;
(b) the information upon which the euro area NCB based its decision, including any information or opinion obtained from the relevant supervisory authority;
(c) the measure taken and a proposed time frame for its application.
Each Eurosystem CB shall, if so requested by another Eurosystem CB, exchange information in relation to such participant, including information in relation to cash transfer orders addressed to it.
3.   A Eurosystem CB that has terminated or suspended the participation of a participant in its TARGET component system in accordance with paragraph 1 shall assume liability in relation to the other Eurosystem CBs if it either:
(a) subsequently authorises the settlement of cash transfer orders addressed to participants whose participation it has suspended or terminated; or
(b) does not comply with the obligations in paragraphs 1 and 2.
4.   A Eurosystem CB that has suspended the participation of a participant in its TARGET component system pursuant to paragraph 1(a) shall only process cash transfer orders from that participant on the instructions of its representatives, including those appointed by a competent authority or a court, such as the participant's insolvency administrator, or pursuant to an enforceable decision of a competent authority or a court providing instructions as to how the payments are to be processed. A Eurosystem CB shall reject all outgoing cash transfer orders from the TIPS DCA(s) of a suspended participant.

Article 16

Procedures for the rejection on the grounds of prudence of an application for participation in TARGET

Where, pursuant to Annex I, Part I, Article 5(5), point (c), a Eurosystem CB rejects on the grounds of prudence an application to join TARGET, that Eurosystem CB shall promptly inform the other Eurosystem CBs of such rejection.

Article 17

Procedures for the suspension, limitation or termination on the grounds of prudence of participation in TARGET, and access to intraday credit and to auto-collateralisation

1.   Where on the grounds of prudence, a euro area NCB suspends, limits or terminates a participant's access to intraday credit pursuant to Annex I, Part II, Article 13(1), point (c) or to auto-collateralisation pursuant to Annex I, Part IV, Article 11 or a Eurosystem CB suspends or terminates a participant's participation in TARGET pursuant to Annex I, Part I, Article 25(2), point (e), the decision shall, to the extent possible, take effect at the same time in all TARGET component systems.
2.   The euro area NCB shall provide the information of Article 15(2) promptly to the relevant supervisory authorities in the euro area NCB’s Member State, with the request that the supervisory authorities share information with the supervisory authorities of other Member States in which the participant has a subsidiary or branch. Taking into account the decision pursuant to paragraph 1, other euro area NCBs shall take appropriate action and provide information thereof promptly to the ECB.
3.   The ECB’s Executive Board may propose to the Governing Council to take any decisions in order to ensure uniform implementation of the measures taken pursuant to paragraphs 1 and 2.
4.   The euro area NCBs of the Member States in which the decision is to be implemented shall inform the participant about the decision, and shall take all necessary implementation measures.

Article 18

Procedures for cooperation by Eurosystem CBs in connection with administrative or restrictive measures

In connection with the implementation of Annex I, Part I, Article 29(3):
1.
any Eurosystem CB shall promptly share with all potentially affected CBs all information that it receives in connection with a proposed cash transfer order, with the exception of liquidity transfer orders between different accounts of the same participant;
2.
any Eurosystem CB that receives from a participant evidence of notification having been made to, or consent having been received from, any competent authority shall promptly transmit such evidence to any other CB acting as the payment service provider of the payer or payee as appropriate;
3.
the Eurosystem CB acting as payment service provider of the payer shall then promptly inform the payer that it can enter a relevant cash transfer order into TARGET.

Article 19

Business continuity and contingency procedures

1.   If an event affecting the normal operation of TARGET occurs, the Eurosystem CB concerned shall immediately notify the TARGET coordinator, who together with the TARGET settlement manager of the Eurosystem CB concerned shall decide on the further steps to be taken.
2.   The Eurosystem CBs shall report a failure linked to a participant as referred to in Annex I, Appendix IV, paragraph 2.4, 3.3 or 4.2 to the TARGET coordinator no more than 30 minutes after the start of the failure or at the first opportunity after detecting the failure if such failure might affect the operation of TARGET or create systemic risk or if the participant has been designated as a critical participant by the Eurosystem CBs on the basis of criteria periodically updated and published on the ECB’s website.
3.   In exceptional circumstances, the Eurosystem CBs may decide to change TARGET’s operating schedule for reasons including but not limited to a failure affecting an AS. Such decision shall be taken collectively by the Eurosystem CBs.
4.   In the cases of any other events which have the potential to affect the normal functioning of TARGET, the Eurosystem CB concerned shall monitor and manage such events in order to prevent any spillover to the smooth functioning of TARGET.
5.   The Eurosystem CBs shall maintain a connection to the Contingency Solution.

Article 20

Treatment of claims under the TARGET compensation scheme

1.   Unless otherwise decided by the Governing Council, the compensation procedure set out in Annex I, Appendix II shall be managed in accordance with this Article.
2.   The CB of the participant submitting the claim for compensation shall assess the compensation claim on a preliminary basis and communicate with the participant in relation to that assessment. Where necessary for the assessment of claims, such CB shall be assisted by other CBs concerned. The relevant CB shall inform the ECB and all other CBs concerned as soon as it becomes aware of pending claims.
3.   Within nine weeks following a technical malfunction of TARGET, the CB of the participant submitting the claim shall prepare a preliminary assessment report containing the CB’s assessment of the claims received and submit it to the ECB and all other CBs concerned.
4.   Within five weeks following receipt of the preliminary assessment report, the Governing Council shall carry out the final assessment of all claims received, and shall decide on the compensation offers to be made to the participants concerned. Within five business days following the completion of the final assessment, the ECB shall communicate the outcome of the final assessment to the CBs concerned. Those CBs shall promptly inform their participants of the outcome of the final assessment and, where applicable, details of the compensation offer, together with the form constituting the letter of acceptance.
5.   Within two weeks following expiry of the period referred to in the final sentence of Annex I, Appendix II, paragraph 4(d), the CB shall inform the ECB and all other CBs concerned about which compensation offers have been accepted and which compensation offers have been rejected.
6.   The CBs shall inform the ECB of any claims submitted to them by their participants outside the scope of the TARGET compensation scheme, but relating to a technical malfunction of TARGET.

Article 21

Treatment of losses caused by a technical malfunction of TARGET

1.   In the event of a technical malfunction of TARGET:
(a) On the payer’s side, any CB with which a payer has placed a deposit benefits from certain financial gains which amount to the difference between the Eurosystem’s main refinancing operations rate and the deposit rate applied to the marginal increase in the use of the Eurosystem’s deposit facility for the period of the technical malfunction of TARGET and up to the amount of the non-settled cash transfer orders. Where the payer is left with non-remunerated surplus funds, the financial gains amount to the Eurosystem’s main refinancing operations rate, applied to the amount of the non-interest-bearing surplus funds for the period of the technical malfunction of TARGET and up to the amount of the non-settled cash transfer orders.
(b) On the payee’s side, the CB from whom the payee has borrowed by using the marginal lending facility benefits from certain financial gains which amount to the difference between the marginal lending facility rate and the Eurosystem’s main refinancing operations rate, applied to the marginal increase in the use of the marginal lending facility for the period of the technical malfunction of TARGET and up to the amount of the non-settled cash transfer orders.
2.   The ECB’s financial gains amount to:
(a) the earnings in relation to the connected NCBs arising from the different remuneration of end-of-day balances of those connected NCBs in relation to the ECB; and
(b) the amount of penalty interest the ECB receives from connected NCBs whenever one of those connected NCBs imposes a penalty on a participant for a failure to reimburse intraday credit on time, as provided for in the agreement between the Eurosystem CBs and the connected NCBs.
3.   The financial gains referred to in paragraphs 1 and 2 shall be pooled by the CBs and the resulting pooled amount shall be used to reimburse those CBs that incur the costs of compensating their participants. Any remaining financial gains or costs incurred by the CBs in compensating their participants shall be shared among the Eurosystem CBs in accordance with the key for subscription to the ECB’s capital.

Article 22

Security rights in relation to funds on sub-accounts and intra-Eurosystem guarantee

1.   For the purpose of the settlement of AS transfer orders related to RTGS AS settlement procedure C, any Eurosystem CB that has opened sub-accounts for its RTGS DCA holders shall ensure that the balances on such sub-accounts (including increases or reductions of that balance resulting from crediting or debiting cross system settlement payments to or from the sub-account or from crediting liquidity transfers to the sub-account) at the moment the AS starts a settlement cycle can only be used for the settlement of AS transfer orders related to that RTGS AS settlement procedure C. This is notwithstanding any insolvency proceedings with respect to the relevant RTGS DCA holder and notwithstanding any individual enforcement measure relating to such RTGS DCA holder’s sub-account.
2.   Each time liquidity is transferred to a RTGS DCA holder’s sub-account and where the Eurosystem CB is not the AS’s CB, such Eurosystem CB shall, upon communication by the AS (via a ‘start-of-cycle’ message), confirm the balance on the sub-account to the relevant AS and, in doing so, guarantee to the AS’s CB payment up to the amount of this particular balance. The confirmation of the balance to the AS shall also entail a legally binding declaration of will by the AS’s CB that the latter guarantees to the AS payment up to the amount of the confirmed balance. By confirming the increase or reduction of that balance upon crediting or debiting cross-system settlement AS transfer orders to or from the sub-account or crediting liquidity transfers to the sub-account, both the Eurosystem CB that is not the AS’s CB and the AS’s CB declare an increase or a reduction of the guarantee in the amount of the payment. Both guarantees shall be irrevocable, unconditional and payable on first demand. Both guarantees shall expire upon communication by the AS that the settlement has been completed (via an ‘end-of-cycle’ message).

SECTION IV

TRANSITIONAL AND FINAL PROVISIONS

Article 23

Dispute resolution and applicable law

1.   In the event of a dispute between Eurosystem CBs in relation to this Guideline, the affected parties shall seek to settle the dispute in accordance with the Memorandum of Understanding on an Intra-ESCB Dispute Settlement Procedure.
2.   By derogation from paragraph 1, if a dispute relating to the division of the tasks between Level 2 and Level 3 cannot be settled by agreement between the affected parties, the Governing Council shall resolve the dispute.
3.   In the event of a dispute of the type referred to in paragraph 1, the parties’ respective rights and obligations shall primarily be determined by the rules and procedures laid down in this Guideline. In disputes concerning cash transfer orders between TARGET component systems, the law of the Member State where the seat of the Eurosystem CB of the payee is located shall apply in a supplementary manner, provided that it does not conflict with this Guideline.

Article 24

Repeal of Guideline 2013/47/EU (ECB/2012/27)

1.   Guideline 2013/47/EU (ECB/2012/27) is repealed with effect from 21 November 2022.
2.   References to the repealed Guideline shall be construed as references to this Guideline.

Article 25

Taking effect and implementation

1.   This Guideline shall take effect on the day of its notification to the national central banks of the Member States whose currency is the euro.
2.   The Eurosystem central banks shall comply with this Guideline from 21 November 2022.
3.   The national central banks of the Members States whose currency is the euro shall take the necessary measures to comply with this Guideline and apply them from 21 November 2022. They shall notify the ECB of the texts and means relating to those measures by 19 April 2022, at the latest.

Article 26

Miscellaneous and transitional provisions

1.   Upon the date specified in Article 25(2), a participant’s:
(a) balances on TARGET2 PM accounts shall be transferred in the relevant MCAs as specified by the participant;
(b) TARGET2 TIPS DCAs shall become TIPS DCAs;
(c) TARGET2 T2S DCAs shall become T2S DCAs;
(d) TARGET2 technical accounts, TARGET2 TIPS AS technical accounts and TARGET2 guarantee fund accounts for AS settlement procedures shall become RTGS AS technical accounts, TIPS AS technical accounts and AS guarantee fund accounts respectively;
(e) balances on Home Accounts shall be transferred in the relevant MCAs as specified by the participant.
2.   Participants shall suffer no loss and gain no profit as a result of the transfer of balances pursuant to paragraph 1.
3.   The intra-Eurosystem obligations arising from settlement of payments between participants in different TARGET2 component systems pursuant to Article 6 of Guideline 2013/47/EU (ECB/2012/27) shall continue to be recorded in TARGET in accordance with Article 6 of this Guideline.
4.   Notwithstanding Annex I, Part I, Article 5(1), points (d) and (e), capacity and country opinions requested by Eurosystem CBs pursuant to Article 13 of Guideline 2013/47/EU (ECB/2012/27) or pursuant to Annex II, Article 8(2), Annex IIA, Article 6(2), and Annex IIB, Article 6(2) to Guideline 2013/47/EU (ECB/2012/27), respectively, shall remain valid for the purposes of this Guideline.
5.   Notwithstanding Annex I, Part II, Article 10(2), point (d), access to intraday credit granted by the Governing Council under the terms of Annex III, paragraph (2)(e) to Guideline 2013/47/EU (ECB/2012/27) shall remain valid.
6.   Groups recognised by the Governing Council in accordance with the definition of ‘group’ in Annex II, Article 1 of Guideline 2013/47/EU (ECB/2012/27) shall continue to be recognised and considered as banking groups for the purposes of this Guideline.

Article 27

Addressees, implementing measures and reporting to level 1

1.   This Guideline is addressed to all Eurosystem central banks.
2.   The Governing Council shall receive a report on an annual basis from Level 2 containing the information required by the Governing Council in order to fulfil its responsibilities as Level 1.
Done at Frankfurt am Main, 24 February 2022.
For the Governing Council of the ECB
The President of the ECB
Christine LAGARDE
(1)  Guideline 2013/47/EU of the European Central Bank of 5 December 2012 on a Trans-European Automated Real-time Gross settlement Express Transfer system (TARGET2) (ECB/2012/27) (
OJ L 30, 30.1.2013, p. 1
).
(2)  Decision 2014/533/EU of the European Central Bank of 13 August 2014 on the identification of TARGET2 as a systemically important payment system pursuant to Regulation (EU) No 795/2014 on oversight requirements for systemically important payment systems (ECB/2014/35) (
OJ L 245, 20.8.2014, p. 5
).
(3)  Regulation of the European Central Bank (EU) No 795/2014 of 3 July 2014 on oversight requirements for systemically important payment systems (ECB/2014/28) (
OJ L 217, 23.7.2014, p. 16
).
(4)  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, p. 45
).
(5)  Regulation (EU) 2021/378 of the European Central Bank of 22 January 2021 on the application of minimum reserve requirements (ECB/2021/1) (
OJ L 73, 3.3.2021, p. 1
).
(6)  Guideline (EU) 2015/510 of the European Central Bank of 19 December 2014 on the implementation of the Eurosystem monetary policy framework (General Documentation Guideline) (ECB/2014/60) (
OJ L 91, 2.4.2015, p. 3
).

ANNEX I

HARMONISED CONDITIONS FOR PARTICIPATION IN TARGET

PART I

General terms and conditions

Article 1

Scope

The terms and conditions set out in this Part I govern the relationship between [insert name of CB] and its participants in TARGET-[insert CB/country reference]. The terms and conditions set out in the following Parts II, III, IV, V, VI and VII apply as far as participants opt for and are granted one or more accounts described in such Parts. The terms and conditions set out in Parts I to VII of this Annex are referred to in this Guideline collectively as the ‘Harmonised Conditions’ or the ‘Conditions’.

Article 2

Appendices

1.   The following Appendices form an integral part of these Conditions:
Appendix I:
Technical specifications for the processing of cash transfer orders
Appendix II:
TARGET compensation scheme
Appendix III:
Terms of reference for capacity and country opinions
Appendix IV:
Business continuity and contingency procedures
Appendix V:
TARGET operating schedule
Appendix VI:
Fee schedule
Appendix VII:
Requirements regarding information security management and business continuity management
[Appendix VIII:
Insert if required: List of definitions set out in Annex III to the Guideline]
2.   In the event of any conflict or inconsistency between the content of any appendix and the content of any other provision in these Conditions, the latter shall prevail.

Article 3

General description of TARGET

1.   TARGET is legally structured as a multiplicity of payment systems composed of all TARGET component systems, each of which is designated as a ‘system’ under the relevant national law implementing Directive 98/26/EC.
2.   TARGET comprises payment systems in euro that settle in central bank money and provide central liquidity management services, real-time gross settlement for payments and services for AS settlement, and enable cash payments in relation to securities settlement and the settlement of instant payments.
3.   TARGET provides:
(a) MCAs for the settlement of central bank operations;
(b) RTGS DCAs for large value real-time gross settlement of payments and sub-accounts if required for AS settlement;
(c) T2S DCAs for cash payments in relation to securities settlement;
(d) TIPS DCAs for the settlement of instant payments; and
(e) the following accounts for AS settlement: (i) RTGS AS technical accounts; (ii) AS guarantee fund accounts; and (iii) TIPS AS technical accounts.
Each account in TARGET-[insert name of CB] shall be identified by means of a unique account number made up of the elements described in Appendix I, paragraph 2.

Article 4

Access criteria

1.   The following types of entities are eligible to become participants in TARGET-[insert CB/country reference] upon request:
(a) credit institutions established in the Union or the EEA, including when they act through a branch established in the Union or the EEA;
(b) credit institutions established outside the EEA, provided that they act through a branch established in the Union or the EEA;
(c) NCBs of Member States and the ECB;
provided that the entities referred to in points (a) and (b) are not subject to restrictive measures adopted by the Council of the European Union or Member States pursuant to Article 65(1)(b), Article 75 or Article 215 of the Treaty, the implementation of which, in the view of [insert name of CB] after informing the ECB, is incompatible with the smooth functioning of TARGET.
2.   The [insert name of CB] may, at its discretion, also admit the following entities as participants:
(a) treasury departments of central or regional governments of Member States;
(b) public sector bodies of Member States authorised to hold accounts for customers;
(c)  
(i) investment firms established in the Union or the EEA, including when they act through a branch established in the Union or the EEA; and
(ii) investment firms established outside the EEA, provided that they act through a branch established in the Union or the EEA;
(d) entities managing AS, and acting in that capacity; and
(e) credit institutions or any of the entities of the types listed in points (a) to (d), in both cases where these are established in a country with which the Union has entered into a monetary agreement allowing access by any of such entities to payment systems in the Union subject to the conditions set out in the monetary agreement and provided that the relevant legal regime applying in the country is equivalent to the relevant Union legislation.

Article 5

Application procedure

1.   In order to become a participant in TARGET-[insert name of CB/country reference] an eligible entity as described in Article 4(1) or an entity that may be admitted by [insert name of CB] under Article 4(2) shall fulfil the following requirements:
(a) install, manage, operate, monitor and ensure the security of the necessary IT infrastructure to connect to TARGET-[insert CB/country reference] and be able to submit cash transfer orders to it. In doing so, applicant participants may involve third parties but retain sole liability;
(b) have passed the tests required by the [insert name of CB];
(c) if it is an applicant for an a RTGS DCA, a T2S DCA or a TIPS DCA it shall also hold or open an MCA with [insert name of CB];
(d) provide a capacity opinion in the form specified in Appendix III, unless the information and representations to be provided in such capacity opinion have already been obtained by the [insert name of CB] in another context;
(e) for the entities referred to in Article 4(1), point (b) and in Article 4(2), point (c)(ii), provide a country opinion in the form specified in Appendix III, unless the information and representations to be provided in such country opinion have already been obtained by the [insert name of CB] in another context;
(f) if it is an applicant for a TIPS DCA, has adhered to the SCT Inst scheme by signing the SEPA Instant Credit Transfer Adherence Agreement;
(g) if it is an applicant for a TIPS AS technical account, has provided evidence that the disclosure letter showing their intent to be an SCT Inst compliant Clearing and Settlement Mechanism (CSM) has been provided to the European Payments Council (EPC).
2.   Applicants shall apply to the [insert name of CB], as a minimum enclosing the following documents/information:
(a) completed reference data collection forms as provided by [insert name of CB];
(b) the capacity opinion, if required by the [insert name of CB], and the country opinion, if required by the [insert name of CB];
(c) if it is an applicant for a TIPS DCA, evidence of their adherence to the SCT Inst scheme;
(d) if the applicant is applying to use the TIPS AS settlement procedure, evidence that they have provided the EPC with the disclosure letter showing their intent to be an SCT Inst compliant CSM;
(e) if the applicant designates a paying agent, the evidence that the paying agent has agreed to act in that role.
3.   Applicants which are already TARGET participants and apply for a new account as described in: (i) Part III (RTGS-DCA); (ii) Part IV (T2S DCA); (iii) Part V (TIPS DCA); (iv) Part VI (RTGS AS technical account); and/or (v) Part VII (TIPS AS technical account), shall comply with the provisions of paragraphs 1 and 2 to the extent relevant for the new account applied for.
4.   The [insert name of CB] may also request any additional information it deems necessary to decide on an application to open a TARGET account.
5.   The [insert name of CB] shall reject the application to participate if:
(a) the applicant is not an eligible entity as described in Article 4(1) or an entity that may be admitted by [insert name of CB] under Article 4(2);
(b) one or more of the participation requirements referred to in paragraph 1 are not met; and/or
(c) according to the [insert name of CB]’s assessment, such participation would endanger the overall stability, soundness and safety of TARGET-[insert CB/country reference] or of any other TARGET component system, or would jeopardise the [insert name of CB]’s performance of its tasks as described in [refer to relevant national law] and the Statute of the European System of Central Banks and of the European Central Bank, or poses risks on the grounds of prudence.
6.   The [insert name of CB] shall communicate its decision on the application to become a participant in TARGET-[insert name of CB/country reference] to the applicant participant within one month of the [insert name of CB]’s receipt of the application. Where the [insert name of CB] requests additional information pursuant to paragraph 4, the decision shall be communicated within one month of the [insert name of CB]’s receipt of this information from the applicant. Any rejection decision shall contain reasons for the rejection.

Article 6

Participants

1.   Participants which are not AS shall hold at least one MCA with the [insert name of CB] and may also hold one or more RTGS DCAs, T2S DCAs and/or TIPS DCAs with the [insert name of CB].
2.   AS which use the RTGS AS settlement procedures or the TIPS AS settlement procedure shall be subject to the terms and conditions set out in this Part as well as in Part VI or Part VII, respectively. They may hold one or more MCAs, T2S DCAs and, exceptionally and if approved by [insert name of CB], one or more RTGS DCAs except in relation to the clearing of instant payments pursuant to the SCT Inst scheme. If an AS holds an RTGS DCA or a T2S DCA it shall also hold at least one MCA with the [insert name of CB]. In the event that an AS holds one or more MCAs or RTGS DCAs or T2S DCAs, the respective Parts of these Conditions shall also apply.

Article 7

Access to a participant’s account by entities other than the participant

1.   To the extent technically possible, a participant may give access to its TARGET accounts to one or more entities it designates, for the purposes of submitting cash transfer orders and performing other actions.
2.   Cash transfer orders submitted or funds received by the entities designated by a participant as referred to in paragraph 1 shall be deemed to have been submitted or received by that participant itself.
3.   The participant shall be bound by such cash transfer orders and any other action taken by the entity or entities referred to in paragraph 1, regardless of the content of, or any non-compliance with, the contractual or other arrangements between that participant and such entity.

Article 8

Billing

1.   The [insert name of CB] shall identify billable items according to Appendix VI and shall allocate each of them to the participant from which that billable item originates.
2.   Any fee payable in relation to a cash transfer order submitted by or cash transfer received by an AS, irrespective of whether it uses the RTGS AS settlement procedures or an RTGS DCA, shall be exclusively charged to that AS.
3.   Billable items generated by actions taken by the designated entities referred in Article 7, as well as by central banks acting on behalf of a participant, shall be allocated to the participant.
4.   The [insert name of CB] shall issue separate invoices to the participant for the relevant services described in: (i) Part III (RTGS-DCA); (ii) Part IV (T2S DCA); (iii) Part V (TIPS DCA); (iv) Part VI (RTGS AS settlement procedures); and (v) Part VII (TIPS AS settlement procedure).
5.   The [insert name of CB] shall settle each invoice by means of a direct debit of an MCA held by the participant, unless the participant has designated another participant in TARGET (which may be in TARGET- [insert name of CB/country reference] or another component system) as a paying agent and instructed the [insert name of CB] to debit the MCA of that paying agent. Such an instruction shall not release the participant from its obligation to pay each invoice.
6.   Where a paying agent has been designated, the participant will provide the [insert name of CB] with evidence that the paying agent has agreed to act in that role.
7.   For the purposes of this Article, each AS shall be treated separately, even if two or more of them are operated by the same legal entity, and irrespective of whether or not the AS has been designated under Directive 98/26/EC. In the case of an AS that has not been designated under Directive 98/26/EC, it shall be identified as an AS by reference to the following criteria: (a) it is a formal arrangement, based on a contractual or legislative instrument, e.g. an agreement among the participants and the system operator; (b) it has multiple membership; (c) it has common rules and standardised arrangements; and (d) is for the purpose of clearing, netting and/or settlement of payments and/or securities between the participants.

Article 9

Billing Groups

1.   Upon the request of the participant the [insert name of CB] shall create a billing group to allow its members to benefit from the degressive pricing applicable to RTGS DCAs. The billing group may only include RTGS DCA holders belonging to the same banking group, from one or more TARGET component systems.
2.   Upon the request of an RTGS DCA holder the [insert name of CB] shall add that RTGS DCA holder to or delete it from a billing group which may be in TARGET-[insert name of CB/country reference] or in any other TARGET component system. The RTGS DCA holder shall inform all other members of the billing group of such a request prior to making it.
3.   RTGS DCA holders included in a billing group shall be invoiced individually as set out in Article 8.

Article 10

Obligations of the [insert name of CB] and the participant

1.   The [insert name of CB] shall offer the services described in Parts II, III, IV, V, VI and VII of these Conditions where a participant has opted for and been granted an account as referred to therein. Save where otherwise provided in these Conditions or required by law, the [insert name of CB] shall use all reasonable means within its power to perform its obligations under these Conditions, without guaranteeing a result.
2.   The [insert name of CB] is the provider of services pursuant to these Conditions. Acts and omissions of the Level 3 NCBs shall be considered as acts and omissions of [insert name of CB], for which it shall assume liability in accordance with Article 22. Participation pursuant to these Conditions shall not create a contractual relationship between participants and the Level 3 NCBs when any of the latter acts in its capacity as a Level 3 NCB. Instructions, messages or information which a participant receives from, or sends to, TARGET in relation to the services provided under these Conditions shall be deemed to be received from, or sent to, [insert name of CB].
3.   The participant shall pay to [insert name of CB] fees in accordance with Article 8.
4.   The participant shall ensure that it is technically connected to TARGET-[insert CB/country reference] in accordance with TARGET operating schedule set out in Appendix V. This obligation may be fulfilled through a designated entity referred to in Article 7.
5.   The participant shall represent and warrant to the [insert name of CB] that the performance of its obligations under these Conditions does not breach any law, regulation or by-law applicable to it or any agreement by which it is bound.
6.   The participant shall pay any applicable stamp duties or other documentary taxes or duties, if applicable, as well as any other costs the participant incurs in opening, maintaining or closing its TARGET account.

Article 11

Cooperation and information exchange

1.   In performing their obligations and exercising their rights under these Conditions, the [insert name of CB] and participants shall cooperate closely to ensure the stability, soundness and safety of TARGET-[insert CB/country reference]. They shall provide each other with any information or documents relevant for the performance of their respective obligations and the exercise of their respective rights under these Conditions, without prejudice to any banking secrecy obligations.
2.   The [insert name of CB] shall establish and maintain a system support desk to assist participants in relation to difficulties arising in connection with system operations.
3.   Up-to-date information on the operational status of each service shall be available on a TARGET Information System (TIS) on a dedicated webpage on the ECB’s website.
4.   The [insert name of CB] may communicate system relevant messages to participants by means of a broadcast message or, if this means is not available, by any other appropriate means of communication.
5.   Participants shall update in a timely manner existing reference data collection forms and submit new reference data collection forms to the [insert name of CB]. Participants shall verify the accuracy of information relating to them that is entered into TARGET-[insert CB/country reference] by the [insert name of CB].
6.   The participant hereby authorises [insert name of CB] to communicate to the Level 3 NCBs any information relating to participants which the Level 3 NCBs may need, in accordance with the agreements between the Level 3 NCBs and the Eurosystem CBs governing the provision of the services to be provided by the Level 3 NCBs.
7.   Participants shall inform the [insert name of CB] without undue delay about any change in their legal capacity and relevant legislative changes affecting issues covered by the country opinion as set out in the terms of reference given in Appendix III.
8.   [insert name of CB] may at any time request an update or renewal of the country or capacity opinions referred to in Article 5(1), points (d) and (e).
9.   Participants shall immediately inform the [insert name of CB] if an event of default occurs in relation to themselves or if they are subject to crisis prevention measures or crisis management measures within the meaning of Directive 2014/59/EU of the European Parliament and of the Council (1) or any other equivalent applicable legislation.

Article 12

Remuneration of Accounts

1.   MCAs, DCAs and sub-accounts shall either be remunerated at zero per cent or at the deposit facility rate, whichever is lower, unless they are used to hold any of the following:
(a) minimum reserves;
(b) excess reserves;
(c) government deposits as defined in Article 2, point (5) of Guideline (EU) 2019/671 of the European Central Bank (ECB/2019/7) (2).
In the case of minimum reserves, the calculation and payment of remuneration of holdings shall be governed by Council Regulation (EC) No 2531/98 (3) and Regulation (EU) 2021/378 (ECB/2021/1).
In the case of excess reserves, the calculation and payment of remuneration of holdings shall be governed by Decision (EU) 2019/1743 of the European Central Bank (ECB/2019/31) (4).
In the case of government deposits, the remuneration of holdings shall be governed by the provisions relating to those government deposits as set out in Article 4 of Guideline (EU) 2019/671 (ECB/2019/7).
2.   Overnight balances held on a TIPS AS technical account or on an RTGS AS technical account for AS settlement procedure D, and guarantee funds, including those held on an AS guarantee fund account, shall be remunerated at the deposit facility rate.

Article 13

Management of Accounts

1.   Participants shall monitor and manage the liquidity on their accounts in line with the TARGET operating schedule as set out in Appendix V and perform transaction-level reconciliation at least once a day. This obligation may be fulfilled through a designated entity referred to in Article 7.
2.   The participant shall make use of the tools provided by [insert name of CB] for the purpose of account reconciliation, in particular the daily statement of account which is made available to each participant. This obligation may be fulfilled through a designated entity referred to in Article 7.
3.   Participants shall immediately inform the [insert name of CB] in the event that a mismatch occurs in relation to any of their accounts.

Article 14

Minimum reserves

1.   Upon request of a participant subject to a minimum reserve requirement, the [insert name of CB] shall mark one or more MCAs or DCAs belonging to that participant in TARGET-[insert CB/country reference] as held for the purpose of fulfilling minimum reserve requirements.
2.   For the purpose of fulfilment of minimum reserve requirements, where applicable to the participant, the sum of the end-of-day balances of all accounts held by that participant with [insert name of CB] and marked for that purpose, shall be taken into account.

Article 15

Floor and ceiling amounts

1.   The participant may set floor and ceiling amounts on its MCA or DCAs.
2.   The participant may choose to receive a notification if the floor or ceiling amount is breached. In addition, for MCAs or RTGS DCAs the participant may opt for the breach to trigger a rule-based liquidity transfer order.
3.   The settlement of a liquidity transfer order shall not trigger a check of whether the floor or ceiling amount has been breached.

Article 16

Account monitoring group

1.   An MCA holder may create one or more account monitoring groups for the purpose of monitoring liquidity on several MCAs or DCAs and will become the leader party for any account monitoring group that it creates.
2.   A participant may add any of its MCAs or DCAs opened within TARGET-[insert CB/country reference] or any other TARGET component system to one or more account monitoring groups and thereby become a member of that account monitoring group. A member of an account monitoring group may initiate the removal of its account from that account monitoring group at any time. A participant shall inform the leader party of an account monitoring group prior to adding an account to or removing an account from that account monitoring group.
3.   Only the leader party for an account monitoring group shall be able to view the balances of all accounts included in that account monitoring group.
4.   The leader party may delete the account monitoring group and shall inform the other members of the account monitoring group prior to such deletion.

Article 17

Acceptance and rejection of cash transfer orders

1.   Cash transfer orders submitted by participants shall be deemed accepted by the [insert name of CB] if:
(a) The transfer message complies with the technical requirements of TARGET described in Appendix I;
(b) the message complies with the formatting rules and conditions described in Appendix I;
(c) the message passes the double-entry check described in Appendix I;
(d) in cases where a payer has been suspended with regard to debiting its account(s) or a payee has been suspended with regard to crediting its account(s), the suspended participant’s CB’s explicit consent has been obtained;
(e) in cases where the cash transfer order is made as part of an RTGS AS settlement procedure, the participant’s account is included in the settlement bank account group requested by that AS as set out in Part VI, Article 1(7); and
(f) in the case of cross-system settlement as part of RTGS AS settlement procedures, the AS concerned is part of a cross-system settlement arrangement as set out in Article 9 of Part VI.
2.   The [insert name of CB] shall immediately reject any cash transfer order that does not fulfil the conditions laid down in paragraph 1. The [insert name of CB] shall inform the participant of any rejection of a cash transfer order, as specified in Appendix I.

Article 18

Entry of cash transfer orders into the system and their irrevocability

1.   For the purposes of the first sentence of Articles 3(1) and 5 of Directive 98/26/EC and [insert national law provisions implementing these Articles of Directive 98/26/EC]:
(a) all cash transfer orders, except as provided for in points b), c) and d) of this paragraph, shall be deemed entered into TARGET-[insert CB/country reference] and irrevocable at the moment that the relevant participant’s TARGET account is debited;
(b) instant payment orders shall be deemed entered into TARGET-[insert CB/country reference] and irrevocable at the moment that the relevant funds on the TIPS DCA of the participant or on its TIPS AS technical account are reserved;
(c) in the case of transactions that are settled on T2S DCAs and that are subject to matching of two separate transfer orders:
(i) such transfer orders, except as provided for in point (ii) of this subparagraph, shall be deemed entered into TARGET-[Insert CB/country reference] at the moment at which they have been declared compliant with the technical rules of T2S by the T2S Platform and irrevocable at the moment the transaction has been given the status ‘matched’ on the T2S Platform;
(ii) in the case of transactions involving one participating CSD that has a separate matching component where transfer orders are sent directly to that participating CSD to be matched in its separate matching component, such transfer orders shall be deemed entered into TARGET-[Insert CB/country reference] at the moment at which they have been declared compliant with the technical rules of T2S by that participating CSD and irrevocable from the moment the transaction has been given the status ‘matched’ on the T2S Platform. A list of participating CSDs referred to in this point (ii) is available on the ECB’s website;
(d) cash transfer orders in connection with RTGS AS settlement procedures shall be deemed entered in the TARGET component system of the account to be debited at the moment at which they are accepted by that TARGET component system and irrevocable at that moment.
2.   The provisions of paragraph 1 shall not affect any rules of AS that stipulate a moment of entry into the AS and/or irrevocability of transfer orders submitted to it at a point in time earlier than the moment of entry of the respective AS transfer orders in the relevant TARGET component system.
3.   Cash transfer orders included in an algorithm may not be revoked during the period that the algorithm is running.

Article 19

Business continuity and contingency procedures

1.   In the event of an abnormal external event or any other event which affects transactions on the TARGET accounts, the business continuity and contingency procedures described in Appendix IV shall apply.
2.   In exceptional circumstances the TARGET operating schedule may be changed, in which case participants will be informed by [insert name of CB].
3.   In exceptional circumstances an AS may make a request to [insert name of CB] to modify the TARGET operating schedule.
4.   The Eurosystem provides a Contingency Solution for use if the events described in paragraph 1 occur. Connection to and use of the Contingency Solution shall be mandatory for participants considered by [insert name of CB] to be critical and for participants that settle very critical transactions as set out in Appendix IV. Other participants may, on request, connect to the Contingency Solution.

Article 20

Security requirements

1.   Participants shall implement adequate security controls to protect their systems from unauthorised access and use. Participants shall be exclusively responsible for the adequate protection of the confidentiality, integrity and availability of their systems.
2.   Participants shall immediately inform the [insert name of CB] of any security-related incidents in their technical infrastructure and, where appropriate, security-related incidents that occur in the technical infrastructure of the third-party providers. The [insert name of CB] may request further information about the incident and, if necessary, request that the participant take appropriate measures to prevent a recurrence of such an event.
3.   The [insert name of CB] may impose additional security requirements, in particular with regard to cybersecurity or the prevention of fraud, on all participants and/or on participants that are considered critical by the [insert name of CB].
4.   Participants shall provide the [insert name of CB] with: (i) permanent access to their attestation of adherence to their chosen NSP’s endpoint security requirements; and (ii) on an annual basis the TARGET self-certification statement as required for the types of accounts that they hold and as published on the [insert name of CB]’s website and on the ECB’s website in English.
5.   The [insert name of CB] shall assess the participant’s self-certification statement(s) on the participant’s level of compliance with each of the requirements set out in the TARGET self-certification requirements. These requirements are listed in Appendix VII.
6.   The participant’s level of compliance with the requirements of the TARGET self-certification shall be categorised as follows, in increasing order of severity: ‘full compliance’; ‘minor non-compliance’; or, ‘major non-compliance’. The following criteria apply: full compliance is reached where participants satisfy 100 % of the requirements; minor non-compliance is where a participant satisfies less than 100 % but at least 66 % of the requirements and major non-compliance where a participant satisfies less than 66 % of the requirements. If a participant demonstrates that a specific requirement is not applicable to it, it shall be considered as compliant with the respective requirement for the purposes of the categorisation. A participant which fails to reach ‘full compliance’ shall submit an action plan demonstrating how it intends to reach full compliance. The [insert name of CB] shall inform the relevant supervisory authorities of the status of such participant’s compliance.
7.   If the participant refuses to grant permanent access to its attestation of adherence to its chosen NSPs endpoint security requirements or does not provide the TARGET self-certification, the participant’s level of compliance shall be categorised as ‘major non-compliance’.
8.   The [insert name of CB] shall re-assess compliance of participants on an annual basis.
9.   The [insert name of CB] may impose the following measures of redress on participants whose level of compliance was assessed as minor or major non-compliance, in increasing order of severity:
(a) enhanced monitoring: the participant shall provide the [insert name of CB] with a monthly report, signed by a senior executive, on its progress in addressing the non-compliance. The participant shall additionally incur a monthly penalty charge for each affected account of EUR 1 000. This measure of redress may be imposed in the event the participant receives a second consecutive assessment of minor non-compliance or an assessment of major non-compliance;
(b) suspension: participation in TARGET-[insert CB/country reference] may be suspended in the circumstances described in Article 25(2), points (b) and/or (c). By way of derogation from Article 25, the participant shall be given three months’ notice of such suspension. The participant shall incur a monthly penalty charge for each suspended account of EUR 2 000. This measure of redress may be imposed in the event the participant receives a second consecutive assessment of major non-compliance;
(c) termination: participation in TARGET-[insert CB/country reference] may be terminated in the circumstances described in Article 25(2), points (b) and/or (c). By way of derogation from Article 25, the participant shall be given three months’ notice. The participant shall incur an additional penalty charge of EUR 1 000 for each terminated account. This measure of redress may be imposed if the participant has not addressed the major non-compliance to the satisfaction of [insert name of CB] following three months of suspension.
10.   Participants allowing access to their TARGET account by third parties as set out in Article 7 and participants having registered addressable BIC holders as set out in Part III, Article 2, shall address the risk stemming from allowing such access in accordance with the security requirements set out in paragraphs 1 to 9.

Article 21

Compensation Scheme

If a cash transfer order cannot be settled on the same business day on which it was accepted due to a technical malfunction of TARGET, the [insert name of CB] shall offer to compensate the participant concerned in accordance with the special procedure laid down in Appendix II.

Article 22

Liability regime

1.   In performing their obligations pursuant to these Conditions, the [insert name of CB] and the participants shall be bound by a general duty of reasonable care in relation to each other.
2.   The [insert name of CB] shall be liable to its participants in cases of fraud (including but not limited to wilful misconduct) or gross negligence, for any loss arising out of the operation of TARGET-[insert CB/country reference]. In cases of ordinary negligence, the [insert name of CB]’s liability shall be limited to the participant’s direct loss, i.e. the amount of the transaction in question and/or the loss of interest thereon, excluding any consequential loss.
3.   The [insert name of CB] shall not be liable for any loss that results from any malfunction or failure in the technical infrastructure (including but not limited to the [insert name of CB]’s computer infrastructure, programmes, data, applications or networks), if such malfunction or failure arises in spite of the [insert name of CB] having adopted those measures that are reasonably necessary to protect such infrastructure against malfunction or failure, and to resolve the consequences of such malfunction or failure (the latter including but not limited to initiating and completing the business continuity and contingency procedures referred to in Appendix IV).
4.   The [insert name of CB] shall not be liable:
(a) to the extent that the loss is caused by the participant; or
(b) if the loss arises out of external events beyond the [insert name of CB]’s reasonable control (force majeure).
5.   Notwithstanding the [insert applicable national law provisions] paragraphs 1 to 4 shall apply to the extent that the [insert name of CB]’s liability can be excluded.
6.   The [insert name of CB] and the participants shall take all reasonable and practicable steps to mitigate any damage or loss referred to in this Article.
7.   In performing some or all of its obligations under these Conditions, the [insert name of CB] may commission third parties in its own name, particularly telecommunications or other network providers or other entities, if this is necessary to meet the [insert name of CB]’s obligations or is standard market practice. The [insert name of CB]’s obligation shall be limited to the due selection and commissioning of any such third parties and the [insert name of CB]’s liability shall be limited accordingly. For the purposes of this paragraph, the Level 3 NCBs shall not be considered as third parties.

Article 23

Evidence

1.   Unless otherwise provided in these Conditions, all cash transfer orders and related messages, such as confirmations of debits or credits, or statement messages, between the [insert name of CB] and participants shall be made through the relevant NSP.
2.   Electronic or written records of the messages retained by the [insert name of CB] or by the relevant NSP shall be accepted as a means of evidence of the payments processed through the [insert name of CB]. The saved or printed version of the original message of the relevant NSP shall be accepted as a means of evidence, regardless of the form of the original message.
3.   If a participant’s connection to the NSP fails, the participant shall use the alternative means of transmission of messages as agreed with [insert name of CB]. In such cases, the saved or printed version of the message produced by the [insert name of CB] shall have the same evidential value as the original message, regardless of its form.
4.   The [insert name of CB] shall keep complete records of cash transfer orders submitted and payments received by participants for a period of [insert period required by relevant national law] from the time at which such cash transfer orders are submitted and payments are received, provided that such complete records shall cover a minimum of five years for any participant in TARGET that is subject to continuous vigilance pursuant to restrictive measures adopted by the Council of the European Union or Member States, or longer if required by specific regulations.
5.   The [insert name of CB]’s own books and records shall be accepted as a means of evidence of any obligations of the participants and of any facts and events that the parties rely on.

Article 24

Duration and ordinary termination of participation and closure of accounts

1.   Without prejudice to Article 25, participation in TARGET-[insert CB/country reference] shall be for an indefinite period of time.
2.   A participant may terminate any of the following at any time giving 14 business days’ notice thereof, unless it agrees a shorter notice period with the [insert name of CB]:
(a) its entire participation in TARGET-[insert CB/country reference];
(b) one or more of its DCAs, RTGS AS technical accounts and/or TIPS AS technical accounts;
(c) one or more of its MCAs, provided that it continues to comply with Article 5.
3.   The [insert name of CB] may terminate any of the following at any time giving three months’ notice thereof, unless it agrees a different notice period with the relevant participant:
(a) a participant’s entire participation in TARGET-[insert CB/country reference];
(b) one or more of a participant’s DCAs, RTGS AS technical accounts or TIPS AS technical accounts;
(c) one or more of a participant’s MCAs, provided that the participant continues to hold at least one MCA.
4.   On termination of participation, the confidentiality duties laid down in Article 28 shall remain in force for a period of five years starting on the date of termination.
5.   On termination of participation, the [insert name of CB] shall close all TARGET accounts of the participant concerned in accordance with Article 26.

Article 25

Suspension and extraordinary termination of participation

1.   A participant’s participation in TARGET-[insert CB/country reference] shall be immediately terminated without prior notice or suspended if one of the following events of default occurs:
(a) the opening of insolvency proceedings; and/or
(b) the participant no longer meets the access criteria laid down in Article 4.
For the purposes of this paragraph, the taking of crisis prevention measures or crisis management measures within the meaning of Directive 2014/59/EU against a participant shall not automatically qualify as the opening of insolvency proceedings.
2.   The [insert name of CB] may terminate without prior notice or suspend the participant’s participation in TARGET-[insert CB/country reference] if:
(a) one or more events of default (other than those referred to in paragraph 1) occur;
(b) the participant is in material breach of any of these Conditions;
(c) the participant fails to carry out any material obligation to the [insert name of CB];
(d) the participant ceases to have a valid agreement with an NSP to provide the necessary connection to TARGET;
(e) any other participant-related event occurs which, in the [insert name of CB]’s assessment, would threaten the overall stability, soundness and safety of TARGET-[insert CB/country reference] or of any other TARGET component system, or which would jeopardise the [insert name of CB]’s performance of its tasks as described in [refer to relevant national law] and the Statute of the European System of Central Banks and of the European Central Bank, or poses risks on the grounds of prudence;
(f) an NCB suspends or terminates the participant’s access to intraday credit, including auto-collateralisation, pursuant to Part II, Article 13; and/or
(g) the participant is excluded from or otherwise ceases to be a member of one of the NSP Closed Group of Users.
3.   In exercising its discretion under paragraph 2, the [insert name of CB] shall take into account, inter alia, the seriousness of the event of default or events mentioned in points (a) to (c) of paragraph 2.
4.   In the event that the [insert name of CB] suspends or terminates a participant’s participation in TARGET-[insert CB/country reference] under paragraphs 1 or 2, the [insert name of CB] shall without undue delay inform – by means of a broadcast message or, if that is not available, by any other appropriate means of communication – the respective participant, other CBs and participants in all of the TARGET component systems of such suspension or termination. Such message shall be deemed to have been issued by the home CB of the respective participant.
5.   Once a message issued under paragraph 4 has been received by the participants, they shall be deemed informed of the termination/suspension of a participant’s participation in TARGET-[insert CB/country reference] or another TARGET component system. The participants shall bear any losses arising from the submission of a cash transfer order to participants whose participation has been suspended or terminated if such cash transfer order was entered into TARGET-[insert CB/country reference] after receipt of the message.

Article 26

Closure of TARGET accounts by [insert name of CB] on termination of participation

On termination of a participant’s participation in TARGET-[insert CB/country reference] pursuant to either Article 24 or 25, the [insert name of CB] shall close the TARGET accounts of the participant concerned, after havingsettled or rejected any queued cash transfer orders, and made use of its rights of pledge and set-off under Article 27.

Article 27

The [insert name of CB]’s rights of pledge and set-off

1.   [Insert if applicable: The [insert name of CB] shall have a pledge over the participant’s existing and future credit balances on its TARGET accounts, thereby collateralising any current and future claims arising out of the legal relationship between the parties.]
(a) [Insert if applicable: A participant’s current and future claims towards the [insert name of the CB] arising from a credit balance on the TARGET accounts shall be transferred to the [insert name of the CB] as collateral, i.e. as a fiduciary transfer, for any current or future claim of the [insert name of the CB] towards the participant arising out of the [insert reference to the arrangement implementing these Conditions]. Such collateral shall be established by the mere fact that the funds have been credited to the participant’s TARGET accounts.]
(b) [Insert if applicable: The [insert name of CB] shall have a floating charge over the participant’s existing and future credit balances on their TARGET accounts, thereby collateralising any current and future claims arising out of the legal relationship between the parties.]
2.   [Insert if applicable: The [insert name of CB] shall have the right referred to in paragraph 1 even if its claims are only contingent or not yet due.]
3.   [Insert if applicable: The participant, acting in its capacity as a TARGET account holder, hereby acknowledges the creation of a pledge in favour of [insert name of CB], with whom that account has been opened; this acknowledgement shall constitute the provision of pledged assets to the [insert name of CB] referred to under [insert relevant national adjective] law. Any amounts paid into the TARGET accounts whose balance is pledged shall, by the mere fact of being paid in, be irrevocably pledged, without any limitation whatsoever, as collateral security for the full performance of the secured obligations.]
4.   On the occurrence of:
(a) an event of default, referred to in Article 25(1); or
(b) any other event of default or event referred to in Article 25(2) that has led to the termination or suspension of the participant’s participation, notwithstanding the commencement of any insolvency proceedings in respect of a participant and notwithstanding any assignment, judicial or other attachment or other disposition of or in respect of the participant’s rights,
all obligations of the participant shall be automatically and immediately accelerated, without prior notice and without the need for any prior approval of any authority, so as to be immediately due. In addition, the mutual obligations of the participant and the [insert name of CB] shall automatically be set off against each other, and the party owing the higher amount shall pay to the other the difference.
5.   The [insert name of CB] shall promptly give the participant notice of any set-off pursuant to paragraph 4 after such set-off has taken place.
6.   The [insert name of CB] may without prior notice debit any participant’s TARGET accounts by any amount which the participant owes the [insert name of CB] resulting from the legal relationship between the participant and the [insert name of CB].
7.   The provisions of this Article shall not create any right, pledge, charge or claim or set-off in respect of the following TARGET accounts used by AS:
(a) TARGET accounts used in accordance with the AS settlement procedures under Part VI or Part VII;
(b) TARGET accounts held by AS under Parts II to V, where funds held on such accounts do not belong to the AS but are held on behalf of their customers or are used to settle cash transfer orders on behalf of their customers.

Article 28

Confidentiality

1.   The [insert name of CB] shall keep confidential all sensitive or secret information, including when such information relates to payment, technical or organisational information belonging to the participant, participants from the same group or the participant's customers, unless the participant or its customer has given its written consent to disclose [insert the following phrase if applicable under national law] or such disclosure is permitted or required under [insert adjective relating to country name] law].
2.   By derogation from paragraph 1, the participant agrees that information on any action taken under Article 25 shall not be considered as confidential.
3.   By derogation from paragraph 1, the participant agrees that the [insert name of CB] may disclose payment, technical or organisational information regarding the participant, participants from the same banking group or the participant's customers, obtained in the course of the operation of TARGET-[insert CB/country reference] to:
(a) other CBs or third parties that are involved in the operation of TARGET-[insert CB/country reference], to the extent that this is necessary for the efficient functioning of TARGET or the monitoring of the participant's or its banking group's exposure;
(b) other CBs in order to carry out the analyses necessary for market operations, monetary policy functions, financial stability or financial integration; or
(c) supervisory, resolution and oversight authorities of Member States and the Union, including CBs, to the extent that this is necessary for the performance of their public tasks,
and provided that in all such cases the disclosure is not in conflict with applicable law.
4.   The [insert name of CB] shall not be liable for the financial and commercial consequences of disclosure made in accordance with paragraph 3.
5.   By derogation from paragraph 1 and provided that this does not make it possible, whether directly or indirectly, to identify the participant or the participant's customers, the [insert name of CB] may use, disclose or publish payment information regarding the participant or the participant's customers for statistical, historical, scientific or other purposes in the exercise of its public functions or of functions of other public entities to which the information is disclosed.
6.   Information relating to the operation of TARGET-[insert CB/country reference] to which participants have had access may only be used for the purposes laid down in these Conditions. Participants shall keep such information confidential, unless the [insert name of CB] has explicitly given its written consent to disclose. Participants shall ensure that any third parties to whom they outsource, delegate or subcontract tasks which have or may have an impact on the performance of their obligations under these Conditions are bound by the confidentiality requirements in this Article.
7.   The [insert name of CB] shall be authorised, in order to settle cash transfer orders, to process and transfer the necessary data to the NSP.

Article 29

Data protection, prevention of money laundering, administrative or restrictive measures and related issues

1.   Participants shall be deemed to be aware of, shall comply with, and shall be able to demonstrate that compliance to the relevant competent authorities with all obligations on them relating to legislation on data protection. They shall be deemed to be aware of, and shall comply with all obligations on them relating to legislation on prevention of money laundering and the financing of terrorism, proliferation-sensitive nuclear activities and the development of nuclear weapons delivery systems, in particular in terms of implementing appropriate measures concerning any payments debited or credited on their TARGET accounts. Participants shall ensure that they are informed about their chosen NSP’s data retrieval policy prior to entering into the contractual relationship with the NSP.
2.   Participants authorise the [insert name of CB] to obtain any information relating to them from any financial or supervisory authority or trade body, whether national or foreign, if such information is necessary for the participant’s participation in TARGET-[insert CB/country reference].
3.   Participants, when acting as the payment service provider of a payer or payee, shall comply with all requirements resulting from administrative or restrictive measures imposed pursuant to Article 75 or 215 of the Treaty to which they are subject, including with respect to notification and/or the obtaining of consent from a competent authority in relation to the processing of transactions. In addition:
(a) when the [insert name of CB] is the payment service provider of a participant that is a payer:
(i) the participant shall make the required notification or obtain consent on behalf of the central bank that is primarily required to make notification or obtain consent, and shall provide the [insert name of CB] with evidence of having made a notification or having received consent;
(ii) the participant shall not enter any cash transfer order for the transfer of funds to an account held by an entity different than the participant, into TARGET until it has obtained confirmation from the [insert name of CB] that the required notification has been made or the consent has been obtained by or on behalf of the payment service provider of the payee;
(b) when the [insert name of CB] is a payment service provider of a participant that is a payee, the participant shall make the required notification or obtain consent on behalf of the central bank that is primarily required to make notification or obtain consent, and shall provide the [insert name of CB] with evidence of having made a notification or having received consent.
For the purposes of this paragraph, the terms ‘payment service provider’, ‘payer’ and ‘payee’ shall have the meanings ascribed to them in the applicable administrative or restrictive measures.

Article 30

Notices

1.   Except where otherwise provided for in these Conditions, all notices required or permitted pursuant to these Conditions shall be sent by registered post, [if relevant – facsimile] or other electronic means if agreed bilaterally, or otherwise in writing. Notices to the [insert name of CB] shall be submitted to the head of the [insert payment systems department or relevant CB unit] of [insert name of CB], [include relevant address of CB] or to the [insert BIC address of the CB] or to [insert if relevant other electronic means that are bilaterally agreed]. Notices to the participant shall be sent to it at the address, [if relevant - facsimile number] or [insert relevant information if other electronic means are bilaterally agreed] or its BIC address as the participant may from time to time notify to the [insert name of CB].
2.   To prove that a notice has been sent, it shall be sufficient to prove that the notice was sent either physically or by electronic means to the relevant addressee.
3.   All notices shall be given in [insert relevant national language and/or ‘English’].
4.   Participants shall be bound by all forms and documents of the [insert name of CB] that the participants have filled in and/or signed, including but not limited to reference data collection forms, as referred to in Article 5(2), point (a), and information provided under Article 11(5), which were submitted in compliance with paragraphs 1 and 2 and which the [insert name of CB] reasonably believes to have been received from the participants, their employees or agents.

Article 31

Contractual relationship with an NSP

1.   In order to send to or receive from TARGET instructions and messages, participants shall:
(a) conclude a contract with an NSP within the framework of the concession contract with that NSP in order to establish a technical connection to TARGET-[insert CB/country reference]; or
(b) connect via another entity which has itself concluded a contract with an NSP within the framework of the concession contract with that NSP.
2.   The legal relationship between a participant and the NSP shall be exclusively governed by the terms and conditions of the contract concluded between them.
3.   The services to be provided by the NSP shall not form part of the services to be performed by the [insert name of CB] in respect of TARGET.
4.   The [insert name of CB] shall not be liable for any acts, errors or omissions of the NSP (including its directors, staff and subcontractors), or for any acts, errors or omissions of third parties selected by participants to gain access to the NSP’s network.

Article 32

Amendment procedure

The [insert name of CB] may at any time unilaterally amend these Conditions, including the Appendices. Amendments to these Conditions, including the Appendices, shall be announced by means of [insert relevant means of announcement]. Amendments shall be deemed to have been accepted unless the participant expressly objects within 14 days of being informed of such amendments. In the event that a participant objects to the amendment, the [insert name of CB] is entitled immediately to terminate that participant’s participation in TARGET-[insert CB/country reference] and close any of its TARGET accounts.

Article 33

Third party rights

1.   Participants shall not transfer, pledge or assign any rights, interests, obligations, responsibilities or claims arising from or relating to these Conditions to any third party without the [insert name of CB]’s written consent.
2.   These Conditions do not create any rights in favour of or obligations in relation to any entity other than the [insert name of CB] and participants in TARGET-[insert CB/country reference].

Article 34

Governing law, jurisdiction and place of performance

1.   The bilateral relationship between the [insert name of CB] and participants in TARGET-[insert CB/country reference] shall be governed by [insert adjective relating to country name] law.
2.   Without prejudice to the competence of the Court of Justice of the European Union, any dispute arising from a matter relating to the relationship referred to in paragraph 1 falls under the exclusive competence of the competent courts of [insert place of the seat of the CB].
3.   The place of performance concerning the legal relationship between the [insert reference to CB] and the participants shall be [insert place of the seat of the CB].

Article 35

Severability

If any provision in these Conditions is or becomes invalid, this shall not prejudice the applicability of all the other provisions of these Conditions.

Article 36

Entry into force and binding nature

1.   These Conditions become effective from [insert relevant date].
2.   [Insert if appropriate under relevant national law: By requesting to participate in TARGET-[insert CB/country reference], applicant participants automatically agree to these Conditions between themselves and in relation to the [insert name of CB].]

PART II

Special terms and conditions for main cash accounts (MCAS)

Article 1

Opening and management of an MCA

1.   The [insert name of CB] shall open and operate at least one MCA for each participant, except where the participant is an AS that only uses RTGS or TIPS AS settlement procedures, in which case the use of an MCA shall be at the discretion of the AS
2.   For the purpose of the settlement of monetary policy operations as set out in [insert reference to the General documentation], and the settlement of interest from such operations, the participant shall designate a primary MCA held with [insert name of CB].
3.   The primary MCA designated in accordance with paragraph 2 shall also be used for the following purposes:
(a) remuneration as set out in Part I, Article 12, unless the participant has designated another participant in TARGET-[insert CB/country reference] for that purpose;
(b) the granting of intraday credit, where applicable.
4.   Any negative balance on a primary MCA shall not be lower than the credit line (if granted). There shall be no debit balance on an MCA that is not a primary MCA.

Article 2

Co-management of an MCA

1.   On the request of an MCA holder the [insert name of CB] shall allow an MCA held by that MCA holder to be co-managed by one of the following:
(a) another MCA holder in TARGET-[insert CB/country reference];
(b) an MCA holder in another TARGET component system;
(c) [[insert name of CB] if applicable].
If the MCA holder holds more than one MCA, each MCA held may be co-managed by a different co-manager.
The co-manager shall have the same rights and privileges in relation to an MCA that it co-manages as it has in relation to its own MCA.
2.   The MCA holder shall provide the [insert name of CB] with evidence of the consent of the co-manager to act in that capacity. [
to be included if 1(c) is used -
] Such evidence of consent to act shall not be required where the co-manager is [insert name of CB.]
3.   An MCA holder acting as co-manager shall fulfil the obligations of the MCA holder of the co-managed MCA under Part I, Article 5(1), point (a), Part I, Article 10(4), and Part I, Article 31(1).
4.   The MCA holder of a co-managed MCA shall fulfil the obligations of a participant under Part I and Part II in respect of the co-managed MCA. In the event that the MCA holder does not have a direct technical connection to TARGET, Part I, Article 5(1), point (a), Part I, Article 10(4), and Part I Article 31(1) shall not apply.
5.   Part I, Article 7 shall apply to an MCA holder that designates an entity to act as co-manager of an MCA holder’s MCA pursuant to this Article.
6.   The MCA holder shall [immediately] notify the [insert name of CB] if the co-manager ceases to act or the co-management arrangement between the MCA holder and the co-manager is terminated.

Article 3

MCA liquidity transfer group

1.   On the request of an MCA holder the [insert name of CB] shall create an MCA liquidity transfer group, for the purpose of enabling the processing of MCA-to-MCA liquidity transfer orders.
2.   On the request of an MCA holder the [insert name of CB] shall add one of the MCA holder’s MCAs to or delete it from an existing MCA liquidity transfer group created in TARGET-[insert CB/country reference] or another TARGET component system. The MCA holder shall inform all other MCA holders in that MCA liquidity transfer group before making such a request.

Article 4

Transactions processed via an MCA

1.   The following transactions shall be processed via an MCA in TARGET-[insert CB/country reference]:
(a) central bank operations;
(b) liquidity transfer orders to and from overnight deposit accounts opened by [insert name of CB] in the name of the participant;
(c) liquidity transfer orders to another MCA within the same MCA liquidity transfer group;
(d) liquidity transfer orders to a T2S DCA, TIPS DCA or RTGS DCA, or to a sub-account thereof.
2.   The following transaction may be processed via an MCA in TARGET-[insert CB/country reference]:
(a) [insert if required [cash transfer orders resulting from lodgements and withdrawals.]]

Article 5

Liquidity transfer orders

1.   An MCA holder may submit a liquidity transfer order as one of the following:
(a) an immediate liquidity transfer order, which shall be an instruction for execution immediately;
(b) a standing liquidity transfer order, which shall be an instruction for the recurring execution of the transfer of a specified amount on the occurrence of a predefined event each business day.

Article 6

Rule-based liquidity transfer orders

1.   An MCA holder may specify a floor and/or a ceiling amount for its MCA.
2.   By setting a ceiling and opting for a rule-based liquidity transfer order, if, following the settlement of a payment order, the ceiling is breached, the MCA holder instructs [insert name of CB] to execute a rule-based liquidity transfer order that credits an RTGS DCA or another MCA within the same MCA liquidity transfer group designated by that MCA holder. The credited RTGS DCA or MCA may be in TARGET-[insert CB/country reference] or another TARGET component system.
3.   By setting a floor and opting for a rule-based liquidity transfer order, if, following the settlement of a payment order, the floor is breached, a rule-based liquidity transfer order is initiated which debits an RTGS DCA or another MCA within the same MCA liquidity transfer group designated by that MCA holder. The debited RTGS DCA or MCA may be in TARGET-[insert CB/country reference] or another TARGET component system. The holder of the RTGS DCA or MCA to be debited must authorise its account to be debited in this manner.
4.   An MCA holder may authorise its MCA to be debited in the event that a floor is breached in one or more specified RTGS DCAs or MCAs within the same liquidity transfer group in TARGET-[insert CB/country reference] or another TARGET component system. By authorising its account to be debited, the MCA holder instructs [insert name of CB] to execute a rule-based liquidity transfer order that credits the RTGS DCA(s) or MCA(s) whenever the floor is breached.
5.   An MCA holder may authorise its MCA to be debited in the event that there is insufficient liquidity on an RTGS DCA designated for the purpose of automated liquidity transfer orders under Part III, Article 1(5) and (6) to settle urgent payment orders, AS transfer orders or high priority payment orders. By authorising its account to be debited, the MCA holder instructs [insert name of CB] to execute a rule-based liquidity transfer order that credits its RTGS DCA.

Article 7

Processing of cash transfer orders

1.   Cash transfer orders, once accepted, shall settle immediately provided that there is available liquidity on the payer’s MCA.
2.   In the event that there are insufficient funds on an MCA to effect settlement, the relevant rule as set out in points (a) to (e) shall apply [depending on the type of cash transfer order].
(a) Payment order on the MCA: the instruction shall be rejected if it is initiated by the [insert name of CB] and would trigger both a change in the participant’s line of intraday credit and a corresponding debit or credit of its MCA. All other instructions shall be queued.
(b) Immediate liquidity transfer order: the order shall be rejected without partial settlement or any further attempt to settle.
(c) Standing liquidity transfer order: the order shall be partially settled without any further attempt to settle.
(d) Rule-based liquidity transfer order: the order shall be partially settled without any further attempt to settle.
(e) Liquidity transfer order to an overnight deposit account: the order shall be rejected without partial settlement or any further attempt to settle.
3.   All cash transfer orders in the queue shall be processed following the ‘first in, first out’ (FIFO) principle without prioritisation or reordering.
4.   Cash transfer orders in the queue at the end of the business day shall be rejected.

Article 8

Liquidity reservation orders

1.   An MCA holder may instruct [insert name of CB] to reserve a specified amount of liquidity on its MCA for the purpose of settling central bank operations or liquidity transfer orders to overnight deposit accounts using one of the following:
(a) a current liquidity reservation order that shall have immediate effect for the current TARGET business day;
(b) a standing liquidity reservation order to be carried out at the start of every TARGET business day.
2.   In the event that the amount of unreserved liquidity is not sufficient to fulfil the current or standing liquidity reservation order, the [insert name of CB] shall partially execute the reservation order. The [insert name of CB] is instructed to execute further reservation orders until the outstanding amount to be reserved is reached. Pending reservation orders shall be rejected at the end of the business day.
3.   Central bank operations shall be settled using the liquidity reserved as set out in paragraph 1 and other cash transfer orders shall only be settled using liquidity available after the amount reserved has been deducted.
4.   Notwithstanding paragraph 3, in the event of insufficient unreserved liquidity on the MCA holder’s primary MCA for the purpose of decreasing the MCA holder’s line of intraday credit the [insert name of CB] shall use the liquidity reserved.

Article 9

Processing of cash transfer orders in the event of suspension or termination

1.   Upon termination of a participant’s participation in TARGET-[insert CB/country reference], the [insert name of CB] shall not accept any new cash transfer orders from that participant. Cash transfer orders in the queue, warehoused cash transfer orders or new cash transfer orders in favour of that participant shall be rejected.
2.   If a participant is suspended from TARGET-[insert CB/country reference] on grounds other than those specified in Part I, Article 25 (1), point (a), the [insert name of CB] shall store all of that participant’s incoming and outgoing cash transfer orders on its MCA and only submit them for settlement after they have been explicitly accepted by the suspended participant’s CB.
3.   If a participant is suspended from TARGET-[insert CB/country reference] on the grounds specified in Part I, Article 25(1), point (a), any outgoing cash transfer orders from that participant’s MCA shall only be processed on the instructions of its representatives, including those appointed by a competent authority or a court, such as the participant’s insolvency administrator, or pursuant to an enforceable decision of a competent authority or a court providing instructions as to how the cash transfer orders are to be processed. All incoming cash transfer orders shall be processed in accordance with paragraph 2.

Article 10

Entities eligible for intraday credit

1.   [insert name of CB] shall provide intraday credit to credit institutions established in the Union or the EEA that are eligible counterparties for Eurosystem monetary policy operations and have access to the marginal lending facility, including when those credit institutions act through a branch established in the Union or the EEA and including branches established in the Union or the EEA of credit institutions that are established outside the EEA, provided that such branches are established in the same country as the relevant euro area NCB. No intraday credit may be provided to entities that are subject to restrictive measures adopted by the Council of the European Union or Member States pursuant to Article 65(1)(b), Article 75 or Article 215 of the Treaty, the implementation of which, in the view of [insert name of CB], is incompatible with the smooth functioning of TARGET.
2.   [insert name of NCB] may also grant intraday credit to the following entities:
(a) credit institutions established in the Union or the EEA that are not eligible counterparties for Eurosystem monetary policy operations and/or do not have access to the marginal lending facility, including when they act through a branch established in the Union or the EEA and including branches established in the Union or the EEA of credit institutions that are established outside the EEA;
(b) treasury departments of central or regional governments of Member States and public sector bodies of Member States authorised to hold accounts for customers;
(c) investment firms established in the Union or the EEA provided that they have concluded an arrangement with a participant with access to intraday credit as set out in paragraph 1 above to ensure that any residual debit position at the end of the relevant day is covered; and
(d) entities other than those falling within point (a) that manage AS and act in that capacity;
provided that in the cases specified in points (a) to (d) the entity receiving intraday credit is established in the same jurisdiction as [insert name of NCB].
3.   Intraday credit shall only be granted on TARGET business days.
4.   For the entities mentioned in paragraph 2(a) to (d), and in accordance with [insert national provisions implementing Article 19 of Guideline (EU) 2015/510 (ECB/2014/60)], intraday credit shall be limited to the day on which it is granted and no extension to overnight credit shall be possible.
5.   [insert name of CB] may provide access to the overnight credit facility to certain eligible CCPs, within the scope of Article 139(2)(c) of the Treaty in conjunction with Articles 18 and 42 of the Statute of the ESCB and [insert national provisions implementing Article 1(1) of Guideline (EU) 2015/510 (ECB/2014/60)]. Such eligible CCPs are those that, at all relevant times:
(a) are eligible entities for the purposes of paragraph 2(d), provided also that those eligible entities are authorised as CCPs in accordance with the applicable Union or national legislation;
(b) are established in the euro area;
(c) have access to intraday credit.
6.   All overnight credit granted to eligible CCPs shall be subject to the terms of this Article 10 and to Articles 11 and 12 (including the provisions in relation to eligible collateral).
7.   The sanctions provided for in Articles 12 and 13 shall apply when eligible CCPs fail to reimburse the overnight credit extended to them by their NCB.

Article 11

Eligible collateral for intraday credit

Intraday credit shall be based on eligible collateral. Eligible collateral shall consist of the same assets as eligible for use in Eurosystem monetary policy operations, and shall be subject to the same valuation and risk control rules as those laid down in [insert national provisions implementing Part Four of Guideline (EU) 2015/510 (ECB/2014/60)].

Article 12

Credit extension procedure for intraday credit

1.   Intraday credit shall be provided free of interest.
2.   The failure by an entity referred to in Article 10(1) to reimburse the intraday credit at the end of the day shall automatically be considered as a request by such entity for recourse to the marginal lending facility. If an entity referred to in Article 10(1) holds a DCA, any end-of-day balance on its DCA(s) shall be taken into account for the purpose of calculating the amount of the entity's recourse to the automatic marginal lending facility. This shall not trigger any equivalent release of assets pre-deposited as collateral for the underlying outstanding intraday credit.
3.   The failure by the entity referred to in Article 10(2), points (a), (c) or (d) to reimburse the intraday credit at the end of the day for whatever reason shall render that entity liable to the following penalties:
(a) if the entity in question has a debit balance on its account at the end of the day for the first time within any 12-month period, then this entity shall incur penalty interest calculated at a rate of five percentage points above the marginal lending facility rate on the amount of such debit balance;
(b) if the entity in question has a debit balance on its account at the end of the day for at least the second time within the same 12-month period, then the penalty interest mentioned in subparagraph (a) shall be increased by 2.5 percentage points for each time additional to the first that a debit position has occurred within this 12-month period.
4.   The Governing Council of the ECB may decide to waive or reduce the penalties imposed pursuant to paragraph 3, if the end-of-day debit balance of the participant in question is attributable to force majeure and/or technical malfunction of TARGET, the latter phrase as defined in [insert reference to the measures implementing Annex III].

Article 13

Suspension, limitation or termination of intraday credit

1.   [insert name of NCB] shall suspend or terminate access to intraday credit if one of the following events of default occurs:
(a) the participant’s primary MCA with the [insert name of NCB] is suspended or terminated;
(b) the participant concerned ceases to meet any of the requirements laid down in Article 10 for the provision of intraday credit;
(c) a decision is made by a competent judicial or other authority to implement in relation to the participant a procedure for the winding-up of the participant or the appointment of a liquidator or analogous officer over the participant or any other analogous procedure;
(d) the participant becomes subject to the freezing of funds and/or other measures imposed by the Union restricting the participant’s ability to use its funds;
(e) the participant’s eligibility as a counterparty for Eurosystem monetary policy operations has been suspended or terminated.
2.   [insert name of NCB] may suspend or terminate access to intraday credit if an NCB suspends or terminates the participant’s participation in TARGET pursuant to that NCB’s implementation of Part I, Article 25(2).
3.   [insert name of CB] may decide to suspend, limit or terminate a participant’s access to intraday credit if the participant is deemed to pose risks on the grounds of prudence.

PART III

Special terms and conditions for real-time gross settlement dedicated cash accounts (RTGS DCAs)

Article 1

Opening and management of an RTGS DCA

1.   The [insert name of CB] shall on the request of an MCA holder open and operate one or more RTGS DCAs, and one or more sub-accounts if required for use for AS settlement. If the MCA holder has adhered to the SCT Inst scheme by signing the SEPA Instant Credit Transfer Adherence Agreement, the RTGS DCA(s) (and any sub-accounts) shall not be opened or operated unless the MCA holder is and remains reachable at all times, either as a TIPS DCA holder or as a reachable party via a TIPS DCA holder.
2.   The [insert name of CB] shall on the request of the holder of an account opened pursuant to paragraph 1 (RTGS DCA holder) add the RTGS DCA or its sub-account to a settlement bank account group for AS settlement. The RTGS DCA holder shall provide [insert name of CB] with any relevant documents, duly signed by that RTGS DCA holder and the AS.
3.   There shall be no debit balance on an RTGS DCA or its sub-accounts.
4.   Sub-accounts shall have a zero balance overnight.
5.   An RTGS DCA holder shall designate one of its RTGS DCAs in TARGET-[insert CB/country reference] for the purpose of processing automated liquidity transfer orders. By such designation the RTGS DCA holder instructs [insert name of CB] to execute an automated liquidity transfer that credits the MCA in the event that there are insufficient funds on its primary MCA for the settlement of payment orders that are central bank operations.
6.   A participant holding two or more RTGS DCAs and two or more MCAs shall designate one of its RTGS DCAs in TARGET-[insert CB/country reference], which is not already designated to its primary MCA, for the purpose of processing automated liquidity transfer orders in the event that there are insufficient funds on one of its other MCAs for the settlement of payment orders that are central bank operations.

Article 2

Addressable BIC holders

1.   RTGS DCA holders that are credit institutions as set out in Part I, Article 4(1), points (a) or (b), or Part I, Article 4(2), point (e), may register addressable BIC holders. RTGS DCA holders may register addressable BIC holders that have adhered to the SCT Inst scheme by signing the SEPA Instant Credit Transfer Adherence Agreement only if such entities are reachable, either as a TIPS DCA holder or as a reachable party via a TIPS DCA holder.
2.   RTGS DCA holders that are entities as set out in Part I, Article 4(2), points (a) to (d) may only register as an addressable BIC holder, any BIC that belongs to the same legal entity.
3.   An addressable BIC holder may submit cash transfer orders to and receive cash transfer orders via an RTGS DCA holder.
4.   An addressable BIC holder may not be registered by more than one RTGS DCA holder.
5.   Cash transfer orders submitted or cash transfers received by addressable BIC holders shall be deemed to have been submitted or received by the participant itself.
6.   The participant shall be bound by such cash transfer orders and any other action taken by the addressable BIC holders, regardless of the content of, or any non-compliance with, the contractual or other arrangements between that participant and such entity.

Article 3

Multi-addressee access

1.   An RTGS DCA holder that is a credit institution as set out in Part I, Article 4(1)(a) or (b) may give authorisation to the following credit institutions and branches to use its RTGS DCA for the purpose of submitting and/or receiving cash transfer orders directly by way of multi-addressee access:
(a) credit institutions as set out in Part I, Article 4(1), points (a) or (b) that belong to the same banking group as the RTGS DCA holder;
(b) branches of that RTGS DCA holder;
(c) other branches or the head-office of the same legal entity as the RTGS DCA holder.
2.   The authorisation to use an RTGS DCA by way of multi-addressee access as set out in paragraph 1 shall be given to entities referred to in point (a) of paragraph 1 that have adhered to the SCT Inst scheme by signing the SEPA Instant Credit Transfer Adherence Agreement only if such entities are reachable, either as a TIPS DCA holder or as a reachable party via a TIPS DCA holder.
3.   Part I, Article 7 shall apply to RTGS DCA holders that give access to their RTGS DCA by way of multi-addressee access.

Article 4

RTGS liquidity transfer group

1.   On the request of an RTGS DCA holder the [insert name of CB] shall create an RTGS liquidity transfer group, for the purpose of enabling the processing of RTGS DCA-to-RTGS DCA liquidity transfer orders.
2.   On the request of an RTGS DCA holder the [insert name of CB] shall add one of the RTGS DCA holder’s RTGS DCAs to or delete it from an existing RTGS liquidity transfer group created in TARGET-[insert CB/country reference] or another TARGET component system. The RTGS DCA holder shall inform all other RTGS DCA holders in that RTGS liquidity transfer group before making such a request.

Article 5

Transactions processed on an RTGS DCA and its sub-accounts

1.   Payment orders to other RTGS DCAs and cash transfer orders to AS guarantee fund accounts shall be processed via an RTGS DCA in TARGET-[insert CB/country reference].
2.   Cash transfer orders related to RTGS AS settlement procedures shall be settled via an RTGS DCA or its sub-accounts in TARGET-[insert CB/country reference].
3.   The following transactions may be processed via an RTGS DCA or its sub-accounts in TARGET-[insert CB/country reference]:
(a) [insert if required] [cash transfer orders resulting from lodgements and withdrawals];
(b) liquidity transfer orders to another RTGS DCA within the same RTGS liquidity transfer group;
(c) liquidity transfer orders to a TIPS DCA or an MCA;
(d) liquidity transfers to an overnight deposit account.
4.   Liquidity transfer orders to T2S DCAs may be processed via an RTGS DCA in TARGET-[insert CB/country reference].

Article 6

Liquidity transfer orders

1.   An RTGS DCA holder may submit a liquidity transfer order as one of the following:
(a) an immediate liquidity transfer order, which shall be an instruction for execution immediately;
(b) a standing liquidity transfer order, which shall be an instruction for the recurring execution of the transfer of a specified amount on the occurrence of a predefined event each business day;
2.   A standing liquidity transfer order may be input or modified by the RTGS DCA holder at any time during a business day and shall become effective as of the next business day.
3.   An immediate liquidity transfer order may be input by the RTGS DCA holder at any time during a business day. An immediate liquidity transfer order for processing in accordance with RTGS AS settlement procedures C or D may also be input by the relevant AS on behalf of the settlement bank.

Article 7

Rule-based liquidity transfer orders

1.   An RTGS DCA holder may specify a floor and/or a ceiling amount for its RTGS DCA.
(a) By setting a ceiling and opting for a rule-based liquidity transfer order, if, following the settlement of a payment order or AS transfer order, the ceiling is breached, the RTGS DCA holder instructs [insert name of CB] to execute a rule-based liquidity transfer order that credits an MCA designated by that RTGS DCA holder. The credited MCA may belong to another participant in TARGET-[insert CB/country reference] or in another TARGET component system.
(b) By setting a floor, and opting for a rule-based liquidity transfer order, if, following the settlement of a payment order or AS transfer order, the floor is breached, a rule-based liquidity transfer order is initiated that debits an MCA authorised by the MCA holder. The debited MCA may belong to another participant in TARGET-[insert CB/country reference] or in another TARGET component system. The holder of the debited MCA must authorise its MCA to be debited in this manner.
2.   An RTGS DCA holder may authorise its RTGS DCA to be debited in the event that a floor is breached in one or more specified MCAs in TARGET-[insert CB/country reference] or another TARGET component system. By authorising its RTGS DCA to be debited, the RTGS DCA holder instructs [insert name of CB] to execute a rule-based liquidity transfer order that credits the MCA(s) whenever the floor is breached.
3.   An RTGS DCA holder may authorise its MCA designated for the purpose of automated liquidity transfer orders under Article 1(5) and (6) to be debited in the event that there is insufficient liquidity on the RTGS DCA to settle urgent payment orders, AS transfer orders or high priority payment orders on its RTGS DCA.

Article 8

Priority rules

1.   The order of priority for the processing of cash transfer orders, in descending level of urgency, shall be:
(a) urgent;
(b) high;
(c) normal.
2.   The following orders shall automatically be assigned the priority ‘urgent’:
(a) AS transfer orders;
(b) liquidity transfer orders including automated liquidity transfer orders;
(c) cash transfer orders to an AS technical account for RTGS AS settlement procedure D.
3.   All cash transfer orders not listed in paragraph 2 shall automatically be assigned the priority ‘normal’, except payment orders to which the RTGS DCA holder has at its discretion assigned the priority ‘high’.

Article 9

Processing of cash transfer orders on RTGS DCAs

1.   Cash transfer orders on RTGS DCAs shall be settled immediately they are accepted, or later as indicated by the RTGS DCA holder in accordance with Article 16 or Article 17, provided in all cases that:
(a) there is available liquidity on the payer’s RTGS DCA;
(b) no cash transfer orders of equal or higher priority are queued; and
(c) any debit limits set in accordance with Article 15 are observed.
2.   If any of the conditions set out in points (a) to (c) of paragraph 1 are not met in relation to a cash transfer order, the following shall apply.
(a) In the case of an automated liquidity transfer order, the [insert name of CB] is instructed to execute the instruction partially and to execute further liquidity transfers whenever liquidity is available, up to the amount of the initial automated liquidity transfer order.
(b) In the case of an immediate liquidity transfer order, the order shall be rejected without partial settlement or any further attempt to settle unless the order is initiated by an AS, in which case it shall be partially settled without any further attempt to settle.
(c) In the case of a standing liquidity transfer order or a rule-based liquidity transfer order, the order shall be partially settled without any further attempt to settle. A standing liquidity transfer order triggered by mandatory RTGS AS settlement procedures C or D and for which there are insufficient funds on the RTGS DCA shall be settled following a pro rata reduction of all orders. A standing liquidity transfer order triggered by optional RTGS AS settlement procedure C and for which there are insufficient funds on the RTGS DCA shall be rejected.
3.   Cash transfer orders on RTGS DCAs, other than those orders referred to in paragraph 2 shall be queued and processed in accordance with the rules set out in Article 10.

Article 10

Queue management and settlement optimisation

1.   Cash transfer orders on RTGS DCAs that are queued in accordance with Article 9(3) shall be processed according to their priority. Subject to paragraph 2 to 5, the ‘first in, first out’ (FIFO) principle shall apply within each category or subcategory of cash transfer orders priority as follows:
(a) urgent cash transfer orders: the automated liquidity transfer orders shall be placed first in the queue. AS transfer orders and other urgent cash transfer orders shall be placed next in the queue;
(b) high priority cash transfer orders shall not be settled while urgent cash transfer orders are queued;
(c) normal priority cash transfer orders shall not be settled while urgent or high priority cash transfer orders are queued.
2.   The payer may change the priority of its cash transfer orders other than urgent cash transfer orders.
3.   The payer may change the position of its cash transfer orders in the queue. The payer may move such cash transfer orders either behind the automated liquidity transfer orders in the queue or to the end of the respective queue with immediate effect at any time during the settlement window for customer and interbank payments as specified in Appendix V.
4.   To optimise the settlement of queued cash transfer orders, the [insert name of CB] may;
(a) use the optimisation procedures described in Appendix I;
(b) settle cash transfer orders with a lower priority (or of the same priority but accepted later) before cash transfer orders with a higher priority (or of the same priority accepted earlier), if the cash transfer orders with a lower priority would net out with payments to be received and result on balance in a liquidity increase for the payer;
(c) settle cash transfer orders with normal priority before other queued normal priority payments accepted earlier, provided that sufficient funds are available and notwithstanding that this may contravene the FIFO principle.
5.   Queued cash transfer orders shall be rejected if they cannot be settled by the cut-off times for the relevant message type as specified in Appendix V.
6.   The provisions regarding settlement of cash transfer orders as set out in Appendix I shall apply.

Article 11

Liquidity reservation orders

1.   An RTGS DCA holder may instruct [insert name of CB] to reserve a specified amount of liquidity on its RTGS DCA using one of the following:
(a) a current liquidity reservation order that shall have immediate effect for the current TARGET business day;
(b) a standing liquidity reservation order to be carried out at the start of every TARGET business day.
2.   An RTGS DCA holder shall assign one of the following statuses to a current or standing liquidity reservation order:
(a) high priority: allows the usage of the liquidity for urgent or high priority cash transfer orders;
(b) urgent priority: allows the usage of the liquidity only for urgent cash transfer orders.
3.   In the event that the amount of unreserved liquidity is not sufficient to fulfil the current or standing liquidity reservation order, the [insert name of CB] shall partially execute the reservation order and is instructed to execute further reservation orders until the outstanding amount to be reserved is reached. Pending reservation orders shall be rejected at the end of the business day.
4.   By requesting the reservation of a specified amount of liquidity for usage for urgent cash transfer orders, the RTGS DCA holder instructs the [insert name of CB] only to settle high priority and normal priority cash transfer orders if there is available liquidity after the amount reserved for usage for urgent cash transfer orders has been deducted.
5.   By requesting the reservation of a specified amount of liquidity for usage for high priority cash transfer orders, the RTGS DCA holder instructs the [insert name of CB] only to settle normal priority cash transfer orders if there is available liquidity after the amount reserved for usage for urgent and high priority cash transfer orders has been deducted.

Article 12

Recall request and answer

1.   An RTGS DCA holder may enter a recall request to request the return of a settled payment order.
2.   The recall request shall be forwarded to the payee of the settled payment order which may answer positively or negatively. A positive answer does not initiate a return of the funds.

Article 13

RTGS directory

1.   The RTGS directory is a list of BICs used for the purpose of routing information and comprises the BICs of:
(a) RTGS DCA holders;
(b) any entity with multi-addressee access;
(c) addressable BIC holders.
2.   The RTGS directory shall be updated daily.
3.   Unless otherwise requested by an RTGS DCA holder, its BICs shall be published in the RTGS directory.
4.   RTGS DCA holders may only distribute the RTGS directory to their branches and entities with multi-addressee access.
5.   RTGS DCA holders acknowledge that the [insert name of CB] and other CBs may publish RTGS DCA holders’ names and BICs. In addition, names and BICs of addressable BIC holders or entities with multi-addressee access may be published and RTGS DCA holders shall ensure that addressable BIC holders or entities with multi-addressee access have agreed to such publication.

Article 14

Processing of cash transfer orders in the event of suspension or termination

1.   Upon termination of an RTGS DCA holder’s participation in TARGET-[insert CB/country reference], [insert name of CB] shall not accept any new cash transfer orders from that RTGS DCA holder. Cash transfer orders in the queue, warehoused cash transfer orders or new cash transfer orders in favour of that RTGS DCA holder shall be rejected.
2.   If an RTGS DCA holder’s participation in TARGET-[insert CB/country reference] is suspended on grounds other than those specified in Part I, Article 25(1), point (a), the [insert name of CB] shall store all of that RTGS DCA holder’s incoming and outgoing cash transfer orders on its RTGS DCA and only submit them for settlement after they have been explicitly accepted by the suspended RTGS DCA holder’s CB.
3.   If an RTGS DCA holder’s participation in TARGET-[insert CB/country reference] is suspended on the grounds specified in Part I, Article 25(1), point (a), any outgoing cash transfer orders from that RTGS DCA holder’s RTGS DCA shall only be processed on the instructions of its representatives, including those appointed by a competent authority or a court, such as the RTGS DCA holder’s insolvency administrator, or pursuant to an enforceable decision of a competent authority or a court providing instructions as to how the cash transfer orders are to be processed. All incoming cash transfer orders shall be processed in accordance with paragraph 2.

Article 15

Debit limits

1.   An RTGS DCA holder may limit the use of available liquidity for payment orders on its individual RTGS DCAs in relation to other RTGS DCAs, except any of the CBs, by specifying bilateral or multilateral limits. Such limits may only be defined in relation to normal priority payment orders.
2.   By specifying a bilateral limit, an RTGS DCA holder instructs the [insert name of CB] that an accepted payment order shall not be settled if the sum of its outgoing normal priority payment orders to another RTGS DCA holder’s RTGS DCA minus the sum of all incoming urgent, high priority and normal priority payments from that RTGS DCA (the net bilateral position) would exceed this bilateral limit.
3.   An RTGS DCA holder may specify a multilateral limit for any relationship that is not subject to a bilateral limit. A multilateral limit may only be specified if the RTGS DCA holder has set at least one bilateral limit. If an RTGS DCA holder specifies a multilateral limit, it instructs the [insert name of CB] that an accepted payment order shall not be settled if the sum of its outgoing normal priority payment orders to all RTGS DCA holders’ RTGS DCAs in relation to which no bilateral limit has been specified minus the sum of all incoming urgent, high priority and normal priority payments from those RTGS DCAs (the net multilateral position) would exceed this multilateral limit.
4.   Limits may be changed in real time with immediate effect or with effect from the next business day. If a limit is changed to zero, it shall not be possible to change it again on the same business day. The definition of a new bilateral or multilateral limit shall only be effective from the next business day.

Article 16

Participants’ instructions with regard to settlement times

1.   An RTGS DCA holder may indicate the earliest time before which a payment order cannot settle or the latest time after which time the payment order will be rejected by using the earliest debit time indicator or the latest debit time indicator, respectively, or may indicate a time range during which the payment order will settle by using both indicators. An RTGS DCA holder may also use the latest debit time indicator solely as a warning indicator. In such cases, the payment order concerned shall not be rejected.
2.   In the event that 15 minutes prior to the indicated latest debit time the payment order has not been settled, the RTGS DCA holder concerned shall be notified accordingly.

Article 17

Payment orders submitted in advance

1.   Payment orders may be submitted up to 10 calendar days before the specified settlement date (warehoused payment orders).
2.   Warehoused payment orders shall be accepted and submitted for processing on the date specified by the RTGS DCA holder at the start of settlement window on that day for customer and interbank payments, as referred to in Appendix V. They shall be placed in front of payment orders of the same priority.

Article 18

Direct debit

1.   An RTGS DCA holder (payer) may give its authorisation for another RTGS DCA holder (payee) in TARGET-[insert CB/country reference] or in another TARGET component system to debit the payer’s RTGS DCA by direct debit.
2.   To enable such arrangement the payer shall provide a prior authorisation to [insert name of CB] entitling [insert name of CB] to debit the payer’s RTGS DCA upon receipt of a valid direct debit instruction.
3.   If a payee receives the authorisation as described in paragraph 1, it may submit direct debit instructions to debit the payer’s RTGS DCA by the amount specified in the instruction.
4.   An RTGS DCA holder that requests to be added to a settlement bank account group of an AS shall be deemed to have given authorisation to [insert name of CB] entitling [insert name of CB] to debit the RTGS DCA holder’s RTGS DCA and sub-account upon receipt of a valid direct debit instruction by that AS.

Article 19

Back-up payment functionality

In the event of the failure of its payment infrastructure, an RTGS DCA holder may request the [insert name of CB] to activate the back-up payment functionality. This allows the RTGS DCA holder to enter certain payment orders using the Graphical User Interface (GUI).

Article 20

Security rights in relation to funds on sub-accounts

1.   The [insert name of CB] shall have [insert reference to a collateralisation technique under the applicable legal system] over the balance on an RTGS DCA holder’s sub-account opened under the arrangements between the relevant AS and its CB for the settlement of AS-related payment instructions in accordance with RTGS AS settlement procedure C. Such balance shall collateralise the RTGS DCA holder’s obligation referred to in paragraph 7 towards the [insert name of CB] in relation to such settlement.
2.   Upon receipt by the [insert name of CB] of a ‘start-of-cycle’ message, the [insert name of CB] shall ensure that the balance on the sub-account of the RTGS DCA holder (including increases or reductions of that balance resulting from crediting or debiting cross-system settlement payments to or from the sub-account, or from crediting liquidity transfers to the sub-account) at the moment the AS starts a cycle can only be used for the settlement of AS transfer orders related to that settlement procedure C. Upon receipt by the [insert name of CB] of an ‘end-of-cycle’ message the balance on the sub-account shall be available for the use of the RTGS DCA holder.
3.   By confirming the balance on the RTGS DCA holder’s sub-account, the [insert name of CB] guarantees to the AS payment up to the amount of this particular balance. By confirming, where applicable, the increase or reduction of the balance upon crediting or debiting cross-system settlement payments to or from the sub-account or crediting liquidity transfers to the sub-account, the guarantee is automatically increased or reduced by the amount of the payment. Notwithstanding the abovementioned increase or reduction of the guarantee, the guarantee shall be irrevocable, unconditional and payable on first demand. If the [insert name of CB] is not the AS’s CB, the [insert name of CB] shall be deemed instructed to issue the abovementioned guarantee to the AS’s CB.
4.   In the absence of any insolvency proceedings in relation to the RTGS DCA holder, the AS transfer orders for the squaring of the RTGS DCA holder’s settlement obligation shall be settled without drawing on the guarantee and without recourse to the security right over the balance on the RTGS DCA holder’s sub-account.
5.   In the event of the RTGS DCA holder’s insolvency, the AS transfer orders for the squaring of the RTGS DCA holder’s settlement obligation shall be a first demand for payment under the guarantee; the debiting of the instructed amount from the RTGS DCA holder’s sub-account (and crediting of the AS’s RTGS AS technical account) shall therefore equally involve the discharge of the guarantee obligation by the [insert name of the CB] and a realisation of its collateral right over the balance on the RTGS DCA holder’s sub-account.
6.   The guarantee shall expire upon receipt by the [insert name of CB] of an ‘end-of-cycle’ message confirming that the settlement has been completed.
7.   The RTGS DCA holder shall be obliged to reimburse to the [insert name of CB] any payment made by the latter under such guarantee.

PART IV

Special terms and conditions for TARGET2-securities dedicated cash accounts (T2S DCAs)

Article 1

Opening and management of a T2S DCA

1.   The [insert name of CB] shall on the request of an MCA holder open and operate one or more T2S DCAs.
2.   There shall be no debit balance on a T2S DCA.
3.   A T2S DCA holder shall designate one MCA for the purpose of processing liquidity transfer orders between T2S DCAs as referred to in Article 3(1), point (c). The designated MCA may be held in TARGET-[insert CB/country reference] or another TARGET component system and may belong to a different participant.

Article 2

Links between securities accounts and T2S DCAs

1.   A T2S DCA holder may request the [insert name of CB] to link its T2S DCA to one or more securities account(s) held on its own behalf or on behalf of its clients which hold securities accounts in one or more participating CSDs.
2.   T2S DCA holders linking their T2S DCA to securities account(s) on behalf of clients as set out in paragraph 1 are responsible for establishing and maintaining the list of linked securities accounts and, where relevant, the set-up of the client-collateralisation feature.
3.   As a result of the request under paragraph 1, the T2S DCA holder is deemed to have given a mandate to the CSD where such linked securities accounts are maintained to debit the T2S DCA with the amounts resulting from securities transactions taking place on these securities accounts.
4.   Paragraph 3 shall apply regardless of any agreements the T2S DCA holder has with the CSD and/or the securities account holders.

Article 3

Transactions processed on T2S DCAs

1.   The following transactions shall be processed via a T2S DCA in TARGET-[insert CB/country reference]:
(a) the settlement of cash instructions stemming from T2S provided that the T2S DCA holder has designated the relevant securities account(s), as referred to in Article 2;
(b) liquidity transfer orders to an RTGS DCA, a TIPS DCA or an MCA;
(c) liquidity transfer orders between T2S DCAs belonging to the same participant or in respect of which the same MCA has been designated pursuant to Article 1(3);
(d) cash transfer orders between the T2S DCA and the T2S DCA of the [insert name of CB] in the particular context of Article 10(2) and (3).
2.   Corporate actions payments may be processed via a T2S DCA.

Article 4

Liquidity transfer orders

A T2S DCA holder may submit liquidity transfer orders as one of the following:
(a) an immediate liquidity transfer order, which shall be an instruction for execution immediately;
(b) a standing liquidity transfer order, which shall be an instruction for the recurring execution of (i) a transfer of a specified transfer amount or (ii) a transfer to reduce the balance of the T2S DCA to a predefined level with the amount of the reduction being transferred to an RTGS DCA, a TIPS DCA or an MCA, on the occurrence of a predefined event each business day.
(c) a predefined liquidity transfer order, which shall be an instruction for the single execution of (i) a transfer of a specified transfer amount or (ii) a transfer to reduce the balance of the T2S DCA to a predefined level with the amount of the reduction being transferred to an RTGS DCA, a TIPS DCA or an MCA, on the occurrence of a predefined event each business day.

Article 5

Reservation and blocking of liquidity

1.   Participants may reserve or block liquidity on their T2S DCAs. This does not constitute a settlement guarantee vis-à-vis any third party.
2.   By requesting to reserve or block an amount of liquidity, a participant instructs the [insert name of CB] to decrease the available liquidity by this amount.
3.   A reservation request is an instruction by which, if the available liquidity is equal to or higher than the amount to be reserved, the reservation is processed. If the available liquidity is lower, it is reserved and the shortfall may be met by incoming liquidity until the full amount of the reservation is available.
4.   A blocking request is an instruction by which, if the available liquidity is equal to or higher than the amount to be blocked, the blocking request is processed. If the available liquidity is lower, no amount is blocked and the blocking request is resubmitted, until the full amount of the blocking request can be met by available liquidity.
5.   The participant may at any time during the business day on which a request to reserve or block liquidity has been processed, instruct the [insert name of CB] to cancel the reservation or blocking. Partial cancellation shall not be permitted.
6.   All requests for reservation or blocking of liquidity under this article shall expire at the end of the business day.

Article 6

Processing of liquidity transfer orders on T2S DCAs

1.   A timestamp for the processing of liquidity transfer orders is allocated in the sequence of their receipt.
2.   All liquidity transfer orders submitted to TARGET-[insert CB/country reference] shall be processed following the ‘first in, first out’ (FIFO) principle without prioritisation or reordering.
3.   After a liquidity transfer order to a TIPS DCA, an MCA, an RTGS DCA or a T2S DCA has been accepted as set out in Part I, Article 17, the TARGET-[insert CB/country reference] shall check if sufficient funds are available on the payer’s T2S DCA to effect settlement. If sufficient funds are available, the liquidity transfer order shall be settled immediately. If sufficient funds are not available, the following shall apply:
(a) in the case of an immediate liquidity transfer order, the order shall be rejected without partial settlement or any further attempt to settle unless these are initiated by a third party as designated in accordance with Part I, Article 7, in which case they shall be partially settled without any further attempt to settle;
(b) in the case of a predefined or standing liquidity transfer order, the order shall be partially settled without any further attempt to settle.

Article 7

Processing of cash transfer orders in the event of suspension or termination

1.   Upon termination of a T2S DCA holder’s participation in TARGET-[insert CB/country reference], the [insert name of CB] shall not accept any new cash transfer orders from that T2S DCA holder.
2.   If a T2S DCA holder is suspended from TARGET-[insert CB/country reference] on grounds other than those specified in Part I, Article 25(1), point (a) , the [insert name of CB] shall store all of that participant’s incoming and outgoing cash transfer orders on its T2S DCA and only submit them for settlement after they have been explicitly accepted by the suspended T2S DCA holder’s CB.
3.   If a T2S DCA holder is suspended from TARGET-[insert CB/country reference] on the grounds specified in Part I, Article 25(1), point (a), any outgoing cash transfer orders from that T2S holder’s T2S DCA shall only be processed on the instructions of its representatives, including those appointed by a competent authority or a court, such as the T2S DCA holder’s insolvency administrator, or pursuant to an enforceable decision of a competent authority or a court providing instructions as to how the cash transfer orders are to be processed. All incoming cash transfer orders shall be processed in accordance with paragraph 2.

Article 8

Eligible entities for auto-collateralisation facilities

1.   [insert name of CB] shall, offer auto-collateralisation facilities to a T2S DCA holder to which it provides intraday credit in accordance with Part II Article 10 if so requested by that T2S DCA holder and on condition that such participant is not subject to restrictive measures adopted by the Council of the European Union or Member States pursuant to Article 65(1)(b), Article 75 or Article 215 of the Treaty, the implementation of which, in the view of the [insert name of CB] is incompatible with the smooth functioning of TARGET.
2.   Auto-collateralisation shall only be granted on a TARGET business day, shall be limited to that day and no extension to overnight credit shall be possible.

Article 9

Eligible collateral for auto-collateralisation operations

1.   Auto-collateralisation shall be based on eligible collateral. Eligible collateral shall consist of the same assets as eligible for use in Eurosystem monetary policy operations, and shall be subject to the same valuation and risk control rules as those laid down in [insert national provisions implementing Part Four of Guideline (EU) 2015/510 (ECB/2014/60)].
2.   Furthermore, eligible collateral for auto-collateralisation:
(a) [insert as relevant: may be limited by the [insert name of CB] by means of an ex ante exclusion of potential close-link collateral];
(b) is subject to certain discretionary choices for the exclusion of eligible collateral as granted to the euro area NCBs by decisions of the Governing Council of the ECB.

Article 10

Credit provision and recovery procedure

1.   Credit obtained by means of auto-collateralisation shall be provided free of interest.
2.   Auto-collateralisation may be reimbursed at any time during the day by the T2S DCA holder.
3.   Auto-collateralisation shall be reimbursed at the latest at the time defined in Appendix V, and in accordance with the following process:
(a) the [insert name of CB] releases the reimbursement instruction which is settled subject to cash being available to reimburse outstanding auto-collateralisation;
(b) if, after performing step (a), the balance on the T2S DCA is not sufficient to reimburse outstanding auto-collateralisation, the [insert name of CB] checks other T2S DCAs opened in its books for the same T2S DCA holder and transfers cash from any or all of these to the T2S DCA where reimbursement instructions are pending;
(c) if, after performing steps (a) and (b), the balance on a T2S DCA is not sufficient to reimburse outstanding auto-collateralisation, the T2S DCA holder shall be deemed to have instructed the [insert name of CB] to transfer the collateral which was used to obtain the outstanding auto-collateralisation to the collateral account of [insert name of CB]. Thereafter, the [insert name of CB] shall provide the liquidity to reimburse the outstanding auto-collateralisation and shall without undue delay debit the primary MCA of the T2S DCA holder.
(d) The [insert name of CB] shall apply a penalty fee of EUR 1 000 for each business day where one or more recourses to collateral relocation under point (c) occur. The penalty fee shall be debited from the primary MCA of the T2S DCA holder referred to in point (c).

Article 11

Suspension, limitation or termination of auto-collateralisation facilities

1.   [insert name of CB] shall suspend or terminate a T2S DCA holder’s access to auto-collateralisation facilities if it suspends or terminates that T2S DCA holder’s access to intraday credit pursuant to Part II, Article 13.
2.   [insert name of CB] shall limit a T2S DCA holder’s access to auto-collateralisation facilities if it has limited that T2S DCA holder’s access to intraday credit pursuant to Part II, Article 13. In such a case, the limit set shall apply to the total of the auto-collateralisation and intraday credit facilities combined, and not to each one separately.

PART V

Special terms and conditions for TARGET instant payment settlement (TIPS) dedicated cash accounts (TIPS DCAs)

Article 1

Opening and management of a TIPS DCA

1.   The [insert name of CB] shall on the request of an MCA holder open and operate one or more TIPS DCAs.
2.   There shall be no debit balance on a TIPS DCA.

Article 2

Sending and receiving messages

1.   A TIPS DCA holder may send messages:
(a) directly, and/or
(b) via one or more instructing parties.
2.   A TIPS DCA holder shall receive messages:
(a) directly; or
(b) via one instructing party.
3.   Part I, Article 7 shall apply to a TIPS DCA holder that sends or receives messages via an instructing party as though that TIPS DCA holder sends or receives messages directly.

Article 3

Reachable parties

1.   A TIPS DCA holder may designate one or more reachable parties. Reachable parties shall have adhered to the SCT Inst scheme by signing the SEPA Instant Credit Transfer Adherence Agreement.
2.   A TIPS DCA holder shall provide evidence to [insert name of CB] of each designated reachable party’s adherence to the SCT Inst scheme.
3.   A TIPS DCA holder shall inform [insert name of CB] 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 DCA.
4.   A TIPS DCA holder may allow its designated reachable parties access via one or more instructing parties.
5.   Part I, Article 7 shall apply to TIPS DCA holders that designate reachable parties.
6.   A TIPS DCA holder that has designated a reachable party shall ensure that at all times that reachable party is available for the purpose of receiving messages.

Article 4

Transactions processed on TIPS DCAs

1.   The following transactions shall be processed via a TIPS DCA in TARGET-[insert CB/country reference]:
(a) instant payment orders;
(b) positive recall answers;
(c) liquidity transfer orders to TIPS AS technical Accounts, MCAs, T2S DCAs or RTGS DCAs;
(d) liquidity transfer orders to sub-accounts;
(e) liquidity transfer orders to overnight deposit accounts.

Article 5

Immediate liquidity transfer orders

A TIPS DCA holder may submit immediate liquidity transfer orders.

Article 6

Processing of cash transfer orders on TIPS DCAs

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-[insert CB/country reference] 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, TARGET-[insert CB/country reference] shall check if sufficient funds are available on the payer’s TIPS DCA 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 [insert name of CB] shall reject an instant payment order if the amount of the instant payment order exceeds any applicable credit memorandum balance (CMB).
6.   After an immediate liquidity transfer order has been accepted as set out in Part I, Article 17, TARGET-[insert CB/country reference] shall check if sufficient funds are available on the payer’s TIPS DCA. If sufficient funds are not available the liquidity transfer order shall be rejected.
7.   After a positive recall answer has been accepted as set out in Part I, Article 17, TARGET-[insert CB/country reference] shall check if sufficient funds are available on the TIPS DCA 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, TARGET-[insert CB/country reference] shall reject positive recall answers if the amount of the positive recall answer exceeds any applicable CMB.

Article 7

Recall request

1.   A TIPS DCA 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 a negative recall answer.

Article 8

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 DCA holders may only distribute the TIPS directory to their branches, 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 DCA holders acknowledge that the [insert name of CB] and other CBs may publish their names and BICs. In addition, the [insert name of CB] and other CBs may publish names and BICs of reachable parties designated by TIPS DCA holders and TIPS DCA holders shall ensure that reachable parties have agreed to such publication.

Article 9

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 10

Processing of cash transfer orders in the event of suspension or extraordinary termination

1.   Upon termination of a TIPS DCA holder’s participation in TARGET-[insert CB/country reference], the [insert name of CB] shall not accept any new cash transfer orders to or from that TIPS DCA holder.
2.   If a TIPS DCA holder’s participation in TARGET-[insert CB/country reference] is suspended on grounds other than those specified in Part I, Article 25(1), point (a), [insert name of CB] 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 DCA holder’s participation in TARGET-[insert CB/country reference] is suspended on the grounds specified in Part I, Article 25(1), point (a), the [insert name of CB] shall reject all of its incoming and outgoing cash transfer orders.
4.   The [insert name of CB] shall process instant payment orders of a TIPS DCA holder whose participation in TARGET-[insert CB/country reference] has been suspended or terminated under Part I, Article 25(1) or (2) and in relation to which the [insert name of CB] has reserved funds on a TIPS DCA pursuant to Article 6(3), point (b) prior to the suspension or termination.

PART VI

Special terms and conditions for ancillary systems (AS) using real-time gross settlement ancillary system (RTGS AS) settlement procedures

Article 1

Opening and Management of AS technical accounts and use of RTGS AS settlement procedures

1.   The [insert name of CB] may on the request of an AS open and operate one or more RTGS AS technical accounts to support RTGS AS settlement procedures.
2.   There shall be no debit balance on an RTGS AS technical account.
3.   RTGS AS technical accounts shall not be published in the RTGS directory.
4.   The AS shall select at least one of the following settlement procedures for the purposes of processing AS transfer orders:
(a) RTGS AS settlement procedure A;
(b) RTGS AS settlement procedure B;
(c) RTGS AS settlement procedure C;
(d) RTGS AS settlement procedure D;
(e) RTGS AS settlement procedure E.
5.   The rules set out in Articles 3, 4, 5, 6 and 7 shall apply to RTGS AS settlement procedures A, B, C, D and E, respectively.
6.   The RTGS AS settlement procedures shall be operational during the times set out in Appendix V.
7.   The AS shall request the [insert name of CB] to create a settlement bank account group.
8.   The AS shall only send AS transfer orders to accounts included in the settlement bank account group referred to in paragraph 7.

Article 2

Priority of AS transfer orders

All AS transfer orders shall automatically be assigned the priority ‘urgent’.

Article 3

RTGS AS settlement procedure A

1.   The AS shall request a dedicated RTGS AS technical account to support the processing of AS transfer orders using settlement procedure A. The balance on such account shall be zero at the end of the day.
2.   The AS may request the opening of an AS guarantee fund account to support settlement in connection with the ‘settlement period’ service. The balances on the AS guarantee fund account shall be used to settle AS transfer orders in the event that there is insufficient available liquidity on a settlement bank's RTGS DCA. The AS guarantee fund account may be held by [insert name of the CB], the AS or an eligible participant. The AS guarantee fund account shall not be published in the RTGS directory.
3.   The AS shall submit AS transfer orders as a batch in a single file in which the sum of debits must balance the sum of credits.
4.   The [insert name of the CB] shall first attempt to settle AS transfer orders that debit the RTGS DCAs of settlement banks and crediting the AS's RTGS AS technical account. Only upon settlement of all such AS transfer orders (including possible funding of the RTGS AS technical account from the AS guarantee fund account) the [insert name of the CB] shall attempt to settle AS transfer orders that debit the RTGS AS technical account and that credit the RTGS DCAs of settlement banks.
5.   If an AS transfer order to debit a settlement bank's RTGS DCA is queued, the [insert name of the CB] shall inform the settlement bank by means of a broadcast message.
6.   If an AS guarantee fund account has been opened and a settlement bank has insufficient funds on its RTGS DCA, the AS may instruct the [insert name of the CB] to activate the guarantee fund mechanism by means of a request to debit the AS guarantee fund account and to credit the RTGS AS technical account. If the AS guarantee fund account does not have sufficient funds to complete settlement, the settlement process shall fail.
7.   If the settlement process fails for any reason, including as referred to in paragraph 6, the [insert name of the CB] shall reject all unsettled AS transfer orders in the single file referred to in paragraph 3 and shall reverse any AS transfer orders that have already been settled.
8.   The AS shall be notified on completion or failure of the settlement.
9.   The AS may opt for the following services:
(a) the ‘information period’ service, as referred to in Article 8(1);
(b) the ‘settlement period’ service, as referred to in Article 8(3)

Article 4

RTGS AS settlement procedure B

1.   The AS shall request a dedicated RTGS AS technical account to support the processing of AS transfer orders using settlement procedure B. The balance on such account shall be zero at the end of day.
2.   The AS may request the opening of an AS guarantee fund account to support settlement in connection with the ‘settlement period’ service. The balances on the AS guarantee fund account shall be used to settle the AS transfer orders in the event that there is insufficient available liquidity on a settlement bank's RTGS DCA. The AS guarantee fund account may be held by [insert name of the CB], the AS or an eligible participant. The AS guarantee fund account shall not be published in the RTGS directory.
3.   The AS shall submit AS transfer orders as a batch in a single file in which the sum of debits must balance the sum of credits.
4.   Settlement procedure B operates on an ‘all-or-nothing’ basis. The [insert name of the CB] shall attempt to simultaneously settle all AS transfer orders that debit the RTGS DCAs of settlement banks and credit the AS’s RTGS AS technical account, and all AS transfer orders that debit the RTGS AS technical account and credit the RTGS DCAs of settlement banks. If one or more of the AS transfer orders cannot be settled, all AS transfer orders shall be queued and an optimisation algorithm shall be applied, and the settlement banks shall be informed.
5.   If an AS guarantee fund account has been opened and a settlement bank has insufficient funds on its RTGS DCA, the AS may instruct the [insert name of the CB] to activate the guarantee fund mechanism by means of a request to debit the AS guarantee fund account and to credit the RTGS AS technical account. If the AS guarantee fund account does not have sufficient funds to complete settlement, the settlement process shall fail.
6.   If the settlement process fails for any reason, including as referred to in paragraph 5, the [insert name of the CB] shall reject all unsettled AS transfer orders in the single file referred to in paragraph 3.
7.   The AS shall be notified on completion or failure of the settlement.
8.   The AS may opt for the following services:
(a) the ‘information period’ service, as referred to in Article 8(1);
(b) the ‘settlement period’ service, as referred to in Article 8(3).

Article 5

RTGS AS settlement procedure C

1.   Settlement procedure C supports settlement using dedicated liquidity on sub-accounts. The AS shall request a dedicated RTGS AS technical account to support the processing of AS transfer orders using settlement procedure C. The balance on such account shall be zero at the end of the day. This RTGS AS technical account may also be used to support the processing of AS transfer orders using settlement procedure E.
2.   The AS shall ensure that each settlement bank opens at least one sub-account that is only to be used by the AS for the purposes of this settlement procedure.
3.   The [insert name of CB] shall start a mandatory settlement procedure C automatically on each TARGET business day according to the schedule set out in Appendix V, that shall trigger the settlement of those standing liquidity transfer orders set up for mandatory settlement procedure C by debiting the RTGS DCAs of the settlement banks and crediting the sub-account referred to in paragraph 2.
4.   Settlement procedure C shall close by means of an end-of-procedure message, which may be sent by the AS at any time prior to the cut-off time for interbank payments as set out in Appendix V. If the AS does not send the end-of-procedure message by that cut-off time, the [insert name of CB] shall close the procedure at that cut-off time.
5.   The closure of the mandatory settlement procedure C leads to an automatic transfer of liquidity from the sub-account referred to in paragraph 2 to the RTGS DCA.
6.   If the mandatory settlement procedure C is closed, the AS may start an optional procedure at any time before the cut-off time for interbank payments as set out in Appendix V, that shall trigger the settlement of those standing liquidity transfer orders set up for optional settlement procedure C by debiting the settlement bank’s RTGS DCA and crediting its RTGS sub-account. The AS may start and close one or several successive optional procedures before the cut-off time for interbank payments. The closure of an optional settlement procedure C leads to an automatic transfer of liquidity from the sub-account referred to in paragraph 2 to the RTGS DCA
7.   The mandatory settlement procedure C and any subsequent optional settlement procedure C may consist of one or several cycles.
8.   The AS may, at any time after the start of a mandatory or optional settlement procedure C, start a cycle by means of a ‘start-of-cycle’ message. After the start of the cycle, liquidity transfers from the sub-account referred to in paragraph 2 may not be made until an ‘end-of-cycle’ message is sent by the AS. The balance can be changed during the cycle as a result of cross-system settlement payments or if a settlement bank transfers liquidity to its sub-account. The [insert name of CB] shall notify the AS of the reduction or increase of liquidity on the sub-account as a result of cross-system settlement payments. If the AS so requests, the [insert name of CB] shall also notify it of the increased liquidity on the sub-account as a result of liquidity transfer orders by the settlement bank.
9.   The AS may submit AS transfer orders as a batch in one or several files while the cycle is open. The cash transfer orders may be for any of the following transactions:
(a) the debit of the sub-accounts of settlement banks and credit of the RTGS AS technical account;
(b) the debit of the RTGS AS technical account and credit of the sub-accounts of settlement banks;
(c) the debit of the RTGS AS technical account and credit of the RTGS DCAs of settlement banks.
10.   The [insert name of CB] shall immediately settle those AS transfer orders that can be settled. AS transfer orders that cannot be settled immediately shall be queued and an optimisation algorithm shall be applied. Any AS transfer orders which remain unsettled at the time the cycle is closed shall be rejected.
11.   The AS shall be notified at the latest by the end of the cycle of the status of the individual AS transfer orders.

Article 6

RTGS AS settlement procedure D

1.   RTGS AS Settlement procedure D supports settlement with the use of pre-funding. The AS shall request a dedicated RTGS AS technical account to support the processing of AS transfer orders using settlement procedure D.
2.   The RTGS AS technical accounts shall only have a zero balance or a positive balance. Liquidity may remain on the RTGS AS technical account overnight whereupon it will be subject to remuneration as set out in Part I, Article 12(2).
3.   The [insert name of CB] shall notify the AS of liquidity transfers debiting the RTGS DCAs of the settlement banks and crediting the RTGS AS technical account. These liquidity transfers may be made on each TARGET business day according to the schedule set out in Appendix V. The AS may input immediate liquidity transfer orders that debit the RTGS AS technical account and credit the RTGS DCAs of the settlement banks.

Article 7

RTGS AS settlement procedure E

1.   RTGS AS Settlement procedure E supports bilateral settlement and the individual processing of AS transfer orders. The AS may use Settlement Procedure E without an RTGS AS technical account for bilateral settlement. The AS shall request an RTGS AS technical account to support the processing of AS transfer orders using settlement procedure E if it opts for the individual processing of AS transfer orders. The balance on this RTGS AS technical account shall be zero at the end of the day. This RTGS AS technical account may also be used for settlement procedure C.
2.   The AS may submit AS transfer orders as a batch in one or several files between:
(a) the RTGS DCAs of the settlement banks and the RTGS AS technical account if used; and
(b) the RTGS DCAs of the settlement banks.
The AS shall be responsible for ensuring the correct sequencing of AS transfer orders in the file to ensure smooth settlement.
3.   The [insert name of CB] shall settle immediately those AS transfer orders that can be settled. AS transfer orders that cannot be settled immediately shall be queued. If an AS transfer order to debit a settlement bank's RTGS DCA is queued, the settlement bank shall be informed via a broadcast message.
4.   The AS may opt for the following services:
(a) the ‘information period’ service, as referred to in Article 8(1);
(b) The ‘settlement period’ service, as referred to in Article 8(3).
5.   The AS shall be notified of the status of the individual AS transfer orders submitted.

Article 8

Information period and settlement period

1.   The ‘information period’ service allows the AS to inform its settlement banks of the liquidity needed to ensure successful settlement. This optional service allows the AS to define a period before the start of the settlement of the AS transfer orders. During that period, and at the request of the settlement bank, the AS may revoke either single AS transfer orders (for RTGS AS settlement procedure E) or files (for RTGS AS settlement procedures A and B). The AS may also request the [insert name of CB] to perform such revocation on its behalf.
2.   In the event that an AS, or the [insert name of CB] on its behalf, revokes single AS transfer orders (for RTGS AS settlement Procedure E) or files (for RTGS AS settlement procedures A and B) during the ‘information period’, the processing of the AS transfer orders shall be cancelled.
3.   The ‘settlement period’ service allows the AS to define a period until which the settlement of the AS transfer orders can take place. This service is a prerequisite for the use of a guarantee fund account, and is optional for the use of AS technical accounts.
4.   During the ‘settlement period’ the AS, or the [insert name of CB] on its behalf, may revoke either single AS transfer orders (for RTGS AS settlement procedure E) or files (for RTGS AS settlement procedures A and B) that do not have a final status and the following shall apply:
(a) if RTGS AS settlement procedure E is used for bilateral settlement, the relevant AS transfer orders shall be reversed;
(b) if RTGS AS settlement procedure E is not used for bilateral settlement, or if in RTGS AS settlement procedure A the entire settlement fails, any settled AS transfer orders in the file shall be reversed and all settlement banks and the AS shall be informed via a broadcast message.
(c) if RTGS AS settlement procedure B is used, the entire settlement fails and all settlement banks and the AS shall be informed via a broadcast message.

Article 9

Cross system settlement

1.   Cross-system settlement allows an AS to credit the RTGS AS technical account of another AS or sub-account of a settlement bank of another AS and is available for AS using RTGS AS settlement procedure C or D.
2.   The [insert name of CB] shall, on the request of the AS, allow cross-system settlement between that AS and another AS in TARGET-[insert country reference/name of CB] or another TARGET component system. The requesting AS shall provide the [insert name of CB] with the authorisation of the other AS.
3.   A cross-system settlement may only be initiated if the two AS have opened a settlement procedure. Furthermore, if the cross-system settlement is initiated by an AS using RTGS AS settlement procedure C, a settlement cycle must also be open for that AS.
4.   An AS using RTGS AS settlement procedure C in the context of cross-system settlement shall only submit AS transfer orders individually that debit the sub-account of one of its AS settlement banks. These AS transfer orders would credit the sub-account of the receiving AS settlement bank if that receiving AS is using RTGS AS settlement procedure C, or would credit the RTGS AS technical account of the receiving AS if that AS is using RTGS AS settlement procedure D.
5.   An AS using RTGS AS settlement procedure D in the context of cross-system settlement shall only submit AS transfer orders individually that debit its RTGS AS technical account. These AS transfer orders would credit the sub-account of the receiving AS settlement bank if that receiving AS is using RTGS AS settlement procedure C, or would credit the RTGS AS technical account of the receiving AS if that AS is using RTGS AS settlement procedure D.
Both AS using cross-system settlement shall be notified via a broadcast message of the settlement or rejection of the AS transfer orders.

Article 10

Effect of suspension or termination

If the suspension or termination of the use of the AS settlement procedures by an AS occurs during the settlement cycle of AS transfer orders, the [insert name of CB] may complete the settlement cycle.

PART VII

Special terms and conditions for ancillary systems using the TARGET instant payment settlement (TIPS) ancillary system settlement procedure (TIPS AS settlement procedure)

Article 1

Opening and management of a TIPS AS technical account

1.   The [insert name of CB] may on the request of an AS that settles instant payments pursuant to the SCT Inst scheme or near instant payments in its own books, open and operate one or more TIPS AS technical accounts.
2.   There shall be no debit balance on a TIPS AS technical account.
3.   The ancillary system shall use a TIPS AS technical account to collect the necessary liquidity set aside by its clearing members to fund their positions.
4.   The ancillary 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.
3.   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-[insert CB/country reference] 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 [insert name of CB] 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 [insert name of CB] 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), [insert name of CB] 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, [insert name of CB] 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, [insert name of CB] 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 [insert name of CB] of each designated reachable party’s adherence to the SCT Inst scheme.
3.   A TIPS AS technical account holder shall inform [insert name of CB] 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-[insert CB/country reference]:
(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 [insert name of CB] 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-[insert CB/country reference], the [insert name of CB] 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[insert CB/country reference] is suspended on grounds other than those specified in Part I, Article 25(1), point (a), [insert name of CB] 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-[insert CB/country reference] is suspended on the grounds specified in Part I, Article 25(1), point (a), the suspended TIPS AS technical account holder’s CB shall reject all of its incoming and outgoing cash transfer orders.
4.   The [insert name of CB] shall process instant payment orders of a TIPS AS technical account holder whose participation in TARGET-[insert CB/country reference] has been suspended or terminated under Part I, Article 25(1) or (2) and in relation to which the [insert name of CB] has reserved funds on a TIPS AS technical account pursuant to Article 4(3), point (b) prior to the suspension or termination.
(1)  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, p. 190
).
(2)  Guideline (EU) 2019/671 of the European Central Bank of 9 April 2019 on domestic asset and liability management operations by the national central banks (ECB/2019/7) (
OJ L 113, 29.04.2019, p. 11
).
(3)  Council Regulation (EC) No 2531/98 of 23 November 1998 concerning the application of minimum reserves by the European Central Bank (
OJ L 318, 27.11.1998, p. 1
).
(4)  Decision (EU) 2019/1743 of the European Central Bank of 15 October 2019 on the remuneration of holdings of excess reserves and of certain deposits (ECB/2019/31) (
OJ L 267, 21.10.2019, p. 12
).

APPENDIX I

TECHNICAL SPECIFICATIONS FOR THE PROCESSING OF CASH TRANSFER ORDERS

In addition to the Harmonised Conditions, the following rules shall apply to the processing of cash transfer orders:

1.   

Testing requirements for participation in TARGET-[insert CB/country reference]

Each participant shall pass a series of tests to prove its technical and operational competence before it may participate in TARGET-[insert CB/country reference].

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

IntraBalanceMovementModificationRequestStatusAdvice

camt.074

IntraBalanceMovementCancellationRequest

camt.075

IntraBalanceMovementCancellationRequestStatusAdvice

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 [insert name of CB] 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 [insert name of CB] 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 [insert name of CB] 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 [insert name of CB] 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 [insert name of CB] at its discretion.
(b) Under the ‘
multiple optimisation
’ algorithm the [insert name of CB] 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 [insert name of CB] 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 [insert name of CB] 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 [insert name of CB] 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 [insert name of CB] 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 [
insert as necessary
the [insert name of CB]’s website and] the ECB’s website in English.
(1)  For sub-accounts this section must start with the 3-character AS code as defined by the central bank.

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 [insert name of CB] 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 EUR 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 (€STR) 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 non-settled 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 non-settled 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 [insert name of CB] in English (see [insert reference to website of CB]). 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 [insert name of CB]. Any additional information and evidence requested by the [insert name of CB] shall be supplied within two weeks of such request being made.
(c) The [insert name of CB] 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 [insert name of CB] 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 [insert name of CB] (see [insert reference to website of CB]). If such letter has not been received by the [insert name of CB] within four weeks, the participants concerned shall be deemed to have rejected the compensation offer.
(e) The [insert name of CB] 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

[Insert name of CB]
[address]

Participation in the [name of the system]

[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 established; hereinafter the ‘jurisdiction’] in connection with the participation of [specify name of Participant] (hereinafter the ‘Participant’) in the [name of the TARGET component system] (hereinafter the ‘System’).
This Opinion is confined to the laws of [jurisdiction] as they exist as on the date of this Opinion. We have made no investigation of the laws of any other jurisdiction as a basis for this Opinion, and do not express or imply any opinion in this regard. Each of the statements and opinions presented below applies with equal accuracy and validity under the laws of [jurisdiction], whether or not the Participant acts through its head office or one or more branches established inside or outside of [jurisdiction] in submitting Cash transfer orders and receiving Cash transfers.

I.   DOCUMENTS EXAMINED

For the purposes of this Opinion, we have examined:
(1) a certified copy of the [specify relevant constitutional documents] of the Participant such as is/are in effect on the date hereof;
(2) [if applicable] an extract from the [specify relevant company register] and [if applicable] [register of credit institutions or analogous register];
(3) [to the extent applicable] a copy of the Participant’s licence or other proof of authorisation to provide banking, investment, funds transfer or other financial services in line with the access criteria for participation in TARGET in [jurisdiction];
(4) [if applicable] a copy of a resolution adopted by the board of directors or the relevant governing body of the Participant on [insert date], [insert year], evidencing the Participant’s agreement to adhere to the System Documents, as defined below; and
(5) [specify all powers of attorney and other documents constituting or evidencing the requisite power of the person or persons signing the relevant System Documents (as defined below) on behalf of the Participant];
and all other documents relating to the Participant’s constitution, powers, and authorisations necessary or appropriate for the provision of this Opinion (hereinafter the ‘Participant Documents’).
For the purposes of this Opinion, we have also examined:
(1) the [insert reference to the arrangements implementing the
Harmonised Conditions for participation in TARGET
] for the System dated [insert date] (hereinafter the ‘Rules’); and
(2) [...].
The Rules and the [...] shall be referred to hereinafter as the ‘System Documents’ (and collectively with the Participant Documents as the ‘Documents’).

II.   ASSUMPTIONS

For the purposes of this Opinion we have assumed in relation to the Documents that:
(1) the System Documents with which we have been provided are originals or true copies;
(2) the terms of the System Documents and the rights and obligations created by them are valid and legally binding under the laws of [insert reference to the Member State of the System] by which they are expressed to be governed, and the choice of the laws of [insert reference to the Member State of the System] to govern the System Documents is recognised by the laws of [insert reference to the Member State of the System];
(3) the Participant Documents are within the capacity and power of and have been validly authorised, adopted or executed and, where necessary, delivered by the relevant parties; and
(4) the Participant Documents are binding on the parties to which they are addressed, and there has been no breach of any of their terms.

III.   OPINIONS REGARDING THE PARTICIPANT

A.
The Participant is a corporation duly established and registered or otherwise duly incorporated or organised under the laws of [jurisdiction].
B.
The Participant has all the requisite corporate powers to execute and perform the rights and obligations under the System Documents to which it is party.
C.
The adoption or execution and the performance by the Participant of the rights and obligations under the System Documents to which the Participant is party do not in any way breach any provision of the laws or regulations of [jurisdiction] applicable to the Participant or the Participant Documents.
D.
No additional authorisations, approvals, consents, filings, registrations, notarisations or other certifications of or with any court or governmental, judicial or public authority that is competent in [jurisdiction] are required by the Participant in connection with the adoption, validity or enforceability of any of the System Documents or the execution or performance of the rights and obligations thereunder.
E.
The Participant has taken all necessary corporate action and other steps necessary under the laws of [jurisdiction] to ensure that its obligations under the System Documents are legal, valid and binding.
This Opinion is stated as of its date and is addressed solely to [insert name of CB] and the [Participant]. No other persons may rely on this Opinion, and the contents of this Opinion may not be disclosed to persons other than its intended recipients and their legal counsel without our prior written consent, with the exception of the European Central Bank and the national central banks of the European System of Central Banks [and [the national central bank/relevant regulatory authorities] of [jurisdiction]].
Yours faithfully,
[signature]

Terms of reference for country opinions for non-EEA participants in TARGET

[Insert name of CB]
[address]
[name of the system]
[location],
[date]
Dear Sir or Madam,
We have been asked as [external] legal advisers to [specify name of Participant or branch of Participant] (the ‘Participant’) in respect of issues arising under the laws of [jurisdiction in which the Participant is established; hereinafter the ‘jurisdiction’] to provide this Opinion under the laws of [jurisdiction] in connection with the participation of the Participant in a system which is a component of TARGET (hereinafter the ‘System’). References herein to the laws of [jurisdiction] include all applicable regulations of [jurisdiction]. We express an opinion herein under the law of [jurisdiction], with particular regard to the Participant established outside [insert reference to the Member State of the System] in relation to rights and obligations arising from participation in the System, as presented in the System Documents defined below.
This Opinion is confined to the laws of [jurisdiction] as they exist on the date of this Opinion. We have made no investigation of the laws of any other jurisdiction as a basis for this Opinion, and do not express or imply any opinion in this regard. We have assumed that there is nothing in the laws of another jurisdiction which affects this Opinion.

1.   DOCUMENTS EXAMINED

For the purposes of this Opinion, we have examined the documents listed below and such other documents as we have deemed necessary or appropriate:
(1) the [insert reference to the arrangements implementing the
Harmonised Conditions for participation in TARGET
] for the System dated [insert date] (hereinafter the ‘Rules’); and
(2) any other document governing the System and/or the relationship between the Participant and other participants in the System, and between the participants in the System and the [insert name of CB].
The Rules and the [.] shall be referred to hereinafter as the ‘System Documents’.

2.   ASSUMPTIONS

For the purposes of this Opinion we have assumed in relation to the System Documents that:
(1) the System Documents are within the capacity and power of and have been validly authorised, adopted or executed and, where necessary, delivered by the relevant parties;
(2) the terms of the System Documents and the rights and obligations created by them are valid and legally binding under the laws of [insert reference to the Member State of the System], by which they are expressed to be governed, and the choice of the laws of [insert reference to the Member State of the System] to govern the System Documents is recognised by the laws of [insert reference to the Member State of the System];
(3) the participants in the System through which any Cash transfer orders are sent or Cash transfers are received, or through which any rights or obligations under the System Documents are executed or performed, are licensed to provide funds transfer services, in all relevant jurisdictions; and
(4) the documents submitted to us in copy or as specimens conform to the originals.

3.   OPINION

Based on and subject to the foregoing, and subject in each case to the points set out below, we are of the opinion that:

3.1.   

Country-specific legal aspects [to the extent applicable]

The following characteristics of the legislation of [jurisdiction] are consistent with and in no way set aside the obligations of the Participant arising out of the System Documents: [list of country-specific legal aspects].

3.2.   

General insolvency issues

3.2.a.   

Types of insolvency proceedings

The only types of insolvency proceedings (including composition or rehabilitation) which, for the purpose of this Opinion, shall include all proceedings in respect of the Participant’s assets or any branch it may have in [jurisdiction] to which the Participant may become subject in [jurisdiction], are the following: [list proceedings in original language and English translation] (together collectively referred to as ‘Insolvency Proceedings’).
In addition to Insolvency Proceedings, the Participant, any of its assets, or any branch it may have in [jurisdiction] may become subject in [jurisdiction] to [list any applicable moratorium, receivership, or any other proceedings as a result of which payments to and/or from the Participant may be suspended, or limitations can be imposed in relation to such payments, or similar proceedings in original language and English translation] (hereinafter collectively referred to as ‘Proceedings’).

3.2.b.   

Insolvency treaties

[jurisdiction] or certain political subdivisions within [jurisdiction], as specified, is/are party to the following insolvency treaties: [specify, if applicable which have or may have an impact on this Opinion].

3.3.   

Enforceability of System Documents

Subject to the points set out below, all provisions of the System Documents will be binding and enforceable in accordance with their terms under the laws of [jurisdiction], in particular in the event of the opening of any Insolvency Proceedings or Proceedings with respect to the Participant.
In particular, we are of the opinion that:

3.3.a.   

Processing of Cash transfer orders

The provisions on processing of Cash transfer orders of the Rules [add the relevant provisions implementing Articles 17 and 18 of Part I of Annex I, Articles 4 to 7 and 9 of Part II of Annex I, Articles 5 to 10 and 14 to 17 of Part III of Annex I, Articles 4 and 6 to 7 of Part IV of Annex I, Articles 6 and 10 of Part V of Annex I] are valid and enforceable. In particular, all Cash transfer orders processed pursuant to such sections will be valid, binding and will be enforceable under the laws of [jurisdiction]. The provision of the Rules which specifies the precise point in time at which Cash transfer orders submitted by the Participant to the System become enforceable and irrevocable [add the relevant provision implementing Article 18 of Annex 1, Part I] is valid, binding and enforceable under the laws of [jurisdiction].

3.3.b.   

Authority of the [insert name of CB] to perform its functions

The opening of Insolvency Proceedings or Proceedings in respect of the Participant will not affect the authority and powers of the [insert name of CB] arising out of the System Documents. [Specify [to the extent applicable] that: the same opinion is also applicable in respect of any other entity which provides the Participants with services directly and necessarily required for participation in the System, e.g. TARGET NSP].

3.3.c.   

Remedies in the event of default

[Where applicable to the Participant, the provisions contained in [list of sections] of the Rules regarding accelerated performance of claims which have not yet matured, the set-off of claims for using the deposits of the Participant, the enforcement of a pledge, suspension and termination of participation, claims for default interest, and termination of agreements and transactions ([insert other relevant clauses of the Rules or the System Documents]) are valid and enforceable under the laws of [jurisdiction].]

3.3.d.   

Suspension and termination

Where applicable to the Participant, the provisions contained in [list of sections] of the Rules (in respect of suspension and termination of the Participant’s participation in the System on the opening of Insolvency Proceedings or Proceedings or other events of default, as defined in the System Documents, or if the Participant represents any kind of systemic risk or has serious operational problems) are valid and enforceable under the laws of [jurisdiction].

3.3.e.   

Penalty regime

Where applicable to the Participant, the provisions contained in [list of sections] of the Rules in respect of penalties imposed on a Participant which is unable to reimburse intraday credit or overnight credit, where applicable, on time are valid and enforceable under the laws of [jurisdiction].

3.3.f.   

Assignment of rights and obligations

The rights and obligations of the Participant cannot be assigned, altered or otherwise transferred by the Participant to third parties without the prior written consent of the [insert name of CB].

3.3.g.   

Choice of governing law and jurisdiction

The provisions contained in [list of sections] of the Rules, and in particular in respect of the governing law, the resolution of a dispute, competent courts, and service of process are valid and enforceable under the laws of [jurisdiction].

3.4.   

Voidable preferences

We are of the opinion that no obligation arising out of the System Documents, the performance thereof, or compliance therewith prior to the opening of any Insolvency Proceedings or Proceedings in respect of the Participant may be set aside in any such proceedings as a preference, voidable transaction or otherwise under the laws of [jurisdiction].
In particular, and without limitation to the foregoing, we express this opinion in respect of any Cash transfer orders submitted by any participant in the System. In particular, we are of the opinion that the provisions of [list of sections] of the Rules establishing the enforceability and irrevocability of Cash transfer orders will be valid and enforceable and that a Cash transfer orders submitted by any participant and processed pursuant to [list of sections] of the Rules may not be set aside in any Insolvency Proceedings or Proceedings as a preference, voidable transaction or otherwise under the laws of [jurisdiction].

3.5.   

Attachment

If a creditor of the Participant seeks an attachment order (including any freezing order, order for seizure or any other public or private law procedure that is intended to protect the public interest or the rights of the Participant’s creditors) — hereinafter referred to as an ‘Attachment’ — under the laws of [jurisdiction] from a court or governmental, judicial or public authority that is competent in [jurisdiction], we are of the opinion that [insert the analysis and discussion].

3.6.   

Collateral [if applicable]

3.6.a.   

Assignment of rights or deposit of assets for collateral purposes, pledge and/or repo

Assignments for collateral purposes will be valid and enforceable under the laws of [jurisdiction]. Specifically, the creation and enforcement of a pledge or repo under the [insert reference to the relevant arrangement with the CB] will be valid and enforceable under the laws of [jurisdiction].

3.6.b.   

Priority of assignees’, pledgees’ or repo purchasers’ interest over that of other claimants

In the event of Insolvency Proceedings or Proceedings in respect of the Participant, the rights or assets assigned for collateral purposes, or pledged by the Participant in favour of the [insert reference to CB] or other participants in the System, will rank in priority of payment above the claims of all other creditors of the Participant and will not be subject to priority or preferential creditors.

3.6.c.   

Enforcing title to security

Even in the event of Insolvency Proceedings or Proceedings in respect of the Participant, other participants in the System and the [insert name of CB] as [assignees, pledgees or repo purchasers as applicable] will still be free to enforce and collect the Participant’s rights or assets through the action of the [insert name of CB] pursuant to the Rules.

3.6.d.   

Form and registration requirements

There are no form requirements for the assignment for collateral purposes of, or the creation and enforcement of a pledge or repo over the Participant’s rights or assets and it is not necessary for the [assignment for collateral purposes, pledge or repo, as applicable], or any particulars of such [assignment, pledge or repo, as applicable,] to be registered or filed with any court or governmental, judicial or public authority that is competent in [jurisdiction].

3.7.   

Branches [to the extent applicable]

3.7.a.   

Opinion applies to action through branches

Each of the statements and opinions presented above with regard to the Participant applies with equal accuracy and validity under the laws of [jurisdiction] in situations where the Participant acts through its one or more of its branches established outside [jurisdiction].

3.7.b.   

Conformity with law

Neither the execution and performance of the rights and obligations under the System Documents nor the submission, transmission or receipt of Cash transfer orders by a branch of the Participant will in any respect breach the laws of [jurisdiction].

3.7.c.   

Required authorisations

Neither the execution and performance of the rights and obligations under the System Documents nor the submission, transmission or receipt of Cash transfer orders by a branch of a Participant will require any additional authorisations, approvals, consents, filings, registrations, notarisations or other certifications of or with any court or governmental, judicial or public authority that is competent in [jurisdiction].
This Opinion is stated as of its date and is addressed solely to the [insert name of CB] and the [Participant]. No other persons may rely on this Opinion, and the contents of this Opinion may not be disclosed to persons other than its intended recipients and their legal counsel without our prior written consent, with the exception of the European Central Bank and the national central banks of the European System of Central Banks [and [the national central bank/relevant regulatory authorities] of [jurisdiction]].
Yours faithfully,
[signature]

APPENDIX IV

BUSINESS CONTINUITY AND CONTINGENCY PROCEDURES

1.   GENERAL PROVISIONS

This Appendix sets out the arrangements between the [insert name of CB] and participants, if TARGET or one or more of the NSPs fail or are affected by an abnormal external event, or if the failure affects any participant.
All references to specific times in this Appendix are to the local time at the seat of the ECB.
Provisions set out in this section 1 shall apply to MCAs, RTGS DCAs and their sub-accounts, RTGS AS technical accounts, T2S DCAs, TIPS DCAs and TIPS AS technical accounts.

1.1.   

Measures of business continuity and contingency processing

(a) In the event that an abnormal external event occurs and/or there is a failure of TARGET and/or there is a failure of one or more NSPs which affects the normal operation of TARGET, the [insert name of CB] shall be entitled to adopt business continuity and contingency processing measures.
(b) The following main business continuity and contingency processing measures shall be available in TARGET:
(i) relocating the operation of TARGET to an alternative site;
(ii) changing the TARGET operating schedule.
(c) In relation to business continuity and contingency processing measures, the [insert name of CB] shall have full discretion regarding whether and which measures are adopted.

1.2.   

Incident communication

If an event described under paragraph 1.1(a) occurs, this shall be communicated to participants via the ECB’s website, if available, through the GUI(s) and, if applicable via domestic communication channels. In particular, communications to participants shall include the following information:
(i) a description of the event and its impact on TARGET;
(ii) the time at which resolution of the event is expected (if known);
(iii) information on the measures already taken (if any);
(iv) the advice to participants (if any);
(v) the timestamp of the communication and indication of when an update will be provided.

1.3.   

Change of operating hours

(a) When changing the TARGET operating schedule as provided for in Part I, Article 19(2) of these Conditions, the [insert name of CB] may delay the cut off times of TARGET for a given business day or delay the start of the following business day, or change the timing of any other event listed in Appendix V.
(b) The cut off times of TARGET for a given business day may be delayed if a TARGET failure has occurred during that day but has been resolved before 18:00. Such a closing time delay should not normally exceed two hours and shall be announced as early as possible to participants.
(c) Once a delay of the cut off times of TARGET is announced, it may be further delayed but may not be withdrawn.

1.4.   

Other provisions

(a) In the event of a failure of the [insert name of CB], some or all of its technical functions in relation to TARGET-[insert CB/country reference] may be performed by other Eurosystem CBs or by the Level 3 NCBs on its behalf.
(b) The [insert name of CB] may require that the participants participate in regular or ad hoc testing of business continuity and contingency processing measures, training or any other preventative arrangements, as deemed necessary by the [insert name of CB]. Any costs incurred by the participants as a result of such testing or other arrangements shall be borne solely by the participants.

2.   BUSINESS CONTINUITY AND CONTINGENCY PROCEDURES (RTGS DCA AND RTGS AS SETTLEMENT PROCEDURES)

In addition to the provisions set out in section 1, the provisions set out in this section 2 shall apply specifically to RTGS DCA holders and AS that make use of the RTGS AS settlement procedures.

2.1.   

Relocation of the operation of TARGET to an alternative site

(a) The relocation of the operation of TARGET to an alternative site, as referred to in paragraph 1.1(b)(i), may be to a place within the same region or in another region.
(b) In the event that the operation of TARGET is relocated to another region, the participants shall: (i) refrain from sending new cash transfer orders to TARGET; (ii) at the request of [insert name of CB] perform a reconciliation; (iii) resubmit any cash transfer orders identified as missing; and (iv) provide the [insert name of CB] with all relevant information in this respect.
(c) The [insert name of CB] may take any further actions including debiting and crediting participants’ accounts in order to return those participants’ accounts to their status prior to the relocation.

2.2.   

Change of operating hours

(a) If [insert name of CB] delays the closing of TARGET as provided for in paragraph 1.3 before 16:50, the minimum period of one hour between the cut-off time for customer and interbank payment orders should normally remain in place.
(b) AS shall have established means to cope with cases where the reopening time is delayed due to a TARGET failure on the previous day.

2.3.   

Contingency processing

(a) If it deems it necessary to do so, the [insert name of CB] shall initiate the contingency processing of cash transfer orders using the Contingency Solution of TARGET or other means. In such cases, contingency processing shall be provided on a best efforts basis. The [insert name of CB] shall inform its participants of the start of contingency processing via any available means of communication.
(b) In contingency processing using the Contingency Solution of TARGET, cash transfer orders shall be submitted by the RTGS DCA holders and authorised by the [insert name of CB]. [insert name of CB] may, exceptionally, also manually input cash transfer orders on behalf of participants. In addition, the AS may submit files containing payment instructions under RTGS AS settlement procedure A, which the AS authorises the [insert name of CB] to upload into the Contingency Solution.
(c) The following cash transfer orders shall be considered as ‘very critical’ and the [insert name of CB] shall use best efforts to process them in a contingency without undue delay:
(i) payments related to the settlement of CLS Bank International operations processed on CLS Settlement;
(ii) central counterparty margin calls.
(d) Cash transfer orders other than those listed in point (c) and which are required to avoid systemic risk shall be considered as ‘critical’ and the [insert name of CB] may decide to initiate contingency processing in relation to them. Critical cash transfer orders shall include but are not limited to:
(i) cash transfer orders related to the settlement of other systemically important payment systems as defined in Regulation (EU) No 795/2014 (ECB/2014/28);
(ii) liquidity transfer orders to T2S DCAs or TIPS DCAs;
(iii) liquidity transfer orders that are indispensable to the execution of very critical cash transfer orders as set out in point (c) or to other critical cash transfer orders.
(e) Cash transfer orders that have been submitted to TARGET-[insert CB/country reference] before the activation of contingency processing, but are queued, may also undergo contingency processing. In such cases the [insert name of CB] shall endeavour to avoid the double processing of cash transfer orders, but the participants shall bear the risk of such double processing if it occurred.
(f) For contingency processing using the Contingency Solution of TARGET, participants shall provide eligible assets as collateral. During contingency processing, incoming cash transfer orders may be used to fund outgoing cash transfer orders.

2.4.   

Failures linked to participants

(a) In the event that a participant has an issue or problem that prevents it from sending cash transfer orders to TARGET, it shall resolve the issue or problem using its own means. In particular, a participant may use any in-house solutions at its disposal, the GUI functionality to process liquidity transfers and payment orders or use the back-up functionality via the GUI.
(b) If the resolution means and/or solutions or functionalities used by the participant as referred to in paragraph (a) are exhausted or if they are insufficient, the participant may then request support from the [insert name of CB] and the [insert name of CB] shall provide such support on a best efforts basis. The [insert name of CB] shall decide what support it offers to the participant.
(c) [Insert if applicable, further detailed contingency measures with respect to AS shall be described in additional arrangements between the [insert name of CB] and the relevant AS.]

3.   BUSINESS CONTINUITY AND CONTINGENCY PROCEDURES (MCA)

In addition to the provisions set out in section 1, the provisions of this section 3 shall apply specifically to MCA holders.

3.1.   

Relocation of the operation of TARGET to an alternative site

(a) the relocation of the operation of TARGET to an alternative site, as referred to in paragraph 1.1(b)(i), may be to a place within the same region or in another region.
(b) In the event that the operation of TARGET is relocated to another region, the participants shall: (i) refrain from sending new cash transfer orders to TARGET; (ii) at the request of [insert name of CB] perform a reconciliation, (iii) resubmit any cash transfer orders identified as missing; and (iv) provide the [insert name of CB] with all relevant information in this respect.
(c) The [insert name of CB] may take any further actions including debiting and crediting participants’ accounts in order to return those participants’ accounts to their status prior to the relocation.

3.2.   

Contingency processing

(a) If it deems it necessary to do so, the [insert name of CB] shall initiate the contingency processing of cash transfer orders using the Contingency Solution of TARGET or other means. In such cases, contingency processing shall be provided on a best efforts basis. The [insert name of CB] shall inform its participants of the start of contingency processing via any available means of communication.
(b) In contingency processing using the Contingency Solution of TARGET, cash transfer orders shall be submitted by the MCA holders and authorised by the [insert name of CB]. [insert name of CB] may, exceptionally, also manually input cash transfer orders on behalf of participants.
(c) Cash transfer orders required to avoid systemic risk shall be considered as ‘critical’ and the [insert name of CB] may decide to initiate contingency processing in relation to them.
(d) Cash transfer orders that have been submitted to TARGET-[insert CB/country reference] before the activation of contingency processing, but are queued, may also undergo contingency processing. In such cases the [insert name of CB] shall endeavour to avoid the double processing of cash transfer orders, but the participants shall bear the risk of such double processing if it occurred.
(e) For contingency processing using the Contingency Solution of TARGET, participants shall provide eligible assets as collateral. During contingency processing, incoming cash transfer orders may be used to fund outgoing cash transfer orders.

3.3.   

Failures linked to participants

(a) In the event that a participant has an issue or problem that prevents it from sending cash transfer orders in TARGET, it shall resolve the issue or problem using its own means. In particular, a participant may use any in-house solutions or the GUI functionality to process liquidity transfers orders.
(b) If the resolution means and/or solutions or functionalities used by the participant as referred to in paragraph (a) are exhausted or if they are insufficient, the participant may request support from the [insert name of CB] and the [insert name of CB] shall provide such support on a best efforts basis. The [insert name of CB] shall decide what support it offers to the participant.

4.   BUSINESS CONTINUITY AND CONTINGENCY PROCEDURES (T2S DCA)

In addition to the provisions set out in section 1, the provisions set out in this section 4 shall apply specifically to T2S DCA holders.

4.1.   

Relocation of the operation of TARGET to an alternative site

(a) The relocation of the operation of TARGET to an alternative site, as set out under paragraph 1.1(b)(i), may be to a place within the same region or in another region (where available).
(b) In the event that the operation of TARGET is relocated to another region, the participants shall (i) refrain from sending new cash transfer orders to TARGET; and (ii) at the request of [insert name of CB] perform a reconciliation, (iii) resubmit any instructions identified as missing and (iv) provide the [insert name of CB] with all relevant information in this respect.
(c) The [insert name of CB] shall be allowed to take any further actions including debit and credit on participants’ accounts in order to bring participants’ account balances to the status they had prior to the relocation.

4.2.   

Failures linked to participants

(a) In the event that a T2S DCA holder has an issue or problem that prevents it from settling cash transfer orders in TARGET-[insert name of CB/country reference], it shall resolve the issue or problem using its own means.
(b) If the resolution means referred to in paragraph (a) are exhausted or if they are insufficient, the participant may request support from the [insert name of CB], and the [insert name of CB] shall provide such support on a best efforts basis. The [insert name of CB] shall decide what support it offers to the participant.

APPENDIX V

TARGET OPERATING SCHEDULE

1.   
The value date for transactions settled in TARGET is always the value date on which the system operates.
2.   
All days except Saturday, Sunday, New Year’s Day, Good Friday (1), Easter Monday (2), 1 May, Christmas Day, and 26 December are TARGET business days and thus may be value dates for the purpose of settlement in TARGET.
3.   
TIPS DCAs and TIPS AS technical accounts are operated on all days. All other types of accounts are operated on all days except for Saturday, Sunday, New Year’s Day, Good Friday (3), Easter Monday (4), 1 May, Christmas Day, and 26 December.
4.   
A business day is opened during the evening of the previous business day.
5.   
The reference time for the system is the local time at the seat of the ECB.
6.   
The different phases of the TARGET business day and the significant operational events relevant to MCAs, RTGS DCAs (5), T2S DCAs and TIPS DCAs (6) are shown in the following table:

HH:MM

MCAs

RTGS DCAs(7)

T2S DCAs

TIPS DCAs(8)

18:45 (D-1)

Start of business day:

Change of value date

Start of business day:

Change of value date

Start of business day:

Change of value date

Preparation of the night-time settlement

Processing of instant payment orders and liquidity transfer orders to/from TIPS AS technical accounts.

No liquidity transfers between TIPS DCAs and other accounts

19:00 (D-1)

Settlement of CBOs

Reimbursement of marginal lending

Refunding of overnight deposits

Processing of automated and rule-based liquidity transfers orders

 

Deadline for acceptance of CMS data feeds

Preparation of the night-time settlement

 

19:30 (D-1)

Settlement of CBOs Processing of standing liquidity transfer orders

Processing of immediate liquidity transfer orders

Settlement of AS transfer orders

Processing of standing liquidity transfer orders

Processing of automated, rule-based and immediate liquidity transfer orders

 

Processing of instant payment orders and liquidity transfer orders from/to MCAs and RTGS DCAs

20:00 (D-1)

 

Night-time settlement cycles

Processing of liquidity transfer orders from/to T2S DCAs

02:30

(calendar day following D-1)

Non-optional maintenance window on

business days after closing days including every business day Monday

Optional maintenance window (if needed) from 03:00–05:00 on remaining days

Non-optional maintenance window on

business days after closing days including every business day Monday

Optional maintenance window (if needed) from 03:00–05:00 on remaining days

Non-optional maintenance window on

business days after closing days including every business day Monday

Optional maintenance window (if needed) from 03:00–05:00 on remaining days(9)

Processing of instant payment orders and liquidity transfer orders to/from TIPS AS technical accounts.

No liquidity transfer orders between TIPS DCAs and other accounts

Re-opening time* (D)

Settlement of CBOs

Processing of automated,

rule-based and immediate

liquidity transfer orders

Settlement of AS transfer orders

Processing of automated, rule-based and immediate liquidity transfer orders.

Processing the customer and interbank payment orders

Night-time settlement cycles

Processing of instant payment orders and liquidity transfer orders to/from TIPS AS technical accounts and liquidity transfer orders between TIPS DCAs and other accounts.

05:00 (D)

 

Day trade/Real-time settlement:

Real-time settlement preparation

Partial settlement windows(10)

 

16:00 (D)

 

Cut-off for DvP orders

 

16:30 (D)

 

Automatic auto-collateralisation reimbursement, followed by the optional cash sweep

 

17:00 (D)

Cut-off for customer payment orders

 

 

17:40 (D)

 

Cut-off for bilaterally agreed treasury management operations (BATM) and CBO cut-off

 

17:45 (D)

Cut-off for liquidity transfer orders to T2S-DCAs

Cut-off for inbound liquidity transfer orders

Blocking of liquidity transfer orders from TIPS DCAs to T2S DCAs. No liquidity transfer orders between T2S DCAs and TIPS DCAs are processed during this period

18:00 (D)

Cut-off for:

liquidity transfer orders

CBOs, except standing facilities

credit line modifications

Cut-off for:

interbank payment orders and

liquidity transfer orders

AS transfer orders

FOP cut-off

End of T2S settlement processing

Recycling and purging

End of day reporting and statements

Processing of instant payment orders and liquidity transfer orders to/from TIPS AS technical accounts.

Blocking of liquidity transfer orders from TIPS DCAs to MCA/RTGS and T2S DCAs. No liquidity transfer orders between TIPS DCAs and other accounts are processed during this period.

Shortly after 18:00:

Change of business day (after receiving the camt.019 message from MCA/RTGS)

Snapshot of TIPS DCAs balances and end-of-day reporting

18:15 (D)

Cut-off for the use of standing facilities

 

 

 

18:40 (D)

Cut-off for use of marginal lending (NCBs only)

End-of-day processing

 

 

 

The operating hours may be changed in the event that business continuity measures are adopted in accordance with Appendix IV. On the last day of the Eurosystem reserve maintenance period, the cut-off times 18:15, 18:40, 18:45, 19:00 and 19:30 for MCAs and RTGS DCAs (as well as RTGS AS technical accounts and sub-accounts and AS guarantee fund accounts) shall occur 15 minutes later.

List of abbreviations and notes to this table:

*
Re-opening times: may vary according to the situation. The information is provided by the Operator.
(D-1)
:
previous business day
(D)
:
calendar day = business day = value date
CMS
:
Collateral Management System
DvP orders
:
Delivery versus Payment orders.
(1)  According to the calendar applicable at the seat of the ECB.
(2)  According to the calendar applicable at the seat of the ECB.
(3)  According to the calendar applicable at the seat of the ECB.
(4)  According to the calendar applicable at the seat of the ECB.
(5)  Also applies to RTGS AS technical accounts, sub-accounts and AS guarantee fund accounts.
(6)  Also applies to TIPS AS technical accounts.
(7)  Also applies to RTGS AS technical accounts, sub-accounts and AS guarantee fund accounts.
(8)  Also applies to TIPS AS technical accounts.
(9)  For T2S DCAs: for the purpose of the maintenance window, 1 May shall be considered as a business day.
(10)  Partial settlement windows take place at 08:00, 10:00, 12:00, 14:00 and 15:30 (or 30 minutes before the beginning of the DvP cut-off time, whichever comes first).

APPENDIX VI

FEE SCHEDULE

1.   GENERAL

1.
The following services are not included in the services offered by [insert name of CB] and shall be charged by the relevant service providers in accordance with their terms and conditions:
(a) services offered by NSPs;
(b) non-cash related T2S services.
2.
A participant that wishes to change its choice of pricing scheme shall communicate this to [insert name of CB] by the twentieth calendar day of the month so that it can be taken into account for the following month.

2.   FEES FOR MCA HOLDERS

1.
MCAs and transactions settled on them shall not incur fees.
2.
[insert if applicable: Fee(s) for co-managed MCAs]

3.   FEES FOR RTGS DCA HOLDERS

1.
RTGS DCA holders shall choose one of the following two pricing options:
(a) a monthly fee, plus a fixed transaction fee per payment order (debit entry).

Monthly fee

 

EUR 150

Transaction fee per payment order

 

EUR 0,80

(b) a monthly fee, plus a transaction fee based on the volume of payment orders (debit entry) and calculated on a cumulative basis as set out in the following table. For participants in a billing group the monthly volume of payment orders (debit entry) for all participants in that group shall be aggregated.

Monthly fee

 

EUR 1 875

Monthly volume of payment orders

Band

From

To

Transaction fee per payment order (EUR)

1.

1

10 000

0,60

2.

10 001

25 000

0,50

3.

25 001

50 000

0,40

4.

50 001

75 000

0,20

5.

75 001

100 000

0,125

6.

100 001

150 000

0,08

7.

Above 150 000

 

0,05

2.
Liquidity transfer orders from RTGS DCAs to sub-accounts, to MCAs, to overnight deposit accounts or to RTGS DCAs held by the same participant or by participants within the same banking group shall be free of charge.
3.
Liquidity transfer orders from RTGS DCAs to MCAs or to RTGS DCAs held by participants not belonging to the same banking group shall incur a charge of EUR 0.80 per transaction (debit entry).
4.
Liquidity transfer orders from RTGS DCAs to T2S DCAs or to TIPS DCAs shall be free of charge.
5.
Cash transfer orders from an RTGS DCA to an AS account (1) shall not be charged to the RTGS DCA holder.
6.
The following fees shall apply to RTGS DCA holders:

Service

Monthly fee (EUR)

Addressable BIC holder (correspondents (2))

20

Unpublished BIC

30

Multi-addressee access (based on BIC 8)

80

4.   FEES FOR AS USING RTGS AS SETTLEMENT PROCEDURES

Fees are charged per ancillary system regardless of the number and type of accounts. AS Operators operating more than one system will be charged for each system.
1.
AS using RTGS AS settlement procedures or having been granted an exception allowing them to settle on an RTGS DCA shall choose one of the following two pricing options:
(a) a monthly fee, plus a fixed transaction fee per cash transfer order.

Monthly fee

 

EUR 300

Transaction fee per cash transfer order

 

EUR 1,60

(b) a monthly fee, plus a transaction fee based on the volume of cash transfer orders and calculated on a cumulative basis as set out in the following table.

Monthly fee

 

EUR 3 750

Monthly volume of cash transfer orders

Band

From

To

Transaction fee per cash transfer order (EUR)

1.

1

5 000

1,20

2.

5 001

12 500

1,00

3.

12 501

25 000

0,80

4.

25 001

50 000

0,40

5.

Above 50 000

 

0,25

Cash transfer orders between an RTGS DCA and an AS account (3) shall be charged to the respective AS according to the pricing option that the AS has opted for.
2.
In addition to the fees set out above, each AS shall be subject to two fixed fees as set out in the following table.

A.

Fixed fee I

Monthly fee per AS

EUR 2 000

B.

Fixed fee II (based on gross underlying value (4))

Size (EUR millions/day)

Annual fee (EUR)

Monthly fee (EUR)

from 0 to 999,99

10 000

833

from 1 000 to 2 499,99

20 000

1 667

from 2 500 to 4 999,99

40 000

3 334

from 5 000 to 9 999,99

60 000

5 000

from 10 000 to 49 999,99

80 000

6 666

from 50 000 to 499 999,99

100 000

8 333

500 000 and above

200 000

16 667

5.   FEES FOR T2S DCA HOLDERS

1.
The following fees shall be charged for the operation of T2S DCAs:

Item

Applied rule

Fee per item (EUR)

Liquidity transfer orders between T2S DCAs

Per transfer for the debited T2S DCA.

0,141

Intra-balance movements

Any successfully executed intra-balance movement (i.e. blocking, unblocking, reservation of liquidity, etc.).

0,094

A2A queries

Per business item within each A2A query generated

0,007

A2A reports

Per business item within each generated A2A report including A2A reports as a result of U2A queries.

0,004

Messages bundled into a file

Per message in each file containing bundled messages

0,004

Transmission

Each transmission per T2S party (both inbound and outbound) will be counted and charged for (except for technical acknowledgement messages).

0,012

U2A queries

Any executed query search function

0,100

Fee per T2S DCA

Any T2S DCA existing at any time during the monthly billing period

Currently free of charge, to be reviewed at regular intervals.

0,000

Auto-collateralisation

Issue or return of auto-collateralisation

0,000

2.
Liquidity transfer orders from a T2S DCA to an RTGS DCA, a TIPS DCA or an MCA shall be free of charge.

6.   FEES FOR TIPS DCA HOLDERS

1.
Fees for the operation of TIPS DCAs shall be charged to the party indicated as shown in the following table:

Item

Rule applied

Fee per item (EUR)

Settled instant payment order

Party to be charged: the owner of the TIPS DCA to be debited

0,002

Unsettled instant payment order

Party to be charged: the owner of the TIPS DCA to be debited

0,002

Settled positive recall answer

Party to be charged: the owner of the TIPS DCA to be credited

0,002

Unsettled positive recall answer

Party to be charged: the owner of the TIPS DCA to be credited

0,002

2.
Liquidity transfer orders from TIPS DCAs to: MCAs; RTGS DCAs; sub-accounts; overnight deposit accounts; TIPS AS technical accounts; and T2S DCAs shall be free of charge.

7.   FEES FOR AS USING TIPS AS SETTLEMENT PROCEDURE

1.
Fees for the use by an AS of the TIPS AS settlement procedure shall be charged to the party indicated as shown in the following table:

Item

Rule applied

Fee per item (EUR)

Settled instant payment order

Party to be charged: the owner of the TIPS AS technical account to be debited

0,002

Unsettled instant payment order

Party to be charged: the owner of the TIPS AS technical account to be debited

0,002

Settled positive recall answer

Party to be charged: the owner of the TIPS AS technical account to be credited

0,002

Unsettled positive recall answer

Party to be charged: the owner of the TIPS AS technical account to be credited

0,002

2.
Liquidity transfer orders from TIPS AS technical accounts to TIPS DCAs shall be free of charge
3.
In addition to the fees set out above, each AS shall be subject to a monthly fee based on the gross underlying volume of instant payments, near instant payments and positive recall answers settled in the AS’s own platform and enabled by the pre-funded positions on the TIPS AS technical account. The fee shall be EUR 0,0005 per settled instant payment, near instant payment or settled positive recall answer. For each month, each AS shall report the gross underlying volume of its settled instant payments, near instant payments and settled positive recall answers rounded down to the nearest ten thousand, at the latest by the third business day of the following month. The reported gross underlying volume shall be applied by the [insert name of CB] to calculate the fee for the following month.
(1)  Regardless of whether it is a RTGS DCA, an RTGS AS technical account or an AS guarantee funds account.
(2)  Addressable BIC holders are available for different participant types: Addressable BIC holder – Correspondent; Addressable BIC holder – Branch of Participant; and Addressable BIC holder – Branch of correspondent. Only the Addressable BIC holder – Correspondent participation type shall incur the fee. The fee shall be charged for each different BIC 11.
(3)  Regardless of whether it is a RTGS DCA, an RTGS AS technical account or an AS guarantee funds Account.
(4)  The ‘gross underlying value’ is the total amount of gross monetary obligations that are discharged via an AS after settlement has taken place on an RTGS DCA or sub-account. For CCPs, the gross underlying value is the total notional value of future contracts or the mark-to-market value of the future contracts, at values to be settled when futures contracts expire and commissions are applied.

APPENDIX VII

REQUIREMENTS REGARDING INFORMATION SECURITY MANAGEMENT AND BUSINESS CONTINUITY MANAGEMENT

MCA HOLDERS, T2S DCA HOLDERS AND TIPS DCA HOLDERS

These requirements regarding information security management or business continuity management shall not apply to MCA holders, T2S DCA holders and TIPS DCA holders.

RTGS DCA HOLDERS AND AS

The requirements set out in section 1 of this Appendix VII (information security management) shall apply to all RTGS DCA holders and AS, except where an RTGS DCA holder or an AS demonstrates that a specific requirement is not applicable to it. In establishing the scope of application of the requirements within its infrastructure, the participant should identify the elements that are part of the Payment Transaction Chain (PTC). Specifically, the PTC starts at a Point of Entry (PoE), i.e. a system involved in the creation of transactions (e.g. workstations, front-office and back-office applications, middleware), and ends at the system responsible to send the message to the NSP.
The requirements set out in section 2 of this Appendix VII (business continuity management) shall apply to RTGS DCA holders and AS designated by the Eurosystem as being critical for the smooth functioning of the TARGET system on the basis of criteria periodically updated and published on the ECB’s website.

1.   

Information security management

Requirement 1.1: Information security policy

The management shall set a clear policy direction in line with business objectives and demonstrate support for and commitment to information security through the issuance, approval and maintenance of an information security policy aiming at managing information security and cyber resilience across the organisation in terms of identification, assessment and treatment of information security and cyber resilience risks. The policy should contain at least the following sections: objectives, scope (including domains such as organisation, human resources, asset management etc.), principles and allocation of responsibilities.

Requirement 1.2: Internal organisation

An information security framework shall be established to implement the information security policy within the organisation. The management shall coordinate and review the establishment of the information security framework to ensure the implementation of the information security policy (as per Requirement 1.1) across the organisation, including the allocation of sufficient resources and assignment of security responsibilities for this purpose.

Requirement 1.3: External parties

The security of the organisation’s information and information processing facilities should not be reduced by the introduction of, and/or the dependence on, an external party/parties or products/services provided by them. Any access to the organisation’s information processing facilities by external parties shall be controlled. When external parties or products/services of external parties are required to access the organisation’s information processing facilities, a risk assessment shall be carried out to determine the security implications and control requirements. Controls shall be agreed and defined in an agreement with each relevant external party.

Requirement 1.4: Asset management

All information assets, the business processes and the underlying information systems, such as operating systems, infrastructures, business applications, off-the-shelf products, services and user-developed applications, in the scope of the Payment Transaction Chain shall be accounted for and have a nominated owner. The responsibility for the maintenance and the operation of appropriate controls in the business processes and the related IT components to safeguard the information assets shall be assigned. Note: the owner can delegate the implementation of specific controls as appropriate, but remains accountable for the proper protection of the assets.

Requirement 1.5: Information assets classification

Information assets shall be classified in terms of their criticality to the smooth delivery of the service by the participant. The classification shall indicate the need, priorities and degree of protection required when handling the information asset in the relevant business processes and shall also take into consideration the underlying IT components. An information asset classification scheme approved by the management shall be used to define an appropriate set of protection controls throughout the information asset lifecycle (including removal and destruction of information assets) and to communicate the need for specific handling measures.

Requirement 1.6: Human resources security

Security responsibilities shall be addressed prior to employment in adequate job descriptions and in terms and conditions of employment. All candidates for employment, contractors and third-party users shall be adequately screened, especially for sensitive jobs. Employees, contractors and third-party users of information processing facilities shall sign an agreement on their security roles and responsibilities. An adequate level of awareness shall be ensured among all employees, contractors and third-party users, and education and training in security procedures and the correct use of information processing facilities shall be provided to them to minimise possible security risks. A formal disciplinary process for handling security breaches shall be established for employees. Responsibilities shall be in place to ensure that an employee’s, contractor’s or third-party user’s exit from or transfer within the organisation is managed, and that the return of all equipment and the removal of all access rights are completed.

Requirement 1.7: Physical and environmental security

Critical or sensitive information processing facilities shall be housed in secure areas, protected by defined security perimeters, with appropriate security barriers and entry controls. They shall be physically protected from unauthorised access, damage and interference. Access shall be granted only to individuals who fall within the scope of Requirement 1.6. Procedures and standards shall be established to protect physical media containing information assets when in transit.
Equipment shall be protected from physical and environmental threats. Protection of equipment (including equipment used off-site) and against the removal of property is necessary to reduce the risk of unauthorised access to information and to guard against loss or damage of equipment or information. Special measures may be required to protect against physical threats and to safeguard supporting facilities such as the electrical supply and cabling infrastructure.

Requirement 1.8: Operations management

Responsibilities and procedures shall be established for the management and operation of information processing facilities covering all the underlying systems in the Payment Transaction Chain end-to-end.
As regards operating procedures, including technical administration of IT systems, segregation of duties shall be implemented, where appropriate, to reduce the risk of negligent or deliberate system misuse. Where segregation of duties cannot be implemented due to documented objective reasons, compensatory controls shall be implemented following a formal risk analysis. Controls shall be established to prevent and detect the introduction of malicious code for systems in the Payment Transaction Chain. Controls shall be also established (including user awareness) to prevent, detect and remove malicious code. Mobile code shall be used only from trusted sources (e.g. signed Microsoft COM components and Java Applets). The configuration of the browser (e.g. the use of extensions and plugins) shall be strictly controlled.
Data backup and recovery policies shall be implemented by the management; those recovery policies shall include a plan of the restoration process which is tested at regular intervals at least annually.
Systems that are critical for the security of payments shall be monitored and events relevant to information security shall be recorded. Operator logs shall be used to ensure that information system problems are identified. Operator logs shall be regularly reviewed on a sample basis, based on the criticality of the operations. System monitoring shall be used to check the effectiveness of controls which are identified as critical for the security of payments and to verify conformity to an access policy model.
Exchanges of information between organisations shall be based on a formal exchange policy, carried out in line with exchange agreements among the involved parties and shall be compliant with any relevant legislation. Third party software components employed in the exchange of information with TARGET (e.g. software received from a Service Bureau) must be used under a formal agreement with the third party.

Requirement 1.9: Access control

Access to information assets shall be justified on the basis of business requirements (need-to-know (1)) and according to the established framework of corporate policies (including the information security policy). Clear access control rules shall be defined based on the principle of least privilege (2) to reflect closely the needs of the corresponding business and IT processes. Where relevant, (e.g. for backup management) logical access control should be consistent with physical access control unless there are adequate compensatory controls in place (e.g. encryption, personal data anonymisation).
Formal and documented procedures shall be in place to control the allocation of access rights to information systems and services that fall within the scope of the Payment Transaction Chain. The procedures shall cover all stages in the lifecycle of user access, from the initial registration of new users to the final deregistration of users that no longer require access.
Special attention shall be given, where appropriate, to the allocation of access rights of such criticality that the abuse of those access rights could lead to a severe adverse impact on the operations of the participant (e.g. access rights allowing system administration, override of system controls, direct access to business data).
Appropriate controls shall be put in place to identify, authenticate and authorise users at specific points in the organisation’s network, e.g. for local and remote access to systems in the Payment Transaction Chain. Personal accounts shall not be shared in order to ensure accountability.
For passwords, rules shall be established and enforced by specific controls to ensure that passwords cannot be easily guessed, e.g. complexity rules and limited-time validity. A safe password recovery and/or reset protocol shall be established.
A policy shall be developed and implemented on the use of cryptographic controls to protect the confidentiality, authenticity and integrity of information. A key management policy shall be established to support the use of cryptographic controls.
There shall be policy for viewing confidential information on screen or in print (e.g. a clear screen, a clear desk policy) to reduce the risk of unauthorised access.
When working remotely, the risks of working in an unprotected environment shall be considered and appropriate technical and organisational controls shall be applied.

Requirement 1.10: Information systems acquisition, development and maintenance

Security requirements shall be identified and agreed prior to the development and/or implementation of information systems.
Appropriate controls shall be built into applications, including user-developed applications, to ensure correct processing. These controls shall include the validation of input data, internal processing and output data. Additional controls may be required for systems that process, or have an impact on, sensitive, valuable or critical information. Such controls shall be determined on the basis of security requirements and risk assessment according to the established policies (e.g. information security policy, cryptographic control policy).
The operational requirements of new systems shall be established, documented and tested prior to their acceptance and use. As regards network security, appropriate controls, including segmentation and secure management, should be implemented based on the criticality of data flows and the level of risk of the network zones in the organisation. There shall be specific controls to protect sensitive information passing over public networks.
Access to system files and program source code shall be controlled and IT projects and support activities conducted in a secure manner. Care shall be taken to avoid exposure of sensitive data in test environments. Project and support environments shall be strictly controlled. Deployment of changes in production shall be strictly controlled. A risk assessment of the major changes to be deployed in production shall be conducted.
Regular security testing activities of systems in production shall also be conducted according to a predefined plan based on the outcome of a risk-assessment, and security testing shall include, at least, vulnerability assessments. All of the shortcomings highlighted during the security testing activities shall be assessed and action plans to close any identified gap shall be prepared and followed-up in a timely fashion.

Requirement 1.11: Information security in supplier

 (3)

relationships

To ensure protection of the participant’s internal information systems that are accessible by suppliers, information security requirements for mitigating the risks associated with supplier’s access shall be documented and formally agreed upon with the supplier.

Requirement 1.12: Management of information security incidents and improvements

To ensure a consistent and effective approach to the management of information security incidents, including communication on security events and weaknesses, roles, responsibilities and procedures, at business and technical level, shall be established and tested to ensure a quick, effective and orderly and safely recover from information security incidents including scenarios related to a cyber-related cause (e.g. a fraud pursued by an external attacker or by an insider). Personnel involved in these procedures shall be adequately trained.

Requirement 1.13: Technical compliance review

A participant’s internal information systems (e.g. back office systems, internal networks and external network connectivity) shall be regularly assessed for compliance with the organisation’s established framework of policies (e.g. information security policy, cryptographic control policy).

Requirement 1.14: Virtualisation

Guest virtual machines shall comply with all the security controls that are set for physical hardware and systems (e.g. hardening, logging). Controls relating to hypervisors must include: hardening of the hypervisor and the hosting operating system, regular patching, strict separation of different environments (e.g. production and development). Centralised management, logging and monitoring as well as managing of access rights, in particular for high privileged accounts, shall be implemented based on a risk assessment. Guest virtual machines managed by the same hypervisor shall have a similar risk profile.

Requirement 1.15: Cloud computing

The usage of public and/or hybrid cloud solutions in the Payment Transaction Chain must be based on a formal risk assessment, taking into account the technical controls and the contractual clauses related to the cloud solution.
If hybrid cloud solutions are used, it is understood that the criticality level of the overall system is the highest one of the connected systems. All on-premises components of the hybrid solutions must be segregated from the other on-premises systems.

2.   

Business Continuity Management

The following requirements relate to business continuity management. Each TARGET participant designated by the Eurosystem as being critical for the smooth functioning of the TARGET system shall have a business continuity strategy in place that complies with the following requirements.

Requirement 2.1:

Business continuity plans shall be developed and procedures for maintaining them are in place.

Requirement 2.2:

An alternate operational site shall be available.

Requirement 2.3:

The risk profile of the alternate site shall be different from that of the primary site, in order to avoid that both sites are affected by the same event at the same time. For example, the alternate site shall be on a different power grid and central telecommunication circuit from those of the primary business location.

Requirement 2.4:

In the event of a major operational disruption rendering the primary site inaccessible and/or critical staff unavailable, the critical participant shall be able to resume normal operations from the alternate site, where it shall be possible to properly close the business day and open the following business day(s).

Requirement 2.5:

Procedures shall be in place to ensure that the processing of transactions is resumed from the alternate site within a reasonable timeframe after the initial disruption of service and commensurate to the criticality of the business that was disrupted.

Requirement 2.6:

The ability to cope with operational disruptions shall be tested at least once a year and critical staff shall be aptly trained. The maximum period between tests shall not exceed one year.
(1)  The need-to-know principle refers to the identification of the set of information that an individual needs access to in order to carry out her/his duties.
(2)  The principle of least privilege refers to the tailoring a subject’s access profile to an IT system to match the corresponding business role.
(3)  A supplier in the context of this exercise should be understood as any third party (and its personnel) which is under contract (agreement), with the institution, to provide a service and under the service agreement the third party (and its personnel) is granted access, either remotely or on site, to information and/or information systems and/or information processing facilities of the institution in scope or associated to the scope covered under the exercise of the TARGET self-certification.

ANNEX II

TARGET GOVERNANCE ARRANGEMENTS

Level 1 — Governing Council

Level 2 — Technical and operational management body

Level 3 — Level 3 NCBs

1.

General provisions

 

 

Final competence in relation to all TARGET issues, in particular the rules for the decision making in TARGET, and responsible for safeguarding the public function of TARGET

Conducting technical, functional, operational and financial management tasks in relation to TARGET and implementing the rules on governance decided by Level 1

Taking decisions on the daily running of TARGET based on the service levels defined in the agreement referred to in Article 7(6) of this Guideline

2.

Pricing policy

 

 

Deciding on pricing structure/pricing policy

Deciding on the pricing envelopes

Regular review of pricing structure/ pricing policy

Drafting and monitoring of pricing envelopes

(Not applicable)

3.

Financing

 

 

Deciding on rules for the financial regime of TARGET

Deciding on the financial envelopes

Drafting proposals for the main features of the financial regime as decided by Level 1.

Drafting and monitoring of financial envelopes

Approval and/or initiation of instalments payed by Eurosystem CBs to Level 3 for provision of services

Approval and/or initiation of reimbursement of fees to the Eurosystem CBs

Providing cost figures to Level 2 for the service provision

4.

Service level

 

 

Deciding on the level of service

Verifying that the service was delivered in accordance with the agreed Service level

Delivering the service in accordance with the agreed Service level

5.

Operation

 

 

 

Deciding on the rules applicable to incidents and crisis situations

Monitoring business developments

Managing the system based on the agreement referred to in Article 7(6) of this Guideline

6.

Change and release management

 

 

Deciding in case of escalation

Approving the Change requests

Approving the release scoping

Approving the release plan and its execution

Assessing the Change Requests

Implementing the Change requests in line with the agreed plan

7.

Risk management

 

 

approving the TARGET Risk Management Framework and the risk tolerance for TARGET as well as accepting remaining risks.

assuming ultimate responsibility for the activities of the first and second lines of defence.

establishing the organisational structure for roles and responsibilities related to risk and control

Conducting the actual risk management

Conducting risk analysis and follow-up

ensuring that all risk management arrangements are maintained and kept-up-to date

approving and reviewing the business continuity plan as outlined in the relevant operational documentation

Providing the necessary information for risk analysis according to Level 1/Level 2 requests

8.

System rules

 

 

Establishing and ensuring adequate implementation of the European System of Central Bank's legal framework for TARGET including the Harmonised Conditions for participation in TARGET

(Not applicable)

(Not applicable)

ANNEX III

DEFINITIONS

(1) ‘
account monitoring group
’ means a group of two or more MCAs and/or DCAs in respect of which one participant, the leader party, has a view over the balance on each of the TARGET accounts in the group;
(2) ‘
addressable BIC holder
’ means an entity which: (a) holds a Business Identifier Code (BIC); and (b) is a correspondent or customer of a RTGS DCA holder or a branch of a RTGS DCA holder, and is able to submit payment orders to and receive payments from a TARGET component system via that RTGS DCA holder;
(3) ‘
ancillary system
’ (AS) means a system operated by an entity established in the Union or the EEA that is subject to supervision and/or oversight by a competent authority and complies with the oversight requirements for the location of infrastructures offering services in euro, as amended from time to time and published on the ECB's website, in which payments and/or financial instruments are exchanged and/or cleared or recorded with (a) the monetary obligations resulting in cash transfer orders which are settled in TARGET and/or (b) funds held in TARGET, in accordance with Guideline ECB/2022/8;
(4) ‘
ancillary system guarantee funds account
’ (AS guarantee funds account) means a technical account used for the purpose of holding guarantee funds to support RTGS AS settlement procedures A and B;
(5) ‘
ancillary system settlement procedure
’ (AS settlement procedure) means any TIPS AS settlement procedure or RTGS AS settlement procedure;
(6) ‘
ancillary system transfer order
’ (AS transfer order) means any cash transfer order that is initiated by an ancillary system for the purpose of an RTGS ancillary system settlement procedure;
(7) ‘
auto-collateralisation
’ means intraday credit granted by a euro area national central bank (NCB) in central bank money triggered when a T2S DCA holder has insufficient funds to settle securities transactions, whereby such intraday credit is collateralised either with the securities being purchased (collateral on flow), or with securities held by the T2S DCA holder in favour of the euro area NCB (collateral on stock). An auto collateralisation transaction consists of two distinct transactions, one for the granting of auto-collateralisation and one for its reimbursement. It may also include a third transaction for any eventual relocation of collateral. For the purposes of Annex I, Part I, Article 18 all three transactions are deemed to have been entered into the system and deemed to be irrevocable at the same time as the transaction for the granting of the auto-collateralisation;
(8) ‘
automated liquidity transfer order
’ means a liquidity transfer order generated automatically to transfer funds from a designated RTGS DCA to the participant’s MCA in the event there are insufficient funds on that MCA for the settlement of central bank operations;
(9) ‘
available liquidity
’ means a credit balance on a participant's account and, if applicable, any intraday credit line granted on the MCA by the relevant euro area NCB in relation to such account but not yet drawn upon, or if applicable, decreased by the amount of any processed reservations of liquidity or blocking of funds on MCAs or DCAs;
(10) ‘
banking group
’ means:
a)
a composition of credit institutions included in the consolidated financial statements of a parent company where the parent company is obliged to present consolidated financial statements under International Accounting Standard 27 (IAS 27), adopted pursuant to Commission Regulation (EC) No 1126/2008 (1) and consisting of either: (i) a parent company and one or more subsidiaries; or (ii) two or more subsidiaries of a parent company; or
b)
a composition of credit institutions as referred to in subparagraph (a)(i) or (ii), where a parent company does not present consolidated financial statements in accordance with IAS 27, but may be able to satisfy the criteria defined in IAS 27 for inclusion in consolidated financial statements, subject to the verification of the CB of the participant;
c)
a bilateral or multilateral network of credit institutions that is: (i) organised through a statutory framework determining the affiliation of credit institutions to such a network; or (ii) characterised by self-organised mechanisms of cooperation (promoting, supporting and representing the business interests of its members) and/or economic solidarity going beyond the ordinary cooperation usual between credit institutions whereby such cooperation and solidarity are permitted by credit institutions’ by-laws or articles of incorporation or established by virtue of separate agreements and in each cases referred to in points (c)(i) and (c)(ii) the ECB’s Governing Council has approved an application to be considered as constituting a banking group;
(11) ‘
branch
’ means a branch within the meaning of point (17) of Article 4(1) of Regulation (EU) No 575/2013 of the European Parleament and of the Council (2) or point (30) of Article 4(1) of Directive 2014/65/EU of the European Parleament and of the Council (3);
(12) ‘
broadcast message
’ means information made simultaneously available to all or a selected group of participants;
(13) ‘
business day
’ or ‘
TARGET business day
’ means any day on which MCAs, RTGS DCAs, or T2S DCAs are available for the settlement of cash transfer orders;
(14) ‘
Business Identifier Code
’ (BIC) means a code as defined by ISO Standard No 9362;
(15) ‘
capacity opinion
’ means a participant-specific opinion that contains an assessment of a participant’s legal capacity to enter into and carry out its obligations;
(16) ‘
cash transfer order
’ means any instruction by a participant or a party acting on its behalf to place at the disposal of a recipient an amount of money from one account by means of a book entry onto another account and which is an ancillary system transfer order, a liquidity transfer order, an instant payment order, a positive recall answer or a payment order;
(17) ‘
central bank
’ (CB) means a Eurosystem CB and/or a connected NCB;
(18) ‘central bank operation’
means any payment order or liquidity transfer order initiated by a CB on an MCA opened in any TARGET component system;
(19) ‘
connected NCB
’ means an NCB, other than a euro area NCB, which is connected to TARGET pursuant to a specific agreement;
(20) ‘
Contingency Solution
’ means the functionality that allows CBs and participants to process cash transfer orders in the event that the normal operation of MCAs and/or RTGS DCAs and/or RTGS AS technical accounts is not possible;
(21) ‘
credit institution
’ means either: (a) a credit institution within the meaning of point (1) of Article 4(1) of Regulation (EU) No 575/2013 (and the national law provisions implementing Article 2(5) of Directive 2013/36/EU of the European Parliament and of the Council (4) as applicable to the credit institution) that is subject to supervision by a competent authority; or (b) another credit institution within the meaning of Article 123(2) of the Treaty that is subject to scrutiny of a standard comparable to supervision by a competent authority;
(22) ‘
credit memorandum balance
’ (CMB) means a limit set by the TIPS DCA holder for the use of liquidity on the TIPS DCA by a specific reachable party;
(23) ‘
cross-system settlement
’ means the settlement of AS transfer orders debiting the RTGS AS technical account or a sub-account of a settlement bank of one AS using AS settlement procedure C or D and crediting the RTGS AS technical account or a sub-account of a settlement bank of another AS using AS settlement procedure C or D;
(24) ‘dedicated cash account’
(DCA) means an RTGS DCA, a T2S DCA or a TIPS DCA;
(25) ‘
deposit facility rate
’ means ‘deposit facility rate’ as defined in point (22) of Article 2 of Guideline (EU) 2015/510 (ECB/2014/60);
(26) ‘
deposit facility
’ means ‘deposit facility’ as defined in point (21) of Article 2 of Guideline (EU) 2015/510 (ECB/2014/60);
(27) ‘
euro area NCB
’ means the national central bank (NCB) of a Member State whose currency is the euro;
(28) ‘
European Payments Council’s SEPA Instant Credit Transfer (SCT Inst) scheme
’ or ‘
SCT Inst Scheme
’ means an automated, open standards scheme providing a set of interbank rules to be complied with by SCT Inst participants, allowing payment services providers in the Single Euro Payments Area (SEPA) to offer an automated SEPA-wide euro instant credit transfer product;
(29) ‘
Eurosystem CB
’ means the ECB or a euro area NCB;
(30) ‘
event of defaul
t’ means any impending or existing event, the occurrence of which may threaten the performance by a participant of its obligations under the Conditions contained in Annex I, Part I or any other rules applying to the relationship between that participant and the participant’s CB or any other CB, including:
(a) where the participant no longer meets the access criteria laid down in the national implementation of Part I, Annex I, Article 4 or the requirements laid down in the relevant national implementation of Part I, Annex I, Article 5(1), point (a);
(b) the opening of insolvency proceedings in relation to the participant;
(c) the submission of an application relating to the proceedings referred to in point (b);
(d) the issue by the participant of a written declaration of its inability to pay all or any part of its debts or to meet its obligations arising in relation to intraday credit;
(e) the entry of the participant into a voluntary general agreement or arrangement with its creditors;
(f) where the participant is, or is deemed by its CB to be, insolvent or unable to pay its debts;
(g) where the participant's credit balance on any of its TARGET accounts, or all or a substantial part of the participant's assets are subject to a freezing order, attachment, seizure or any other procedure that is intended to protect the public interest or the rights of the participant's creditors;
(h) where participation of the participant in another TARGET component system and/or in an AS has been suspended or terminated;
(i) where any material representation or pre-contractual statement made by the participant or which is implied to have been made by the participant under the applicable law is incorrect or untrue;
(j) the assignment of all or a substantial part of the participant's assets;
(31) ‘
guarantee funds
’ means funds provided by participants of an AS, to be used in the event of the failure, for whatever reason, of one or more participants to meet their payment obligations in the AS;
(32) ‘
insolvency proceedings
’ means insolvency proceedings within the meaning of Article 2(j) of Directive 98/26/EC ;
(33) ‘
instant payment order
’ means, in line with the European Payments Council’s SEPA Instant Credit Transfer (SCT Inst) scheme, a cash transfer order which can be executed 24 hours a day any calendar day of the year, with immediate or close to immediate settlement and notification to the payer, and which includes: (i) TIPS DCA to TIPS DCA instant payment orders; (ii) TIPS DCA to TIPS AS technical account instant payment orders; (iii) TIPS AS technical account to TIPS DCA instant payment orders; and (iv) TIPS AS technical account to TIPS AS technical account instant payment orders;
(34) ‘
instructing party
’ means an entity which has been designated as such by a TIPS DCA holder or the holder of a TIPS AS technical account, and which is allowed to send instant payment orders or liquidity transfer orders and/or receive instant payment orders or liquidity transfer orders on behalf of that account holder or a reachable party of that account holder;
(35) ‘
intraday credit
’ means credit extended for a period of less than one business day;
(36) ‘
investment firm
’ means an investment firm within the meaning of [insert national law provisions implementing Article 4(1)(1) of Directive 2014/65/EU], excluding the institutions specified in the national law provisions implementing Article 2(1) of Directive 2014/65/EU as applicable to the investment firm, provided that the investment firm in question is:
a)
authorised and supervised by a recognised competent authority, which has been designated as such under Directive 2014/65/EU; and
b)
entitled to carry out the activities referred to under [insert national law provisions implementing items 2, 3, 6 and 7 of Section A of Annex I to Directive 2014/65/EU as applicable to the investment firm];
(37) ‘
Level 3 NCBs
’ means the Deutsche Bundesbank, the Banque de France, the Banca d’Italia and the Banco de España in their capacity as the CBs developing and operating TARGET for the Eurosystem’s benefit;
(38) ‘
liquidity transfer order
’ means a cash transfer order to transfer a specified amount of funds for the purpose of liquidity management;
(39) ‘
marginal lending facility rate
’ means ‘marginal lending facility rate’ as defined in point (57) of Article 2 of Guideline (EU) 2015/510 (ECB/2014/60);
(40) ‘
marginal lending facility
’ means ‘marginal lending facility’ as defined in point (56) of Article 2 of Guideline (EU) 2015/510 (ECB/2014/60);
(41) ‘
mobile proxy look-up (MPL) service
’ means a service which enables TIPS DCA holders, AS using TIPS AS technical accounts and reachable parties, who receive from their customers a request to execute an instant payment order in favour of a beneficiary identified with a proxy (e.g. a mobile number), to retrieve from the central MPL repository the corresponding beneficiary IBAN and the BIC to be used to credit the relevant TARGET Instant Payment Settlement (TIPS) account;
(42) ‘
near instant payment
’ means a transfer of cash order which complies with the European Payments Council’s SEPA Credit Transfer Additional Optional Services (SCT AOS) NL Standard for instant processing of SEPA credit transfers;
(43) ‘network service provider’
(NSP) means an undertaking that has been awarded a concession with the Eurosystem to provide connectivity services via the Eurosystem Single Market Infrastructure Gateway to the TARGET services;
(44) ‘
non-settled cash transfer order
’ means a cash transfer order that is not settled on the business day on which it is accepted;
(45) ‘
participant
’ means; a) an entity that holds at least one MCA and may additionally hold one or more DCAs in TARGET; or b) an AS;
(46) ‘
payee
’ means, except where used in Article 29, Part I of Annex I, a participant whose MCA or DCA, will be credited as a result of a cash transfer order being settled;
(47) ‘
payer
’ means, except where used in Article 29, Part I of Annex I, a participant whose MCA or DCA, will be debited as a result of a cash transfer order being settled;
(48) ‘
payment order
’ means any instruction by a participant or a party acting on its behalf to place at the disposal of a recipient an amount of money from one account by means of a book entry onto another account and which is not an AS transfer order, a liquidity transfer order, an instant payment order or a positive recall answer;
(49) ‘
positive recall answer
’ means, in line with the European Payments Council’s SEPA Instant Credit Transfer (SCT Inst) scheme, a cash transfer order initiated by the receiver of a recall request, in response to a recall request, for the benefit of the sender of that recall request;
(50) ‘
public sector body
’ means an entity within the ‘public sector’, the latter term as defined in Article 3 of Council Regulation (EC) No 3603/93 (5);
(51) ‘
reachable party
’ means an entity which: (a) holds a Business Identifier Code (BIC); (b) is designated as such by a TIPS DCA holder or by an ancillary system holding a TIPS AS technical account; (c) is a correspondent, customer, or branch of a TIPS DCA holder or a participant of an ancillary system; or is a correspondent, customer, or branch of a participant of an ancillary system holding a TIPS AS technical account and (d) is addressable through TIPS and is able to submit cash transfer orders and receive cash transfer orders either via the TIPS DCA holder or by an ancillary system holding a TIPS AS technical account, or directly if so authorised by the TIPS DCA holder or by an ancillary system holding a TIPS AS technical account;
(52) ‘
Real-time gross settlement ancillary system settlement procedure
’ (RTGS AS settlement procedure) means one of the range of special, predefined services for the submission and settlement of AS transfer orders related to settlement of AS on RTGS DCAs, sub-accounts and RTGS AS technical accounts;
(53) ‘Real-time gross settlement ancillary system technical account’
(RTGS AS technical account) means an account held by an AS or by the CB in its TARGET component system on behalf of the AS and used in the context of an RTGS AS settlement procedure;
(54) ‘
recall request
’ means a message from an RTGS DCA holder or a TIPS DCA holder requesting reimbursement of a settled payment order or instant payment order respectively;
(55) ‘
rule-based liquidity transfer order
’ means a liquidity transfer order that is triggered as a result of: (a) the balance on an MCA or RTGS DCA breaching a pre-defined floor or ceiling; or (b) insufficient funds being available to cover queued urgent payment orders, AS transfer orders or high priority payment orders on an RTGS DCA;
(56) ‘
settlement bank account group
’ means a list of RTGS DCAs and/or sub accounts set in the context of the settlement of an ancillary system using RTGS AS settlement procedures;
(57) ‘
settlement bank
’ means an RTGS DCA holder whose RTGS DCA or sub-account is used to settle AS transfer orders submitted by an AS using the RTGS AS settlement procedures;
(58) ‘
suspension
’ means the temporary freezing of the rights and obligations of a participant for a period of time to be determined by the participant’s CB;
(59) ‘
TARGET account
’ means any account opened in a TARGET component system;
(60) ‘
TARGET component system
’ means any of the CBs’ systems that form part of TARGET;
(61) ‘
TARGET coordinator
’ means a person appointed by the ECB to ensure the daily operational management of TARGET, to manage and coordinate activity in the event of an abnormal situation occurring and to coordinate the dissemination of information to participants;
(62) ‘
TARGET Instant Payment Settlement (TIPS) ancillary system settlement procedure
’ (TIPS AS settlement procedure) means the predefined service for the submission and settlement of liquidity transfer orders and instant payment orders related to settlement of AS on TIPS DCAs and TIPS AS technical accounts;
(63) ‘TARGET Instant Payment Settlement (TIPS) ancillary system technical account’
(TIPS AS technical account) means an account held by an AS or by the CB in its TARGET component system on behalf of the AS for use by the AS for the purpose of settling instant payments or near instant payments in its own books;
(64) ‘
TARGET settlement manager
’ means a person appointed by a Eurosystem CB to monitor the operation of its TARGET component system;
(65) ‘
TARGET2-Securities
’ (T2S) means the set of hardware, software and other technical infrastructure components through which the Eurosystem provides the services to CSDs and Eurosystem CBs that allow core, neutral and borderless settlement of securities transactions on a delivery-versus-payment basis in central bank money;
(66) ‘technical malfunction of TARGET’
means any defect or failure in the technical infrastructure and/or the computer systems used by the relevant TARGET component system, or any other event that makes it impossible to execute and complete the processing of cash transfer orders according to the relevant parts of this Guideline in the relevant TARGET component system.
(1)  Commission Regulation (EC) No 1126/2008 of 3 November 2008 adopting certain international accounting standards in accordance with Regulation (EC) No 1606/2002 of the European Parliament and of the Council (
OJ L 320, 29.11.2008, p. 1
).
(2)  Regulation (EU) No 575/2013 of the European Parliament and of the Council of 26 June 2013 on prudential requirements for credit institutions and amending Regulation (EU) No 648/2012 (
OJ L 176, 27.6.2013, p. 1
).
(3)  Directive 2014/65/EU of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Directive 2002/92/EC and Directive 2011/61/EU (
OJ L 173, 12.6.2014, p. 349
).
(4)  Directive 2013/36/EU of the European Parliament and of the Council of 26 June 2013 on access to the activity of credit institutions and the prudential supervision of credit institutions, amending Directive 2002/87/EC and repealing Directives 2006/48/EC and 2006/49/EC (
OJ L 176, 27.6.2013, p. 338
).
(5)  Council Regulation (EC) No 3603/93 of 13 December 1993 specifying definitions for the application of the prohibitions referred to in Articles 104 and 104b (1) of the Treaty (
OJ L 332, 31.12.1993, p. 1
).
Markierungen
Leseansicht