Delta-Dokument für SRZ zu EBICS Version 1.1 vom 30. Juli 2010 (auf der Basis der EBICS-Version 2.42) Z ENTRALER KREDITAUSSCHUSS Seite:1
Inhalt 1 Grundlagen und Überblick... 3 1.1 Intention zur Verwendung von EBICS im SRZ-Verfahren... 3 1.2 Grundlegende Festlegungen zur Dokumentation... 3 1.3 Verwendete EBICS-Version und Grobüberblick über das Delta... 4 2 Festlegungen... 5 2.1 Unterschriftsklasse... 5 2.2 Vorabprüfung... 5 2.3 Ablauf der Autorisierung... 5 2.4 Migration von FTAM zu EBICS... 6 2.5 SRZ-Kundenprotokoll... 7 2.6 SEPA-Container im SRZ-Verfahren... 7 2.7 Zulässige Auftragsarten für das SRZ-Verfahren... 7 2.7.1 DTAUS-Format... 7 2.7.2 SEPA-Format... 8 2.7.3 Kontoinformationen... 8 2.7.4 Geldkartetransaktionen... 9 2.7.5 Sonstige Auftragsarten... 10 Z ENTRALER KREDITAUSSCHUSS Seite:2
1 Grundlagen und Überblick 1.1 Intention zur Verwendung von EBICS im SRZ-Verfahren Bisher bildete nur das FTAM-Verfahren die Grundlage für die technische Spezifikation der Kommunikation in den Richtlinien zur Beteiligung von Service-Rechenzentren am beleglosen Datenaustausch im Zahlungsverkehr sowie in den "Richtlinien für die Bereitstellung von Kontoauszugsinformationen zum Abruf durch Service-Rechenzentren mittels Datenfernübertragung (DFÜ)". Nicht nur vor dem Hintergrund, dass die FTAM-basierte Kommunikation durch den ZKA nicht mehr weiterentwickelt wird, sondern insbesondere, um die Service-Rechenzentren an den Vorteilen des neuen im Electronic Banking bereits etablierten - IP-basierten Kommunikationsverfahrens EBICS teilhaben zu lassen, werden nunmehr die relevanten Regelungen der EBICS-Spezifikation in die neuen, überarbeiteten Richtlinien aufgenommen. Auf diese Weise wird insbesondere auch das auf der Anwendungsebene bisher ausschließlich auf der Erteilung eines beleggebundenen Sammelauftrag basierende Autorisierungskonzept um das Konzept der Verteilten Elektronischen Unterschrift (VEU) ergänzt. Dieses ermöglicht eine zeitlich und räumlich unabhängige kundenübergreifende Autorisierung von Aufträgen. Service-Rechenzentren treten im EBICS-Verfahren in der Rolle eines EBICS-Kunden auf, der auf der Grundlage der SRZ-Vereinbarung für andere Kunden Aufträge einreicht und/oder Kontoinformationen abruft. Im Rahmen der Einreichung der Daten durch das Service-Rechenzentrum kommt dabei ausschließlich die in EBICS spezifizierte Unterschriftsklasse T ( Berechtigung nur zum Transport ) zur Verwendung. Der bzw. die entsprechenden EBICS-Teilnehmer des Kunden Service- Rechenzentrum dürfen daher nur die Unterschriftsklasse T besitzen. Zur Autorisierung der Aufträge kommen entweder ein papierhafter Sammelauftrag oder nachgelagerte elektronische Freigabeverfahren (z.b. Verteilte Elektronische Unterschrift) durch berechtigte Teilnehmer der Endkunden zum Einsatz. Von SRZ eingereichte Dateien enthalten in der Regel Aufträge für mehrere Mandanten des SRZ. Diese Dateien werden durch die entgegennehmende Stelle (Kreditinstitut, Zentrale Annahmestelle, Zentralstelle) auf die beauftragten Kreditinstitute und einzelne Endkunden aufgeteilt. 1.2 Grundlegende Festlegungen zur Dokumentation Bei der Verwendung von EBICS unter Beteiligung von Service-Rechenzentren (kurz: EBICS im SRZ- Verfahren) gelten grundsätzlich die in der Anlage 1 (EBICS-Spezifikation) des DFÜ-Abkommens beschriebenen Regeln und Definitionen. Darüber hinaus müssen jedoch einige, mitunter die EBICS- Spezifikation einschränkende Festlegungen für das SRZ-Verfahren getroffen werden. Um das SRZ-Verfahren und insbesondere dessen Weiterentwicklung und Fortschreibung von der Versionsführung der Anlage 1 des DFÜ-Abkommens zu entkoppeln, wurden diese Festlegungen in Z ENTRALER KREDITAUSSCHUSS Seite:3
dem vorliegenden Dokument (kurz: Delta-Dokument) beschrieben. Es wird dabei auf eine konkrete Version der EBICS-Spezifikation verwiesen. Zielsetzung ist, das Delta-Dokument bei einem Versionswechsel in EBICS immer kurzfristig nachgelagert anzupassen. Erforderlich ist dann immer: 1. Anpassung des Verweises auf die EBICS-Version, auf die Bezug genommen wird, in Kapitel 1.3 ( Verwendete EBICS-Version und Grobüberblick über das Delta ) 2. ggf. Überarbeitung der im Delta-Dokument beschriebenen Festlegungen, falls der Versionswechsel in EBICS Auswirkungen auf das SRZ-Verfahren hat. 1.3 Verwendete EBICS-Version und Grobüberblick über das Delta Dieses Delta-Dokument nimmt Bezug auf die EBICS-Version 2.4.2 und die zugehörigen EBICS-Schemas H003/S001. Daraus ergeben sich im Grobüberblick folgende Festlegungen für das SRZ-Verfahren: Festlegungen hinsichtlich Kapitel in EBICS 2.4.2 Siehe Kapitel im Delta- Dokument Beschreibung 3.5.1 2.1 Service-Rechenzentren wird grundsätzlich nur die Unterschriftsklasse T zugeordnet. 3.6, 5.3 2.2 Die Vorabprüfung ist nicht vorgesehen. 3.12 2.3 Modifikationen zum Ablauf der Autorisierung im EBICS-Verfahren 4.8 2.4 Keine Migration von FTAM auf EBICS 10.2 2.5 Kundenprotokoll für SEPA-Zahlungen im SRZ-Verfahren 13 2.7 Die für das SRZ-Verfahren zulässigen Auftragsarten Z ENTRALER KREDITAUSSCHUSS Seite:4
2 Festlegungen 2.1 Unterschriftsklasse Die Auftragsdaten der Sendeaufträge MÜSSEN vor dem Versand signiert, d.h. mit einer EU versehen werden. Vom Service-Rechenzentrum eingereichte Sendeaufträge werden grundsätzlich mit einer Transport- Unterschrift (Unterschriftsklasse T) signiert. Zur nachträglichen elektronischen Autorisierung steht dem Kunden z.b. die Verteilte Elektronische Signatur (VEU; siehe Kapitel 8 der EBICS- Spezifikation) zur Verfügung. Unterschriftsberechtigungen des Typs T werden dem Service-Rechenzentrum bzw. den EBICS- Teilnehmern des Service-Rechenzentrums pauschal zugewiesen. Die vom Service-Rechenzentrum eingesetzte Transportunterschrift dient ausschließlich zur Absicherung der Einreichung von Aufträgen, die das Service-Rechenzentrum (SRZ) im Auftrag seiner Kunden gemäß SRZ-Vereinbarung durchführt. Die Transportunterschrift ist in diesem Fall nur dem SRZ (Teilnehmer innerhalb des SRZ) zugeordnet. Sofern mit dem Endkunden eine EBICS-Autorisierung mittels VEU vereinbart wurde, so muss der Endkunde dies mit seiner eigenen Kunden- und TeilnehmerID (UserID) durchführen. 2.2 Vorabprüfung Die Vorabprüfung steht in der Abwicklung des Zahlungsverkehrs unter Einschaltung von Service- Rechenzentren nicht zur Verfügung. Daher entfallen für das SRZ-Verfahren die Kapitel 3.6 und 5.3 der EBICS-Spezifikation. 2.3 Ablauf der Autorisierung Die in Kapitel 3.12 der EBICS-Spezifikation beschriebenen Varianten der Autorisierung sind für das SRZ-Verfahren nur eingeschränkt gültig. Für die Autorisierung der Aufträge im SRZ-Verfahren gelten folgende Bestimmungen: Die Einreichung der Nutzdaten (Auftragsdaten) der Endkunden (Sammeldatei) erfolgt zusammen mit einer Transport-EU (Unterschriftsklasse T) durch einen Sendeauftrag des Service-Rechenzentrums mit den Auftragsattributen DZHNN. Die Zentralstelle bzw. eine von ihr autorisierte technische Annahmestelle prüft die Transport-EU des Service Rechenzentrums unmittelbar nach Empfang der Auftragsdaten der Endkunden gemäß den in EBICS unterstützten Signaturverfahren. Bei negativem Prüfergebnis wird die gesamte Datei mit den Auftragsdaten der Endkunden von der Zentralstelle bzw. der autorisierten technischen Annahmestelle abgelehnt (gelöscht) und unmittelbar das negative Prüfergebnis in das für das Service-Rechenzentrum bestimmte Kundenprotokoll gemäß der EBICS-Spezifikation protokolliert. Das Service-Rechenzentrum ist verpflichtet, sich durch zeitnahes Abholen des Kundenprotokolls vom Status der Bearbeitung der eingereichten Auftragsdaten Z ENTRALER KREDITAUSSCHUSS Seite:5
zu informieren. Eine Konto- und/oder Limitprüfung erfolgt im Rahmen der Prüfung der Transport-EU des Service Rechenzentrums nicht. Bei positivem Prüfergebnis wird die gesamte Datei mit den Auftragsdaten der Endkunden von der Zentralstelle bzw. der autorisierten technischen Annahmestelle der Weiterverarbeitung zugeführt und unmittelbar das positive Prüfergebnis in das für das Service-Rechenzentrum bestimmte Kundenprotokoll gemäß der EBICS-Spezifikation protokolliert. Das Service-Rechenzentrum ist verpflichtet, sich durch zeitnahes Abholen des Kundenprotokolls vom Status der erfolgreichen Dateiübertragung und der Prüfung der Transportunterschrift der eingereichten Auftragsdaten zu informieren. Durch die positive Prüfung der Transport-EU des Service-Rechenzentrums ist keine Autorisierung der Auftragsdaten der Endkunden erfolgt. Eine Autorisierung durch die berechtigten Endkunden erfolgt nachträglich. Die Autorisierung durch die Endkunden kann je nach grundsätzlicher Vereinbarung zwischen Kreditinstitut und Endkunde unterschiedlich erfolgen: 1. Autorisierung durch Elektronische Unterschrift(en) gemäß EBICS-Spezifikation Die Einreichung der noch ausstehenden bankfachlichen EU(s) erfolgt unmittelbar durch den (unterschriftsberechtigten) Endkunden, d.h. durch dessen unterschriftsberechtigte EBICS- Teilnehmer mit Hilfe der Auftragsart HVE gemäß der EBICS-Spezifikation. Hierzu muss zwischen Endkunde und Kreditinstitut eine EBICS-Vereinbarung bestehen. 2. Autorisierung außerhalb des EBICS-Verfahrens durch papierhaften Sammelauftrag Sonstige Autorisierungsverfahren können zwischen Endkunde und Kreditinstitut bilateral vereinbart werden. Jede logische Datei (Sammler) bezieht sich auf genau eine Kontoverbindung. Die Art der Autorisierung wird entsprechend der jeweiligen Kundenvereinbarungen je Kontoverbindung auf den Systemen des Kreditinstituts hinterlegt. Sofern vom Kunden gewünscht, erfolgt die Weiterleitung der Daten zur Freigabe auf Basis eines Datenbegleitzettels. Die Autorisierung durch Elektronische Unterschrift kann gewählt werden, wenn zu dem betreffenden Kunden (Kontoinhaber) eine EBICS- Vereinbarung existiert und Teilnehmer mit entsprechender Unterschrift administriert sind. Die Bereitstellung der Auftragsdaten für die elektronische Signatur (Einstellung in VEU) wird im jeweiligen Kundenprotokoll des betreffenden Kunden eingetragen. 2.4 Migration von FTAM zu EBICS Die Migration betrifft nur vom Kreditinstitut freigeschaltete bankfachliche FTAM-Schlüssel, die in EBICS weiter verwendet werden sollen. Dies ist für das SRZ-Verfahren nicht relevant, da bisher gemäß SRZ-Verfahren nur eine papierhafte Autorisierung mittels Sammelauftrag vorgesehen war. Daher entfällt für das SRZ-Verfahren das Kapitel 4.8 der EBICS-Spezifikation. Z ENTRALER KREDITAUSSCHUSS Seite:6
2.5 SRZ-Kundenprotokoll Für die Protokollierung von Einreichungen im SEPA-Datenformat (vgl. Anlage 2a, Kapitel 10.2.) gilt folgende Besonderheit. Da SEPA-Zahlungsdateien im SRZ-Verfahren ohne bankfachliche Elektronische Unterschriften eingereicht werden, wird pro im Container enthaltener logischer Datei immer der Hashwert im Kundenprotokoll ausgegeben. Die anderen Kundenprotokollvarianten für SEPA-Zahlungen des Kapitels 10.2 gelten somit nicht. 2.6 SEPA-Container im SRZ-Verfahren Im SRZ-Verfahren ist bei SEPA-Zahlungen immer der SEPA-Container zu verwenden, dies wird in Anlage 4c (Delta-Dokument für SRZ zum SEPA-Zahlungsverkehr) beschrieben. Die Version 2.4 der Anlage 3 (Datenformatstandards) des DFÜ-Abkommens wurde zum 1. November 2009 bezüglich der SEPA-Datenformate an die EPC Implementation Guidelines 3.2 angepasst. Insbesondere ist nun die Einreichung von Überweisungen bzw. Lastschriften für mehrere Konten und/oder Ausführungstermine (d.h. mehrere Sammler) in einer pain-nachricht/datei (genannt EPC/ZKA-Variante) die Standardvariante. Ein Container kann eine oder mehrere pain-nachrichten enthalten. Abweichend hiervon gilt im SRZ-Verfahren, dass eine pain-nachricht genau einen Sammler (PmtInf- Block) enthält (Details siehe Anlage 4c). Selektionskriterium für eine Weiterleitung der einzelnen pain-nachrichten nach Auflösung des Containers ist der BIC des Auftraggeberkontos (kommt pro pain-nachricht nur einmal vor, da nur ein Sammler erlaubt). 2.7 Zulässige Auftragsarten für das SRZ-Verfahren Für das SRZ-Verfahren gelten ausschließlich die nachfolgend beschriebenen Auftragarten. 2.7.1 DTAUS-Format DTV*) Zahlungsverkehrsdateien von Service-Rechenzentren senden DTAUS0 ECS Senden electronic-cash Lastschriftdatei DTAUS0 Sofern die Autorisierung durch den Endkunden mittels Verteilter Elektronischer Unterschrift erfolgt, so wird die vom Service-Rechenzentrum mittels Auftragsart DTV eingereichte Sammeldatei nach Endkunden aufgesplittet und unter Verwendung der Auftragsart IZX 1 (Einstellung einer vom SRZ 1 Die Verwendung einer separaten Auftragsart IZX ermöglicht die - Administration von Teilnehmern des Endkunden, welche nur SRZ-Aufträge unterschreiben können, jedoch keine Aufträge einreichen dürfen - klare Kennzeichnung im Kundenprotokoll und der VEU, dass es sich um von einem SRZ eingereichte Aufträge handelt - Vermeidung von doppelten Auftragsnummern - Differenzierung beim kontoführenden Institut zwischen SRZ-Aufträgen und vom Endkunden eingereichte Aufträge (Statistik) ZENTRALER KREDITAUSSCHUSS Seite:7
eingereichten DTAUS0-Datei in die VEU) oder DTV*) in das EBICS-System des kontoführenden Instituts eingestellt. *) nach bilateraler Vereinbarung ist auch IZV (Inlandszahlungsverkehrsdatei senden), MCV und MC4 (IZV-Datei im Magnetbandformat senden) zulässig 2.7.2 SEPA-Format CCS (Customer Credit Transfer Service-RZ) CDS (Customer Direct Debit Service-RZ) C2S (Customer B2B Direct Debit Service-RZ) Senden von SEPA-Überweisungen in einem Container durch Service-Rechenzentrum Senden von SEPA-Basis-Lastschriften in einem Container durch Service-Rechenzentrum Senden von SEPA-Firmen-Lastschriften in einem Container durch Service-Rechenzentrum XML-Container mit pain.001.002.03 XML-Container mit pain.008.002.02 XML-Container mit pain.008.002.02 Sofern die Autorisierung durch den Endkunden mittels Verteilter Elektronischer Unterschrift (VEU) erfolgt, so wird die vom Service-Rechenzentrum eingereichte Sammeldatei nach Endkunden aufgesplittet und unter Verwendung der folgenden Auftragsarten in das EBICS-System des kontoführenden Instituts eingestellt. SRZ Auftragsart CCS CDS C2S Auftragsart zur Einstellung in die VEU CCX (Einstellung von einem SRZ eingereichten SEPA- Überweisungen in die VEU) oder CCS CDX (Einstellung von einem SRZ eingereichten SEPA- Basislastschriften in die VEU) oder CDS C2X (Einstellung von einem SRZ eingereichten SEPA- Firmenlastschriften in die VEU) oder C2S 2.7.3 Kontoinformationen Z ENTRALER KREDITAUSSCHUSS Seite:8
STA Abholen Swift-Tagesauszüge MT940 C52 C53 C54 Bank To Customer-Account Report Bank To Customer-Statement Report Bank To Customer-Debit Credit Notification Zip-Datei mit 1-n Nachrichten des Typs camt.052.001.02 (gemäß Anlage 3 des DFÜ-Abkommens) Zip-Datei mit 1-n Nachrichten des Typs camt.053.001.02 (gemäß Anlage 3 des DFÜ-Abkommens) Zip-Datei mit 1-n Nachrichten des Typs camt.054.001.02 (gemäß Anlage 3 des DFÜ-Abkommens) Neben dem MT 940, können sofern das kontoführende Institut dies unterstützt, die drei auf ISO 20022 basierenden Cash Management-Nachrichten (camt) für Kontoauszugsinformationen verwendet werden. 2.7.4 Geldkartentransaktionen GBZ GRC Einreichen von BZAHL-Dateien (Geldkarte-Transaktionsdateien) Abholen von Rückmeldedateien (Ergebnis der Verarbeitung von Geldkarte-Transaktionsdaten) Formatspezifikation siehe Schnittstellenspezifikation für die ZKA-Chipkarte, Geldkarte, Händlersysteme, Version 5.0, 23.11.2004, Kapitel 2.5 CSV-Format 2 2 Die Spezifikation des CSV-Formats ist in Arbeit. Z ENTRALER KREDITAUSSCHUSS Seite:9
2.7.5 Sonstige Auftragsarten Kennung Text HAA Abrufbare Auftragsarten abholen Optional HCA HCS Änderung der Teilnehmerschlüssel für Authentifikation und Verschlüsselung senden Änderung der Teilnehmerschlüssel für EU, Authentifikation und Verschlüsselung senden Optional / Verpflichtend zu unterstützen Verpflichtend Verpflichtend HEV Unterstützte EBICS-Versionen abrufen Verpflichtend HIA Übermittlung der Teilnehmerschlüssel für Authentifikation und Verschlüsselung im Rahmen der Teilnehmerinitialisierung Verpflichtend HKD Kunden- und Teilnehmerdaten des Kunden abholen Optional HPB Transfer der öffentlichen Bankschlüssel (Abholen) Verpflichtend HPD Bankparameter abholen Verpflichtend HTD Kunden- und Teilnehmerdaten des Teilnehmers abholen Optional HVE VEU-Unterschrift hinzufügen (durch den Kontoinhaber) Verpflichtend Die folgenden Auftragsarten dienen dem Schlüsselmanagement bzw. der Protokollierung: INI PTK PUB SPR Passwort-Initialisierung senden Abholen Kundenprotokoll Senden Public Key zur Unterschriftenverifizierung Sperren der Zugangsberechtigung Public Key des Kunden für die EU (siehe EBICS- Spezifikation, Kapitel 14) Siehe Kapitel 10 der EBICS-Spezifikation und Kapitel 2.5 dieses Dokuments Public Key des Kunden für die EU (siehe EBICS- Spezifikation, Kapitel 14) Übertragung einer EU-Datei mit der Signatur für eine Dummy-Datei, die nur ein Leerzeichen enthält Z ENTRALER KREDITAUSSCHUSS Seite:10