TARGET2 (Trans-European Automated Real-time Gross Settlement Express Transfer System der 2. Systemgeneration) ist ein von der Europäischen Zentralbank (EZB) in den EU-Mitgliedsstaaten für die Kontoführung und eilbedürftige Abwicklung des europäischen Großbetragszahlungsverkehrs bereitgestelltes Individiualzahlungssystem.
Dieser Zahlungsverkehrplattform liegt eine standardisierte technische Infrastruktur zu Grunde, die als ein zentrales Fundament für die gesamte Zahlungsverkehrsarchitektur des Eurosystems etabliert wurde. Damit hatte sich die technische Weiterentwicklung der bis dato genutzten nationalen RTGS Systemen erübrigt.
TAREGT2 ist ein mit einem europaweiten Liquiditätsmanagement ausgestattetes Bruttosystem, welches in Echtzeit grenzüberschreitende auf die Währung Euro lautende Zahlungen endgültig verarbeiten kann, sofern vom Zahlungspflichtigen auf dem Zentralbankkonto ein ausreichendes Guthaben vorgehalten wird. |
Für die Ausführung von Transaktionen über TARGET2 sind – auch wenn es sich hierbei um eine Gemeinschaftsplattform handelt, die vorrangig für den Großbetragszahlungsverkehr angedacht ist – keine Mindestbeträge vorgegeben. Die Steuerung der TARGET2 Nutzung erfolgt über die festgelegten Transaktionskosten, die im Vergleich zur Ausführung über das SEPA Massenzahlungsverkehrssystem wesentlich teurer sind.
Der operative Betrieb der TARGET2 Geschäftsabwicklung über die Gemeinschaftsplattform (Single Shared Platform; SSP) wird in den europäischen Teilnehmerländern durch die jeweiligen nationalen Zentralbanken auf der Grundlage eines vordefinierten Service Level Agreement angeboten.
Relevante TARGET2 Informationsquellen: Detailed Functional Specifications (UDFS) |
» User Detailed Functional Specifications (UDFS) - Core Services 1st book |
» User Detailed Functional Specifications (UDFS) - Optional Services 2nd book |
» User Detailed Functional Specifications (UDFS) - XML-Messages 4th book |
Bei der Deutschen Bundesbank ist dem technischen Wechsel auf das TARGET2 Zahlungsabwicklungs- und Kontoführungssystem eine sogenannte Transition Period vorausgegangen, in der die Kontoführung für die deutschen Kreditinstitute sukzessive auf die Payments Module der TARGET2 Gemeinschaftsplattform verlagert wurde.
Das sogenannte PM Konto wurde hierbei zum vollwertigen Hauptkonto eines Kreditinstitutes. Beim SCL Verfahren (SEPA) und beim auslaufenden nationalen elektronischen Massenzahlungsverkehrsverfahren (EMZ) erfolgen die jeweiligen Buchungen auf den Unterkonten (Sub Accounts) des Payments Module.
TARGET2 bietet aber auch die Möglichkeit zum europaweiten Settlement von über SWIFT angeschlossenen Nebensystemen (Wertpapierverrechnung, Devisenverrechnung, Geldmarkt). In Folge dessen, dass Clearstream und Eurex die Wertpapierverrechnung auf TAGRET2 verlagern, erfolgt die geldliche Verrechnung nicht mehr auf den Bundesbankkonten sondern unmittelbar auf den Konten der TARGET2 Teilnehmer.
Das Kernsystem von TARGET2 ist jedoch die Abwicklung des Zahlungsverkehrs im Payment Module (PM). Darüber hinaus ist das auf SWIFTNet basierende Information und Control Module (ICM) fester Bestandteil von TARGET2 und steht allen direkten Teilnehmern zur Verfügung.
Die Zentralbanken erhalten mit Contigency Module (CM) ein Notfallinstrument, mit dem sie auf das SWIFTNet zugreifen können. Das Static Data Modul dient der Verwaltung von Stammdaten.
TARGET2 Payments and Accounting Processing Services System (PAPSS) |
|
» Payments Module (PM) |
Zahlungsmodul |
» Standing Facilities Module (SF) |
Modul für ständigen Fazilitäten |
» Reserve Management Module (RM) |
Modul für Mindestreserveverwaltung |
» Home Accounting Module (HAM) |
Heimatkontomodul |
» Static Data Module (SD) |
Stammdatenmodul |
» Contingency Module (CM) |
Contingency-Modul |
» Information and Control Module (ICM) |
Informations- und Steuerungsmodul |
Das Liquiditätsmanagement von TARGET2 kann von den direkten Teilnehmern optional genutzt werden und bietet europaweit Möglichkeiten zur Liquiditätssteuerung, zur Reservierung von Liquidität für das Settlement von Nebensystemen und ein Liquiditätspooling.
Ein Liquiditätspooling kann mit einem virtuellen Konto kann über die Liquidität aller Mitglieder einer Kontengruppe verfügt werden, ist aber auf Konten aus dem Euroraum beschränkt. Soll das Liquiditätspooling hingegen mit konsolidierten Informationen erfolgen, werden summarische Informationen für eine Kontengruppe auch für Konten außerhalb des Euroraums bereitgestellt.
ISO 20022 gilt in der Finanzwirtschaft als zukunftsweisender Standard. Dieses bedeutet, dass nicht nur SEPA Formate ISO 20022 konform sind, sondern neue Infrastrukturen wie zum Beispiel TARGET2 Security (T2S) ausschließlich auf ISO 20022 aufsetzen.
Auch im SWIFT Umfeld sollen spezielle ISO 20022 konforme Nachrichten für den Individualzahlungsverkehr die bisherigen MT Nachrichtentypen ablösen. Eine Nutzung der neuen Formate wird damit einhergehend auch für TARGET2 zwingend erforderlich.
Die beschlossene ISO 20022 Migrationstrategie für TARGET2 enthält folgende Eckpunkte:
TARGET2 Implementierungen |
Release |
Termin |
SEPA Credit Transfer (SCT) in TARGET2 |
SSP Release 6.0 |
Nov. 2012 |
ISO20022 für Verbindung TARGET2 Securities (T2S) mit TARGET2
ISO20022 konforme CAMT Nachrichten für Liquiditätsmanagement |
SSP Release 7.0 |
Nov. 2013 |
ISO20022 Restmengen von TARGET2, die noch FIN- Standards nutzen
» Interbank- Zahlung (MT 202) |
SSP Release 8.0 |
Nov. 2014 |
Nachrichtenaustausch mit T2S |
|
Jun. 2015 |
Umstellung Zahlungsverkehrsnachrichten
» SWIFT MTs werden durch ihre jeweiligen MX-Äquivalente ersetzt
» Nach Einführung der MT-Äquivalente sollen die MX-Nachrichten
» Alle für Zahlungsverkehr genutzten MT-Nachrichten werden zum
» Es wird in TARGET2 keine Koexistenz von MT und MX geben
» TARGET2 bietet keine Konvertierung zwischen beiden Formaten an im Juni 2015 |
|
Nov. 2017 |
Bei TARGET2 wird zwischen direkten und indirekten Teilnehmern unterschieden.
Die direkten Teilnehmer haben direkten Zugriff zum Payment Module (d.h. ein eigenes TARGET2 Konto) und können Zahlungen eigenverantwortlich direkt in das/aus dem TARGET2 System einreichen/empfangen, vorhandene Real-time Informationen abrufen sowie die angebotenen Kontrollmechanismen nutzen. Die Verantwortung für das eigene Liquiditätsmanagement und die Überwachung des Abwicklungsprozesses obliegt den direkten Teilnehmern selbst.
Direkte Teilnehmer können indirekten Teilnehmer den Zugang zum Payment Module zur Verfügung stellen. Für Nebensysteme existiert eine eigene Schnittstelle und basiert auf SWIFTNet (InterAct und FileAct) und XML Messages.
Fachliche Kriterien für TARGET2 Zugang als direkter Teilnehmer |
|
Kreditinstitute mit Sitz im Europäischen Wirtschaftsraum (EWR) |
|
Kreditinstitute mit Sitz außerhalb des EWR, sofern Zweigstelle im EWR ansässig ist |
|
Nationale Zentralbanken der EU-Mitgliedstaaten und die EZB |
|
Europäische Zentralbank |
|
Sonstige Institute, sofern von der zuständigen Zentralbank zugelassen |
|
|
z.B. |
|
» Öffentliche Stellen von EU-Mitgliedstaaten |
|
» Wertpapierdienstleistungsunternehmen (oder dessen Zweigstelle) mit Sitz im EWR |
|
|
Fachliche Kriterien für TARGET2 Zugang als indirekter Teilnehmer |
|
Kreditinstitute mit Sitz im EWR benötigen eine vertragliche Vereinbarung mit einem direkten TARGET2 Teilnehmer, um über dessen PM-Konto TARGET2 Zahlungsaufträge einzureichen und/oder TARGET2 Zahlungen empfangen zu können. |
Hinweis: Direkte Teilnehmer am TARGET2 System können ihre Zweigstellen oder den zu ihrer Institutsgruppe angehörenden Unternehmen – sofern sich deren Sitz in einem EWR Land befindet – bevollmächtigen ihre Zahlungen direkt ohne Mitwirkung des direkten Teilnehmers über sein PM-Konto via eines so genannten Multi-Adressaten Zuganges abzuwickeln.
Bei der Ausführung von TARGET2 Nachrichten muss unterschieden werden, ob es sich bei der Empfängerbank um einen direkten oder um einen indirekten Teilnehmer handelt.
Die von TARGET2 Zentralbanken anerkannten indirekte Teilnehmer sind im TARGET2 Verzeichnis mit der Angabe ihres direkten Teilnehmers enthalten. Ein direkter Teilnehmer muss als SWIFT Empfänger im Header der Nachricht angegeben werden. In diesem Fall muss die Senderbank darauf achten, dass der indirekte Teilnehmer im Nachrichtenteil (Felder 56, 57 und 58) mitgeteilt wird.
Die Registrierung bei TARGET2 als direkter Teilnehmer setzt eine vorherige separate Registrierung bei SWIFT voraus. Für die Zahlungsaufträge können nur die im TARGET2 Directory veröffentlichten BIC genutzt werden. |
Die Stammdaten für die Adressierung von Zahlungen sind im TARGET2 Directory – welches das RTGSplus Directory abgelöst hat - hinterlegt.
Im TARGET2 Directory ist für alle direkt und indirekt erreichbaren Teilnehmer ein SWIFT BIC oder ein NON SWIFT BIC enthalten. Die direkten TARGET2 Teilnehmer lassen sich hierbei durch den Service Code „TGT“ von den indirekten Teilnehmer (Service Code = TG+) unterscheiden.
Kunden einer Zentralbank haben entweder ein Konto im Home Accounting Module (HAM) oder in einer eigenen Home Accounting Application (PHA). Sie können im TARGET2 Directory registriert sein und über die Zentralbank - bei der das oben genannte Konto geführt wird - adressiert werden.
Das TARGET2 Directory wird wöchentlich aktualisiert. Die Auslieferung einer neuen Version erfolgt freitags mit Geschäftsbeginn und wird am darauf folgenden Montag gültig. Die monatlichen Aktualisierungen des BIC Directory gehen als Änderungen in das TARGET2 Directory ein.
Beim Auslieferungsweg push mode – der direkten TARGET2 Teilnehmern vorbehalten ist – wird von der SSP allen registrierten Benutzern automatisiert eine Datei mit den Änderungen gegenüber der Vorversion via SWIFTNet FileAct zugesendet. Wenn keine Änderungen vorhanden sind wird eine Leerdatei versendet.
Beim Auslieferungsweg pull mode kann jeder Teilnehmer über den FileAct Service von SWIFT einen Download des TARGET2 Directory (Änderungsversion oder Vollversion) anfordern.
Das Gültigkeitsdatum der Version ist im Header enthalten.
Informationen zur Struktur des TARGET2 Directory erhalten Sie im Kapitel Bankstammdaten (Bank Code Directories)
Die Dringlichkeit von TARGET2 Zahlungen wird über Prioritätsklassen gesteuert.
TARGET2 Prioritätsklassen |
|
0 |
highly urgent payments |
1 |
urgent payments |
2 |
normal payments (default) |
Zahlungen der Prioritätsklasse 0 werden nach dem first in first out Prinzip abgewickelt. Stehen Zahlungen dieser Prioritätsklasse zur Abwicklung an, so müssen Zahlungen der anderen Klassen warten. Zahlungen der Prioritätsklasse 1 werden ebenfalls nach dem first in first out Prinzip abgewickelt.
Zahlungen der Prioritätsklasse Klasse 2 werden nach dem „FIFO by passing Prinzip abgewickelt. d.h. die Abwicklung erfolgt unter Aspekten der Liquidität Sofern diese vorhanden ist, können die Zahlungen auch ausgeführt werden, wenn andere Zahlungen der gleichen Klasse noch in der Warteschlange stehen. Innerhalb der Zahlungsarten gibt es keine weitere Priorisierung.
Für die Abwicklung highly urgent und urgent Transaktionenkann Liquidität reserviert werden.
In TARGET2 können Zahlungen unter Angabe einer Ausführungszeit (timed payments) eingestellt werden. Man unterscheidet hierbei zwischen Earliest debit time (/FROTIME/hhmm Ausführungszeit ab hhmm) und Latest debit time [/REJTIME/hhmm Ausführungszeit bis hhmm (Option A); /TILTIME/hhmm Ausführungszeit bis hhmm (Option B) und /CLSTIME/hhmm Ausführungszeit bis hhmm (nur im MT202)].
Für Kundenzahlungen darf "hhmm" einen Wert von 07:00 bis 17:00 sowie für Interbankenzahlungen von 07.00 bis 18:00 haben.
Sofern es sich um Zahlungen aus dem Ausland handelt, können zusätzlich die Codes /SNDTIME/hhmm+iinn bzw. /RNCTIME/hhmm+iinn verwendet werden, wobei „ii“ und „nn“ die Stunden- und Minutenangaben nach UTC (SWIFT Standard zur Datums- und Zeit- Verschlüsselung) angeben.
In TARGET2 besteht die Möglichkeit der Einlieferung von Zahlungen (für MT103 und MT202) bis zu fünf TARGET2-Arbeitstage im Voraus. Die Steuerung der sogenannte Warehouse functionality erfolgt über das Wertstellungsdatum (Valuta) in Feld 32A. Bei Erreichung des Wertstellungsdatums wird die TARGET2 Zahlung mit Geschäftsbeginn durch das Payment Module ausgeführt (time stamp: 7:00).
Eine Liquidität kann sowohl auf dem PM Konto (Payments Modul) auf dem HAM Konto (Heimatkontomodul) oder auf dem proprietären Heimatkonto der jeweiligen nationalen Zentralbank vorgehalten und sowohl mittels ICM (via SWIFTNet InterAct) als auch von 7.00 Uhr bis 18.00 Uhr mittels SWIFTNet FIN transferiert werden.
TARGET2 Zahlungen werden bei der Deutschen Bundesbank über ein gesondertes Abwicklungskonto gebucht. Dieses Konto kann von einem Heimatkonto mit Liquidität versorgt werden. Die Liquidität kann auch über Nacht vorgehalten werden.
Als TARGET2 Geschäftstage gelten - im Sinne einer Erreichbarkeit TARGET2-Gemeinschaftsplattform (Single Shared Platform, SSP) - alle Kalendertage eines Jahres mit Ausnahme Samstag und Sonntag sowie mit Ausnahme der folgenden Feiertage: Neujahr, Karfreitag, Ostermontag, 1. Mai sowie am 25. und 26. Dezember.
TARGET2 Tagesablauf |
Uhrzeit |
Erläuterung |
|||
Tagverarbeitung BEGINN |
07.00 - 18:00 Uhr |
Transaktionen, Liquiditätsübertrag |
|||
D |
|
bis 12.00 Uhr |
|
Zahlung gegen Zahlung Abwicklung von Devisengeschäften in mehreren Währungen via Continuous Linked Settlement (CLS) mit Zugang zum Zentralbankgeld von jeder zugelassen Währung |
|
|
bis 16.45 Uhr |
|
Zahlungsausgleich Tagesabschluss EURO (Großbetragszahlungssystem für grenzüberschreitende Transaktionen in EUR zwischen in der EU ansässigen Kreditinstitute) via Nebensystemschnittstelle ASI |
||
bis 17.00 Uhr |
Annahmeschluss Kundenzahlungen (Nach dem Zeitpunkt eingehende Zahlungsaufträge werden zurückgewiesen, es sei denn es handelt sich hierbei um terminierte Zahlungen, die bis zum Ausführungstag in der TARGET2 Gemeinschaftsplattform gespeichert werden sollen) |
||||
|
bis 18.00 Uhr |
|
Annahmeschluss Interbankzahlungen (Nach dem Zeitpunkt eingehende Zahlungsaufträge werden zurückgewiesen, es sei denn es handelt sich hierbei um terminierte Zahlungen, die bis zum Ausführungstag in der TARGET2 Gemeinschaftsplattform gespeichert werden sollen |
||
Tagverarbeitung ENDE D |
18.00 - 18:45 Uhr |
ICM Nachricht an alle TARGET2 Nutzer, das die Tagesverarbeitung beendet wurde |
|||
|
bis 18.15 Uhr |
|
» Liquiditätsrücktransfer von
» Nutzung ständiger Fazilitäten » Versand Saldeninformationen an RM Modul » Versand Kontoauszug MT 940/ 950 |
||
|
ab 18.30 Uhr |
|
Interne Zentralbankbuchungen |
||
Tagverarbeitung BEGINN D+1 |
18.45 - 19:00 Uhr |
ICM Nachricht an alle TARGET2 Nutzer, das die Tagesendearbeiten abgeschlossen sind und mit den Vorbereitungsarbeiten für den nächsten Geschäftstag begonnen werden kann. |
|||
Nachtverarbeitung Vorbereitung D+1 |
19.00 - 19:30 Uhr |
Im Bedarfsfall Bereitstellung von Liquidität für Zahlungsausgleich, des Weiteren ist auch eine Aktualisierung von Kreditlinien oder eine Abwicklung von Repo-Geschäften vor Eröffnung möglich |
|||
Nachtverarbeitung D+1 |
19.30 - 22:00 Uhr |
Liquidität auf PM Konten wird durch eine Gutschrift auf Unterkonten für die Nachtverarbeitung von Nebensystemen übertragen. |
|||
Wartungsarbeit |
22.00 - 01:00 Uhr |
Ständig reserviertes Zeitfenster |
|||
Nachtverarbeitung D |
01.00 - 07:00 Uhr |
Liquiditätstransfers zum/ vom RTGS Konto können bei Bedarf während des gesamten Nachtverarbeitungsfensters mittels ICM durchgeführt werden. |
Die Deutsche Bundesbank liefert optional TARGET2 positive oder negative Quittungsdateien aus, deren Inhalt für den Abgleich von eingereichten TARGET2 Aufträgen genutzt werden kann.
In TARGET2 werden mit dem eingehenden Nachrichtentyp MT 910 Gutschriften bestätigt; Belastungen hingegen werden mit den eingehenden Nachrichtentyp MT 900 bestätigt.
Technische Anforderungen für die Teilnahme an TARGET2 bezüglich Infrastruktur, Netzwerk und Formaten |
||
1. |
Jeder Teilnehmer, der den internetbasierten Zugang nutzt, muss sich mit dem ICM von TARGET2 verbinden, indem er einen Local Client, ein Betriebssystem und einen Internetbrowser gemäß dem Anhang „Internetbasierte Teilnahme — Systemanforderungen für den Internetzugang“ zu den User Detailed Functional Specifications (UDFS) mit bestimmten Einstellungen verwendet.
Alle PM-Konten der Teilnehmer erhalten einen acht- bzw. elfstelligen BIC als Kennung. Darüber hinaus muss jeder Teilnehmer vor seiner Aufnahme in TARGET2 eine Reihe von Tests bestehen, um seine technische und operationale Eignung unter Beweis zu stellen. |
|
2. |
Für die Übermittlung von Zahlungsaufträgen und Zahlungsnachrichten im PM wird die TARGET2-Plattform BIC, TRGTXEPMLVP, als Sender und Empfänger von Nachrichten genutzt.
Zahlungsaufträge, die an einen Teilnehmer gesendet werden, der den internetbasierten Zugang nutzt, sollten diesen Teilnehmer als Empfänger in dem Feld für den Begünstigten benennen. Zahlungsaufträge, die von einem Teilnehmer eingegeben wurden, der den internetbasierten Zugang nutzt, werden diesen Teilnehmer als den Auftraggeber identifizieren. |
|
3. |
Die Teilnehmer, die den internetbasierten Zugang nutzen, verwenden die Public Key Infrastructure (PKI) gemäß dem „Benutzerhandbuch Internetzugang für den Public-Key-Zertifizierungsdienst“. |
|
|
||
Typen von Zahlungsnachrichten |
||
1. |
Die Teilnehmer, die den internetbasierten Zugang nutzen, können folgende Zahlungsarten nutzen: |
|
a) |
Kundenzahlungen, d.h. Überweisungen, bei denen der beauftragende und/oder begünstigte Kunde kein Finanzinstitut ist, |
|
b) |
STP Kundenzahlungen, d.h. Überweisungen, bei denen der beauftragende und/oder begünstigte Kunde kein Finanzinstitut ist und die im Modus „durchgängig automatisierte Abwicklung“ („Straight Through Processing“) ausgeführt werden, |
|
c) |
Bank an Bank Überweisungen zur Anforderung von Geldtransfers zwischen Finanzinstituten, |
|
d) |
Deckungszahlungen zur Anforderung von Geldtransfers zwischen Finanzinstituten im Zusammenhang mit einer zugrunde liegende Kundenüberweisung. |
|
Darüber hinaus können die Teilnehmer, die den internetbasierten Zugang zu einem PM-Konto nutzen, Lastschriftaufträge empfangen. |
||
2. |
Die Teilnehmer müssen die Feldbelegungsregeln - die in Kapitel 9.1.2.2 der UDFS, Buch 1, definiert sind - beachten. |
|
3. |
Die Feldbelegung wird auf der Ebene von TARGET2 gemäß den UDFS Anforderungen geprüft. Die Teilnehmer können untereinander besondere Regeln für die Feldbelegung vereinbaren. Ob die Teilnehmer diese besonderen Regeln einhalten, wird innerhalb von TARGET2 jedoch nicht geprüft. |
|
4. |
Die Teilnehmer, die den internetbasierten Zugang nutzen, können über TARGET2 Deckungszahlungen vornehmen, d. h. Zahlungen durch Korrespondenzbanken zur Abwicklung (Deckung) von Überweisungsnachrichten, die auf andere, direktere Weise an die Bank eines Kunden übermittelt werden. Die in diesen Deckungszahlungen enthaltenen Kundendaten werden nicht im ICM angezeigt. |
|
|
||
Überprüfung auf doppelte Auftragserteilung |
||
1. |
Alle Zahlungsaufträge werden einer Überprüfung auf doppelte Auftragserteilung unterzogen, damit Zahlungsaufträge, die versehentlich mehr als einmal eingereicht wurden, zurückgewiesen werden können. |
|
2. |
Folgende Felder von Nachrichtentypen werden überprüft: |
|
» Absender (Basis Header, Feld BIC Adresse) |
||
» Nachrichtentyp (Application Header, Feld Nachrichtentyp) |
||
» Empfänger (Application Header, Feld Zieladresse) |
||
» Transaktionsreferenznummer (TRN, Feld :20) |
||
» Zugehörige Referenz (Related Reference, Feld :21) |
||
» Wertstellungsdatum/ Valutadatum (Feld :32) |
||
» Betrag (Feld :32) |
||
3. |
Stimmen alle in Absatz 2 beschriebenen Felder bezüglich eines neu eingereichten Zahlungsauftrags mit denen eines bereits angenommenen Zahlungsauftrags überein, wird der neu eingereichte Zahlungsauftrag zurückgegeben. |
|
|
||
Fehlercodes |
||
Wird ein Zahlungsauftrag zurückgewiesen, wird eine Abbruchmitteilung über das ICM zur Verfügung gestellt, in der mittels Fehlercodes der Grund für die Zurückweisung angegeben wird. Die Fehlercodes sind in Kapitel 9.4.2 der UDFS definiert. |
||
|
||
Zeitvorgaben für die Abwicklung |
||
1. |
Bei Zahlungsaufträgen mit Earliest Debit Time Indicator ist das Codewort "/FROTIME/" zu verwenden. |
|
2. |
Bei Zahlungsaufträgen mit Latest Debit Time Indicator stehen zwei Optionen zur Verfügung. |
|
a) |
Codewort "/REJTIME/" Zahlungsaufträge, die nicht bis zum angegebenen Belastungszeitpunkt abgewickelt werden konnten, werden zurückgegeben. |
|
b) |
Codewort "/TILTIME/" Zahlungsaufträge, die nicht bis zum angegebenen Belastungszeitpunkt abgewickelt werden konnten, werden nicht zurückgegeben, sondern bleiben in der entsprechenden Warteschlange. |
|
Für beide Optionen gilt: Wurden Zahlungsaufträge mit einem Latest Debit Time Indicator 15 Minuten vor der angegebenen Zeit noch nicht abgewickelt, wird automatisch eine Nachricht über das ICM gesendet. |
||
3. |
Wenn das Codewort "/CLSTIME/" verwendet wird, wird mit dem Zahlungsauftrag in gleicher Weise verfahren wie in Absatz 2 Buchstabe b. |
|
|
||
…… |
||
|
||
Nutzung des Informations- und Kontrollmoduls (ICM) |
||
1. |
Das ICM kann für die Eingabe von Zahlungsaufträgen genutzt werden. |
|
2. |
Das ICM kann für den Informationsaustausch und die Liquiditätssteuerung genutzt werden. |
|
3. |
Mit Ausnahme von gespeicherten Zahlungsaufträgen und Kundenstammdaten sind über das ICM lediglich Daten, die sich auf den laufenden Geschäftstag beziehen, abrufbar. Die Bildschirmmasken werden nur in englischer Sprache angeboten. |
|
4. |
Informationen werden im Anfragemodus (pull) bereitgestellt; das bedeutet, dass jeder Teilnehmer um Bereitstellung von Informationen ersuchen muss. Die Teilnehmer überprüfen das ICM während des Geschäftstages regelmäßig auf wichtige Nachrichten. |
|
5. |
Für die Teilnehmer, die den internetbasierten Zugang nutzen, steht nur der User-to-Application Modus (U2A) zur Verfügung. Der U2A ermöglicht die direkte Kommunikation zwischen dem Teilnehmer und dem ICM. Die Informationen werden in einem Browser angezeigt, der auf einem PC läuft. Weitere Einzelheiten sind im ICM- Benutzerhandbuch aufgeführt. |
|
6. |
Jeder Teilnehmer verfügt über mindestens einen Computerarbeitsplatz mit Internetzugang, um über U2A Zugriff auf das ICM zu erhalten. |
|
7. |
Die Zugriffsrechte für das ICM werden mittels Zertifikaten gewährt, deren Nutzung in den Absätzen 10 bis 13 ausführlicher beschrieben wird. |
|
8. |
Die Teilnehmer können das ICM auch nutzen, um Liquidität: |
|
a) |
[falls zutreffend einfügen] von ihrem PM-Konto auf ihr Konto außerhalb des PM; |
|
b) |
zwischen dem PM-Konto und den Unterkonten des betreffenden Teilnehmers sowie |
|
c) |
vom PM-Konto auf das Spiegelkonto eines Nebensystems zu übertragen. |
|
|
||
Die UDFS, das ICM Benutzerhandbuch und das „Benutzerhandbuch: Internetzugang für den Public-Key Zertifizierungsdienst“ |
||
Weitere Einzelheiten und Beispiele zur Erläuterung der oben aufgeführten Regeln sind in den UDFS und im ICM- Benutzerhandbuch, die von Zeit zu Zeit geändert und auf der Website der [Name der Zentralbank einfügen] sowie der TARGET2-Website (in englischer Sprache) veröffentlicht werden, sowie im „Benutzerhandbuch: Internetzugang für den Public-Key-Zertifizierungsdienst“ aufgeführt. |
||
|
||
…… |
Gebühren für direkte Teilnehmer |
|
1. |
Die monatliche Gebühr für die Verarbeitung von Zahlungsaufträgen in TARGET2 beträgt für direkte Teilnehmer 70 EUR Internetzugangsgebühr je PM-Konto zuzüglich 150 EUR je PM-Konto zuzüglich einer Transaktionspauschale (je Belastungsbuchung) in Höhe von 0,80 EUR; |
2. |
Direkten Teilnehmern, die eine Veröffentlichung ihres BIC im TARGET2-Directory ablehnen, wird eine zusätzliche monatliche Gebühr von 30 EUR je Konto berechnet. |
3. |
Je Teilnehmer werden für jedes PM-Konto bis zu fünf aktive Zertifikate durch die Zentralbank kostenlos ausgestellt und unterhalten. Die Zentralbank erhebt eine Gebühr von 50 EUR für jedes weitere aktive Folgezertifikat. Die Zentralbank erhebt eine jährliche Unterhaltsgebühr von 11 EUR für jedes weitere aktive Folgezertifikat. Aktive Zertifikate sind drei Jahre lang gültig. |
|
|
Rechnungsstellung |
|
4. |
Für direkte Teilnehmer gelten die folgenden Regeln für die Rechnungsstellung: Der direkte Teilnehmer erhält die Rechnung für den Vormonat mit Angabe der zu entrichtenden Gebühren spätestens bis zum fünften Geschäftstag des Folgemonats. Die Zahlung erfolgt spätestens bis zum zehnten Arbeitstag dieses Monats auf das von der Zentralbank angegebene Konto und wird dem PM-Konto des Teilnehmers belastet. |